An EAT-based Key Attestation Token
Internet-Draft draft-bft-rats-kat-03
Mathias Brossard
arm
mathias.brossard@arm.com
Thomas Fossati
Linaro
thomas.fossati@linaro.org
Hannes Tschofenig
hannes.tschofenig@gmx.net
04 March 2024
Security
Remote ATtestation ProcedureS
evidence
key attestation
TLS
This document defines an evidence format for key attestation based on the Entity Attestation Token (EAT).
Discussion Venues
Discussion of this document takes place on the Remote ATtestation ProcedureS Working Group mailing list (rats@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/rats/.
Source for this draft and an issue tracker can be found at https://github.com/thomas-fossati/draft-kat.
Introduction
This document defines an evidence format for key attestation based on EAT [I-D.ietf-rats-eat].
Terminology
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 of a system. In our case, the RoT is expected to offer the functionality for attesting to the state of the platform, and indirectly also to attest the integrity of the IK (public as well as private key) and the confidentiality of the IK private key.
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:
Evidence containing properties of the environment(s) in which the private keys are stored. For example, a Relying Party may want to know whether a private key is stored in a hardware security module and cannot be exported in unencrypted fashion.
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.
Identity Key (IK):
The IK consists of a private and a public key. The private key is used by the usage protocol. The public key is included in the Key Attestation Token. The IK is protected by the RoT.
Usage Protocol:
A (security) protocol that requires demonstrating possession of the private IK.
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 [RFC9334].
Platform Attestation Token (PAT):
An AT containing claims relating to the security state of the platform, including software constituting the platform trusted computing base (TCB). The process of generating a PAT typically involves gathering data during measured boot.
Key Attestation Token (KAT):
An AT containing a claim with a public key. The KAT may also contain other claims, such as those indicating its validity. The KAT is signed by the KAK. The key attestation service, which is part of the platform root of trust (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 usage protocol. If the KAT already includes a PAT, in form of a nested token, then it already corresponds to a CAB. A CAB is equivalent to a certificate that binds the identity of the platform's TCB with the IK public key.
Presenter:
Party that proves possession of a private key to a recipient of a KAT.
Recipient:
Party that receives the KAT containing the proof-of-possession key information from the presenter.
Key Attestation Service (KAS):
The issuer that creates the KAT and bundles a KAT together with a PAT in a CAB.
The reader is assumed to be familiar with the vocabulary and concepts defined in [RFC9334].
CDDL [RFC8610] [RFC9165] is used to describe the data formats and the examples in Section 6 use CBOR diagnostic notation defined in Section 8 of [STD94] and Appendix G of [RFC8610].
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 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Architecture
Key attestation is an extension to the attestation functionality described in [RFC9334]. We describe this conceptually by splitting the internals of the attester into two parts, platform attestation and key attestation. This is shown in Figure 1. These are logical roles and implementations may combine them into a single physical entity.
Security-sensitive functionality, like attestation, has to be placed into the trusted computing base. Since the trusted computing base itself may support different isolation layers, the design allows platform attestation to be separated from key attestation whereby platform attestation requires more privilege than the key attestation code. Cryptographic services, used by key attestation and by platform attestation, are separated although not shown in the figure.
The protocol used for communication between the Presenter and the Recipient is referred as usage protocol. The usage protocol, which is outside the scope of this specification, needs to support proof-of-possession of the private key (explained further below). An example usage protocol is TLS with the extension defined in [I-D.fossati-tls-attestation].
Architecture

Attester

Key

Platform

Attestation

Attestation

Service

Service

Trusted

Computing

Base

Usage

Protocol

Presenter

Recipient

  .------------------------------------.
 | .----------------------------------. |
 | | Attester                         | |
 | | .-------------.  .-------------. | |
 | | | Key         |  | Platform    | | |
 | | | Attestation |  | Attestation | | |
 | | | Service     |  | Service     | | |
 | | '-------------'  '-------------' | |
 | '----------------------------------' |
 |       ^                              |
 |       |       Trusted Computing Base |
  '------+-----------------------------'
         |
         |
         v
 .-----------------.                 .-----------------.
 |                 | Usage Protocol  |                 |
 |    Presenter    +---------------->|    Recipient    |
 |                 |                 |                 |
 '-----------------'                 '-----------------'

The Presenter triggers the generation of the IK. The IK consists of a public key (pIK) and a private key (sIK). The Presenter may, for example, use the following API call to trigger the generation of the key pair for a given algorithm and to obtain a key handle (key_id).

key_id = GenerateKeyPair(alg_id)

The private key is created and stored such that it is only accessible to the KAS rather than to the Presenter.
Next, the KAS needs to trigger the creation of the Platform Attestation Token (PAT) by the Platform Attestation Service. The PAT needs to be linked to the Key Attestation Token (KAT) and this linkage can occur in a number of ways. One approach is described in this specification in Section 5.1. The Key Attestation Token (KAT) includes the public key of the IK (pIK) and is then signed with the Key Attestation Key (KAK).
To ensure freshness of the PAT and the KAT a nonce is used, as suggested by the RATS architecture [RFC9334]. Here is the symbolic API call to request a KAT and a PAT, which are concatenated together as the CAB.

cab = createCAB(key_id, nonce)

Once the CAB has been sent by the Presenter to the Recipient, the Presenter has to demonstrate possession of the private key. The signature operation uses the private key of the IK (sIK). How this proof-of-possession of the private key is accomplished depends on the details of the usage protocol and is outside the scope of this specification.
The Recipient of the CAB and the proof-of-possession data (such as a digital signature) first extracts the PAT and the KAT. The PAT and the KAT may need to be conveyed to a Verifier. If the PAT is in the form of attestation results the checks can be performed locally at the Recipient, whereby the following checks are made:
- The signature protecting the PAT MUST pass verification when using available trust anchor(s).
- The chaining of PAT and KAT MUST be verified. The detailed verification procedure depends on the chaining mechanism utilized.
- The claims in the PAT MUST be matched against stored reference values.
- The signature protecting the KAT MUST pass verification.
- The KAT MUST be checked for replays using the nonce included in the KAT definition (see Figure 2).
Once all these steps are completed, the verifier produces the attestation result and includes (if needed) the IK public key (pIK).
Key Attestation Token Format
Proof-of-Possession
The KAT utilizes the proof-of-possession functionality defined in [RFC8747] to encode the public key of the IK (pIK).
KAT Definition

;# import rfc9052

kat = {
  &(eat_nonce: 10) => bstr .size (8..64)
  &(cnf: 8) => ak-pub
  &(kak-pub: 2500) => COSE_Key
}

ak-pub = cnf-map

cnf-map = {
  &(cose-key: 1) => COSE_Key
}

The claims in the KAT are as follows:
- eat_nonce: challenge from the relying party
- cnf: the key confirmation [RFC8747] of the pIK, encoded as COSE_Key [STD96]
- kak-pub: the public part of the KAK (used for verification of the KAT), encoded as COSE_Key
Platform Attestation Token Format
There are no strict requirements regarding the composition of the platform attestation token's claims-set, except for the presence of the eat_nonce claim used for binding (Section 5.1.1).
An example of PAT could be the PSA Token [I-D.tschofenig-rats-psa-token].
KAT-PAT Bundle
The KAT and PAT tokens are combined in a CMW "collection" [I-D.ietf-rats-msg-wrap] as shown in Figure 3.
KAT Bundle Definition

cab = {
  "kat": [ "application/eat+cwt", bytes .cbor cose_sign1<kat> ]
  "pat": [ "application/eat+cwt", bytes .cbor cose_sign1<pat> ]

  "__cmwc_t": "tag:ietf.org,2024-02-29:rats/kat"
}

KAT-PAT linkage
KAT and PAT are a form of layered attestation (Section 3.2 of [RFC9334]). For the scheme to be secure, it is crucial that their linkage is captured in their combined wire image. The way this is achieved is by hashing the CBOR-encoded COSE_Key corresponding to the KAK (i.e., the kak-pub claim in the KAT) and using it to populate the eat_nonce claim in the PAT. The signature on the PAT seals the image of the used KAK and therefore the linkage between the two layers.
Examples
KAT

{
    / nonce / 10: h'B91B03129222973C214E42BF31D6872A3EF2DBDDA401FBD1
F725D48D6BF9C817',
    / kak-pub / 2500: {
        / kty /  1: 2, / EC2 /
        / crv / -1: 1, / P-256 /
        / x /   -2: h'F0FFFA7BA35E76E44CA1F5446D327C8382A5A40E5F2974
5DF948346C7C88A5D3',
        / y /   -3: h'7CB4C4873CBB6F097562F61D5280768CD2CFE35FBA97E9
97280DBAAAE3AF92FE'
    },
    / cnf / 8: {
        / COSE_Key / 1: {
            / kty /  1: 2, / EC2 /
            / crv / -1: 1, / P-256 /
            / x /   -2: h'D7CC072DE2205BDC1537A543D53C60A6ACB62ECCD8
90C7FA27C9E354089BBE13',
            / y /   -3: h'F95E1D4B851A2CC80FFF87D8E23F22AFB725D535E5
15D020731E79A3B4E47120'
        }
    }
}

Minimal PAT

{
  / eat_nonce / 10: h'FAF2BCA754DFD3F309FCED20791DC1173B1BF61CF5
49145A6EDD4AD4CE2DC4F2'
}

CMW Collection combining KAT and PAT

{
  "kat": [
    "application/eat+cwt",
    << [
      / protected / h'A10126',
      / unprotected / {},
      / payload (KAT Claims-Set) / << {
        / nonce / 10: h'B91B03129222973C214E42BF31D6872A3EF2DBDD
A401FBD1F725D48D6BF9C817',
        / kak-pub / 2500: {
          / kty /  1: 2, / EC2 /
          / crv / -1: 1, / P-256 /
          / x /   -2: h'F0FFFA7BA35E76E44CA1F5446D327C8382A5A40E
5F29745DF948346C7C88A5D3',
          / y /   -3: h'7CB4C4873CBB6F097562F61D5280768CD2CFE35F
BA97E997280DBAAAE3AF92FE'
        },
        / cnf / 8: {
          / COSE_Key / 1: {
            / kty /  1: 2, / EC2 /
            / crv / -1: 1, / P-256 /
            / x /   -2: h'D7CC072DE2205BDC1537A543D53C60A6ACB62E
CCD890C7FA27C9E354089BBE13',
            / y /   -3: h'F95E1D4B851A2CC80FFF87D8E23F22AFB725D5
35E515D020731E79A3B4E47120'
          }
        }
      } >>,
      / signature / h'56F50D131FA83979AE064E76E70DC75C070B6D991A
EC08ADF9F41CAB7F1B7E2C47F67DACA8BB49E3119B7BAE77AEC6C89162713E0C
C6D0E7327831E67F32841A'
    ] >>
  ],

  "pat": [
    "application/eat+cwt",
    << [
      / protected / h'A10126',
      / unprotected / {},
      / payload (PAT Claims-Set) / << {
      / eat_nonce / 10: h'5CA3750DAF829C30C20797EDDB7949B1FD028C
5408F2DD8650AD732327E3FB64'
      / further platform specific claims /
    } >>,
    / signature / h'F9F41CAB7F1B7E2C47F67DACA8BB49E3119B7BAE77AE
C6C89162713E0CC6D0E7327831E67F32841A56F50D131FA83979AE064E76E70D
C75C070B6D991AEC08AD'
    ] >>
  ],

  "__cmwc_t": "tag:ietf.org,2024-02-29:rats/kat"
}

Security Considerations
TODO Security
IANA Considerations
TODO IANA
References
Normative References
[I-D.ietf-rats-eat]

The Entity Attestation Token (EAT)
Laurence Lundblade
Security Theory LLC
Giridhar Mandyam
Jeremy O'Donoghue
Qualcomm Technologies Inc.
Carl Wallace
Red Hound Software, Inc.
15 January 2024
Internet-Draft draft-ietf-rats-eat-25
[I-D.ietf-rats-msg-wrap]

RATS Conceptual Messages Wrapper (CMW)
Henk Birkholz
Fraunhofer SIT
Ned Smith
Intel
Thomas Fossati
Linaro
Hannes Tschofenig
27 February 2024
Internet-Draft draft-ietf-rats-msg-wrap-04
[RFC8610]

Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures
H. Birkholz
C. Vigano
C. Bormann
June 2019
RFC 8610
DOI 10.17487/RFC8610
[RFC8747]

Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
M. Jones
L. Seitz
G. Selander
S. Erdtman
H. Tschofenig
March 2020
RFC 8747
DOI 10.17487/RFC8747
[RFC9165]

Additional Control Operators for the Concise Data Definition Language (CDDL)
C. Bormann
December 2021
RFC 9165
DOI 10.17487/RFC9165
[STD94]

Concise Binary Object Representation (CBOR)
C. Bormann
P. Hoffman
December 2020
STD 94
RFC 8949
DOI 10.17487/RFC8949
[STD96]

CBOR Object Signing and Encryption (COSE): Structures and Process
J. Schaad
August 2022
STD 96
RFC 9052
DOI 10.17487/RFC9052
[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels
S. Bradner
March 1997
BCP 14
RFC 2119
DOI 10.17487/RFC2119
[RFC8174]

Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
B. Leiba
May 2017
BCP 14
RFC 8174
DOI 10.17487/RFC8174
Informative References
[RFC9334]

Remote ATtestation procedureS (RATS) Architecture
H. Birkholz
D. Thaler
M. Richardson
N. Smith
W. Pan
January 2023
RFC 9334
DOI 10.17487/RFC9334
[I-D.tschofenig-rats-psa-token]

Arm's Platform Security Architecture (PSA) Attestation Token
Hannes Tschofenig
Simon Frost
Arm Limited
Mathias Brossard
Arm Limited
Adrian L. Shaw
HP Labs
Thomas Fossati
Linaro
21 February 2024
Internet-Draft draft-tschofenig-rats-psa-token-22
[I-D.fossati-tls-attestation]

Using Attestation in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
Hannes Tschofenig
Yaron Sheffer
Intuit
Paul Howard
Arm Limited
Ionuț Mihalcea
Arm Limited
Yogesh Deshpande
Arm Limited
23 October 2023
Internet-Draft draft-fossati-tls-attestation-04
Amalgamated CDDL

cab = {
  "kat": [ "application/eat+cwt", bytes .cbor cose_sign1<kat> ]
  "pat": [ "application/eat+cwt", bytes .cbor cose_sign1<pat> ]

  "__cmwc_t": "tag:ietf.org,2024-02-29:rats/kat"
}

;# import rfc9052

kat = {
  &(eat_nonce: 10) => bstr .size (8..64)
  &(cnf: 8) => ak-pub
  &(kak-pub: 2500) => COSE_Key
}

ak-pub = cnf-map

cnf-map = {
  &(cose-key: 1) => COSE_Key
}

pat = {
  &(eat_nonce: 10) => bstr .size (8..64)
  * (int / text) => any
}

cose_sign1<C> = [
  Headers
  payload: bytes .cbor C
  signature: bytes
]

Acknowledgments
TODO acknowledge.