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

[<[e-mail]>]

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... (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