octane indice <[email protected]> wrote:
>"Segall, Ariel E" <[email protected]> wrote:
>> ------------------ --------------------
>>
>> I can't speak to the testsuite code, but:
>>
>> > - what does it mean exactly to load a key ?
>>
>> Keys created by the TPM are returned to the user as a "key
>> blob", which contains the public key, the encrypted private
>> key, and some information about the key.
>> In order for the key to be used, it must be loaded: the user
>> provides the blob to the TPM, and the TPM decrypts the
>> private key and holds it in its internal memory for use.
>>
>> In the TSS, loading a key can sometimes be used simply
>> to get a TSS-level key handle, when the key (such as
>> the SRK) is already stored within the TPM.
>>
>> (I'm glossing over some of the finer details; does that answer
>> your question, or do you need more?)
>>
>I can't speak for anybody, but I personnaly need more.
>
>Do you speak of the operation of sealing and
>unsealing data?
No, although there are some similarities.
When data is sealed by the TPM, the TPM returns a sealed blob with the data
encrypted, along with a similar set of information about the data blob. (For
example, a Seal blob includes the state of the TPM's PCRs at the time the blob
was created, and may optionally include a set of PCR values required for the
blob to be unsealed.) Sealed data is encrypted using either a TPM storage key
or the Storage Root Key; we call this the parent key.
Similarly, when a new key is created by the TPM, the TPM returns a blob with
the private key data encrypted, along with cleartext information about the key:
the type of the key, its public half, the PCR state required for this key to be
used, the key's length and algorithm, etc. Every new key also has a parent key;
just as with Seal, the parent is the key used to encrypt the private key half.
This blob is returned to the user, and the key does *not* remain in the TPM:
the TPM has very limited memory, and so the responsibility for tracking and
preserving keys is delegated to the user. The only two keys for which this is
*not* true are the Endorsement Key and the Storage Root Key. The SRK is
guaranteed to be present (assuming you haven't erased it by clearing the TPM,
but that's another topic) and is what allows you to store other keys in their
encrypted blobs on disk: it's the *root*, the parent that you never need to
load. (The SRK is created during the TakeOwnership command; that command does
return a key blob, but it's a key blob with no encrypted private portion, used
for informational purposes only.)
However, the unseal operation is *completely* different from LoadKey. Unseal
takes a Seal blob, and if the indicated parent key is available within the TPM
(is the SRK, or is a loaded TPM storage key, any PCR constraints on the key are
met, and any authorization data has been provided) the TPM will decrypt the
data in the blob and *return the decrypted data to the user*.
In contrast, the LoadKey operation-- I'm skipping the special case of the SRK
right now-- takes a WrapKey blob and an indicated parent key, and similarly
verifies the availability of the parent. However, if the private key can
successfully be decrypted, it is *not* returned to the user. The private key is
loaded into the TPM's internal memory, and a *handle* -- not the key itself--
is returned to the user. The user can then use that handle as input for the
many other TPM commands which call for user-provided keys. (For example, if I
had my very own storage key that I wanted to use for sealing and unsealing
data, I would first load it, and then call the Unseal command with the key
handle I got from the LoadKey command. If I wanted to sign data, I would first
load a signing key, and use that handle.) The handles returned by the TSS are
an abstraction of the handles returned by the TPM, because the TSS key
management does provide some handy features like keeping the user from caring
about the TPM's tendency to swap out keys when it runs out of memory; running
LoadKeyByUUID on the SRK gets you a TSS-level handle for it, even though you're
not actually *loading* the SRK.
Does that answer your question?
Ariel
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
TrouSerS-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/trousers-users