Re: A _good_ and valid use for TPM

[phcoder <phcoder@gmail.com>]

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

Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> On Wed, Feb 18, 2009 at 11:05 PM, Jan Alsenz <janalsenz@student.ethz.ch> wrote:
>> I've recently started porting TrustedGRUB (
>> http://sourceforge.net/projects/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
>> that.
> 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
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel