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

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

[Olivier Sessink]

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? 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.

I was thinking along the lines of:
- check a checksum of the MBR and partition table
- check a checksum of the complete /boot filesystem
- check the pointers in the kernel system call table (detects many rootkits)
- check for virtualization (any virtual rootkits)
- ...? any better ideas how to detect tampering?

Obviously all of this should be done by a binary inside the encrypted 
filesystem - everything in /boot (kernel and initrd) is not to be 
trusted. That means we can only warn the user after the password is 
probably gone already, but this is better than nothing.

Any comments, ideas or links  ?

regards,
Olivier

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

[Luca Berra]

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? 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.

I'm sorry if anyone has physical access to the machine, you lose.
there is nothing you can do to prevent it.
If your laptop is stolen and later found, i would not trust typing my
password again booting from that disk. I would boot from a rescue media
or install the disk in another machine and recover the data.
What you suggest only creates a false sense of security and should be
avoided.

L.
-- 
Luca Berra -- bluca@comedia.it
         Communication Media & Services S.r.l.
  /"\
  \ /     ASCII RIBBON CAMPAIGN
   X        AGAINST HTML MAIL
  / \

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

[Olivier Sessink]

Luca Berra 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? 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.
> 
> I'm sorry if anyone has physical access to the machine, you lose.
> there is nothing you can do to prevent it.
> If your laptop is stolen and later found, i would not trust typing my
> password again booting from that disk. I would boot from a rescue media
> or install the disk in another machine and recover the data.
> What you suggest only creates a false sense of security and should be
> avoided.

yes you are 100% right from a perfect security viewpoint. However, we're 
looking at a "regular user" deployment, and we know that our regular 
users are not going to look after their devices as good as most IT 
security professionals will do (they might even carry their password in 
their wallet, or tell the password over the phone). So our aim is not 
100% perfect security, but just "make it (a lot) harder" to get to the 
data.

The data on the devices is interesting enough for a simple hack, but not 
interesting enough for a very complicated attack (or a physical 
keylogger or tempest attack). So if we can avoid the simple attacks we 
have improved the overall security.

So in our not-so-perfect world we will loose from a determined hacker 
anyway. But perhaps we can be safe from the script kiddies.

Olivier

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

[Heinz Diehl]

On 28.12.2009, Olivier Sessink wrote: 

> yes you are 100% right from a perfect security viewpoint. However,
> we're looking at a "regular user" deployment, and we know that our
> regular users are not going to look after their devices as good as
> most IT security professionals will do (they might even carry their
> password in their wallet, or tell the password over the phone). So
> our aim is not 100% perfect security, but just "make it (a lot)
> harder" to get to the data.

Anybody who has the skills and the motivation to modify your kernel/initrd
is far from being your "regular user", and is most likely able and has the
expertise to do other things to your machine as well.

"Please repeat with me: there is no way to avoid or detect backdoors if
physical access to the machine has ever been granted." (Werner Koch on
gnupg-users 19.02.2009 on exactly the same topic).

			     

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

[Olivier Sessink]

Heinz Diehl wrote:
> On 28.12.2009, Olivier Sessink wrote: 
> 
>> yes you are 100% right from a perfect security viewpoint. However,
>> we're looking at a "regular user" deployment, and we know that our
>> regular users are not going to look after their devices as good as
>> most IT security professionals will do (they might even carry their
>> password in their wallet, or tell the password over the phone). So
>> our aim is not 100% perfect security, but just "make it (a lot)
>> harder" to get to the data.
> 
> Anybody who has the skills and the motivation to modify your kernel/initrd
> is far from being your "regular user", and is most likely able and has the
> expertise to do other things to your machine as well.

I'm not so sure about that. Most script kiddies can modify an initrd 
(just google for 'dm-crypt evil maid' and you'll find at least one 
script-kiddie level recipe). But I don't think there are many script 
kiddies that can do a TEMPEST attack or install a physical keylogger in 
a laptop.

> "Please repeat with me: there is no way to avoid or detect backdoors if
> physical access to the machine has ever been granted." (Werner Koch on
> gnupg-users 19.02.2009 on exactly the same topic).

