Mailing List Archive: Gentoo: Hardened

Setting up a (more) secure notebook

Index | Next | Previous | View Threaded

meyerm at fs

Nov 17, 2009, 3:20 PM

Post #1 of 9 (1060 views)
Permalink

Setting up a (more) secure notebook

Hi,

I'm currently setting up a notebook, which will contain sensitive data. I want
to fully encrypt the whole harddrive with luks using a keyfile encrypted with
gnupg.

Since I have to leave the notebook sometimes in possible "unsecure" places,
all the boot-stuff (kernel, boot-loader, initramfs, keyfile) is placed on a
small USB key at my keychain. Basically that's an outsourced /boot.

Now I'd like to try to use the usb-key just as a generic loader for an already
encrypted kernel on the harddrive. The kernel/initramfs of the USB key loads
the LUKS-partition and instead of booting this system with the already loaded
kernel from the USB key it should replace the running kernel with another one
incl. initramfs from the harddrive using kexec from the encrypted partition.

Basically I have this setup running. One problem is, I'd have to compile
kexec-tools with a non-hardened toolchain. (see bug #183062)

But now I'm wondering what security implications I get by doing it this way.
What for problems do you see by doing it this way? Would it be a better idea
to just forget about that stuff and stay with an external /boot.

Thanks!
Marcel

schism at subverted

Nov 17, 2009, 5:03 PM

Post #2 of 9 (1019 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

FWIW, this doesn't *precisely* belong on -hardened, but since much of
the audience for secured booting is the same I doubt many will complain.

On Wed, Nov 18, 2009 at 12:20:13AM +0100, Marcel Meyer wrote:
> Now I'd like to try to use the usb-key just as a generic loader for an already
> encrypted kernel on the harddrive. The kernel/initramfs of the USB key loads
> the LUKS-partition and instead of booting this system with the already loaded
> kernel from the USB key it should replace the running kernel with another one
> incl. initramfs from the harddrive using kexec from the encrypted partition.

I'm following you all the way up to the kexec - what exactly are you
trying to solve by doing that? The only approach more protected against
physical compromise is a TPM-integrated boot where you seal the LUKS key
to your particular BIOS/bootloader/kernel/initrd measurement, but that's
not quite possible in the Linux world yet.

If the kernel or initrd on the USB key are compromised (which it seems
you're trying to protect against), they're under no obligation to follow
the kexec path. Once you've unlocked the LUKS partition the kimono has
dropped, so to speak, and they're free to do whatever malicious deeds
they wish. You could raise the bar on that a little by using write-once
media like an optical disc instead of a USB key, and even make it
visually "unique" by physically modifying the disc in some manner that
doesn't damage its readability, but you're still just engaging in an
arms race.

Look at bug #204830 for a start on the TPM integration. What's missing
right now is an initrd-usable app (not all of TrouSerS) that would
replace GPG in your use case, unsealing the key from the TPM and passing
it on to cryptsetup. I expect cryptsetup could be modified to do the
job itself, but that's beyond my level of knowledge right now.

meyerm at fs

Nov 18, 2009, 11:41 AM

Post #3 of 9 (1013 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

Thank you for dealing with my message :-)

Am Mittwoch, 18. November 2009 02:03:23 schrieb schism [at] subverted:
> FWIW, this doesn't *precisely* belong on -hardened, but since much of
> the audience for secured booting is the same I doubt many will complain.

Hehe, yes. And it's a hardened system (of course). And I have hardened
compiler problems ;-). Aaand there was no traffic on gentoo-hardened for about
a month. We have to check if the list is still working :-)

> On Wed, Nov 18, 2009 at 12:20:13AM +0100, Marcel Meyer wrote:
> > Now I'd like to try to use the usb-key just as a generic loader for an
> > already encrypted kernel on the harddrive. The kernel/initramfs of the
> > USB key loads the LUKS-partition and instead of booting this system with
> > the already loaded kernel from the USB key it should replace the running
> > kernel with another one incl. initramfs from the harddrive using kexec
> > from the encrypted partition.
>
> I'm following you all the way up to the kexec - what exactly are you
> trying to solve by doing that?

