Thread hijack: TPM-> Intel vPro (Protecting keys using a TPM)

[Martin Paljak]

Hello,

I'd like to abuse the opportunity of people discussing TPM-s (a weird
thing) and ask, if anyone knows more about the even weirder "smart
card like technology built into intel latest CPU-s" in vPro-s ?

Now I have one of those CPU-s in my latop and I'd like to make use of
the technology... But there's almost no easy information about them
available anywhere.

Martin

On Mon, Mar 18, 2013 at 6:15 PM, Kent Yoder <shpedoikal at gmail.com> wrote:
> Hi Ross, now that I'm back from vacation I'll respond with a little
> more detail that might help.
>
> On Thu, Mar 7, 2013 at 12:44 PM, Ross McIlroy <rmcilroy at google.com> wrote:
>> Hi,
>>
>> I'm currently looking into improving the end-to-end support for storing and
>> accessing private keys / certificates on TPM devices on Linux.  At present
>> it is possible to use OpenCryptoKI to provide a PKCS#11 interface to the
>> TPM, however, there are a number of issues which make doing so inconvenient:
>>
>>    - (i) Applications need to be configured to explicitly dlopen the
>> OpenCryptoKI pcsk11 module library
>>    - (ii) They need to discover which slot holds the TPM token (if any)
>>    - (iii) They need to provide a pin to OpenCryptoKI to login to the TPM
>> token to perform any operations (e.g., signing, encryption, etc.) with the
>> private keys stored there or to add new keys.  Since this pin is not linked
>> to the users login credentials, it's an added complication for them, as well
>> as an added complication for developers who need to provide some gui /
>> command-line pin input mechanism.
>>
>> p11-kit seems a good place to start to address (i) - if p11-kit becomes the
>> standard for merging the system-wide pkcs11 modules, then apps only need to
>> load a single well-known module to have access to all the keys provided,
>> including those on the TPM.
>
>   i, ii, and iii are all pkcs11-only issues, unrelated to the TPM.
> IMHO it sounds like p11-kit would be a good place to try to solve
> them.
>
>   For some background on opencryptoki's tpm token - one of the things
> we wanted to accomplish there was migration support. If your TPM dies
> we wanted to be able to take the entire opencryptoki TPM token data
> store and move it to a new machine. To do this we created 2 new keys
> which serve as the roots of the TPM key hierarchy for pkcs11 public
> objects and pkcs11 private objects.  We create these 2 keys using
> openssl in software, then wrap them both using the SRK.  These are
> stored internally to opencryptoki and are the parents of all keys
> created through pkcs11.
>
>   Because of the migration support, key importing becomes an issue. If
> you've got a key lying around on your filesystem who's parent is the
> SRK, we have no way to import it into opencryptoki and guarantee
> migration support.
>
>   Perhaps we could hack opencryptoki so that it can accept keys whos
> parent is the SRK.  We have no plans to do this atm, but it might be
> worthwhile in the interests of creating a single centralized keystore.
>  On the other hand it sounds like several people have already added
> native TSS support.
>
> Kent
> _______________________________________________
> p11-glue mailing list
> p11-glue at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/p11-glue