Internet-Draft | EAT Measured Component | June 2024 |
Frost, et al. | Expires 13 December 2024 | [Page] |
A measured component is a measurable object of an attester's target environment, that is, an object whose state can be sampled and digested. Examples of measured components include the invariant part of firmware that is loaded in memory at startup time, a run-time integrity check, a file system object, or a CPU register.¶
This document defines a "measured component" format that can be used with the EAT Measurements
claim.¶
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/draft-fft-rats-eat-measured-component.¶
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 13 December 2024.¶
Copyright (c) 2024 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.¶
Section 4.2.16 of [I-D.ietf-rats-eat] defines a Measurements
claim that:¶
"[c]ontains descriptions, lists, evidence or measurements of the software that exists on the entity or any other measurable subsystem of the entity."¶
This claim allows for different measurement formats, each identified by a different CoAP Content-Format (Section 12.3 of [RFC7252]). Currently, the only specified format is CoSWID of type "evidence", as per Section 2.9.4 of [RFC9393].¶
This document introduces a "measured component" format that can be used with the EAT Measurements
claim in addition to or as an alternative to CoSWID.¶
The term "measured component" refers to any measurable object on a target environment, that is, an object whose state can be sampled and digested. This includes, for example: the invariant part of a firmware component that is loaded in memory at startup time, a run-time integrity check (RTIC), a file system object, or a CPU register.¶
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.¶
In this document, CDDL [RFC8610] [RFC9165] [I-D.ietf-cbor-cddl-modules] [I-D.ietf-cbor-cddl-more-control] is used to describe the data formats.¶
A "measured component" information element includes the digest of the component's sampled state along with metadata that helps in identifying the component. Optionally, any entities responsible for signing the installed component can also be specified.¶
The information model of a "measured component" is described in Table 1.¶
IE | Description | Requirement Level |
---|---|---|
Component Name | The name given to the measured component. It is important that this name remains consistent across different releases to allow for better tracking of the same measured item across updates. When combined with a consistent versioning scheme, it enables better signaling from the appraisal procedure to the relying parties. | REQUIRED |
Component Version | A value representing the specific release or development version of the measured component. Using Semantic Versioning is RECOMMENDED. | OPTIONAL |
Digest Value | Hash of the measured component. | REQUIRED |
Digest Algorithm | Hash algorithm used to compute the Digest Value. | REQUIRED |
Signers | One or more unique identifiers of entities signing the measured component. | OPTIONAL |
The data model is inspired by the "PSA software component" claim (Section 4.4.1 of [I-D.tschofenig-rats-psa-token]), which has been refactored to take into account the recommendations about new EAT claims design in Appendix E of [I-D.ietf-rats-eat].¶
measured-component
Data Item
;# import digest from RFCYYYY as corim measured-component = [ id: component-id measurement: corim.digest ? signers: [ + signer-type ] ]¶
id
The measured component identifier encoded according to the format described in Section 4.1.1.¶
measurement
Digest value and algorithm, encoded using CoRIM digest format (Section 1.3.8 of [I-D.ietf-rats-corim]).¶
signers
One or more signing entities, see Section 4.1.2.¶
;# import sw-version-type from RFCXXXX as eat component-id = [ name: text ? version: eat.sw-version-type ]¶
name
A string that provides a human readable identifier for the component in question. Format and adopted conventions depend on the component type.¶
version
A compound version
data item that reuses encoding and semantics of [I-D.ietf-rats-eat] sw-version-type
.¶
A signer is an entity that digitally signs the measured component. For example, as in UEFI Secure Boot [UEFI2] and Arm Trusted Board Boot [TBBR-CLIENT]. A signer is associated with a public key. It could be an X.509 certificate, a raw public key, a public key thumbprint, or some other identifier that can be uniquely associated with the signing entity. In some cases, multiple parties may need to sign a component to indicate their endorsement or approval. This could include roles such as a firmware update system, fleet owner, or third-party auditor. The specific purpose of each signature may depend on the deployment, and the order of signers within the array could indicate meaning.¶
If an EAT profile (Section 6 of [I-D.ietf-rats-eat]) uses measured components, it MUST specify whether the signers
field is used.
If it is used, the profile MUST also specify what each of the entries in the signers
array represents, and how to interpret the corresponding signer-type
.¶
signer-type = bytes¶
measurements-format
Extensions
The CDDL in Figure 1 extends the $measurements-body-cbor
and $measurements-body-json
EAT sockets to add support for measured-component
s to the Measurements
claim.¶
Each socket is extended with two new types: a "native" representation that is used when measured-component
and the EAT have the same serialization (e.g., they are both CBOR), and a "tunnel" representation that is used when the serializations differ.¶
measurements-format
for CBOR EAT
The entries in Table 2 are the allowed content-type
/ content-format
pairs when the measured-component
is carried in a CBOR EAT.¶
Note the use of the "native" and "tunnel" formats from Figure 1, and how the associated CoAP Content-Format is used to describe the original serialization.¶
content-type (CoAP C-F equivalent) | content-format |
---|---|
application/measured-component+cbor
|
mc-cbor
|
application/measured-component+json
|
tstr .b64u mc-json
|
measurements-format
for JSON EAT
Table 3 is the equivalent of Table 2 for JSON-serialized EAT.¶
content-type (CoAP C-F equivalent) | content-format |
---|---|
application/measured-component+json
|
mc-json
|
application/measured-component+cbor
|
tstr .b64u mc-cbor
|
(The examples are CBOR only. JSON examples will be added in a future version of this document.)¶
The example in Figure 2 is a measured component with all the fields populated.¶
The example in Figure 3 is the same measured component as above but used as the format of a measurements
claim in a EAT claims-set.¶
Note that the example uses a CoAP Content-Format value from the experimental range (65000), which will change to the value assigned by IANA for the application/measured-component+cbor
Content-Format.¶
Note also that the array contains only one measured component, but additional entries could be added if the measured TCB is made of multiple, individually measured components.¶
The Name and Version of a component could provide an attacker with detailed information about the running software and configuration settings of the device. This information could also expose private details regarding the device. The stability requirement for the component's Name could potentially enable tracking.¶
RFC Editor: replace "RFCthis" with the RFC number assigned to this document.¶
IANA is requested to add the following media types to the "Media Types" registry [IANA.media-types].¶
Name | Template | Reference |
---|---|---|
mc+cbor
|
application/measured-component+cbor
|
RFCthis |
mc+json
|
application/measured-component+json
|
RFCthis |
application/measured-component+cbor
application¶
measured-component+cbor¶
n/a¶
n/a¶
binary (CBOR)¶
n/a¶
RFCthis¶
Attesters, Verifiers and Relying Parties¶
The syntax and semantics of fragment identifiers are as specified for "application/cbor". (No fragment identification syntax is currently defined for "application/cbor".)¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
application/measured-component+json
application¶
measured-component+json¶
n/a¶
n/a¶
binary (JSON is UTF-8-encoded text)¶
n/a¶
RFCthis¶
Attesters, Verifiers and Relying Parties¶
The syntax and semantics of fragment identifiers are as specified for "application/json". (No fragment identification syntax is currently defined for "application/json".)¶
RATS WG mailing list (rats@ietf.org)¶
COMMON¶
none¶
IETF¶
no¶
IANA is requested to register two Content-Format numbers in the "CoAP Content-Formats" sub-registry, within the "Constrained RESTful Environments (CoRE) Parameters" Registry [IANA.core-parameters], as follows:¶
Content-Type | Content Coding | ID | Reference |
---|---|---|---|
application/measured-component+cbor | - | TBD1 | RFCthis |
application/measured-component+json | - | TBD2 | RFCthis |
The list of currently open issues for this documents can be found at https://github.com/thomas-fossati/draft-fft-rats-eat-measured-component/issues.¶
Note to RFC Editor: please remove before publication.¶
The authors would like to thank Carl Wallace, Carsten Bormann, Giridhar Mandyam and Laurence Lundblade for providing comments, reviews and suggestions that greatly improved this document.¶