Re: Keeping files away from users
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(peter@llama.nslug.n , 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
Reply to: