Challenge to David Wagner on TCPA

[AARG! Anonymous]

Sampo Syreeni writes:

> On 2002-08-01, AARG!Anonymous uttered to ptrei at rsasecurity.com,...:
>
> >It does this by taking hashes of the software before transferring
> >control to it, and storing those hashes in its internal secure
> >registers.
>
> So, is there some sort of guarantee that the transfer of control won't be
> stopped by a check against cryptographic signature within the executable
> itself, in the future? That sort of thing would be trivial to enforce via
> licencing terms, after all, and would allow for the introduction of a
> strictly limited set of operating systems to which control would be
> transferred.

TCPA apparently does not have "licensing terms" per se.  They say,
in their FAQ, http://www.trustedcomputing.org/docs/Website_TCPA%20FAQ_0703021.pdf,
"The TCPA spec is currently set up as a 'just publish' IP model."
So there are no licensing terms to enforce, and no guarantees that
people won't do bad things outside the scope of the spec.  Of course,
you realize that the same thing is true with PCs today, right?  There are
few guarantees in this life.

If you think about it, TCPA doesn't actually facilitate the kind of
crypto-signature-checking you are talking about.  You don't need all
this fancy hardware and secure hashes to do that.  Your worrisome
signature checking would be applied on the software which *hasn't
yet been loaded*, right?  All the TCPA hardware will give you is a
secure hash on the software which has already loaded before you ran.
That doesn't help you; in fact your code can pretty well predict the
value of this, given that it is running.  Think about this carefully,
it is a complicated point but you can get it if you take your time.

In short, to implement a system where only signed code can run, TCPA is
not necessary and not particularly helpful.


> I'm having a lot of trouble seeing the benefit in TCPA
> without such extra measures, given that open source software would likely
> evolve which circumvented any protection offered by the more open ended
> architecture you now describe.

I don't follow what you are getting at with the open source.  Realize that
when you boot a different OS, the TCPA attestation features will allow
third parties to detect this.  So your open source OS cannot masquerade
as a different one and fool a third party server into downloading data
to your software.  And likewise, data which was sealed (encrypted)
under a secure OS cannot be unsealed once a different OS boots, because
the sealing/unsealing is all done on-chip, and the chip uses the secure
hash registers to check if the unsealing is allowed.


> >Then, when the data is decrypted and "unsealed", the hash is compared to
> >that which is in the TPM registers now.  This can make it so that data
> >which is encrypted when software system X boots can only be decrypted
> >when that same software boots.
>
> Again, such values would be RE'd and reported by any sane open source OS
> to the circuitry, giving access to whatever data there is. If this is
> prevented, one can bootstrap an absolutely secure platform where whatever
> the content provider says is the Law, including a one where every piece of
> runnable OS software actually enforces the kind of control over
> permissible signatures Peter is so worried about. Where's the guarantee
> that this won't happen, one day?

Not sure I follow this here... the sealed data cannot be reported by an
open source OS because the secret keys never leave the chip without being
themselves encrypted.  As for your second proposal, you are suggesting
that you could write an OS which would only run signed applications?
And run it on a TCPA platform?  Sure, I guess you could.  But you wouldn't
need TCPA features to do it.  See the comments above: any OS today could
be modified to only run apps that were signed with some special key.
You shouldn't blame TCPA for this.


> >In answer to your question, then, for most purposes, there is no signing
> >key that your TPM chip trusts, so the issue is moot.
>
> At the hardware level, yes.

TCPA is a hardware spec.  Peter was asking about TCPA, and I gave him the
answer.  You can hypothesize all the facist software you want, but you
shouldn't blame these fantasies on TCPA.

> At the software one, it probably won't be,
> even in the presence of the above considerations. After you install your
> next Windows version, you will be tightly locked in with whatever M$
> throws at you in their DLL's,

Doesn't Microsoft already sign their system DLLs in NT?

> and as I pointed out, there's absolutely no
> guarantee Linux et al. might well be shut out by extra features, in the
> future. In the end what we get is an architecture, which may not embody
> Peter's concerns right now, but which is built from the ground up to bring
> them into being, later.

Again, you are being entirely hypothetical here.  Please describe exactly
how either attestation or secure storage would assist in creating a boot
loader that would refuse to run Linux, or whatever other horrible disaster
you envision.


> More generally, as long as we have computers which allow data to be
> addressed as code and vice versa, the ability to control use of data will
> necessarily entail ability to control use of code.

Look, I have describe in detail how it works, and you're just giving
these meaningless slogans.  TCPA lets you prove to other people what
code you are running; it lets you seal data such that it can only be
unsealed by the same code which sealed it.  How does this relate to
your little saying?  The ability to encrypt data means... the ability
to encrypt code?  So what?

> So, either we will get
> systems where circumventing copyright controls is trivial or ones where
> you cannot compile your own code. All the rest is just meaningless syntax.
> In that light I bet you can guess why people are worried about TCPA and
> its ilk.

Nonsense, there is no need to stop people from compiling their own
code in order to protect data!  The steps are simple: trusted app runs,
connects to server; proves it is trusted via TCPA attestation; server
downloads data to trusted app based on attestation; trusted app seals
data.  User reboots into open source OS, can't access data because it
is sealed; can't fool server because of attestation.  He can write all
the code he wants and it won't change this logic.  TCPA does not depend
on stopping people from running their own code; it depends on verifying
what code is running, and tying it to the crypto.  That's all.