En réponse à "Segall, Ariel E" <[email protected]> :
> 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.
>
So, that's what I'm using.
I took ownership of the Key and I use trustedGrub.
Then I can use my key:
tpm_sealdata -z -p4 -p8 -p9 -p14 -i clear.key -o seal.key
shred clear.key
And when I need to use my private data, I use
tpm_unsealdata -i seal.key
I use the Storage Root Key. Is it?
> 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;
Can you give the list of command you use? That's
what I don't clearly understand with
"when a new key is created".
> 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.)
>
Ok.
> 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*.
>
Ok, so that's what I'm expecting when typing:
tpm_unsealdata -z -i seal.key
> 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.
>
Ok. But there's no tool for it, like tpm_sealdata
and tpm_unsealdata? At least, their man doesn't
mention how to use them with a handle.
> Does that answer your question?
>
I think that an example would help me very much.
For the tpm_sealdata and tpm_unsealdata, I
understand what's going on.
But for that loading keys, I have some trouble
of seeing what's happen.
-I create a Key
-I have a half of this key in a file I store wherever I
want
-I can then load this half key and ask TPM to uncipher
some datas. The datas will then get deciphered (If the
PCRs are OK)
But there's no high level tool for doing it?
And more; what's the difference?
What's important is the way that PCRs are filled
when asking for TPM operations. What's the difference
for using an unseal operation with
tpm_unsealdata
and unseal data using a half key? I'm not sure taking
the point, but maybe I don't understand how it works.
> Ariel
> ------------------- Fin du message d'origine ---------------------
Envoyé avec Inmano, ma messagerie renversante et gratuite :
http://www.inmano.com
------------------------------------------------------------------------------
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
