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

Carolin Latze <> Wed, 14 October 2009 14:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7106B3A6A03 for <>; Wed, 14 Oct 2009 07:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_25=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9oyeH-1gJiin for <>; Wed, 14 Oct 2009 07:00:55 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6B7CF3A691B for <>; Wed, 14 Oct 2009 07:00:55 -0700 (PDT)
Received: from ([]) by stage1 with esmtp with id 1My4PB-0006e8-TQ for <> from <>; Wed, 14 Oct 2009 16:00:41 +0200
Message-ID: <>
Date: Wed, 14 Oct 2009 15:58:39 +0200
From: Carolin Latze <>
User-Agent: Thunderbird (X11/20090916)
MIME-Version: 1.0
To: "" <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: Re: [TLS] [Fwd: {Virus?} I-D Action:draft-latze-tls-tpm-extns-00.txt]
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Oct 2009 14:00:57 -0000 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: [] On Behalf Of
>> ext Carolin Latze
>> Sent: 09 October, 2009 11:05
>> To: Blumenthal, Uri
>> Cc: ''
>> 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 <>
>>> 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: <>
>>>> To: <>
>>>> 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: <>
>>>> Reply-To: <>
>>>> To: <>
>>>> 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:
>>>> Internet-Drafts are also available by anonymous FTP at:
>>>> 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

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: +41 26 300 83 30			+41 79 72 965 27