add to that: "encryption is not perfect if your house is not TEMPEST 
proof or burglar proof, or if you can be blackmailed, or if you have 
children that can be kidnapped, or if they simply drug you, etc. etc."

If somebody is really determined to get to your data they will succeed, 
skilled or not skilled. I suppose everybody on this list knows this one: 
http://imgs.xkcd.com/comics/security.png

Olivier

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

[[lesh] Ivan Nikolic]

[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]

you can set bios password for every boot (if you trust your bios, this would mean that for any 
software tampering your machine has to be taken appart, disk unplugged, etc. but most bioses had a lot of backdoor
passwords few years back, don't know how it is now, but not very nice I suppose)

so, to be extra sure, somekind of sum of unencrypted files is nice, yes.
that would mean that person would have to get past bios, boot another system, modify your kernel to make your hashing 
program lie to you (know in advance that you use one, and which) and that is hard enough for me:)
(and is the most feaseable software hack idea those "if there is phisical access game over" people are talking about)

if you are that paranoid, you cary your initrd/kernel on usb with you.

btw,
those problems can be addressed with an evil child of drm, chain of trust.
http://theinvisiblethings.blogspot.com/2009/01/why-do-i-miss-microsoft-bitlocker.html


I'm gonna setup the hash thing right now :)


* Heinz Diehl (htd@fancy-poultry.org) wrote:
> On 28.12.2009, Olivier Sessink wrote: 
> 
> > yes you are 100% right from a perfect security viewpoint. However,
> > we're looking at a "regular user" deployment, and we know that our
> > regular users are not going to look after their devices as good as
> > most IT security professionals will do (they might even carry their
> > password in their wallet, or tell the password over the phone). So
> > our aim is not 100% perfect security, but just "make it (a lot)
> > harder" to get to the data.
> 
> Anybody who has the skills and the motivation to modify your kernel/initrd
> is far from being your "regular user", and is most likely able and has the
> expertise to do other things to your machine as well.
> 
> "Please repeat with me: there is no way to avoid or detect backdoors if
> physical access to the machine has ever been granted." (Werner Koch on
> gnupg-users 19.02.2009 on exactly the same topic).
> 
> 			     
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
PGP 0x96085C00 http://lesh.sysphere.org

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Olivier Sessink]

Heinz Diehl wrote:
> On 28.12.2009, Olivier Sessink wrote: 
> 
>> yes you are 100% right from a perfect security viewpoint. However,
>> we're looking at a "regular user" deployment, and we know that our
>> regular users are not going to look after their devices as good as
>> most IT security professionals will do (they might even carry their
>> password in their wallet, or tell the password over the phone). So
>> our aim is not 100% perfect security, but just "make it (a lot)
>> harder" to get to the data.
> 
> Anybody who has the skills and the motivation to modify your kernel/initrd
> is far from being your "regular user", and is most likely able and has the
> expertise to do other things to your machine as well.
> 
> "Please repeat with me: there is no way to avoid or detect backdoors if
> physical access to the machine has ever been granted." (Werner Koch on
> gnupg-users 19.02.2009 on exactly the same topic).

I seem to be unable to find this discussion in
http://lists.gnupg.org/pipermail/gnupg-users/2009-February/date.html

are you sure about this date?

Olivier

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

[Milan Broz]

On 12/29/2009 01:25 PM, Olivier Sessink wrote:
> Heinz Diehl wrote:
>> On 28.12.2009, Olivier Sessink wrote: 
>> "Please repeat with me: there is no way to avoid or detect backdoors if
>> physical access to the machine has ever been granted." (Werner Koch on
>> gnupg-users 19.02.2009 on exactly the same topic).
> 
> I seem to be unable to find this discussion in
> http://lists.gnupg.org/pipermail/gnupg-users/2009-February/date.html
> 
> are you sure about this date?

http://lists.gnupg.org/pipermail/gnupg-users/2009-February/035776.html

Milan

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

[Arno Wagner]

On Tue, Dec 29, 2009 at 12:11:58AM +0100, Heinz Diehl wrote:
> On 28.12.2009, Olivier Sessink wrote: 
> 
> > yes you are 100% right from a perfect security viewpoint. However,
> > we're looking at a "regular user" deployment, and we know that our
> > regular users are not going to look after their devices as good as
> > most IT security professionals will do (they might even carry their
> > password in their wallet, or tell the password over the phone). So
> > our aim is not 100% perfect security, but just "make it (a lot)
> > harder" to get to the data.
> 
> Anybody who has the skills and the motivation to modify your kernel/initrd
> is far from being your "regular user", and is most likely able and has the
> expertise to do other things to your machine as well.
> 
> "Please repeat with me: there is no way to avoid or detect backdoors if
> physical access to the machine has ever been granted." (Werner Koch on
> gnupg-users 19.02.2009 on exactly the same topic).

I don't agree. But you have to think outside of the box and use a
separate, uncompromised boot medium that the attacker did not have
access to. With only the potentially modified system, you would
have to reverse-engineer all software on it, which is infeasible
in practice, even more so without an additional external system 
to do the analysis on. 

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Heinz Diehl]

On 29.12.2009, Arno Wagner wrote: 

> I don't agree. But you have to think outside of the box and use a
> separate, uncompromised boot medium that the attacker did not have
> access to.

Sorry, but I can't see how this would help. The attacker installs a
hardware keylogger and just doesn't care.

It's a matter of concept: before a security solution is implemented, a
risk analysis has to be done. To have /boot on an external medium or to
store checksums of the unencrypted files on a CD/DVD/stick is fine, as
long as the risk it carries is accepted, along with the worst case scenario
under given circumstances. It's up to the operator.

For total security, the machine is regarded compromised if access to it ever
has been granted. As a last consequence, it's impossible to detect if the
machine has been tampered with.

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

[Olivier Sessink]

Heinz Diehl wrote:
> On 29.12.2009, Arno Wagner wrote: 
> 
>> I don't agree. But you have to think outside of the box and use a
>> separate, uncompromised boot medium that the attacker did not have
>> access to.
> 
> Sorry, but I can't see how this would help. The attacker installs a
> hardware keylogger and just doesn't care.

I don't see the averae script kiddie install a hardware keylogger in a 
modern laptop.

If you have an intelligence agency after you you're screwed anyway. 
They'll use a tempest attack or something so you won't even notice that 
you gave them your password (I don't have a tempest proof room in my 
house, perhaps other people have?).

So it's a matter of security management. For highly confidential data 
you need ($$$) a tempest proof environment with armed guards. For only 
slightly sensitive data, simple disk encryption and some measures 
against script kiddies are usually enough.

Olivier

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

[Arno Wagner]

On Tue, Dec 29, 2009 at 10:15:36PM +0100, Heinz Diehl wrote:
> On 29.12.2009, Arno Wagner wrote: 
> 
> > I don't agree. But you have to think outside of the box and use a
> > separate, uncompromised boot medium that the attacker did not have
> > access to.
> 
> Sorry, but I can't see how this would help. The attacker installs a
> hardware keylogger and just doesn't care.

That will require a second access to the hardware. And it is a
whole order of magnitude (at least) more difficult and expensive
that the software attack. 
 
> It's a matter of concept: before a security solution is implemented, a
> risk analysis has to be done. To have /boot on an external medium or to
> store checksums of the unencrypted files on a CD/DVD/stick is fine, as
> long as the risk it carries is accepted, along with the worst case scenario
> under given circumstances. It's up to the operator.
> 
> For total security, the machine is regarded compromised if access to it ever
> has been granted. As a last consequence, it's impossible to detect if the
> machine has been tampered with.

"total security" is a meaningless concept, unless you design and 
manufacture all hardware components yourself, which in practce
means it is a meaningless concept.
 
Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Heinz Diehl]

On 30.12.2009, Arno Wagner wrote: 

> "total security" is a meaningless concept, unless you design and 
> manufacture all hardware components yourself, which in practce
> means it is a meaningless concept.

Yes, that was a bad choice of words, I realised it directly after sending
the mail to the list. 

s/total security/max possible security under given circumstances/;

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

[Arno Wagner]

On Wed, Dec 30, 2009 at 03:16:44PM +0100, Heinz Diehl wrote:
> On 30.12.2009, Arno Wagner wrote: 
> 
> > "total security" is a meaningless concept, unless you design and 
> > manufacture all hardware components yourself, which in practce
> > means it is a meaningless concept.
> 
> Yes, that was a bad choice of words, I realised it directly after sending
> the mail to the list. 
> 
> s/total security/max possible security under given circumstances/;

