Remote ATtestation ProcedureS T. Fossati
Internet-Draft Y. Deshpande
Intended status: Informational Arm Ltd
Expires: 4 September 2025 H. Birkholz
Fraunhofer SIT
3 March 2025
A CoRIM Profile for Arm's Platform Security Architecture (PSA)
draft-fdb-rats-psa-endorsements-06
Abstract
PSA Endorsements include reference values, endorsed values,
cryptographic key material and certification status information that
a Verifier may need in order to appraise attestation Evidence
produced by a PSA device. This memo defines PSA Endorsements as a
profile of the CoRIM data model.
Discussion Venues
This note is to be removed before publishing as an RFC.
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/corim-psa.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2025.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction
2. Conventions and Definitions
3. PSA Endorsements
3.1. PSA Endorsement Profile
3.2. PSA Endorsements to PSA RoT Linkage
3.3. Reference Values
3.4. Attestation Verification Claims
3.5. Certification Claims
3.6. Software Upgrades and Patches
4. Security Considerations
5. IANA Considerations
5.1. CBOR Tag Registrations
5.2. CoRIM Profile Registration
5.3. CoMID Codepoints
5.3.1. CoMID Triples Map Extension
5.3.2. CoMID Measurement Values Map Extension
Acknowledgements
References
Normative References
Informative References
Authors' Addresses
1. Introduction
PSA Endorsements include reference values, endorsed values,
cryptographic key material and certification status information that
a Verifier needs in order to appraise attestation Evidence produced
by a PSA device [PSA-TOKEN]. This memo defines PSA Endorsements as a
profile of the CoRIM data model [CoRIM].
2. Conventions and Definitions
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.
An understanding of the [CoRIM] data model is a prerequisite.
The reader is also assumed to be familiar with the terms defined in
Section 2.1 of [PSA-TOKEN] and in Section 4 of [RATS-ARCH].
3. PSA Endorsements
PSA Endorsements describe an attesting device in terms of the
hardware and firmware components that make up its PSA Root of Trust
(RoT). This includes the identification and expected state of the
device as well as the cryptographic key material needed to verify
Evidence signed by the device's PSA RoT. Additionally, PSA
Endorsements can include information related to the certification
status of the attesting device.
There are three basic types of PSA Endorsements:
* Reference Values (Section 3.3), i.e., measurements of the PSA RoT
firmware;
* Attestation Verification Claims (Section 3.4), i.e., cryptographic
keys that are used to verify signed Evidence produced by the PSA
RoT, along with the identifiers that bind the keys to their device
instances;
* Certification Claims (Section 3.5), i.e., metadata that describe
the certification status associated with a PSA device;
There is a fourth PSA Endorsement type that aims at covering more
advanced Verifier use cases (e.g., the one described in Section 7 of
[TEEP]):
* Software Relations (Section 3.6), used to model upgrade and patch
relationships between software components.
3.1. PSA Endorsement Profile
PSA Endorsements are carried in one or more CoMIDs inside a CoRIM.
The profile attribute in the CoRIM MUST be present and MUST be set to
the URI http://arm.com/psa/iot/1 as shown in Figure 1.
/ corim-map / {
/ corim.profile / 3: 32("http://arm.com/psa/iot/1")
/ ... /
}
Figure 1: PSA IoT version 1, CoRIM profile
The list of all, and only, the CoMIDs that are currently "active"
(i.e., CoMIDs that contain triples that can be used for appraisal) is
provided in a CoBOM tag.
// TODO CoBOM example
3.2. PSA Endorsements to PSA RoT Linkage
Each PSA Endorsement - be it a Reference Value, Attestation
Verification Claim or Certification Claim - is associated with an
immutable PSA RoT. The linkage between a PSA Endorsement and its PSA
RoT is made by means of the unique PSA RoT identifier known as
Implementation ID (see Section 3.2.2 of [PSA-TOKEN]).
In order to support PSA Implementation IDs, the CoMID type $class-id-
type-choice is extended as follows:
; from draft-tschofenig-rats-psa-token
psa-implementation-id-type = bytes .size 32
tagged-implementation-id-type = #6.600(implementation-id-type)
$class-id-type-choice /= tagged-implementation-id-type
Besides, a PSA Endorsement can be associated with a specific instance
of a certain PSA RoT - as is the case for Attestation Verification
Claims. A PSA Endorsement is associated with a PSA RoT instance by
means of the Instance ID (see Section 3.2.1 of [PSA-TOKEN]) and its
"parent" Implementation ID.
These identifiers are typically found in the subject of a CoMID
triple, encoded in an environment-map as shown in Figure 2.
/ environment-map / {
/ comid.class / 0 : {
/ comid.class-id / 0 :
/ tagged-impl-id-type / 600(
h'61636d652d696d706c656d656e746174
696f6e2d69642d303030303030303031'
),
/ comid.vendor / 1 : "ACME Ltd.",
/ comid.model / 2 : "Roadrunner 1.0"
},
/ comid.instance / 1 :
/ tagged-ueid-type / 550(
h'01
4ca3e4f50bf248c39787020d68ffd05c
88767751bf2645ca923f57a98becd296'
)
}
Figure 2: Example PSA RoT Identification
Optional vendor and model can be specified as well. Together, they
are interpreted as a unique identifier of the product that embeds the
PSA RoT. It is RECOMMENDED to consistently provide a product
identifier.
3.3. Reference Values
Reference Values carry measurements and other metadata associated
with the updatable firmware in a PSA RoT. When appraising Evidence,
the Verifier compares Reference Values against the values found in
the Software Components of the PSA token (see Section 3.4.1 of
[PSA-TOKEN]).
When there is more than one measurement associated to a certain PSA
RoT, the measurements are spread across multiple reference-triple-
records and, in certain cases, across multiple CoMIDs. A single
CoBOM MUST completely describe the updatable PSA RoT.
The elements of the psa-software-component map defined in
Section 4.4.1 of [PSA-TOKEN] are matched against CoMID measurement-
map entries as follows:
+==================+=============================+=================+
| PSA Evidence | PSA Endorsement | Description |
+==================+=============================+=================+
| measurement-type | measurement-values-map.name | Section 4.4.1.1 |
| | | of [PSA-TOKEN] |
+------------------+-----------------------------+-----------------+
| measurement- | measurement-values- | Section 4.4.1.2 |
| value | map.digests[*][1] | of [PSA-TOKEN] |
+------------------+-----------------------------+-----------------+
| version | measurement-values- | Section 4.4.1.3 |
| | map.version.version | of [PSA-TOKEN] |
+------------------+-----------------------------+-----------------+
| measurement-desc | measurement-values- | |
| | map.digests[*][0] | |
+------------------+-----------------------------+-----------------+
| signer-id | authorized-by[0] | Section 4.4.1.4 |
| | | of [PSA-TOKEN] |
+------------------+-----------------------------+-----------------+
Table 1: PSA Software Component Mappings
The digests array MUST contain at least one entry and MAY contain
more than one entry if multiple digests (obtained with different hash
algorithms) of the same measured component exist.
The authorized-by in the measurement-map MUST have exactly one entry
of type tagged-thumbprint-type (CBOR tag 557) containing the signer-
id.
The example in Figure 3 shows a CoMID encoding a PSA Endorsement of
type Reference Value for a firmware measurement associated with
Implementation ID acme-implementation-id-000000001.
/ concise-mid-tag / {
/ comid.tag-identity / 1 : {
/ comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f'
},
/ comid.triples / 4 : {
/ comid.reference-triples / 0 : [
[
/ environment-map / {
/ comid.class / 0 : {
/ comid.class-id / 0 :
/ tagged-impl-id-type / 600(
h'61636d652d696d706c656d656e746174
696f6e2d69642d303030303030303031'
),
/ comid.vendor / 1 : "ACME Ltd.",
/ comid.model / 2 : "Roadrunner 1.0"
}
},
[
/ measurement-map / {
/ comid.mval / 1 : {
/ comid.version / 0 : {
/ version / 0: "1.3.5"
},
/ comid.digests / 2 : [
[
/ hash-alg-id / "sha-256",
/ hash-value / h'44aa336af4cb14a8
79432e53dd6571c7
fa9bccafb75f4882
59262d6ea3a4d91b'
]
],
/ comid.name / 11 : "PRoT"
},
/ authorized-by / 2 : [
557([
/ hash-alg-id / "sha-256",
/ hash-value / h'acbb11c7e4da2172
05523ce4ce1a245a
e1a239ae3c6bfd9e
7871f7e5d8bae86b'
])
]
}
]
]
]
}
}
Figure 3: Example Reference Value
3.4. Attestation Verification Claims
An Attestation Verification Claim carries the verification key
associated with the Initial Attestation Key (IAK) of a PSA device.
When appraising Evidence, the Verifier can use the Implementation ID
and Instance ID claims (see Section 3.2) to look up the verification
key that it SHALL use to check the signature on the Evidence. This
allows the Verifier to prove (or disprove) the Attester's claimed
identity.
Each verification key is provided alongside the corresponding device
Instance and Implementation IDs (and, possibly, a product identifier)
in an attest-key-triple-record. Specifically:
* The Instance and Implementation IDs are encoded in the
environment-map as shown in Figure 2;
* The IAK public key is carried in the comid.key entry in the
verification-key-map. The IAK public key is a PEM-encoded
SubjectPublicKeyInfo [RFC5280]. There MUST be only one
verification-key-map in an attest-key-triple-record;
* The optional comid.keychain entry MUST NOT be set by a CoMID
producer that uses the profile described in this document, and
MUST be ignored by a CoMID consumer that is parsing according to
this profile.
The example in Figure 4 shows the PSA Endorsement of type Attestation
Verification Claim carrying a secp256r1 EC public IAK associated with
Instance ID 4ca3...d296.
/ concise-mid-tag / {
/ comid.tag-identity / 1 : {
/ comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f'
},
/ comid.triples / 4 : {
/ comid.attest-key-triples / 3 : [
[
/ environment-map / {
/ comid.class / 0 : {
/ comid.class-id / 0 :
/ tagged-impl-id-type / 600(
h'61636d652d696d706c656d656e746174
696f6e2d69642d303030303030303031'
),
/ comid.vendor / 1 : "ACME Ltd.",
/ comid.model / 2 : "Roadrunner 1.0"
},
/ comid.instance / 1 :
/ tagged-ueid-type / 550(
h'01
4ca3e4f50bf248c39787020d68ffd05c
88767751bf2645ca923f57a98becd296'
)
},
[
/ verification-key-map / {
/ comid.key / 0 :
"MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgA
ETl4iCZ47zrRbRG0TVf0dw7VFlHtv18HInY
hnmMNybo+A1wuECyVqrDSmLt4QQzZPBECV8
ANHS5HgGCCSr7E/Lg=="
}
]
]
]
}
}
Figure 4: Example Attestation Verification Claim
3.5. Certification Claims
PSA Certified [PSA-CERTIFIED] defines a certification scheme for the
PSA ecosystem. A product - either a hardware component, a software
component, or an entire device - that is verified to meet the
security criteria established by the PSA Certified scheme is
warranted a PSA Certified Security Assurance Certificate (SAC). A
SAC contains information about the certification of a certain product
(e.g., the target system, the attained certification level, the test
lab that conducted the evaluation, etc.), and has a unique
Certificate Number.
The linkage between a PSA RoT -- comprising the immutable part as
well as zero or more of the mutable components -- and the associated
SAC is provided by a Certification Claim, which binds the PSA RoT
Implementation ID and the software component identifiers with the SAC
unique Certificate Number. When appraising Evidence, the Verifier
can use the Certification Claims associated with the identified
Attester as ancillary input to the Appraisal Policy, or to enrich the
produced Attestation Result.
A Certification Claim is encoded as a conditional-endorsement-triple-
record.
The SAC is encoded in a psa-cert-num that extends the measurement-
values-map:
$$measurement-values-map-extension //= (
&(psa-cert-num: 100) => psa-cert-num-type
)
psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}"
The conditional-endorsement-triple-record is constructed as follows:
* The Implementation ID of the immutable PSA RoT to which the SAC
applies is encoded as a tagged-impl-id-type in the environment-map
of the stateful-environment-record;
* Any software component that is part of the certified PSA RoT is
encoded as a reference value (see Section 3.3) in the measurement-
map of the stateful-environment-record;
* The unique SAC Certificate Number is encoded as psa-cert-num in
the measurement-values-map.
The example in Figure 5 shows a Certification Claim that associates
Certificate Number 1234567890123 - 12345 to Implementation ID acme-
implementation-id-000000001 and a single "PRoT" software component
with version "1.3.5".
/ concise-mid-tag / {
/ comid.tag-identity / 1 : {
/ comid.tag-id / 0 : h'dbb0508ac658421c99c904124bab59ca'
},
/ comid.triples / 4 : {
/ comid.conditional-endorsement-triple / 9 : [
[
/ stateful-environment-record / [
/ environment-map / {
/ comid.class / 0 : {
/ comid.class-id / 0 :
/ tagged-impl-id-type / 600(
h'61636d652d696d706c656d656e746174
696f6e2d69642d303030303030303031'
),
/ comid.vendor / 1 : "ACME Ltd.",
/ comid.model / 2 : "Roadrunner 1.0"
}
},
/ measurement-map / {
/ comid.mval / 1 : {
/ comid.version / 0 : {
/ version / 0: "1.3.0"
},
/ comid.digests / 2 : [
[
/ hash-alg-id / "sha-256",
/ hash-value / h'44aa336af4cb14a8
79432e53dd6571c7
fa9bccafb75f4882
59262d6ea3a4d91b'
]
],
/ comid.name / 11 : "PRoT"
},
/ authorized-by / 2 : [
557([
/ hash-alg-id / "sha-256",
/ hash-value / h'acbb11c7e4da2172
05523ce4ce1a245a
e1a239ae3c6bfd9e
7871f7e5d8bae86b'
])
]
}
],
/ measurement-values-map / {
/ psa.cert-num / 100 : "1234567890123 - 12345"
}
]
]
}
}
Figure 5: Example Certification Claim
3.6. Software Upgrades and Patches
In order to model software lifecycle events such as updates and
patches, this profile defines a new triple that conveys the following
semantics:
* SUBJECT: a software component
* PREDICATE: (non-critically / critically) (updates / patches)
* OBJECT: another software component
The triple is reified and used as the object of another triple, psa-
swrel-triple-record, whose subject is the embedding environment.
comid.psa-swrel-triples = TBD2
$$triples-map-extension //= (
comid.psa-swrel-triples => [ + psa-swrel-triple-record ]
)
psa.updates = 1
psa.patches = 2
psa-swrel-rel = [
type: psa.updates / psa.patches
security-critical: bool ; true means it's a fix for a security bug
]
sw-rel = [
new: comid.measurement-map ; the "new" firmware
rel: psa-swrel-rel ; patches/updates and the security flag
old: comid.measurement-map ; the "old" firmware
]
psa-swrel-triple-record = [
environment-map
sw-rel
]
An example of a security critical update involving versions "1.2.5"
and "1.3.0" of software component "PRoT" within the target
environment associated with Implementation ID acme-implementation-
id-000000001 is shown in Figure 6.
/ concise-mid-tag / {
/ comid.tag-identity / 1 : {
/ comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f'
},
/ comid.triples / 4 : {
/ comid.psa-swrel-triples / 5 : [
[
/ environment-map / {
/ comid.class-id / 0 :
/ tagged-impl-id-type / 600(
h'61636d652d696d706c656d656e746174
696f6e2d69642d303030303030303031'
),
/ comid.vendor / 1 : "ACME Ltd.",
/ comid.model / 2 : "Roadrunner 1.0"
},
/ sw-rel / [
/ new / {
/ comid.mval / 1 : {
/ comid.version / 0 : {
/ version / 0: "1.3.0"
},
/ comid.digests / 2 : [
[
/ hash-alg-id / "sha-256",
/ hash-value / h'44aa336af4cb14a8
79432e53dd6571c7
fa9bccafb75f4882
59262d6ea3a4d91b'
]
],
/ comid.name / 11 : "PRoT"
},
/ authorized-by / 2 : [
557([
/ hash-alg-id / "sha-256",
/ hash-value / h'acbb11c7e4da2172
05523ce4ce1a245a
e1a239ae3c6bfd9e
7871f7e5d8bae86b'
])
]
},
/ rel / [
/ type / 1, / psa.updates /
/ security-critical / true
],
/ old / {
/ comid.mval / 1 : {
/ comid.version / 0 : {
/ version / 0: "1.2.5"
},
/ comid.digests / 2 : [
[
/ hash-alg-id / "sha-256",
/ hash-value / h'98b06c3f4bfeb294
f69dae2bbe7d4be0
750e258a86414d90
a17cda9e2e775337'
]
],
/ comid.name / 11 : "PRoT"
},
/ authorized-by / 2 : [
557([
/ hash-alg-id / "sha-256",
/ hash-value / h'acbb11c7e4da2172
05523ce4ce1a245a
e1a239ae3c6bfd9e
7871f7e5d8bae86b'
])
]
}
]
]
]
}
}
Figure 6: Example Critical Software Upgrade
4. Security Considerations
// TODO
5. IANA Considerations
5.1. CBOR Tag Registrations
IANA is requested to allocate the following tag in the "CBOR Tags"
registry [IANA.cbor-tags], preferably with the specified value:
+=====+==============+==========================+
| Tag | Data Item | Semantics |
+=====+==============+==========================+
| 600 | tagged bytes | PSA Implementation ID |
| | | (Section 3.2 of RFCthis) |
+-----+--------------+--------------------------+
Table 2: CoRIM CBOR Tags
5.2. CoRIM Profile Registration
IANA is requested to register the following profile value in the
// TODO CoRIM registry.
+==========================+======+============================+
| Profile Value | Type | Semantics |
+==========================+======+============================+
| http://arm.com/psa/iot/1 | uri | The CoRIM profile |
| | | specified by this document |
+--------------------------+------+----------------------------+
Table 3: PSA profile for CoRIM
5.3. CoMID Codepoints
5.3.1. CoMID Triples Map Extension
IANA is requested to register the following codepoints to the "CoMID
Triples Map" registry.
+=======+=========================+===============+
| Index | Item Name | Specification |
+=======+=========================+===============+
| 50 | comid.psa-swrel-triples | RFCthis |
+-------+-------------------------+---------------+
Table 4: PSA CoMID Triples
5.3.2. CoMID Measurement Values Map Extension
+=====+====================+==============+========================+
| Key | Item Name | Item Type | Specification |
+=====+====================+==============+========================+
| 100 | comid.psa-cert-num | psa-cert-num | Section 3.5 of RFCthis |
+-----+--------------------+--------------+------------------------+
Table 5: Measurement Values Map Extensions
Acknowledgements
// TODO
References
Normative References
[CoRIM] Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-06, 18
October 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-corim-06>.
[IANA.cbor-tags]
IANA, "Concise Binary Object Representation (CBOR) Tags",
<https://www.iana.org/assignments/cbor-tags>.
[PSA-TOKEN]
Tschofenig, H., Frost, S., Brossard, M., Shaw, A. L., and
T. Fossati, "Arm's Platform Security Architecture (PSA)
Attestation Token", Work in Progress, Internet-Draft,
draft-tschofenig-rats-psa-token-24, 23 September 2024,
<https://datatracker.ietf.org/doc/html/draft-tschofenig-
rats-psa-token-24>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/rfc/rfc5280>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
Informative References
[PSA-CERTIFIED]
"PSA Certified", 2021, <https://www.psacertified.org>.
[RATS-ARCH]
Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/rfc/rfc9334>.
[TEEP] Pei, M., Tschofenig, H., Thaler, D., and D. M. Wheeler,
"Trusted Execution Environment Provisioning (TEEP)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-teep-architecture-19, 24 October 2022,
<https://datatracker.ietf.org/doc/html/draft-ietf-teep-
architecture-19>.
Authors' Addresses
Thomas Fossati
Arm Ltd
Email: thomas.fossati@arm.com
Yogesh Deshpande
Arm Ltd
Email: yogesh.deshpande@arm.com
Henk Birkholz
Fraunhofer SIT
Email: henk.birkholz@sit.fraunhofer.de