Re: TPM support with SATA drives

[Robert Millan]

On Sun, Apr 20, 2008 at 12:07:01AM -0700, Julian Blake Kongslie wrote:
> I'm taking this sub-discussion off-list because we're clearly no longer
> particularly relevant to Grub. If you particularly want to keep it
> on-list, feel free to forward this message to the list on your own.

Ok.  With your permission, I will.  But I encourage you to reconsider keeping
it on-list.  I think it's beneficial to have this discussion in public, and
also think it's relevant to GRUB.  We get enquiries about this all the time,
and I believe it's critical that information about this problem can be spread
as much as possible.

> On Sat, 2008-04-19 at 13:34 +0200, Robert Millan wrote:
> > It's part of the point, but there's more to it.  You can see evidence of 
> > that
> > in two facts:
> >
> >   - The TPM has a master key that the owner never gets a copy of.  Not even
> >     if she requests it to the vendor.
> 
> Note that the vendor may not have the master key, either. In the TPM I
> have, taking ownership changes the keys stored on-chip, including the
> endorsement key and the SRK.
> 
> >   - The TPM refuses to sign things with its master key when it doesn't feel
> >     like it.  So if you want to use the TPM to emmit a certificate that
> >     proves you're running Microsoft Windows, but you're not, the TPM will
> >     refuse to help you.
> 
> Or, you can boot into Linux, feed in the same PCR updates that windows
> would, and generate the same certificate.
> 
> Note that TPM, as specified, is actually weaker than this: in my case,
> once I have informed someone of my true endorsement key, I cannot rerun
> the take ownership functionality of my TPM without being forced to
> notify them that my endorsement key has changed. In the normal TPM
> situation, I could freely give out my true endorsement public key,
> possibly running whatever software they wanted me to in the process,
> then wipe my system, rerun the take ownership function, and ask my
> (presumably free-software) operating system to send whatever PCR updates
> and endorse whatever messages I wanted, with the same key.

You're getting into very specific details, that I can't follow.  I haven't
studied how the TCG stack works in depth.  What I know are the fundamentals:

  - They say you can use that to implement remote attestation.
  - You can't implement remote attestation without a master key that the
    TPM can use to sign things, but is not under your control.

This is enough of a point for me.  Unless you can deny them, there's no reason
that we start discussing specific details.

> > Of course.  But we're talking about the *owner* having control.  The 
> > software
> > stack is not the only way the owner can control her own hardware.  For 
> > example,
> > she could get a printed copy of the master key.  Or there could be a
> > jumper/button in the TPM that overrides the restrictions I explained above
> > (So-called "owner override", which was proposed and rejected because "it was
> > against the purpose of providing TPMs" -- draw conclussions from what that
> > means).
> 
> Owner override is a means of directly changing PCRs instead of following
> the PCR update protocol -- this very nearly removes the point of the
> PCRs entirely, yes. That said, I suspect tieing it to the physical
> access bit and adding another control bit would be acceptable, as there
> are already ways to arrange for an arbitrary final PCR configuration
> with work and a cooperative OS

When you say "cooperative OS", do you mean an OS that will cooperate with
the user, or that will cooperate with someone else in order to implement
remote attestation?

> -- I, personally, would be quite happy
> with a tainted bit that was set on any PCR configuration which had been
> overridden, and could not be used as a dependant bit by the TPM sealing
> mechanism (a purely informative bit), but I would be very hesitant of a
> completely invisible override. I am not aware of the exact proposals or
> reasons for rejection that the TCG has made.

Because otherwise remote attestation can't be implemented.  It's obvious
they wanted to embed that mallicious feature in their TPMs in a way that
users can't put it off.

> > You think remote attestation is voluntary, but by its nature it cannot be
> > made voluntary.  Voluntary means I can refuse to participate without giving
> > the challenger any information about my system.  However, my refusal to
> > participate *IS* already information.  In fact, if you add to it another
> > piece of information -- namely, the (future) fact that everyone has a
> > complete Treacherous stack --, what do you get?  Right!  You get the ability
> > to distinguish who is running your CrapWare 2000[tm] DRM program and who
> > isn't.
> 
> Alternatively, you could "elect to participate" by sending the
> challenger an arbitrary public key that you claim is from your TPM, but
> is not. How do you propose they tell the difference?

I demand they *DON'T*.  It is my right to claim I'm running CrapWare 2000[tm]
any time I want to, whether I'm really running it or not.  It is in fact a
very basic right.  If you live in the US, it's protected under the First
Amendment.  And TPM proponents are trying to jeopardize it by use of technical
means.

And in fact the consequences are terrible.  Next time you see, your right to
run a free operating system will have disappeared.  Websites you visit will
insist you run Adobe Flash or Microsoft Silverlight, since they want to use
DRM features on these programs.  Heck, maybe even your ISP will forbid you
from using the Internet unless you agree to let them spy on you.

> > Which means that in the future (unless computer users reject it outright),
> > DRM proponents will have a very powerful tool in order to coerce everyone
> > into using the anti-features they put in their programs (which obviously
> > nobody *wants* to have, that's why they have to make it so confusing).
> 
> It seems, to me, like you are heavily confusing the hardware features
> provided by a TPM and the software dis-features commonly provided by,
> for example, the Windows operating system. They really don't depend on
> eachother

I know that.  In fact remote attestation is not completely implemented yet.

But it's only a matter of time untill existing anti-features are ported to
it, or new anti-features are developed.

> - a TPM is a wonderful tool for me, as a free-software user,
> to gain significant extra security on my system. If you're using an
> operating system you already don't trust to act in your interest, the
> hardware's cooperation isn't particularly required for it to make your
> life torture and deny you access to your own files.

It would be a wonderful tool if they hadn't added poison to it.  When you can
buy a TPM and get a printed copy of its master key at the same time, *then*
I'll agree with you on this.

Really, we're on the same boat.  You just want security features, which is
fine.  The only problem is that hardware vendors who would provide these
features to you, put a poison pill in them.  Instead of accepting their
blackmail, demand that they provide those features without the poison.  It'll
work wonders for you if they do, and you won't be acting against the freedoms
of users.

Btw, my expertise with hardware engineering is very limited.  How difficult
would it be for a small group to develop schematics for a TPM chip that
doesn't restrict the user?  Then its licensing terms could demand that its
master key is always passed along to its owner, or something like that.

-- 
Robert Millan

<GPLv2> I know my rights; I want my phone call!
<DRM> What use is a phone call… if you are unable to speak?
(as seen on /.)