Arno Wagner wrote:
On Mon, Dec 28, 2009 at 09:28:43PM +0100, Olivier Sessink wrote:
Hi all,
I was wondering if there are some 'common' ways to prevent tampering
with the unencrypted kernel and initrd in the case of an encrypted root
filesystem?
No. Any "common" way would automatically become ineffective. Your
only chance is to do something unexpected and hence uncommon.
true.
If somebody has access to your computer they could change
the initrd and kernel and make your encryption useless (e.g. store the
password in /boot, or send it over the network, etc. etc.). It shouldn't
be too hard to make this at least very difficult.
It is theoretically impossible and practically very hard.
That sentence was incorrect, read "make this at least very difficult to
do undetected". I know there is no way to stop the password getting
stolen, but it should be pretty hard to do this undetected.
I was thinking along the lines of:
- check a checksum of the MBR and partition table
=> Fake the check
that is practically very hard. As attacker you only have access to to
the unencrypted /boot the first time. So even if you know there will be
an MBR check, you have to change the kernel to provide the original MBR
data when the first sectors of the harddisk is requested by some binary.
For the MBR this might be feasible, but for the complete /boot device
this might become more problematic. The attacker cannot change the
binary that does the check because the attacker doesn't know which one
it is, and he doesn't know what it looks like (it's in the encrypted
image). Too hard for a script kiddie. Or am I overlooking something obvious?
[..]
With an attacker competent enough to do this type of tampering
google and follow the recipe how to change the initrd?
you are screwed as long as you rely on the on-disk information.
with a determined attacker (does not need to be a hacker) you are
screwed anyway (tempest attacks, physical keyloggers, camera's, drugs,
blackmail etc.). Encryption doesn't matter if they want your data.
But here is something easy: Use an external boot medium for
verification, e.g. a memory-stick installed Knoppix with some
custom check script you call manually or automatically. Keep
the external checker system separate from the laptop. With
that the ideas you outlined above would work. You can, e.g.,
compary MBR and files in /boot to checksums or good copies.
I currently have an 8GB SuperTalent Stick with the Knoppix
DVD installed on it in my vallet. Adding packages and your own
data/programs is possible as it has a writable filesystem
(writes get ovelayed on top of the read-only DVD image).
I am aware of this concept, but it just moves the problem to the usb
image (somebody sneaks into your hotel room at night ....). And again if
somebody did change the usb image there is no way you are going to find
out, even if they did something that could have been detected very
easily such as a changed initrd. I don't expect our "regular users" to
carry a very good safe with them day and night (and a safe can be picked
as well).
Olivier
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
