[PATCH] enhanced smartcard support

[Carolin Latze]

Hi Jouni,

I will send them the next week. I also found a way to use private keys 
that never leave the TPM. There are two ways to do so. One of the is to 
use new certificate, that are not X.509 compliant, which is desired in 
my setup, but perhaps not for everybody. The other way is to use SKAE 
aware certificates, which are X.509 certificates, but require a SKAE 
aware CA, which does not exist atm (at least from what I know). I will 
try to explain that more detailed:

The TPM may generate keys that do never leave it (at least the private 
part ;-)) and may be used for certification purposes. Those keys are 
called identity keys. In order to certify those keys, a request is sent 
to a special CA, called Privacy CA. At the moment, there is one Privacy 
CA up and running: www.privacyca.com In order to sign an identity key, 
the Privacy CA needs some certificates from the TPM, that should be 
shipped with it. But at the moment only Infineon ships one of the 
certificates needed. The guy who implemented www.privacyca.com is aware 
of that problem and allows to create the identity certificate without 
those additional certificates. The identity certificate is then a valid 
X.509 certificate. But for some reasons, those keys cannot be used in 
TLS authentication (the TPM standard forbids that, don't ask me why). 
Therefore, you have to create new keys, that do also never leave the 
TPM. Those new keys will be signed by that X.509 identity certificate. 
And now it becomes complicated: A signed key is somehow a certificate, 
BUT the identity certificate has the CA:false constraint, which means, 
that the signed key will never be valid X.509! Additionally, the items 
that are signed are different from the items that are signed in X.509.

Up to now, there are two solutions for that problem:

1) My solution :-)
As the signed key is somehow a certificate I defined a new type of 
certificate called TPM-Certificate. This certificate looks very similar 
to X.509, but carries the TPM relevant items. I am working on an OpenSSL 
extension in order to handle this type of certificates. I think, that is 
a very nice, easy and obvious solution :) I will inform you when I 
finished my work. I have already a first prototype running, but that is 
more a hack. I am working on a better version now.

2) SKAE:
This solution has been defined by the trusted computing group in order 
to be able to work with X.509 certificates. SKAE is an X.509 extension 
that carries the signed items. The idea is to generate a new certificate 
request for the signed key including the SKAE extension. This request is 
then sent to a SKAE aware CA (which does not exist at the moment as far 
as I know) which signs everything like always done in X.509 and issues a 
valid X.509.

Well I must admit, this TPM authentication is terribly complicated, but 
don't hesitate to ask in order to understand whats going on!

Regards
Carolin

Jouni Malinen wrote:
> On Fri, May 23, 2008 at 10:52:55AM +0200, Carolin Latze wrote:
>
>   
>> I am still subscribed to this list, but did not really follow it. I just 
>> read something about how to create the TPM into wpa_supplicant and I 
>> have to say that I got it working. I cannot provide a patch till now, 
>> but will prepare one if you are interested in it. I am able to store 
>> X.509 certificates in the TPM and access the TPM during EAP-TLS 
>> authentication. I used the OpenSSL TPM engine in order to implement that 
>> feature.
>>     
>
> If your changes do something else than the patches from David, I would
> be interested in seeing them. I applied David's patches and they allow
> PKCS#11 engine to be used with opencryptoki module to access the
> certificates and private key from TPM.
>
>