Solved Question about disk encryption: Why the master key always gets stored on the encrypted disk?

sku1d

sku1d

I have read a lot about gbde, geli and dm-crypt under linux, but a question remains: Why would iI store my master key on the disk? Seriously! Anybody could rip the metadata off the disk in no time and brute force the password in a cluster without even having additional encrypted sample data laying around. But wait... How can the cluster determine, that it found a correct passphrase? Well... How the metadata looks like depends on the encryption framework used, but all encrypt their master keys with a user key and I cannot tell whether or not the encrypted master key contains anything predictable by itself, because that seems to be undocumented. So I am concerned that some frameworks have metadata in their encrypted master keys allowing attackers to quickly check many passwords against those.

What a bummer that it does not seem to be possible to put those metadata on another drive under freebsdFreeBSD. Maybe one could use some kind of spanning/jbod devices and use them with geli to overcome this, because geli puts its meta data in the last sector of the disk. I’m going to try that while waiting for an answer.
 
sku1d said:
What a bummer that it does not seem to be possible to put those metadata on another drive under FreeBSD.
Click to expand...

You can. Or rather, you can store your keyfile(s) on a separate drive; by default, the backup metadata is stored in /var/backups, which (if you're doing it right) is also encrypted. It is also possible to use multiple keyfiles in separate locations to generate a single key. At the end of the day, though, what it comes down to is (a) you almost never need anywhere near as tight a security setup as you might like to think; and (b) the only truly secure system is the one no human on Earth can possibly access. Which is what you'll get if you start scattering keys all over the place.
 
Hi! I have recently be too busy to spend much time on this topic, but during the past days I managed to watch that video shepherdAZ meantioned and which I found interesting (thanks!) even so it does not really tell how that was done.

Also thanks to ANOKNUSA for pointing out, that this is getting a bit paranoid. That might be true, but I want it like that ;)

In the meantime my personal FreeBSD love story continued: I figured out, that one can use mdconfig -f <file> to create false devices called /dev/mdX, which can then be concatenated with GEOM by using geom concat create <name> /dev/daX /dev/mdX (where daX is a disk drive to be encrypted, which also gets called 'provider' in this context) and finally initialized with geli using geli init /dev/concat/<name>. It is important, that <file> exists on a removable drive and is big enough to hold the meta data. So it must be at least as big as one sector is on /dev/daX: fdisk /dev/daX; truncate -s 4096 <file> or something like that. I verified all steps with hexedit and I will report back how long it works before blowing up in my face.
 
If you are really concerned, it is perfectly possible to move the entire /boot filesystem onto a USB stick that you can hang around your neck and therefore actually encrypt the entire hard disk in the computer, with cryptographic verification as well as encryption. "Full" disk encryption typically leaves unencrypted boot files that could be maliciously modified (in FreeBSD's case, with GELI the kernel is left unencrypted). Of course, who is to say your hardware hasn't been attacked, or that someone has introduced a malicious bug into FreeBSD or one of the applications you are running? :) In my humble opinion, if someone with enough determination wants to get you, they probably will.
 
One of my favourites from xkcd.com:
security.png
 
You must log in or register to reply here.
Back
Top