Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]

[Carolin Latze <[e-mail]>]

[e-mail] wrote:
> TCG-compliant AIK Certificates are pretty much useless for authenticating
> devices, since the whole point of Privacy CA and AIK Certificates is to 
> hide the real device identity/identifier for privacy purposes.
> A valid AIK Credential asserts that the AIK private key is in *some*
> genuine conforming TPM, but doesn't really contain device identifiers 
> that would be useful for authentication of a specific device. 
>
> IMHO situations where you'd want to allow access to anyone who has
> a genuine TPM (but nobody else) are pretty rare... 
[CL] At the moment, yes. But that might change in the future. I can
imagine scenarios, where it is sufficient to know that the client device
has a genuine TPM. Further remote attestation might follow later (or
might not be necessary). Maybe it is sufficient, that the client has an
AIK from a certain Privacy CA, because I, as a server, trust that
Privacy CA, and since the client has a genuine TPM, I also know that the
certificate really belongs to him (private key has not been copied to
other machine etc). I can also imagine scenarios, where you bind a
person to a device by contract or a scenario where you sell/provide
devices that should be able to connect to your TLS secured services, so
maybe, you run a Privacy CA yourself.... For me that depends on the
business case itself.... (and I can also imagine scenarios, where it
does not make any sense at all :-)).
> (and would 
> probably involve a "remote attestation" about what software the
> device is currently running -- so don't really belong in TLS anyway).
> Best regards,
> Pasi
> (not wearing any hats)
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of
>> ext Carolin Latze
>> Sent: 09 October, 2009 11:05
>> To: Blumenthal, Uri
>> Cc: '[e-mail]'
>> Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-
>> 00.txt]
>>
>> Ok,
>>
>>     
>>> Are you implying that CA-certified certs are less secure than self-
>>>       
>> signed ones?! Or that getting your TPM-provided Public Key signed by a
>> CA lessens its security?
>>     
>> [CL] No, nothing like that. I think my english might be a problem, but
>> I
>> try to explain what I mean:
>>
>> TPMs come with the possibility to create so called attestation identity
>> keys (AIKs) that will be signed by a certain certificate authority
>> called Privacy CA  resulting in an AIK certificate. The process of
>> signing by the Privacy CA includes verifying that those keys have been
>> generated by a genuine TPM. The private part of the AIK never leaves
>> the
>> TPM, which means that the AIK certificates prove that they belong to a
>> genuine, given TPM. The AIK certificate is a valid X.509 certificate,
>> which can be verified using the standard X.509 verification functions.
>> So if you use those certificates in authentication protocols you can
>> authenticate devices (using their TPM). But, unfortunatly, those keys
>> have some restrictions which makes it impossible to use them in TLS
>> direclty:
>>
>> 1) they are restricted to SHA-1 signing (well, that should not be a
>> problem with TLS 1.2)
>> 2) they only sign data that originates in the TPM (that means in order
>> to use them with TLS, every data that has to be signed has to originate
>> in the TPM, which is not impossible and might be useful in some cases,
>> but is rather complicated)
>>
>> In order to be able to use something like the AIKs in authentication,
>> the TPM standard propose to define new keys (with the property that the
>> private part never leaves the TPM) and sign them using the AIK. That
>> signing process is also defined in the standard and results in a
>> special
>> structure called TCPA_CERTIFY_INFO. That structure proves that a
>> certified key has been signed by a valid AIK, which itself can be
>> verified using standard X.509 verification techniques. Unfortunatly,
>> TCPA_CERTIFY_INFO does not have the same format like X.509. The
>> certified key could be used in TLS directly, but how do we verify that
>> it belongs to a given TPM? There are several solutions that all rely on
>> the fact, that the AIK certificate proves that this certificate key
>> belongs to a genuine, given TPM:
>>
>> 1) Make it an X.509 certificate signed by the AIK (=> results in
>> complete easy to verify chain). This is not possible since the AIK
>> certificate carries the CA:false constraint.
>> 2) Make it an X.509 proxy certificate of the AIK. Not possible since
>> the
>> subject of the AIK is NULL.
>>
>> Those would be the easy possibilities, but since they do not work, the
>> TCG defined a new X.509 extension to carry the TCPA_CERTIFY_INFO
>> structure called SKAE. Again two possibilities arise to make use of
>> that
>> extension:
>>
>> 1) Generate a new X.509 certificate request around the certified key,
>> include the SKAE extension, and send the request to a CA to sign it.
>> This results in a standard X.509 certificate that can be used for TLS.
>> But if the server wants to ensure that this certificate is bound (= the
>> private key never leaves the TPM) to a certain genuine TPM, he has to
>> verify the SKAE extension too. That means he has to get the AIK
>> certificate too, which is not part of the chain. The SKAE extension
>> carries a hint where to find that certificate.  Now my opinion to that
>> approach: A second certificate request is needed (apart from the AIK
>> certificate request needed anyway), which is overkill (just my opinion,
>> I know, that other people do not have a problem with that) and - and
>> thats the bigger problem from my point of view - if the server really
>> wants to verify that the keys originates from a given, genuine TPM, he
>> has to download, request, get ... the AIK in addition to what he gets
>> out of the TLS handshake. So there has to be some kind of storage for
>> the AIK certificates, that either sends the AIK certificates to all the
>> servers or receives SKAE extensions from servers to validate them. I
>> think that might result in scalability problems (just my opinion).
>> 2) Generate an X.509 self-signed certificate around the certified key
>> including the SKAE extension, use it in the handshake and send the AIK
>> certificate that verifies the SKAE extension within the supplemental
>> data handshake message. I think that approach has a better scalability.
>>
>> BTW: Everything I described above is only needed if you want to use
>> those special keys. If you only want to use the TPM as a key storage
>> and
>> secure provider for functions like signing etc, there is no need for
>> any
>> modification to TLS and X.509. The reason why I want to use those
>> special keys is that they are available and have those nice properties
>> of being (provable) bound to a genuine, given TPM. If you ask me now to
>> ignore those keys if they introduce those difficulties then I think
>> that
>> is a valid conclusion. I only think that there should be a possibility
>> to use them if they are available.
>>     
>>> And how can self-signed certs be possibly bound to "identity certs
>>>       
>> signed by a CA"?
>>     
>> [CL] Using that SKAE extension explained above.
>>     
>>> I still don't understand your justification (or reasons) for mucking
>>>       
>> with a perfectly usable TLS model.
>>     
>> [CL] I think I tried to explain that above
>>     
>>> Perhaps you'd want to describe in a few sentences what it is that
>>>       
>> you're trying to accomplish with TPM-generated public keys, and how TLS
>> as-is does not allow that? And why what you're trying to do would of
>> interest to anybody else on the planet who uses TPM and/or TLS?
>>     
>> [CL] I think I tried to explain that too. I think, AIKs and certified
>> keys are a good possibility to authentication TPM equipped devices even
>> if they introduce some difficulties. But I also see the problem that
>> TLS
>> has been available much longer than TPMs, so it would have been easy to
>> adapt the TPM to TLS needs instead to do it vice versa. I have not been
>> part of the TPM standardization although I try to discuss with TCG
>> people too. There might be good reason for the things they defined that
>> I do not see at the moment. And since TPMs are already shipped with all
>> the features described above I try to make it usable like that.
>>     
>>> ----- Original Message -----
>>> From: Carolin Latze <[e-mail]>
>>> To: Blumenthal, Uri
>>> Sent: Thu Oct 08 04:02:09 2009
>>> Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-
>>>       
>> extns-00.txt]
>>     
>>> They are still valid X.509... the only difference is that they are
>>> self-signed and not CA-signed. And the reason to use self-signed
>>> certificates is that you don't need to send another certificate
>>>       
>> request
>>     
>>> without loosing security since the self-signed certificates are bound
>>>       
>> to
>>     
>>> identity certificates that are signed by a CA.
>>>
>>> Blumenthal, Uri wrote:
>>>
>>>       
>>>> And the reason you want to do this instead of using valid X.509
>>>>         
>> certs is...?
>>     
>>>> ----- Original Message -----
>>>> From: [e-mail] <[e-mail]>
>>>> To: [e-mail] <[e-mail]>
>>>> Sent: Wed Oct 07 11:16:52 2009
>>>> Subject: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-
>>>>         
>> 00.txt]
>>     
>>>> Hi all,
>>>>
>>>> after several experiments with TPMs as authentication devices in
>>>> EAP-TLS, we figured out, that the specific modifications in order to
>>>>         
>> use
>>     
>>>> TPMs might be rather an extension to TLS than an EAP extension.
>>>> Therefore, we gave it a try and defined a new TLS extension in order
>>>>         
>> to
>>     
>>>> use TPM certified keys directly with TLS. We are aware of the fact,
>>>>         
>> that
>>     
>>>> there is a possibility to request new valid X.509 certificates for
>>>>         
>> those
>>     
>>>> keys which allows to use them with standard TLS (and do not require
>>>>         
>> a
>>     
>>>> new extension), but since we want to avoid that request (and we
>>>>         
>> think
>>     
>>>> that this does not introduce any security issues), we propose this
>>>> extension.
>>>>
>>>> We are always open for discussions, (critical) feedback,
>>>>         
>> suggestions, ...
>>     
>>>> Regards
>>>> Carolin Latze
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: 	{Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt
>>>> Date: 	Wed, 7 Oct 2009 16:45:01 +0200
>>>> From: 	[e-mail] <[e-mail]>
>>>> Reply-To: 	[e-mail] <[e-mail]>
>>>> To: 	[e-mail] <[e-mail]>
>>>>
>>>>
>>>>
>>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>>>         
>> directories.
>>     
>>>> 	Title           : Transport Layer Security (TLS) Extensions for
>>>>         
>> the Trusted Platform Module (TPM)
>>     
>>>> 	Author(s)       : C. Latze, et al.
>>>> 	Filename        : draft-latze-tls-tpm-extns-00.txt
>>>> 	Pages           : 10
>>>> 	Date            : 2009-10-07
>>>>
>>>> Trusted Platform Modules (TPMs) become more and more widespread in
>>>> modern desktop and laptop computers and provide secure storage and
>>>> cryptographic functions.  As one nice feature of TPMs is that they
>>>> can be identified uniquely, they provide a good base for device
>>>> authentication in protocols like TLS.This document specifies a TLS
>>>> extension that allows to use TPM certified keys with TLS in order to
>>>> allow for a secure and comfortable device authentication in TLS.
>>>>
>>>> A URL for this Internet-Draft is:
>>>> http://www.ietf.org/internet-drafts/draft-latze-tls-tpm-extns-00.txt
>>>>
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> ftp://ftp.ietf.org/internet-drafts/
>>>>
>>>> Below is the data which will enable a MIME compliant mail reader
>>>> implementation to automatically retrieve the ASCII version of the
>>>> Internet-Draft.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>         
>>>       
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>     

-- 
Carolin Latze
PhD Student				ICT Engineer

Department of Computer Science		Swisscom Strategy and Innovation
Boulevard de Pérolles 90		Ostermundigenstrasse 93
CH-1700 Fribourg      			CH-3006 Bern
	
phone: [phone]			[phone]
homepage: http://diuf.unifr.ch/people/latzec