Re: [gentoo-user] TPM feature - do I need it?

[Rich Freeman]

On Sat, Nov 29, 2014 at 6:44 PM, Mick <michaelkintzios@×××××.com> wrote:
>
> Thanks Rich, it seems not all modern MoBos have it.  This doesn't:
>

Interesting, I had really thought they were ubiquitous.

>
> If I enable this TPM thing, do I automatically open ports at pre/post-boot
> time giving access to my machine?  Or is remote attestation something I have a
> say over?
>

It has to be implemented in software.  The only thing the chip does is
let software call it and ask it to sign data.  The chip can't talk to
the network on its own.

Remote attestation doesn't actually give anybody access to your
machine.  Now, it does let you prove to somebody that they actually do
have access to your machine, if you installed software that gave them
access.  Suppose I gave you a piece of software and asked you to
install it on your machine so that I could evesdrop on everything you
do.  If you refuse to do it I'll fire you from your job.  Without
remote attestation you could install that software in a VM or emulator
somewhere and tell me you complied, and it would be impossible for me
to tell that you did this if your VM was well-implemented.  On the
other hand, if my software implemented remote attestation then the
best you could do is block it, in which case I brand you as
non-compliant and fire you.  With remote attestation I could get a
list of the boot path from the firmware to my software and see if
there is anything in it that could tamper with my software.  If I
dictate that you have to run TrustedCo Linux v5 then I could see that
you're running an unpatched version of it and know that my process is
directly talking to the kernel, which I know doesn't let you tamper
with it, and that kernel is directly running on the hardware having
been loaded by a trusted firmware/bootloader.

> Also, what happens if the TPM chip, or the whole MoBo blows up?  Will I ever
> be able to access my data using another PC?

Only if you encrypted it.  A TPM chip doesn't do much more than except
store and retrieve data, and digitally sign things.  It just tends to
be used in a way that greatly limits the ability of arbitrary
processes to access the data stored on the chip.

With Linux you're basically completely in control.  You choose to
encrypt your drive and store the key in the TPM, and you instruct the
TPM to only hand it over under the conditions you specify, such as a
particular bootloader, kernel, and initramfs (or something like that -
I've never implemented it myself).  If somebody tries to boot your
system with some other kernel/bootloader/initramfs then the TPM will
not have the valid signature chain and it will refuse to divulge your
full-disk encryption key.  I imagine that you could generate the key
outside the TPM and keep a copy of it somewhere and load it into the
TPM, so that if you mess up you can just mount it manually.

It is a bit like UEFI - if you use it properly it becomes a tool which
allows the device owner to secure his own device against other
intruders.  The problems only come when people want to treat your
device as if it is their device.  With Linux you control almost all of
it, though I would GREATLY prefer it if TPM chips did not come with
vendor-supplied certificates (that is, if there was no way for anybody
to determine if the master key inside was externally loaded by the end
user or not).  If they didn't come pre-loaded with certificates then
they would be just as usable for securing your own machine (since you
could add your own certificate/etc), but they would be useless for DRM
(since no key was ever in the chip at a time when it was in the
possession of somebody trusted by the media companies).

I also don't have much more than a general interest in this area, so
I'm sure there are some fine details above which are inaccurate.  The
gist of it should be right though.

--
Rich