Better but not quite there either. You do not need "max", you 
need to find the right risk balance. IT security is risk management,
nothing else.

First you need an attacker model and an estimation of the worth
of your data/system integrity. Then you go from there. If the 
attacker needs to invest slighlty more than you loose from the
attack (and the countermeasurer cost), you have found the right 
balance. This is made more difficult because you will only have
estimates for most numbers.

Arno

-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Hannes Erven]

Arno Wagner schrieb:
> On Tue, Dec 29, 2009 at 12:11:58AM +0100, Heinz Diehl wrote:
>> "Please repeat with me: there is no way to avoid or detect backdoors if
>> physical access to the machine has ever been granted." (Werner Koch on
>> gnupg-users 19.02.2009 on exactly the same topic).
> 
> I don't agree. 

How do you protect against e.g. a hardware key logger? You don't.


-hannes

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

[Gregy]

2009/12/29 Hannes Erven <h.e@gmx.at>:
> Arno Wagner schrieb:
>> On Tue, Dec 29, 2009 at 12:11:58AM +0100, Heinz Diehl wrote:
>>> "Please repeat with me: there is no way to avoid or detect backdoors if
>>> physical access to the machine has ever been granted." (Werner Koch on
>>> gnupg-users 19.02.2009 on exactly the same topic).
>>
>> I don't agree.
>
> How do you protect against e.g. a hardware key logger? You don't.
>
Well, you could set entirely new, random keymap for every boot.

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

[Arno Wagner]

On Tue, Dec 29, 2009 at 10:31:16PM +0100, Hannes Erven wrote:
> Arno Wagner schrieb:
> > On Tue, Dec 29, 2009 at 12:11:58AM +0100, Heinz Diehl wrote:
> >> "Please repeat with me: there is no way to avoid or detect backdoors if
> >> physical access to the machine has ever been granted." (Werner Koch on
> >> gnupg-users 19.02.2009 on exactly the same topic).
> > 
> > I don't agree. 
> 
> How do you protect against e.g. a hardware key logger? You don't.

A hardware keylogger not a backdoor at all.

Arno 
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Zdenek Kaspar]

Dne 28.12.2009 21:28, Olivier Sessink napsal(a):
> 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? 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.
> 
> I was thinking along the lines of:
> - check a checksum of the MBR and partition table
> - check a checksum of the complete /boot filesystem
> - check the pointers in the kernel system call table (detects many
> rootkits)
> - check for virtualization (any virtual rootkits)
> - ...? any better ideas how to detect tampering?
> 
> Obviously all of this should be done by a binary inside the encrypted
> filesystem - everything in /boot (kernel and initrd) is not to be
> trusted. That means we can only warn the user after the password is
> probably gone already, but this is better than nothing.
> 
> Any comments, ideas or links  ?
> 
> regards,
> Olivier

Hi Olivier,

If you think someone had access to your hardware then you should avoid
running untrusted/modified kernel, initrd and bootloader at all.

The checksum approach looks fine to me when it's done with binaries from
trusted LiveCD/USB environment - http://www.sysresccd.org/

For /boot and bootloader might be efficient:
$ dd ... | sha512sum

If you're really paranoid then you should remove the drive and
investigate on another machine....... annoying.

HTH, Z.

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

[Zdenek Kaspar]

Dne 28.12.2009 23:41, Zdenek Kaspar napsal(a):
> Dne 28.12.2009 21:28, Olivier Sessink napsal(a):
>> 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? 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.
>>
>> I was thinking along the lines of:
>> - check a checksum of the MBR and partition table
>> - check a checksum of the complete /boot filesystem
>> - check the pointers in the kernel system call table (detects many
>> rootkits)
>> - check for virtualization (any virtual rootkits)
>> - ...? any better ideas how to detect tampering?
>>
>> Obviously all of this should be done by a binary inside the encrypted
>> filesystem - everything in /boot (kernel and initrd) is not to be
>> trusted. That means we can only warn the user after the password is
>> probably gone already, but this is better than nothing.
>>
>> Any comments, ideas or links  ?
>>
>> regards,
>> Olivier
> 
> Hi Olivier,
> 
> If you think someone had access to your hardware then you should avoid
> running untrusted/modified kernel, initrd and bootloader at all.
> 
> The checksum approach looks fine to me when it's done with binaries from
> trusted LiveCD/USB environment - http://www.sysresccd.org/
> 
> For /boot and bootloader might be efficient:
> $ dd ... | sha512sum
> 
> If you're really paranoid then you should remove the drive and
> investigate on another machine....... annoying.
> 
> HTH, Z.
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Just check the critical files on /boot + bootloader.

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