Well, several things.

First: convenience and reliability. By having a more or less static kernel and
initramfs with a small, generic subset of modules which can boot all of my
computers, I can reuse this USB stick (with several key/password-combinations)
for more than one machine. And when updating the kernel and/or the modules on
my "work-kernel" I don't have to remember adding it to the USB-stick and
keeping it consistant. So updating because of the newest graphics card driver
is a little less trouble.

> [..]
> If the kernel or initrd on the USB key are compromised (which it seems
> you're trying to protect against), they're under no obligation to follow
> the kexec path. Once you've unlocked the LUKS partition the kimono has
> dropped, so to speak, and they're free to do whatever malicious deeds
> they wish.

Second: a little bit more security (by obscurity...?). You are right that a
running kernel could do a lot of harm when having access to the data. But when
that kernel on the USB stick decrypts a trustworthy kernel from the /boot on
HD, calls kexec on it (the /sbin/init on this boot partition will have to do
that) and this kernel then decrypts the /-partition with another password/key-
combination, shouldn't this help a little bit?

I mean I can not prevent this potential corrupted kernel from starting and
then accessing my /boot partition. But as long as the "attacker" did not
invest so much work to keep this kernel alive "behind" a kexec call or
starting some virtual machine etc. pp., the newly started kernel should take
full control - and if something different (like another kernel from the USB-
stick) is started, I will recognize that and don't enter the password for the
data.

So my main question here is: does it make sense to replace the first kernel by
a trusted second one or is it too easy to hide behind such functionality?

Of course this will not detain any serious hackers - besides they would have
better methods like adding simple hardware hacks. But would this work as a
protection against by-chance-hacker, getting somehow their hands on the key
for a short time?

> Look at bug #204830 for a start on the TPM integration. What's missing
> right now is an initrd-usable app (not all of TrouSerS) that would
> replace GPG in your use case, unsealing the key from the TPM and passing
> it on to cryptsetup. I expect cryptsetup could be modified to do the
> job itself, but that's beyond my level of knowledge right now.

Thank you for that hint! I will follow it since at least my newest notebook
now has some TPM chip inside.

I already searched for some USB tokens so that they can't be copied at least.
But that still wouldn't help with the problem of a modified initramfs which
sends stuff over the network, f.ex.

Thanks,
Marcel

schism at subverted

Nov 22, 2009, 8:38 AM

Post #4 of 9 (995 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

On Wed, Nov 18, 2009 at 08:41:10PM +0100, Marcel Meyer wrote:
> First: convenience and reliability. By having a more or less static kernel and
> initramfs with a small, generic subset of modules which can boot all of my
> computers, I can reuse this USB stick (with several key/password-combinations)
> for more than one machine. And when updating the kernel and/or the modules on
> my "work-kernel" I don't have to remember adding it to the USB-stick and
> keeping it consistant. So updating because of the newest graphics card driver
> is a little less trouble.

I don't find that terribly convenient, but to each their own. You're
building up a lot of complexity that's not going to necessarily be very
robust.

> Second: a little bit more security (by obscurity...?). You are right that a
> running kernel could do a lot of harm when having access to the data. But when
> that kernel on the USB stick decrypts a trustworthy kernel from the /boot on
> HD, calls kexec on it (the /sbin/init on this boot partition will have to do
> that) and this kernel then decrypts the /-partition with another password/key-
> combination, shouldn't this help a little bit?

Not really, once you have malicious code running on your machine at this
level, it's game over. There are several approaches they can take to
getting your password, but if you've lost control of the first kernel
you've lost control of them all.

> I mean I can not prevent this potential corrupted kernel from starting and
> then accessing my /boot partition. But as long as the "attacker" did not
> invest so much work to keep this kernel alive "behind" a kexec call or
> starting some virtual machine etc. pp., the newly started kernel should take
> full control - and if something different (like another kernel from the USB-
> stick) is started, I will recognize that and don't enter the password for the
> data.

I think you're both overestimating your powers of observation and
underestimating the abilities of an intentional and knowledgeable
attacker. Anything can be faked.

> So my main question here is: does it make sense to replace the first kernel by
> a trusted second one or is it too easy to hide behind such functionality?
>
>
> Of course this will not detain any serious hackers - besides they would have
> better methods like adding simple hardware hacks. But would this work as a
> protection against by-chance-hacker, getting somehow their hands on the key
> for a short time?

It doesn't really make sense because you're not protecting against a
"casual" attacker at this point anyway. All FDE protects against is
powered-down physical compromise (typically theft or loss). The moment
your threat model includes a malicious attacker returning ownership to
you, you've gone way beyond the "by-chance-hacker" assessment and deeply
into espionage territory. At that point, if the attacker has had
manipulative access to your boot media, nothing short of hardware-level
measurements is really going to "guarantee" the safety of your data. I
also refer you to http://xkcd.com/538/.

There's nothing stopping you from this pursuit, it simply isn't going to
protect against what you may think it does. It adds unnecessary
complexity for that purpose, and complexity just adds more opportunities
for failure and subversion. If you find it convenient, that's just up
to you.

meyerm at fs

Nov 28, 2009, 12:39 PM

Post #5 of 9 (988 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

Am Sonntag, 22. November 2009 17:38:02 schrieb schism [at] subverted:
> It doesn't really make sense because you're not protecting against a
> "casual" attacker at this point anyway. All FDE protects against is
> powered-down physical compromise (typically theft or loss). The moment
> your threat model includes a malicious attacker returning ownership to
> you, you've gone way beyond the "by-chance-hacker" assessment and deeply
> into espionage territory. At that point, if the attacker has had
> manipulative access to your boot media, nothing short of hardware-level
> measurements is really going to "guarantee" the safety of your data. I
> also refer you to http://xkcd.com/538/.

Hehe, this comic is very true. Even though I didn't try to hide from
government or highly criminal guys, I guess you are right that the "by-chance-
hackers" won't be able to do anything which will get prevented by this way of
doing it.

> There's nothing stopping you from this pursuit, it simply isn't going to
> protect against what you may think it does. It adds unnecessary
> complexity for that purpose, and complexity just adds more opportunities
> for failure and subversion. If you find it convenient, that's just up
> to you.

Well, I guess I'll let it be for the time beeing.

Thank you for the discussion!

mansourmoufid at gmail

Nov 28, 2009, 3:55 PM

Post #6 of 9 (981 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

On Wed, Nov 18, 2009 at 2:41 PM, Marcel Meyer <meyerm [at] fs> wrote:
> I mean I can not prevent this potential corrupted kernel from starting and
> then accessing my /boot partition. But as long as the "attacker" did not
> invest so much work to keep this kernel alive "behind" a kexec call or
> starting some virtual machine etc. pp., the newly started kernel should take
> full control - and if something different (like another kernel from the USB-
> stick) is started, I will recognize that and don't enter the password for the
> data.
>
> So my main question here is: does it make sense to replace the first kernel by
> a trusted second one or is it too easy to hide behind such functionality?

If I understand correctly, your goal is simply to ensure that the
kernel on the USB drive doesn't get tampered with? In that case,
perhaps a solution would be to keep hashes of it on that same drive,
and sign those with, say, a key on a smart card. (The FSFE offers one
along with instructions. [1]) You could verify everything at boot
time, and if there were discrepancies, custom boot scripts (kept
alongside the kernel, also hashed and signed) could prevent the
machine from booting, or something along those lines...

[1] http://fellowship.fsfe.org/card.en.html

--
Mansour Moufid

schism at subverted

Nov 28, 2009, 8:44 PM

Post #7 of 9 (979 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

On Sat, Nov 28, 2009 at 06:55:09PM -0500, Mansour Moufid wrote:
> If I understand correctly, your goal is simply to ensure that the
> kernel on the USB drive doesn't get tampered with? In that case,
> perhaps a solution would be to keep hashes of it on that same drive,
> and sign those with, say, a key on a smart card. (The FSFE offers one
> along with instructions. [1]) You could verify everything at boot
> time, and if there were discrepancies, custom boot scripts (kept
> alongside the kernel, also hashed and signed) could prevent the
> machine from booting, or something along those lines...

That's a very interesting card, but for different reasons. Since it's
not integrated into the hardware of the system, it too is at the mercy
of whatever the subverted kernel wants it to see. Nothing short of a
hardware-integrated measurement from POST through kernel & initrd is
going to guarantee (for some definition thereof) that there hasn't been
some malicious modification of the process.

There is vanishingly little chance that an adversary with the knowledge
and motive to modify your kernel will miss whatever little userspace
games you may play with hashes, kexec, or the like. It may take them
a second attempt or more time than they'd like, or they may just beat
you with a $5 wrench until you tell them what they want. We're not
talking about casual attackers at this point, they're at least as
knowledgeable as you, and typically well-financed to boot. Even so,
you're far more likely to simply have your equipment stolen (which
simple FDE with a strong passphrase solves) than you are to really
encounter this type of threat.

