On Thu, Jun 05, 2003 at 09:30:51AM +0200, Luis Gomez - InfoEmergencias wrote: > We'd like to protect that content, so that even if someone unplugs the > machine > and connects the HD to another Linux box, they can't access that information. > Of course it's difficult to do, but we think there might be a possibility to > achieve success.
Against a sophisticated attacker, it's totally impossible to do what you want. They could run bochs an boot the x86 emulator from the new hard drive, and examine the contents of the system's memory whenever they wanted. Obviously, that's not easy, since you have to figure out where the encryption key is in memory (if that's what you used to protect the drive). From a practical point of view, if you just want to defend against casual attackers, encryption might do the trick. Use an encrypted filesystem, and hide the key somewhere in the kernel or something else outside the encrypted FS. When the system boots, it gets the key and uses it to mount the drive. It you add some code to the kernel to hide an obfuscated key in memory, and maybe make it available by reading /proc/sekret, or a char device, you could have the system boot up without requiring a password (which would be no good, because whoever has the password could use it when they move the drive to another machine.) Err, just thought of a problem with this: The kernel is GPLed, so you are required to give a copy of the source to anyone with a copy of the binary. Given that, they'd know where to look in the kernel binary for the key, even if the source you supplied has the secret key changed to something else. You'd have to embed the secret key into something else. (Linus apparently has no problem with binary-only kernel modules, so that's an option!) The trick to all this is not to give away where to look for the key in any boot scripts or initial ramdisk that could be read by putting the disk in another machine. A line like /bin/gen-password | mount -o loop ... pretty much gives the game away. I guess the best way really is to stash stuff in the kernel, since then you'll at least know who's asking for the source. Still, a script reading from /proc/sekret is a giveaway. If someone put the drive in another machine, they could edit the boot scripts so that it printed out the password. Then, you could boot from the drive, get the password, then put the drive back into another computer and mount the encrypted filesystem. So, all you can really do is make things tricky for people who aren't experts, and hopefully don't find this message with google. :) Here's what I suggest, after having thought about it while writing this message: Use an initrd. Scramble it by XORing it with a pattern[1]. Hack the kernel so it descrambles it at boot time. Put the password in the initrd, or in the kernel. (Even if you put the password in the kernel, you want to hide the initrd, because it will have mount(8) getting a password from /proc/sekret, or something.) Use some sort of encrypted filesystem on the hard drive. [1]using strong encryption wouldn't matter, because it's just as easy to disassemble the part of the kernel that unscrambles it to get the key is the same amount of work as finding out what it's XORed with, unless they figure it out from known-plaintext (the GZIP header). Make sure your pattern's not too short, so they have to disassemble the kernel or ask you for the source. If you know who's asking for the source, that's much better than not knowing who's hacking your work. -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , s.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC
