Think about this:
Use a encrypted loopback. To get the key without storing it on the
computer:
Get some kind of unique combined fingerprint of the computer and hd
through a c/c++ programmed algorithm and sending them to a secure
"password" server using some kind of (variable server provided salt)
hashing with md5. The server can encrypt the loopback KEY using the
fingerprint as a passphrase and send it sniff safe.
Isn't this going to safe enought for some cases?
--
Koba
On Thu, 5 Jun 2003 12:16:21 -0300, Peter Cordes <[EMAIL PROTECTED]>
wrote:
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.
