On Fri, Feb 01, 2008 at 11:49:58AM +0100, Michael wrote: > Hello, > > I recently had an idea how to improve the security of encrypted devices. > > Currently I am using mount_vnd on my X41 notebook and also another > system which works really nice. Playing around a bit with mount_vnd and > after changing the sources a little it is even possible to decrypt and > automount a partition just by inserting an USB stick. The passphrase is > compiled in, the saltfile is on the USB stick, the number of rounds is > in the script which gets run from /etc/hotplug/attach. > > > Before I get to my real question... the mount_vnd option "rounds". What > does it really do and which would be a good value? Does it depend? if > so, on what? The size of the saltfile or length of the password? >
I once tried to reach the RFC for PKCS #5 PBKDF2 about this, and as I remember it, the "rounds" is used to create more computational work for an attacker. I do not really think the saltfile or password sizes should affect this much, rather more the speed of current and future processors. So you can probably set it as high as you can whithout until it starts affecting the init time of the vnd device too much. > > Ok, back to topic. I was thinking about to use a saltfile which consists > of the keyfile on the USB stick, but also of some checksum or some other > information gathered from the hardware, so it would only be possible to > decrypt the partition on the same hardware, so even if you steal or copy > the HDD and the USB stick, decrypting would be impossible. > Interesting idea, but I wonder if it is necessary... Again, if I remember correctly; if your salt is random enough, it need not be secret. It is just used to randomize your password. Attackers come with pre-calculated dictionaries and try to crack your password, and if the salt is unknow to the attacker until he/she gets into the system he/she will have to re-calculate the whole dictionary with the now known salt and rounds. And if the rounds is high enough re-calculating a dictionary will not be feasible. > Now I am looking for a way to gather unique information about the > system. The type of information must exist on every system running > OpenBSD, so something like "hw.serialno" can't be used. Also, the > information should have the same format and everything even after > upgrading to a newer version of OpenBSD, so no dmesg. "pcidump -v" also > won't work because the output of two equal ALIX is 100% the same. > > I was thinking about the MAC address of the first network card, or even > all existing network cards in the system, but that information should be > too easy to come by. I would go for using the MACs, but I would like to > know if anyone here got any better ideas first. :-) > > > Thanks in advance, > > Michael -- / Raimo Niskanen, Erlang/OTP, Ericsson AB
