Re: A _good_ and valid use for TPM

[phcoder <phcoder@gmail.com>]

I don't know much about TPM but from example that I read at 
TreacherousGrub website actual verification is done by TreachorousGrub. 
I don't see how such a verification can protect against anything.
If you suppose that your attacker is unable to tamper the hardware then 
bios and grub password is all you need. If you suppose that he can then 
you can't even trust your ram modules. It can be tampered in many ways 
like serving hacked bootloader or just being non-volatile then an 
attacker can read the key from memory.
FSF acknowledges that treacherouscomputing may offer minor advantages 
but dissmisses the technology as whole and I agree with them.
However, I'm neither a grub maintainer nor fsf representative.
Regards
Vladimir 'phcoder' Serbinenko
Alex Besogonov wrote:
> I know that TPM has been mentioned several times on this list. With
> absolutely inadequate knee-jerk reactions from GRUB developers :(
> 
> Currently I have a problem - I need to protect confidential private
> data (we try to protect privacy of our customers) from the _physical_
> theft of the server. A simple full hard drive encryption should work
> just fine except for one small detail - there's nobody to enter the
> password when server reboots.
> 
> I've solved this by adding an intermediate system which connects to
> another server (which I consider physically secure), retrieves
> decryption key and does kexec into the real OS passing this key as a
> parameter. So I can just delete the key from the secure server to stop
> the physically insecure sever from booting, it'll then be useless for
> attackers since there's no decryption key present on it.
> 
> However, it would be fairly trivial for attacker to steal the server
> and/or make a full copy of its hard drive and then modify intermediate
> system to print the decryption key. Not good. And there's no way to
> solve it in software, since attacker can trivially change the
> bootloader.
> 
> So I've added another layer of security - I use TPM to remotely attest
> that the bootloader and the intermediate system is not modified. It
> requires chain of trust from BIOS to the intermediate system. So if
> attacker tries to modify bootloader or intermediate system image - TPM
> will not provide keys for communication with the secure server.
> 
> Please note, that if TPM chip is blocked/kicked/de-soldered/sacrificed
> to GNU gods then I can still retrieve all data because the main
> decryption key is NOT kept in the TPM module (TPM is only used to
> attest integrity of the system). Also, this is not a DRM scheme.
> 
> So... Why not add TPM patches into the mainline GRUB2 project? GPLv3
> protects nicely against the possible DRM misuse of GRUB2 and TPM. Also
> I can assist in forward-porting of 'Trusted GRUB' patch.
> 
> 
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel