Re: [dm-crypt] encrypted root: prevent / detect tampering with kernel / initrd

[Olivier Sessink <oliviersessink@gmail.com>]

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