[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A _good_ and valid use for TPM

From: phcoder
Subject: Re: A _good_ and valid use for TPM
Date: Thu, 19 Feb 2009 16:05:10 +0100
User-agent: Thunderbird (X11/20090105)

First of all your system is still totally vulnerable to emanation and power analysis or hw tampering. By reflashing bios one can bypass all tpm protections (don't say it's difficult because it's closed source and so on. Look at all closed source obfuscations/pseudo-protections that get cracked every day) Personally if tpm support is merged into mainline grub2 I'll stop using it. However what you request doesn't need tpm. Authenticity of modules, configuration files and so on can be verified by one of 4 methods:
1) internal signatures
2) file in signed gpg container
3) detached signatures
4) signed hash file
First three goals can be achieved by adding a layer similar to gzio
behaviour of checking can be controlled by environment variables and flags passed to
grub_signed_file_open (filename, flags);
First advantage is that you can override it manually supplying grub password
When signature module isn't loaded then this function is available as a dummy (all files are unsigned/wrong signature). Public key can be embedded in signature module. When loaded signature module sets strict signing policy which can be then overriden by variable (to set such a variable you need either password or a command in signed grub.cfg) Then these modules can be embedded in core.img. In this case if core.img is untampered everything is verified. Ensuring integrity of core.img is platform-dependent. Some platforms (openfirmware, efi, ...) load core.img directly and if they have an ability to check the boot image it's straightforward. I haven't thought yet how to do it in limited space of mbr. In coreboot scenario it's even the best bet. You can put grub2 in rom and if you use rom instead of flashrom it's a wonderful solution. But even if you use flash rom your security is similar to scenario you propose since as I said at the begining modyfiing flash bios you can bypass tpm scenario
Advantage of this approach is the ability to safely update over network
Forth goal can be achieved with usage of first part and function similar to sha1sum or whirlpoolsum (my prefered hash) Another idea: for some partitions (e.g. system partitions) signatures or mac can be much better. btrfs supports checksumming of data and metadata. Add mac support is easy. Signatures are more delicate I'm looking for compact and fast signatures. I personally would be interested in implementing security features in grub2 as long as tpm stays away

Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz <address@hidden> wrote:
I've recently started porting TrustedGRUB ( ) to GRUB2.
I didn't get too far as I don't have too much time right now, but I managed to
complete the MBR bootloader.
Great! MBR is the most scary part :)

I agree with you on the usefulness of a TPM for disk encryption and have a
similar scheme planned.
Regardless of the outcome of the discussion on the mailing list I would be
interested in a "trusted" GRUB2 version. Maybe we could join forces?
Absolutely. I just hate doing work that won't appear in the mainline version :(

BTW, the "manufacturer key" everyone is talking about is usually referred to as
"endorsement key", which is generated during production (and whose private part
is considered possibly in the possession of the manufacturer). I heard, that
some newer TPM versions support reinitializing this key, but I'm not sure of
Uhm... TPM_CreateEndorsementKeyPair can be used to create the
endorsement key pair, and the spec also says that TPM chip _must_ ship
with empty endorsement key. It also can later be changed.

And you do loose the ability to do remote attestation with "official"
entities, if you do it.
Well, I don't care about that. And in any case, no-one uses TPM for
'official' purposes.

Grub-devel mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]