On Mon, Mar 12, 2007 at 05:22:21PM +0100, Sebastian Bork wrote: > Andreas Hasenack wrote: > >I thought about some stuff: > >- use something in the environment as the secret. Like some MAC > > addresses of the local switches and routers, some wireless SID, etc. > > This is insecure. If someone has access to the machine (to steal it), > this person will also be able to read out the data you use as secret. > > >- use a complex scheme with the password stored on a remote server which > > would, after a series of validations, connect back to the booting > > server to mount the fs for it. > > You could use a server in your LAN which only accepts requests from the > inside of this LAN and validates additional things like packet roundtrip > time etc. before giving the secret to your host - but your attacker > could just boot the machine before he carries it away and acquire the > key by sniffing. > > So if your attacker has more than a few seconds to mount his attack, the > best solution would be to only give the secret if e.g. root has entered > a password on the prompt of the validating server in the last n minutes > prior to booting the machine with your crypto fs. If not, write a Hmm, maybe I can work with that. The validating server in my scenario would indeed be better protected and far away. So this scheme would mean that all boots are sort of "requested" before being done. Not a 100% unattended, but a compromise. --------------------------------------------------------------------- dm-crypt mailing list - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
