octane indice <[email protected]> wrote:
> 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?
Yes, those commands use the SRK to seal.
>> 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".
Sadly, there aren't (yet) any command-line tools for creating
new keys; adding some is on my to-do list for one of these
days, but don't get your hopes up. Maybe someone else will
add some.
In the meantime, you can use the TrouSerS library to create
and use keys other than the SRK. The relevant functions I've
used are Tspi_Key_CreateKey, or Tspi_TPM_CollateIdentityRequest
for creating identity keys (AIKs), although there
are others. If you don't need a complex key hierarchy and are
just sealing and unsealing data, however, you shouldn't need to
worry about creating and loading keys.
>> 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.
Nope, sorry. Right now, it's SRK-only.
>> 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?
Yes, exactly. (Although your file really does have *both* halves
of the key; we just don't do anything particularly interesting with
the public half in the situations we've been discussing, and only
the private half is encrypted.)
> 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.
If you only have one expected user on the system and
you just want to make sure that no one can reboot your
machine into a different OS and access your file, or to
do a basic trusted boot test (where you, say, seal a
picture of your choosing, and if it displays properly after
unsealing you know the machine is in the expected state)?
There's no real difference; all of those use cases rely only
on the PCR constraints on the seal blob itself.
An example of when using non-SRK keys *is* useful:
If you have multiple users on the system, you might not
want all users to have access to all sealed data, regardless
of the system configuration; however, if all users need TPM
functionality, your SRK secret will probably be well-known
(either literally or with a shared password). Sealed blobs
cannot themselves require authentication to unseal.
However, TPM *keys* can require authentication to use.
Giving each system user a storage key of their own, with a
password known only to that user, allows users to seal data
for their own personal use.
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
