Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Arm Limitedhannes.tschofenig@arm.comArm LimitedThomas.Fossati@arm.comArm LimitedPaul.Howard@arm.comArm LimitedIonut.Mihalcea@arm.comArm LimitedYogesh.Deshpande@arm.com
Security
TLSInternet-DraftVarious attestation technologies have been developed and formats have been standardized.
Examples include the Entity Attestation Token (EAT) and Trusted Platform Modules (TPMs).
Once attestation information has been produced on a device it needs to be communicated
to a relying party. This information exchange may happen at different layers in the
protocol stack.This specification provides a generic way of passing attestation information in the
TLS handshake.Attestation is the process by which an entity produces evidence about itself
that another party can use to evaluate the trustworthiness of that entity.
One format of encoding evidence is standardized with the Entity Attestation
Token (EAT) but there are other formats, such as
attestation produced by Trusted Platform Modules (TPMs) .This specification defines how to convey attestation information in the
TLS handshake with different encodings being supported. This specification
standardizes two attestation formats – EAT and TPM-based attestation.Note: This initial version of the specification focuses on EAT-based attestation.
Future versions will also define TPM-based attestation.The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,
“SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119 .The following terms are used in this document:Root of Trust (RoT): A set of software and/or hardware components that need
to be trusted to act as a security foundation required for accomplishing the
security goals. In our case, the RoT is expected to offer the functionality
for attesting to the state of the platform.Attestation Key (AK): Cryptographic key belonging to the RoT that is only used
to sign attestation tokens.Platform Attestation Key (PAK): An AK used specifically for signing attestation
tokens relating to the state of the platform.Key Attestation Key (KAK): An AK used specifically for signing KATs. In some
systems only a single AK is used. In that case the AK is used as a PAK and a KAK.TLS Identity Key (TIK): The KIK consists of a private and a public key. The private key is used in the CertificateVerify message during the TLS handshake. The public key is included in the Key Attestation Token.Attestation Token (AT): A collection of claims that a RoT assembles (and signs) with the purpose of informing - in a verifiable way - Relying Parties about the identity and state of the platform. Essentially a type of “Evidence” as per the RATS architecture terminology.Platform Attestation Token (PAT): An AT containing claims relating to the state of the software running on the platform. The process of generating a PAT typically involves gathering data during measured boot.Key Attestation Token (KAT): An AT containing a claim with a proof-of-possession (PoP) key. The KAT may also contain other claims, such as those indicating its validity. The KAT is signed by the KAK. The attestation
service part of the RoT conceptually acts as a local certification authority since the KAT behaves like a certificate.Combined Attestation Bundle (CAB): A structure used to bundle a KAT and a PAT together for transport in the TLS handshake. If the KAT already includes a PAT, in form of a nested token, then it already corresponds to a CAB.The Remote Attestation Procedures (RATS) architecture
defines two types of interaction models for attestation,
namely the passport model and the background-check model. The subsections below
explain the difference in their interactions.To simplify the description in this section we focus on the use case where the
client is the attester and the server is the relying party. Hence, only the
client_attestation_type extension is discussed. The verifier is not shown in
the diagrams. The described mechanism allows the roles to be reversed.As typical with new features in TLS, the client indicates support for the new
extension in the ClientHello. The client_attestation_type extension lists the
supported attestation formats. The server, if it supports the extension and one of the
attestation formats, it confirms the use of the feature.Note: The newly introduced extension also allows nonces to be exchanged. Those
nonces are used for guaranteeing freshness of the generated attestation tokens.When the attestation extension is successfully negotiated, the content of the
Certificate message is replaced with attestation information described in this
document.A peer has to demonstrate possession of the private key via the CertificateVerify
message. While attestation information is signed by the attester, it typically
does not contain a public key (for example via a proof-of-possession key claim
).The attestation service on a device, which creates the attestation information,
is unaware of the TLS exchange and the attestation service does not directly
sign externally provided data, as it would be required to compute the CertificateVerify message.Hence, the following steps happen:The client generates the TIK, which are referred here as skT and pkT, for example
using the following API call:The private key would be created and stored by the crypto hardware supported by
the device (rather than the TLS client in software).Next, the attestation service needs to be triggered to create a Platform
Attestation Token (PAT) and the Key Attestation Token (KAT). The Key Attestation
Token (KAT) includes a claim containing the
public key of the TIK (pkT). The KAT is then signed with the Key Attestation
Key (KAK).To ensure freshness of the PAT and the KAT a nonce is provided by the relying
party / verifier. Here is the symbolic API call to request a KAT and a PAT, which
are concatinated together as the CAB.Once the Certificate message containing the CAB has been sent, the CertificateVerify
has to be created and it requires access to the private key. The signature operation
uses the private key of the TIK (skT).The recipient of the Certificate and the CertificateVerify messages first extracts
the PAT and the KAT from the Certificate message. The PAT and the KAT need to be
conveyed to the verification service, whereby the following checks are made:The signature protecting the PAT passes verification when using available trust anchor(s).The PAT has not been replayed, which can be checked by comparing the nonce included
in one of the claims and matching it against the nonce provided to the attester.The claims in the PAT are matched against stored reference values.The signature protecting the KAT passes verification.The claims in the KAT are validated, if needed.Once all these steps are completed, the verifier produces the attestation result and
includes (if needed) the TIK public key.In the subsections we will look at how the two message pattern fit align with the
TLS exchange.The passport model is described in Section 5.1 of . A key feature
of this model is that the attester interacts with the verification service before initiating
the TLS exchange. It sends evidence to the verification service, which then returns the
attestation result (including the TIK public key).The example exchange in shows how a client
provides attestation to the server by utilizing EAT tokens .
With the ClientHello the TLS client needs to indicate that it supports the EAT-based
attestation format. The TLS server acknowledges support for this attestation type in
the EncryptedExtensions message. In the Certificate message the TLS client transmits the attestation result to the TLS
server, in form a CAB (i.e. a concatinated PAT and KAT).The TLS client then creates the CertificateVerify message by asking the crypto
service to sign the TLS handshake message transcript with the TIK private key.
The TLS server then verifies this message by utilizing the TIK public key.
ServerHello ^ KeyExch
{EncryptedExtensions} ^ Server
+ client_attestation_type(eat) |
{CertificateRequest} v Params
{Certificate} ^
{CertificateVerify} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate}
Auth | {CertificateVerify}
v {Finished} -------->
[Application Data] <-------> [Application Data]
]]>The background check model is described in Section 5.2 of .The message exchange of the background check model differs from the passport
model because the TLS server needs to provide a nonce in the ServerHello to the
TLS client so that the attestation service can feed the nonce into the generation
of the PAT. The TLS server, when receiving the CAB, will have to contact the
verification service.
ServerHello ^ Key
client_attestation_type(eat) | Exch
+ nonce v
{EncryptedExtensions} ^ Server
{CertificateRequest} v Params
{Certificate} ^
{CertificateVerify} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate}
Auth | {CertificateVerify}
v {Finished} -------->
[Application Data] <-------> [Application Data]
]]>This document defines a new extension to carry the attestation types.
The extension is conceptually similiar to the ‘server_certificate_type’
and the ‘server_certificate_type’ defined by .;
opaque nonce<0..2^16-1>;
case server:
CertificateType client_attestation_type;
opaque nonce<0..2^16-1>;
}
} ClientAttestationTypeExtension;
struct {
select(ClientOrServerExtension) {
case client:
CertificateType server_attestation_types<1..2^8-1>;
opaque nonce<0..2^16-1>;
case server:
CertificateType server_attestation_type;
opaque nonce<0..2^16-1>;
}
} ServerAttestationTypeExtension;
]]>The Certificate payload is used as a container, as shown in
. The shown Certificate structure is
an adaptation of .;
/* attestation type defined in this document */
case EAT:
opaque cab<1..2^24-1>;
/* attestation type defined in this document */
case TPM:
opaque tpmStmtFormat<1..2^24-1>;
case X509:
opaque cert_data<1..2^24-1>;
};
Extension extensions<0..2^16-1>;
} CertificateEntry;
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
]]>To simplify parsing of an EAT-based attestation payload,
the PAT and the KAT are typed.This specification extends the ClientHello and the EncryptedExtensions
messages, according to .The high-level message exchange in shows the
client_attestation_type and server_attestation_type extensions added
to the ClientHello and the EncryptedExtensions messages.
ServerHello ^ Key
+ key_share* | Exch
+ pre_shared_key* v
{EncryptedExtensions} ^ Server
+ client_attestation_type |
+ server_attestation_type
{CertificateRequest*} v Params
{Certificate*} ^
{CertificateVerify*} | Auth
{Finished} v
<-------- [Application Data*]
^ {Certificate*}
Auth | {CertificateVerify*}
v {Finished} -------->
[Application Data] <-------> [Application Data]
]]>In order to indicate the support of attestation types, clients include
the client_attestation_type and/or the server_attestation_type
extensions in the ClientHello.The client_attestation_type extension in the ClientHello indicates
the attestation types the client is able to provide to the server,
when requested using a CertificateRequest message.The server_attestation_type extension in the ClientHello indicates
the types of attestation types the client is able to process when
provided by the server in a subsequent Certificate payload.The client_attestation_type and server_attestation_type extensions
sent in the ClientHello each carry a list of supported attestation
types, sorted by client preference. When the client supports only
one attestation type, it is a list containing a single element.The TLS client MUST omit attestation types from the
client_attestation_type extension in the ClientHello if it is not
equipped with the corresponding attestation functionality, or if
it is not configured to use it with the given TLS
server. If the client has no attestation types to send in
the ClientHello it MUST omit the client_attestation_type extension
in the ClientHello.The TLS client MUST omit attestation types from the
server_attestation_type extension in the ClientHello if it is not
equipped with the attestation verification functionality. If the
client has no attestation types to send in the ClientHello it
MUST omit the entire server_attestation_type extension from the
ClientHello.If the server receives a ClientHello that contains the
client_attestation_type extension and/or the server_attestation_type
extension, then three outcomes are possible:The server does not support the extension defined in this
document. In this case, the server returns the EncryptedExtensions
without the extensions defined in this document.The server supports the extension defined in this document, but
it does not have any attestation type in common with the client.
Then, the server terminates the session with a fatal alert of
type “unsupported_certificate”.The server supports the extensions defined in this document and
has at least one attestation type in common with the client. In
this case, the processing rules described below are followed.The client_attestation_type extension in the ClientHello indicates
the attestation types the client is able to provide to the server,
when requested using a certificate_request message. If the TLS
server wants to request a certificate from the client (via the
certificate_request message), it MUST include the
client_attestation_type extension in the EncryptedExtensions. This
client_attestation_type extension in the EncryptedExtensions then indicates
the content the client is requested to provide in a
subsequent Certificate payload. The value conveyed in the
client_attestation_type extension MUST be selected from one of the
values provided in the client_attestation_type extension sent in the
client hello. The server MUST also include a certificate_request
payload in the EncryptedExtensions message.If the server does not send a certificate_request payload (for
example, because client authentication happens at the application
layer or no client authentication is required) or none of the
attestation types supported by the client (as indicated in the
client_attestation_type extension in the ClientHello) match the
server-supported attestation types, then the client_attestation_type
payload in the ServerHello MUST be omitted.The server_attestation_type extension in the ClientHello indicates
the types of attestation types the client is able to process when provided
by the server in a subsequent Certificate message. With the
server_attestation_type extension in the EncryptedExtensions, the TLS server
indicates the attestation type carried in the Certificate payload.
Note that only a single value is permitted in the
server_attestation_type extension when carried in the EncryptedExtensions
message.The Trusted Platform Module (TPM) is one type of hardware RoT. TPMs offer the ability to produce both key and platform attestation tokens.Platform Configuration Registers (PCRs) represent the core mechanism in TPMs for measuring and conveying information about the platform state via remote attestation. While specifications exist for assigning individual PCRs to specific software components, the choice of which combination of PCRs to include for any attestation procedure (and which hashing algorithm to use) is left to the parties involved. The agreement over and the configuration of the PCR selection falls outside the scope of this specification and is thus expected to occur out-of-band.The attestation evidence is produced through the TPM2_Quote operation. The evidence along with all other relevant metadata is transmitted in a format derived from the Attestation Statements. This format and the workflows around it are defined below.The TPM Platform Attestation Statement is a modified version of the TPM Attestation Statement Format, which covers key attestation tokens.ver: The version of the TPM specification to which the signature conforms.alg: A COSEAlgorithmIdentifier containing the identifier of the algorithm used to generate the attestation signature.x5c: A certificate for the PAK, followed by its certificate chain. The contents of the array SHOULD follow the same requirements as the x5chain header parameter defined in Section 2 of , with the sole difference that a CBOR array is also used when only pakCert is present.
pakCert: The PAK certificate used for the attestation.sig: The attestation signature, in the form of a TPMT_SIGNATURE structure as specified in Part 2, Section 11.3.4 of .attestInfo: The TPMS_ATTEST structure over which the above signature was computed, as specified in Part 2, Section 10.12.8 of .Generate a signature using the operation specified in Part 3, Section 18.4 of , using the PAK as the signing key, the out-of-band agreed-upon PCR selection. Freshness of the attestation is given by the nonce provided by the relying party. The nonce is included as qualified data to the TPM2_Quote operation, concatenated with an identifier of the platform being attested, as shown below:The platform identifier is a 16-bytes long UUID, with the remaining data representing the nonce. The UUID is intended to help the verifier link the platform with its expected reference values.Set the attestInfo field to the quoted PCR selection produced by the operation, and sig to the signature generated above.The inputs to the verification procedure are as follows:an attestation statement in the format described abovethe nonce sent to the attestera database of reference values for various platformsThe steps for verifying the attestation:Verify that the attestation token is a valid CBOR structure conforming to the CTAP2 canonical CBOR encoding form defined in Section 6 of , and perform CBOR decoding on it to extract the contained fields.Verify that alg describes a valid, accepted signing algorithm.Verify that x5c is present and follows the requirements laid out for x5chain in .Verify the sig is a valid signature over attestInfo using the attestation public key in pakCert with the algorithm specified in alg.Verify that pakCert meets the requirements in Section 8.3.1 of .Verify that attestInfo is valid: Verify that magic is set to TPM_GENERATED_VALUE.Verify that type is set to TPM_ST_ATTEST_QUOTE.Verify that attested contains a TPMS_QUOTE_INFO structure as specified in Part 2, Section 10.12.4 of .Extract extraData and parse it assuming the format defined above to obtain platform UUID and the nonce. Verify that the nonce is correct.Verify that the platform UUID obtained earlier is valid and represents a platform found in the database.Retrieve the reference values defined for this platform. Compute the digest of the concatenation of all relevant PCRs using the hash algorithm defined in alg. The PCRs are concatenated as described in “Selecting Multiple PCR” (Part 1, Section 17.5 of ). Verify that this digest is equal to pcrDigest in attested and that the hash algorithm defined in pcrSelect is aligned with the one in alg.Note that the remaining fields in the “Standard Attestation Structure” (Part 1, Section 31.2 of ), i.e., qualifiedSigner, clockInfo and firmwareVersion are ignored. These fields MAY be used as an input to risk engines.If successful, return implementation-specific values representing attestation type AttCA and attestation trust path x5c.Attesting to the provenance and properties of a key is possible through a TPM if the key resides on the TPM. The TPM 2.0 key attestation mechanism used in this specification is TPM2_Certify. The workflow for generating the evidence and assessing them, as well as the format used to transport them, follows closely the TPM Attestation Statement defined in Section 8.3 of , with one modification:For both signing and verification, attToBeSigned is unnecessary and therefore its hash is replaced with the nonce coming from the relying party as the qualifying data when signing, and as the expected extraData value during verification.The WebAuthn specification uses the term AIK to refer to the signing key. In this specification we use the term KAK instead. The credential (i.e., attested) key is in our case the TIK.TBD.TBD: Create new registry for attestation types.Key words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)This specification describes how to declare in a CBOR Web Token (CWT) (which is defined by RFC 8392) that the presenter of the CWT possesses a particular proof-of-possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800) but using Concise Binary Object Representation (CBOR) and CWTs rather than JavaScript Object Notation (JSON) and JSON Web Tokens (JWTs).Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)This document specifies a new certificate type and two TLS extensions for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The new certificate type allows raw public keys to be used for authentication.Remote Attestation Procedures ArchitectureFraunhofer SITMicrosoftSandelman Software WorksIntel CorporationHuawei Technologies In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.
The Entity Attestation Token (EAT)Security Theory LLCQualcomm Technologies Inc.Qualcomm Technologies Inc. An Entity Attestation Token (EAT) provides an attested claims set
that describes state and characteristics of an entity, a device like
a phone, IoT device, network equipment or such. This claims set is
used by a relying party, server or service to determine how much it
wishes to trust the entity.
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
attestation-oriented claims. To a large degree, all this document
does is extend CWT and JWT.
CBOR Object Signing and Encryption (COSE): Header parameters for carrying and referencing X.509 certificatesAugust Cellars The CBOR Signing And Encrypted Message (COSE) structure uses
references to keys in general. For some algorithms, additional
properties are defined which carry parameters relating to keys as
needed. The COSE Key structure is used for transporting keys outside
of COSE messages. This document extends the way that keys can be
identified and transported by providing attributes that refer to or
contain X.509 certificates.
TPM Main Specification Level 2 Version 1.2, Revision 116Trusted Computing GroupTrusted Platform Module Library Specification, Family "2.0", Level 00, Revision 01.59Trusted Computing GroupWeb Authentication: An API for accessing Public Key Credentials, Level 2World Wide Web ConsortiumClient to Authenticator ProtocolWorld Wide Web ConsortiumRFC EDITOR: PLEASE REMOVE THE THIS SECTIONInitial versionThe discussion list for the IETF TLS working group is located at the e-mail
address tls@ietf.org. Information on the group and information on how to
subscribe to the list is at https://www1.ietf.org/mailman/listinfo/tlsArchives of the list can be found at:
https://www.ietf.org/mail-archive/web/tls/current/index.html