Cryptographic privacy protection in TCPA

[Nomen Nescio]

Carl Ellison suggested an alternate way that TCPA could work to allow
for revoking virtualized TPMs without the privacy problems associated
with the present systems, and the technical problems of the elaborate
cryptographic methods.

Consider first the simplest possible method, which is just to put a
single signature key in each TPM and allow the TPM to use that to sign
its messages on the net.  This is reliable and allows TPM keys to be
revoked, but it obviously offers no privacy.  Every usage of a TPM key
can be correlated as coming from a single system.

TCPA fixed this by adding a trusted third party, the "Identity CA" who
would be the only one to see the TPM key.  But Carl offers a different
solution.

Instead of burning only one key into the TPM, burn several.  Maybe even
a hundred.  And let these keys be shared with other TPMs.  Each TPM has
many keys, and each key has copies in many TPMs.

Now let the TPMs use their various keys to identify themselves in
transactions on the net.  Because each key belongs to many different
TPMs, and the set of TPMs varies for each key, this protects privacy.
Any given usage of a key can be narrowed down only to a large set of
TPMs that possess that key.

If a key is misused, i.e. "scraped" out of the TPM and used to create a
virtualized, rule-breaking software TPM, it can be revoked.  This means
that all the TPMs that share that one key lose the use of that key.
But it doesn't matter much, because they each have many more they can use.
Since it is expected that only a small percentage of TPMs will ever need
their keys revoked, most TPMs should always have plenty of keys to use.

One problem is that a virtualized TPM which loses one of its keys will
still have others that it can use.  Eventually those keys will also be
recognized as being mis-used and be revoked as well.  But it may take
quite a while before all the keys on its list are exhausted.

To fix this, Carl suggests that the TPM manufacturer keep a list of all
the public keys that are in each TPM.  Then when a particular TPM has
some substantial fraction of its keys revoked, that would be a sign that
the TPM itself had been virtualized and all the rest of the keys could be
immediately revoked.  The precise threshold for this would depend on the
details of the system, the number of keys per TPM, the number of TPMs that
share a key, the percentage of revoked keys, etc.  But it should not be
necessary to allow each TPM to go through its entire repertoire of keys,
one at a time, before a virtualized TPM can be removed from the system.

Carl indicated that he suggested this alternative early in the TCPA
planning process, but it was not accepted.  It does seem that while
the system has advantages, in some ways it shares the problems of the
alternatives.  It provides privacy, but not complete privacy, not as
much as the cryptographic schemes.  And it provides security to the TPM
issuers, but not complete security, not as much as the Privacy CA method.
In this way it can be seen as a compromise.  Often, compromise solutions
are perceived more in terms of their disadvantages than their benefits.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at wasabisystems.com