TCPA and Open Source

[AARG! Anonymous]

One of the many charges which has been tossed at TCPA is that it will
harm free software.  Here is what Ross Anderson writes in the TCPA FAQ
at http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html (question 18):

> TCPA will undermine the General Public License (GPL), under which
> many free and open source software products are distributed....
>
> At least two companies have started work on a TCPA-enhanced version of
> GNU/linux. This will involve tidying up the code and removing a number
> of features. To get a certificate from the TCPA corsortium, the sponsor
> will then have to submit the pruned code to an evaluation lab, together
> with a mass of documentation showing why various known attacks on the code
> don't work.

First we have to deal with this certificate business.  Most readers
probably assume that you need this cert to use the TCPA system, and
even that you would not be able to boot into this Linux OS without such
a cert.  This is part of the longstanding claim that TCPA will only boot
signed code.

I have refuted this claim many times, and asked for those who disagree to
point to where in the spec it says this, without anyone doing so.  I can
only hope that interested readers may be beginning to believe my claim
since if it were false, somebody would have pointed to chapter and verse
in the TCPA spec just to shut me up about it if for no better reason.

However, Ross is actually right that TCPA does support a concept for
a certificate that signs code.  It's called a Validation Certificate.
The system can hold a number of these VC's, which represent the "presumed
correct" results of the measurement (hashing) process on various software
and hardware components.  In the case of OS code, then, there could be
VC's representing specific OS's which could boot.

The point is that while this is a form of signed code, it's not something
which gives the TPM control over what OS can boot.  Instead, the VCs
are used to report to third party challengers (on remote systems) what
the system configuration of this system is "supposed" to be, along with
what it actually is.  It's up to the remote challenger to decide if he
trusts the issuer of the VC, and if so, he will want to see that the
actual measurement (i.e. the hash of the OS) matches the value in the VC.

So what Ross says above could potentially be true, if and when TCPA
compliant operating systems begin to be developed.  Assuming that there
will be some consortium which will issue VC's for operating systems,
and assuming that third parties will typically trust that consortium and
only that one, then you will need to get a VC from that group in order
to effectively participate in the TCPA network.

This doesn't mean that your PC won't boot the OS without such a cert; it
just means that if most people choose to trust the cert issuer, then you
will need to get a cert from them to get other people to trust your OS.
It's much like the power Verisign has today with X.509; most people's
software trusts certs from Verisign, so in practice you pretty much need
to get a cert from them to participate in the X.509 PKI.

So does this mean that Ross is right, that free software is doomed under
TCPA?  No, for several reasons, not least being a big mistake he makes:

> (The evaluation is at level E3 - expensive enough to keep out
> the free software community, yet lax enough for most commercial software
> vendors to have a chance to get their lousy code through.) Although the
> modified program will be covered by the GPL, and the source code will
> be free to everyone, it will not make full use of the TCPA features
> unless you have a certificate for it that is specific to the Fritz chip
> on your own machine. That is what will cost you money (if not at first,
> then eventually).

The big mistake is the belief that the cert is specific to the "Fritz"
chip (Ross's cute name for the TPM).

Actually the VC data structure is not specific to any one PC.  It is
intentionally designed not to have any identifying information in it
that will represent a particular system.  This is because the VC cert
has to be shown to remote third parties in order to get them to trust the
local system, and TCPA tries very hard to protect user privacy (believe
it or not!).  If the VC had computer-identifying information in it, then
it would be a linkable identifier for all TCPA interactions on the net,
which would defeat all of the work TCPA does with Privacy CAs and whatnot
to try to protect user privacy.  If you understand this, you will see
that the whole TCPA concept requires VC's not to be machine specific.

People always complain when I point to the spec, as if the use of facts
were somehow unfair in this dispute.  But if you are willing, you can look
at section 9.5.4 of http://www.trustedcomputing.org/docs/main%20v1_1b.pdf,
which is the data structure for the validation certificate.  It is an
X.509 attribute certificate, which is a type of cert that would normally
be expected to point back at the machine-specific endorsement cert.
But in this case they have altered the Holder field, which normally
performs this function, to instead hold the measurement result that the
certificate asserts is correct (i.e. in this context, the hash of the OS).
As a result, no data in the VC is machine specific.

The bottom line is that VCs are not machine specific and are designed
not to be.  Therefore if HP or anyone else gets a cert on their version
of Linux, anyone will be able to use that same cert and prove to remote
users that they are running a TCPA compliant OS.  This contradicts one
of Ross's main claims above.

In fact, with Microsoft now apparently commited to Palladium, it appears
that if TCPA survives at all, it may be solely as a Linux phenomenon!
Reports are that both HP and IBM are working on Linux compatible
versions of TCPA.  Ironically, not only is Ross's claim wrong about TCPA
undermining open source, it could conceivably turn out that TCPA will
be completely reliant on open source operating systems.

At the same time I think it is fair to say that there is an inherent
conflict between the usual development techniques for open source code,
and the requirements for security certification.  Once an OS has been
certified by some respected body as being secure and trusted along TCPA
lines, then changes to the code will invalidate the certification.

This makes sense on two levels.  Logically, if the code has changed
from what was inspected and certified, we can no longer have the same
guarantees that the security properties have been preserved.  And
in terms of syntax, with the TCPA Validation Certificate holding a
hash of the certified code, making any change will change the hash
and so the certificate will be invalid.

The result is that any modification to the code, no matter how slight,
will change the hash and keep it from being usable with the old VC.
Of course, the same thing happens with commercial code.  But GPL tends
to rely more on frequent, small, incremental changes - "release early
and often".  This practice will not work well with a hash-based security
certification concept.

There may be some creative workarounds possible for "trusted Linux"
developers.  They could set up their own certification infrastructure
and allow core Linux kernel team members to issue certs.  Especially
if TCPA is not used on Windows systems, as seems likely to be the case
now, Linux kernel developers will have considerable leverage in working
out the best way to tackle this problem.

Keep in mind, too, that one can make a strong case that open source
code in general is a far better fit for the general concept of remote
trust that TCPA/Palladium attempt to build.  If your trusted system is
running code whose source you can inspect, code which you might even be
able to build yourself from source, you can have much greater confidence
and peace of mind when you allow it to run on your system.  I would be
much more likely to trust a piece of software that was going to lock up
its data, if I could be confident of exactly what it was doing.

Adam Back wrote earlier about ideas to let the user inspect the data
stream into or out of a Palladium application.  I responded that this
would invalidate the security guarantees for a large and interesting
class of apps, such as the secure P2P enhancements I have sketched.
But you can achieve much of what Adam wanted simply by choosing to run
open source Palladium apps.  Those are the ones where you know exactly
what you are trusting the system to do.  They are the ones that you know
have no backdoor, spyware, or other objectionable, secret features.

And note that in the context of application programs, there is no need
for the OS certification described above.  Trust in these programs would
be handled on a completely decentralized basis, with each distributed
application handling its own trust decisions.  There would be no
centralized certification system.  Rather, the software would decide
for itself which versions to trust.

Summing up, it is at best a vast oversimplification to say that TCPA is
a GPL-killer.  It may cause some problems specifically for Linux due to
the need to get certifications that are widely accepted.  But it sounds
like HP and possibly IBM are going to at least get the ball rolling
with these certifications, so we can expect a TCPA compliant Linux in
some form.  And Linux developers may be able to come up with mechanisms
that will allow them to continue making frequent Linux releases while
still being able to support TCPA features.

For general applications, TCPA/Palladium could be a tremendous marketing
opportunity for open source.  Transparency and trust go together like
hand in glove.  In the long run I think the open source community will
thrive and benefit from TCPA and Palladium.