mansourmoufid at gmail

Nov 29, 2009, 8:12 AM

Post #8 of 9 (969 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

On Sat, Nov 28, 2009 at 11:44 PM, <schism [at] subverted> wrote:
> That's a very interesting card, but for different reasons. Since it's
> not integrated into the hardware of the system, it too is at the mercy
> of whatever the subverted kernel wants it to see. Nothing short of a
> hardware-integrated measurement from POST through kernel & initrd is
> going to guarantee (for some definition thereof) that there hasn't been
> some malicious modification of the process.

Yes, that's true. I just saw the flaw in this scheme. (An attacker
would simply replace gpg on the USB drive with one that has the
attacker's keys hard-coded, made to completely ignore the smart card,
and re-hash/sign everything...)

Google's new OS claims to prevent exactly this sort of attack by using
"custom" firmware to conduct regular checks:
http://www.youtube.com/watch?v=A9WVmNfgjtQ#t=2m24s
Apparently, the key used to check the kernel for modification is kept
in "read-only" firmware, along with "verifier logic" (hash test
cases?). If they're successful, perhaps Gentoo Hardened could adopt
these methods.

Digressing... Given that we cannot ensure the integrity of our kernel,
presumably the attacker cannot ensure theirs either. Short of
preventing tampering, the next best thing would be to detect it, and
in some cases knowing that data was tampered with is potentially more
valuable than the data itself. For example, one could "bait" an "evil
maid" attack, and later study the modified kernel, to phone home with
a dupe payload, etc... Now that would make a good movie. ; )

--
Mansour Moufid

franxisco1988 at gmail

Nov 29, 2009, 8:56 AM

Post #9 of 9 (974 views)
Permalink

Re: Setting up a (more) secure notebook [In reply to]

2009/11/29 Mansour Moufid <mansourmoufid [at] gmail>:
> Google's new OS claims to prevent exactly this sort of attack by using
> "custom" firmware to conduct regular checks:
> http://www.youtube.com/watch?v=A9WVmNfgjtQ#t=2m24s
> Apparently, the key used to check the kernel for modification is kept
> in "read-only" firmware, along with "verifier logic" (hash test
> cases?). If they're successful, perhaps Gentoo Hardened could adopt
> these methods.
Well, at least a part of that firmware should be overwritable with new hashes or otherwise I can assure you data tampering wouldn't be as dangerous as exploit using on outdated kernels.

The thing is, knowing where that firmware is you can reflash it with your new hashes so you'll foil the scheme. Of course this could take some time on a laptop (15 minutes tops) and you can be sure that somebody interested can get a replacement for the tamper proof parts.

BTW: I rather use a 1$ rubber hose.

Attachments:

signature.asc (0.19 KB)

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads