Challenge to David Wagner on TCPA

[Brian A. LaMacchia]

I just want to point out that, as far as Palladium is concerned, we really
don't care how the keys got onto the machine. Certain *applications* written
on top of Palladium will probably care, but all the hardware & the security
kernel really care about is making sure that secrets are only divulged to
the code that had them encrypted in the first place.  It's all a big trust
management problem (or a series of trust management problems) --
applications that are going to rely on SCP keys to protect secrets for them
are going to want some assurances about where the keys live and whether
there's a copy outside the SCP.  I can certainly envision potential
applications that would want guarantees that the key was generated on the
SCP & never left, and I can see other applications that want guarantees that
the key has a copy sitting on another SCP on the other side of the building.

So the complexity isn't in how the keys get initialized on the SCP (hey, it
could be some crazy little hobbit named Mel who runs around to every machine
and puts them in with a magic wand).  The complexity is in the keying
infrastructure and the set of signed statements (certificates, for lack of a
better word) that convey information about how the keys were generated &
stored.  Those statements need to be able to represent to other applications
what protocols were followed and precautions taken to protect the private
key.  Assuming that there's something like a cert chain here, the root of
this chain chould be an OEM, an IHV, a user, a federal agency, your company,
etc. Whatever that root is, the application that's going to divulge secrets
to the SCP needs to be convinced that the key can be trusted (in the
security sense) not to divulge data encrypted to it to third parties.
Palladium needs to look at the hardware certificates and reliably tell
(under user control) what they are. Anyone can decide if they trust the
system based on the information given; Palladium simply guarantees that it
won't tell anyone your secrets without your explicit request..

                    --bal

P.S. I'm not sure that I actually *want* the ability to extract the private
key from an SCP after it's been loaded, because presumably if I could ask
for the private key then a third party doing a black-bag job on my PC could
also ask for it.  I think what I want is the ability to zeroize the SCP,
remove all state stored within it, and cause new keys to be generated
on-chip.  So long as I can zero the chip whenever I want (or zero part of
it, or whatever) I can eliminate the threat posed by the manufacturer who
initialized the SCP in the first place.

Lucky Green <shamrock at cypherpunks.to> wrote:
> Ray wrote:
>>
>>> From: "James A. Donald" <jamesd at echeque.com>
>>> Date: Tue, 30 Jul 2002 20:51:24 -0700
>>
>>> On 29 Jul 2002 at 15:35, AARG! Anonymous wrote:
>>>> both Palladium and TCPA deny that they are designed to restrict
>>>> what applications you run.  The TPM FAQ at
>>>> http://www.trustedcomputing.org/docs/TPM_QA_071802.pdf reads
>>>> ....
>>>
>>> They deny that intent, but physically they have that capability.
>>
>> To make their denial credible, they could give the owner
>> access to the private key of the TPM/SCP.  But somehow I
>> don't think that jibes with their agenda.
>
> Probably not surprisingly to anybody on this list, with the exception
> of potentially Anonymous, according to the TCPA's own TPM Common
> Criteria Protection Profile, the TPM prevents the owner of a TPM from
> exporting the TPM's internal key. The ability of the TPM to keep the
> owner of a PC from reading the private key stored in the TPM has been
> evaluated to E3 (augmented). For the evaluation certificate issued by
> NIST, see:
>
> http://niap.nist.gov/cc-scheme/PPentries/CCEVS-020016-VR-TPM.pdf
>
>> If I buy a lock I expect that by demonstrating ownership I
>> can get a replacement key or have a locksmith legally open it.
>
> It appears the days when this was true are waning. At least in the PC
> platform domain.
>
> --Lucky
>
>
> ---------------------------------------------------------------------
> The Cryptography Mailing List
> Unsubscribe by sending "unsubscribe cryptography" to
> majordomo at wasabisystems.com


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