Re: [TrouSerS-users] Sealing data for a remote system?

[Kent Y. <shp...@gm...>]

Hi Torsten,

  First, a couple of things:  I think your definitions of Seal and
Unseal are ok.  See the FAQ for clarifications:
http://trousers.sf.net/faq.html#4.5.

> I am trying to use the TPM to encrypt data so that it is only
> decryptable by a specific remote system under a certain configuration.

  Ok, I think what you might want is something similar to tpm_keyring,
an app I wrote to test out the TSS.  It generates an openssl keypair
and then wraps the private key with other user's TPM's SRK public key,
giving other users the ability to use the openssl key on their machine
without letting them see the private key or distribute it further.  In
tpm_keyring, however, I used Bind to encrypt the data using this key,
where you would want Seal.  That'd be a useful feature for me to add.=20
More details on how tpm_keyring works are in the README in CVS under
applications/tpm_keyring.

> >From the TCG Specification Architecture Overview
> (https://www.trustedcomputinggroup.org/downloads/TCG_1_0_Architecture_Ove=
rview.pdf) I gather from section 4.2.6.3, that sealing should be exactly wh=
at I need: "Sealed messages are bound to a set of platform metrics specifie=
d by the message sender. Platform metrics specify platform configuration st=
ate that must exist before decryption will be allowed."
>=20
> Therefore it should be easy to use the Seal function to create a blob
> which can only be decrypted using the private key of a foreign TPM with
> given metrics.
>=20
> Now the manpage of Tspi_Data_Seal reads:
>=20
>   "Encrypt a data blob in a mannar that is only decryptable by
> Tspi_Data_Unseal on the same system."

  Its not necessarily "on the same system", that is a bit misleading.=20
If the key used to encrypt is the same, and the PCR's that are
selected at Seal time are the same as at Unseal time on *any* system,
the data can be unsealed.

> Apart from the typo (patch attached) this seems to suggest that sealed
> data is just to be decrypted on the same platform. There are some
> obvious use cases for that feature but sadly that's not usable to me.

  Hopefully my comment above opens the door you are looking for...
=20
> So - how is the intended protocol to encrypt some data for a specific
> target system and state? I know that it is possible to create keys that
> are only usable under given configuration metrics but that's hardly what
> I would like to use. Apart from the complicated protocol that I could
> envision (Alice talking to Bob to give him something for his eyes only:)
>=20
> 1. Alice sends Bob a challenge C and a request R for his configuration
> 2. Bob uses the Quote function to sign C, including his PCR values and
> the public part of a key K, which is bound to that configuration,
> sending this to Alice
> 3. Alice checks the Quote and send the secret bound to K
> 4. Bob unbinds the secret
>=20
> This protocol looks really sucky. Any suggestions how it could be
> improved? Did I misunderstand Seal and Unseal?

  As for the design of this type of system, I don't feel qualified to
answer this question. :-)  There seems to be some interest on this
list from those who'd like to discuss the theory here, so perhaps
others will chime in.  I think what you may ultimately be after is a
remote attestation solution, which will probably not materialize for
some time (see the FAQ for info on its dependencies).

thanks for the patch,
Kent