[Heinz Diehl]

On 28.12.2009, Olivier Sessink wrote: 

> 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? If somebody has access to your computer they could
> change the initrd and kernel and make your encryption useless

If anyone ever gets physical access to your machine, all bets are off.
There's no way for you to proof that your machine has not been tampered with.

You can have a checksum of the contents in /boot, the MBR or whatsoever, you
name it. The attacker won't care and install a hardware keylogger or
whatever suits best.

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

[Arno Wagner]

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.

> 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.

> I was thinking along the lines of:
> - check a checksum of the MBR and partition table
=> Fake the check
> - check a checksum of the complete /boot filesystem
=> See above
> - check the pointers in the kernel system call table (detects many rootkits)
=> See above.
> - check for virtualization (any virtual rootkits)
=> Very hard and the check can be removed.
> - ...? any better ideas how to detect tampering?
>
> Obviously all of this should be done by a binary inside the encrypted  
> filesystem - everything in /boot (kernel and initrd) is not to be  
> trusted. That means we can only warn the user after the password is  
> probably gone already, but this is better than nothing.
>
> Any comments, ideas or links  ?

With an attacker competent enough to do this type of tampering
you are screwed as long as you rely on the on-disk information.

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).

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Olivier Sessink]

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

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

[Arno Wagner]

On Tue, Dec 29, 2009 at 11:52:37PM +0100, Olivier Sessink wrote:
> Arno Wagner wrote:
[...]
>> 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).

Simple again: Wear it on a chain around your neck.
Anybody that can beat this likely can beat any and all
other security measures you can implement.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

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

[Olivier Sessink]

Arno Wagner wrote:
> On Tue, Dec 29, 2009 at 11:52:37PM +0100, Olivier Sessink wrote:
>> Arno Wagner wrote:
> [...]
>>> 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).
> 
> Simple again: Wear it on a chain around your neck.
> Anybody that can beat this likely can beat any and all
> other security measures you can implement.

we're talking "regular users" here. You know, the ones that write
passwords on pieces of paper even if you tell them not to write
passwords ever down. So these users are quite a weak link in the
security. So we do the best we can do that is acceptable for the
end-user, and will likely work with our end-users. I think they will
laugh very hard if we tell them to wear a memory-stick around their
necks.. It won't work. They will leave it on their hotel room or in
their luggage.

Olivier

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

[Arno Wagner]

On Wed, Dec 30, 2009 at 11:48:03AM +0100, Olivier Sessink wrote:
> Arno Wagner wrote:
> > On Tue, Dec 29, 2009 at 11:52:37PM +0100, Olivier Sessink wrote:
> >> Arno Wagner wrote:
> > [...]
> >>> 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).
> > 
> > Simple again: Wear it on a chain around your neck.
> > Anybody that can beat this likely can beat any and all
> > other security measures you can implement.
> 
> we're talking "regular users" here. You know, the ones that write
> passwords on pieces of paper even if you tell them not to write
> passwords ever down. So these users are quite a weak link in the
> security. So we do the best we can do that is acceptable for the
> end-user, and will likely work with our end-users. I think they will
> laugh very hard if we tell them to wear a memory-stick around their
> necks.. It won't work. They will leave it on their hotel room or in
> their luggage.
> 

So your set-up is one with no user competence, no willingness to
do anything that could increase physical security if it is 
a bit bothersome? How do you get them to use passwords in the
first place?

Anyways, it does not have to be around the neck, in the wallet 
with instructions to give/show it to nobody would also work. I 
don't think anything in the machine would work against a competent
attacker. That means the user has to do attack detection and 
the bootable USB key is one of the few means to qualify a low 
competence user to do this.

Arno
-- 
Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@wagner.name 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier