< draft-tschofenig-rats-psa-token-01.txt   draft-tschofenig-rats-psa-token-02.txt >
RATS H. Tschofenig, Ed. RATS H. Tschofenig, Ed.
Internet-Draft S. Frost Internet-Draft S. Frost
Intended status: Standards Track M. Brossard Intended status: Standards Track M. Brossard
Expires: October 10, 2019 A. Shaw Expires: January 9, 2020 A. Shaw
T. Fossati
Arm Limited Arm Limited
April 08, 2019 July 08, 2019
Arm's Platform Security Architecture (PSA) Attestation Token Arm's Platform Security Architecture (PSA) Attestation Token
draft-tschofenig-rats-psa-token-01 draft-tschofenig-rats-psa-token-02
Abstract Abstract
The insecurity of IoT systems is a widely known and discussed The insecurity of IoT systems is a widely known and discussed
problem. The Arm Platform Security Architecture (PSA) is being problem. The Arm Platform Security Architecture (PSA) is being
developed to address this challenge by making it easier to build developed to address this challenge by making it easier to build
secure systems. secure systems.
This document specifies token format and claims used in the This document specifies token format and claims used in the
attestation API of the Arm Platform Security Architecture (PSA). attestation API of the Arm Platform Security Architecture (PSA).
skipping to change at page 1, line 43 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 10, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 29 skipping to change at page 2, line 34
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5 3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5
4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9 4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9
5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security and Privacy Considerations . . . . . . . . . . . . . 14 7. Security and Privacy Considerations . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
skipping to change at page 3, line 19 skipping to change at page 3, line 27
the device, interoperability needs arise. In this specification the device, interoperability needs arise. In this specification
these interoperability needs are addressed by a combination of these interoperability needs are addressed by a combination of
- a set of claims encoded in CBOR, - a set of claims encoded in CBOR,
- embedded in a CBOR Web Token (CWT), - embedded in a CBOR Web Token (CWT),
- protected by functionality offered by the CBOR Object Signing and - protected by functionality offered by the CBOR Object Signing and
Encryption (COSE) specification. Encryption (COSE) specification.
Further details on concepts expressed below can be found within the
PSA Security Model documentation [PSA-SM].
Figure 1 shows the architecture graphically. Apps on the IoT device Figure 1 shows the architecture graphically. Apps on the IoT device
communicate with services on the secure world using a defined API. communicate with services on the secure world using a defined API.
The attestation API exposes tokens, as described in this document, The attestation API exposes tokens, as described in this document,
and those tokens may be presented to network or application services. and those tokens may be presented to network or application services.
+-----------------+------------------+ +-----------------+------------------+
| Normal World | Secure World | | Normal World | Secure World |
| | +-+ | | | +-+ |
| | |A| | | | |A| |
| | |T| | | | |T| |
skipping to change at page 4, line 22 skipping to change at page 4, line 22
| | +-+ |S| |S| | | | +-+ |S| |S| |
| | |C| |T| |T| | | | |C| |T| |T| |
+----------+ | | |R| |A| |O| | +----------+ | | |R| |A| |O| |
| Network | | +----------+ | |Y| |T| |R| | | Network | | +----------+ | |Y| |T| |R| |
| and App |<=============| Apps | +--+--+ |P| |I| |A| | | and App |<=============| Apps | +--+--+ |P| |I| |A| |
| Services | | +----------+ |P | | |T| |O| |G| | | Services | | +----------+ |P | | |T| |O| |G| |
+----------+ | +----------+ |S | | |O| |N| |E| | +----------+ | +----------+ |S | | |O| |N| |E| |
| |Middleware| |A | | +-+ +-+ +-+ | | |Middleware| |A | | +-+ +-+ +-+ |
| +----------+ | | | +----------+ | | +----------+ | | | +----------+ |
| +----------+ |A | | | | | | +----------+ |A | | | | |
| | | |P | | | TF-M Core| | | | | |P | | | SPM | |
| | RTOS and | |I | | +----------+ | | | RTOS and | |I | | +----------+ |
| | Drivers | +--+--+ +----------+ | | | Drivers | +--+--+ +----------+ |
| | | | | Boot | | | | | | | Boot | |
| +----------+ | | Loader | | | +----------+ | | Loader | |
| | +----------+ | | | +----------+ |
+-----------------+------------------+ +-----------------+------------------+
| H A R D|W A R E | | H A R D|W A R E |
+-----------------+------------------+ +-----------------+------------------+
Internet of Things Device Internet of Things Device
Figure 1: Software Architecture Figure 1: Software Architecture
2. Conventions and Terminology 2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in
2119 [RFC2119]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2.1. Glossary 2.1. Glossary
RoT Root of Trust, the minimal set of software, hardware and data RoT Root of Trust, the minimal set of software, hardware and data
that has to be implicitly trusted in the platform - there is no that has to be implicitly trusted in the platform - there is no
software or hardware at a deeper level that can verify that the software or hardware at a deeper level that can verify that the
Root of Trust is authentic and unmodified. Root of Trust is authentic and unmodified.
SPE Secure Processing Environment, a platform's processing SPE Secure Processing Environment, a platform's processing
environment for software that provides confidentiality and environment for software that provides confidentiality and
integrity for its runtime state, from software and hardware, integrity for its runtime state, from software and hardware,
outside of the SPE. Contains the Secure Partition Manager, the outside of the SPE. Contains the Secure Partition Manager (SPM),
Secure Partitions and the trusted hardware. the Secure Partitions and the trusted hardware.
NSPE Non Secure Processing Environment, the security domain outside NSPE Non Secure Processing Environment, the security domain outside
of the SPE, the Application domain, typically containing the of the SPE, the Application domain, typically containing the
application firmware and hardware. application firmware and hardware.
3. Information Model 3. Information Model
Table 1 describes the utilized claims. Table 1 describes the utilized claims.
+----------------+--------------+-----------------------------------+ +----------------+--------------+-----------------------------------+
| Claim | Mandatory | Description | | Claim | Mandatory | Description |
+----------------+--------------+-----------------------------------+ +----------------+--------------+-----------------------------------+
| Challenge | Yes | Input object from the caller. For | | Auth Challenge | Yes | Input object from the caller. For |
| | | example, this can be a | | | | example, this can be a |
| | | cryptographic nonce, a hash of | | | | cryptographic nonce, a hash of |
| | | locally attested data, or both. | | | | locally attested data. The length |
| | | The length must be 32, 48, or 64 | | | | must be 32, 48, or 64 bytes. |
| | | bytes. |
| | | | | | | |
| Instance ID | Yes | Represents the unique identifier | | Instance ID | Yes | Represents the unique identifier |
| | | of the instance. It is a hash of | | | | of the instance. It is a hash of |
| | | the public key corresponding to | | | | the public key corresponding to |
| | | the Initial Attestation Key. | | | | the Initial Attestation Key. The |
| | | full definition is in [PSA-SM]. |
| | | | | | | |
| Verification | No | Information used by a relying | | Verification | No | A hint used by a relying party to |
| Service | | party to locate a validation | | Service | | locate a validation service for |
| Indicator | | service for the token. The value | | Indicator | | the token. The value is a text |
| | | is a text string that can be used | | | | string that can be used to locate |
| | | to locate the service or a URL | | | | the service or a URL specifying |
| | | specifying the address of the | | | | the address of the service. A |
| | | service. | | | | verifier may choose to ignore |
| | | this claim in favor of other |
| | | information. |
| | | | | | | |
| Profile | No | Contains the name of a document | | Profile | No | Contains the name of a document |
| Definition | | that describes the 'profile' of | | Definition | | that describes the 'profile' of |
| | | the report. The document name may | | | | the report. The document name may |
| | | include versioning. The value for | | | | include versioning. The value for |
| | | this specification is | | | | this specification is |
| | | PSA_IOT_PROFILE_1. | | | | PSA_IOT_PROFILE_1. |
| | | | | | | |
| Implementation | Yes | Represents the original | | Implementation | Yes | Uniquely identifies the |
| ID | | implementation signer of the | | ID | | underlying immutable PSA RoT. A |
| | | attestation key and identifies | | | | verification service can use this |
| | | the contract between the report | | | | claim to locate the details of |
| | | and verification. A verification | | | | the verification process. Such |
| | | service will use this claim to | | | | details include the |
| | | locate the details of the | | | | implementation's origin and |
| | | verification process. | | | | associated certification state. |
| | | | | | | |
| Client ID | Yes | Represents the Partition ID of | | Client ID | Yes | Represents the Partition ID of |
| | | the caller. It is a signed | | | | the caller. It is a signed |
| | | integer whereby negative values | | | | integer whereby negative values |
| | | represent callers from the NSPE | | | | represent callers from the NSPE |
| | | and where positive IDs represent | | | | and where positive IDs represent |
| | | callers from the SPE. The full | | | | callers from the SPE. The full |
| | | definition of the partition ID is | | | | definition of the partition ID is |
| | | defined in the PSA Firmware | | | | given in [PSA-FF]. |
| | | Framework (PSA-FF) [PSA-FF]. |
| | | | | | | |
| Security | Yes | Represents the current lifecycle | | Security | Yes | Represents the current lifecycle |
| Lifecycle | | state of the PSA RoT. The state | | Lifecycle | | state of the PSA RoT. The state |
| | | is represented by a 16-bit | | | | is represented by an integer that |
| | | unsigned integer that is divided | | | | is divided to convey a major |
| | | to convey a major state and a | | | | state and a minor state. A major |
| | | minor state. A major state is | | | | state is mandatory and defined by |
| | | defined by [PSA-SM]. A minor | | | | [PSA-SM]. A minor state is |
| | | state is 'IMPLEMENTATION | | | | optional and 'IMPLEMENTATION |
| | | DEFINED'. The encoding is: | | | | DEFINED'. The encoding is: |
| | | version[15:8] - PSA lifecycle | | | | version[15:8] - PSA security |
| | | state, and version[7:0] - | | | | lifecycle state, and version[7:0] |
| | | IMPLEMENTATION DEFINED state. The | | | | - IMPLEMENTATION DEFINED state. |
| | | PSA lifecycle states are listed | | | | The PSA lifecycle states are |
| | | below. For PSA, a remote verifier | | | | listed below. For PSA, a remote |
| | | can only trust reports from the | | | | verifier can only trust reports |
| | | PSA RoT when it is in SECURED, | | | | from the PSA RoT when it is in |
| | | NON_PSA_ROT_DEBUG or | | | | SECURED or NON_PSA_ROT_DEBUG |
| | | RECOVERABLE_PSA_ROT_DEBUG major | | | | major states. |
| | | states. |
| | | | | | | |
| Hardware | No | Provides metadata linking the | | Hardware | No | Provides metadata linking the |
| version | | token to the GDSII that went to | | version | | token to the GDSII that went to |
| | | fabrication for this instance. It | | | | fabrication for this instance. It |
| | | can be used to link the class of | | | | can be used to link the class of |
| | | chip and PSA RoT to the data on a | | | | chip and PSA RoT to the data on a |
| | | certification website. It must be | | | | certification website. It must be |
| | | represented as a thirteen-digit | | | | represented as a thirteen-digit |
| | | [EAN-13] | | | | [EAN-13] |
| | | | | | | |
| Boot Seed | Yes | Represents a random value created | | Boot Seed | Yes | Represents a random value created |
| | | at system boot time that will | | | | at system boot time that will |
| | | allow differentiation of reports | | | | allow differentiation of reports |
| | | from different system sessions. | | | | from different boot sessions. |
| | | | | | | |
| Software | Yes (unless | A list of software components | | Software | Yes (unless | A list of software components |
| Components | the No | that represent the entire | | Components | the No | that represent all the software |
| | Software | software state of the system. | | | Software | loaded by the PSA Root of Trust. |
| | Measurements | This claim is recommended in | | | Measurements | This claim is needed for the |
| | claim is | order to comply with the rules | | | claim is | rules outlined in [PSA-SM]. The |
| | specified) | outlined in the [PSA-SM]. The | | | specified) | software components are further |
| | | software components are further |
| | | explained below. | | | | explained below. |
| | | | | | | |
| No Software | Yes (if no | In the event that the | | No Software | Yes (if no | In the event that the |
| Measurements | software | implementation does not contain | | Measurements | software | implementation does not contain |
| | components | any software measurements then | | | components | any software measurements then |
| | specified) | the Software Components claim | | | specified) | the Software Components claim |
| | | above can be omitted but instead | | | | above can be omitted but instead |
| | | it will be mandatory to include | | | | it will be mandatory to include |
| | | this claim to indicate this is a | | | | this claim to indicate this is a |
| | | deliberate state. | | | | deliberate state. This claim is |
| | | intended for devices that are not |
| | | compliant with [PSA-SM]. |
+----------------+--------------+-----------------------------------+ +----------------+--------------+-----------------------------------+
Table 1: Information Model of PSA Attestation Claims. Table 1: Information Model of PSA Attestation Claims.
The PSA lifecycle states consist of the following values: The PSA lifecycle states consist of the following values:
- UNKNOWN (0x1000u) - PSA_LIFECYCLE_UNKNOWN (0x0000u)
- PSA_ROT_PROVISIONING (0x2000u) - PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u)
- SECURED (0x3000u) - PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u)
- NON_PSA_ROT_DEBUG (0x4000u) - PSA_LIFECYCLE_SECURED (0x3000u)
- RECOVERABLE_PSA_ROT_DEBUG (0x5000u) - PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u)
- PSA_LIFECYCLE_RECOVERABLE_PSA_ROT_DEBUG (0x5000u)
- PSA_LIFECYCLE_DECOMMISSIONED (0x6000u) - PSA_LIFECYCLE_DECOMMISSIONED (0x6000u)
Table 2 shows the structure of each software component entry in the Table 2 shows the structure of each software component entry in the
Software Components claim. Software Components claim.
+-----+-------------+-----------+-----------------------------------+ +-----+-------------+-----------+-----------------------------------+
| Key | Type | Mandatory | Description | | Key | Type | Mandatory | Description |
| ID | | | | | ID | | | |
+-----+-------------+-----------+-----------------------------------+ +-----+-------------+-----------+-----------------------------------+
| 1 | Measurement | No | A short string representing the | | 1 | Measurement | No | A short string representing the |
| | Type | | role of this software component | | | Type | | role of this software component |
| | | | (e.g. 'BL' for Boot Loader). | | | | | (e.g. 'BL' for Boot Loader). |
| | | | | | | | | |
| 2 | Measurement | Yes | Represents a hash of the | | 2 | Measurement | Yes | Represents a hash of the |
| | Value | | invariant software component in | | | value | | invariant software component in |
| | | | memory at startup time. The value | | | | | memory at startup time. The value |
| | | | must be a cryptographic hash of | | | | | must be a cryptographic hash of |
| | | | 256 bits or stronger. | | | | | 256 bits or stronger. |
| | | | | | | | | |
| 3 | Reserved | No | Reserved | | 3 | Reserved | No | Reserved |
| | | | | | | | | |
| 4 | Version | No | The issued software version in | | 4 | Version | No | The issued software version in |
| | | | the form of a text string. The | | | | | the form of a text string. The |
| | | | value of this claim will | | | | | value of this claim will |
| | | | correspond to the entry in the | | | | | correspond to the entry in the |
| | | | original signed manifest of the | | | | | original signed manifest of the |
| | | | component. | | | | | component. |
| | | | | | | | | |
| 5 | Signer ID | No | The hash of a signing authority | | 5 | Signer ID | No | The hash of a signing authority |
| | | | public key for the software | | | | | public key for the software |
| | | | component. The value of this | | | | | component. The value of this |
| | | | claim will correspond to the | | | | | claim will correspond to the |
| | | | entry in the original manifest | | | | | entry in the original manifest |
| | | | for the component. | | | | | for the component. This can be |
| | | | used by a verifier to ensure the |
| | | | components were signed by an |
| | | | expected trusted source. This |
| | | | field must be present to be |
| | | | compliant with [PSA-SM]. |
| | | | | | | | | |
| 6 | Measurement | No | Description of the software | | 6 | Measurement | No | Description of the software |
| | description | | component, which represents the | | | description | | component, which represents the |
| | | | way in which the measurement | | | | | way in which the measurement |
| | | | value of the software component | | | | | value of the software component |
| | | | is computed. The value will be a | | | | | is computed. The value will be a |
| | | | text string containing an | | | | | text string containing an |
| | | | abbreviated description (or name) | | | | | abbreviated description (or name) |
| | | | of the measurement method which | | | | | of the measurement method which |
| | | | can be used to lookup the details | | | | | can be used to lookup the details |
skipping to change at page 9, line 4 skipping to change at page 9, line 12
The following measurement types are current defined: The following measurement types are current defined:
- 'BL': a Boot Loader - 'BL': a Boot Loader
- 'PRoT': a component of the PSA Root of Trust - 'PRoT': a component of the PSA Root of Trust
- 'ARoT': a component of the Application Root of Trust - 'ARoT': a component of the Application Root of Trust
- 'App': a component of the NSPE application - 'App': a component of the NSPE application
- 'TS': a component of a Trusted Subsystem - 'TS': a component of a Trusted Subsystem
4. Token Encoding 4. Token Encoding
The report is represented as a token, which must be formatted in The report is represented as a token, which must be formatted in
accordance to the Entity Attestation Token (EAT) [I-D.mandyam-eat]. accordance to the Entity Attestation Token (EAT) [I-D.ietf-rats-eat].
The token consists of a series of claims declaring evidence as to the The token consists of a series of claims declaring evidence as to the
nature of the instance of hardware and software. The claims are nature of the instance of hardware and software. The claims are
encoded in CBOR [RFC7049] format. encoded in CBOR [RFC7049] format.
5. Claims 5. Claims
The token is modelled to include custom values that correspond to the The token is modelled to include custom values that correspond to the
following claims suggested in the EAT specification: following claims suggested in the EAT specification:
- nonce (mandatory); arm_psa_nonce is used instead - nonce (mandatory); arm_psa_nonce is used instead
skipping to change at page 10, line 5 skipping to change at page 10, line 5
- UEID (mandatory); arm_psa_UEID is used instead - UEID (mandatory); arm_psa_UEID is used instead
- origination (recommended); arm_psa_origination is used instead - origination (recommended); arm_psa_origination is used instead
Later revisions of this documents might phase out those custom claims Later revisions of this documents might phase out those custom claims
to be replaced by the EAT standard claims. to be replaced by the EAT standard claims.
As noted, some fields must be at least 32 bytes long to provide As noted, some fields must be at least 32 bytes long to provide
sufficient cryptographic strength. sufficient cryptographic strength.
+--------+--------------+----------------------------+--------------+ +-------+----------------+----------------------------+-------------+
| Claim | Claim | Claim Name | CBOR Value | | Claim | Claim | Claim Name | CBOR Value |
| Key | Description | | Type | | Key | Description | | Type |
+--------+--------------+----------------------------+--------------+ +-------+----------------+----------------------------+-------------+
| -75000 | Profile | arm_psa_profile_id | Text string | | -7500 | Profile | arm_psa_profile_id | Text string |
| | Definition | | | | 0 | Definition | | |
| | | | | | | | | |
| -75001 | Client ID | arm_psa_partition_id | Unsigned | | -7500 | Client ID | arm_psa_partition_id | Unsigned |
| | | | integer or | | 1 | | | integer or |
| | | | Negative | | | | | Negative |
| | | | integer | | | | | integer |
| | | | | | | | | |
| -75002 | Security | arm_psa_security_lifecycle | Unsigned | | -7500 | Security | arm_psa_security_lifecycle | Unsigned |
| | Lifecycle | | integer | | 2 | Lifecycle | | integer |
| | | | | | | | | |
| -75003 | Impl. ID | arm_psa_implementation_id | Byte string | | -7500 | Implementation | arm_psa_implementation_id | Byte string |
| | | | (>=32 bytes) | | 3 | ID | | (>=32 |
| | | | | | | | | bytes) |
| -75004 | Boot Seed | arm_psa_boot_seed | Byte string | | | | | |
| | | | (>=32 bytes) | | -7500 | Boot Seed | arm_psa_boot_seed | Byte string |
| | | | | | 4 | | | (>=32 |
| -75005 | Hardware | arm_psa_hw_version | Text string | | | | | bytes) |
| | Version | | | | | | | |
| | | | | | -7500 | Hardware | arm_psa_hw_version | Text string |
| -75006 | Software | arm_psa_sw_components | Array of map | | 5 | Version | | |
| | Components | | entries. | | | | | |
| | | | (compound | | -7500 | Software | arm_psa_sw_components | Array of |
| | | | map claim) | | 6 | Components | | map entries |
| | | | | | | | | (compound |
| -75007 | No Software | arm_psa_no_sw_measurements | Unsigned | | | | | map claim). |
| | Measurements | | integer | | | | | See below |
| | | | | | | | | for allowed |
| -75008 | Challenge | arm_psa_nonce | Byte string | | | | | key-values. |
| | | | | | | | | |
| -75009 | Instance ID | arm_psa_UEID | Byte string | | -7500 | No Software | arm_psa_no_sw_measurements | Unsigned |
| | | | | | 7 | Measurements | | integer |
| -75010 | Verification | arm_psa_origination | Byte string | | | | | |
| | Service | | or | | -7500 | Auth Challenge | arm_psa_nonce | Byte string |
| | Indicator | | StringOrURI | | 8 | | | |
+--------+--------------+----------------------------+--------------+ | | | | |
| -7500 | Instance ID | arm_psa_UEID | Byte string |
Each map entry of the software component claim MUST have the | 9 | | | |
following types for each key value: | | | | |
| -7501 | Verification | arm_psa_origination | Byte string |
| 0 | Service | | |
| | Indicator | | |
+-------+----------------+----------------------------+-------------+
When using the Software Components claim each key value MUST
correspond to the following types:
1. Text string (type) 1. Text string (type)
2. Byte string (measurement, >=32 bytes) 2. Byte string (measurement, >=32 bytes)
3. Reserved 3. Reserved
4. Text string (version) 4. Text string (version)
5. Byte string (signer ID, >=32 bytes) 5. Byte string (signer ID, >=32 bytes)
6. Text string (measurement description) 6. Text string (measurement description)
The following key values will be present in the software components
claim: 1 (Type), 2 (Measurement Value), 4 (Version) and 5 (Signer
ID). Keys 3 (Reserved) and 6 (Measurement Description) will not be
present. Instead of a referenced Measurement Description it is
defined that all cases, the software measurement value is taken as a
SHA256 hash of the software image, prior to it executing in place.
6. Example 6. Example
The following example shows an attestation token that was produced The following example shows an attestation token that was produced
for a device that has a single-stage bootloader, and an RTOS with a for a device that has a single-stage bootloader, and an RTOS with a
device management client. From a code point of view, the RTOS and device management client. From a code point of view, the RTOS and
the device management client form a single binary. the device management client form a single binary.
EC key using curve P-256 with: EC key using curve P-256 with:
- x: - x:
skipping to change at page 14, line 33 skipping to change at page 14, line 33
IANA is requested to allocate the claims defined in Section 5 to the IANA is requested to allocate the claims defined in Section 5 to the
[RFC8392] created CBOR Web Token (CWT) Claims registry [IANA-CWT]. [RFC8392] created CBOR Web Token (CWT) Claims registry [IANA-CWT].
The change controller are the authors and the reference is this The change controller are the authors and the reference is this
document. document.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.mandyam-eat] [I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros, Mandyam, G., Lundblade, L., Ballesteros, M., and J.
M., and J. O'Donoghue, "The Entity Attestation Token O'Donoghue, "The Entity Attestation Token (EAT)", draft-
(EAT)", draft-mandyam-eat-01 (work in progress), November ietf-rats-eat-01 (work in progress), July 2019.
2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)", [RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017, RFC 8152, DOI 10.17487/RFC8152, July 2017,
<https://www.rfc-editor.org/info/rfc8152>. <https://www.rfc-editor.org/info/rfc8152>.
[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/info/rfc8174>.
[RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig, [RFC8392] Jones, M., Wahlstroem, E., Erdtman, S., and H. Tschofenig,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392, "CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>. May 2018, <https://www.rfc-editor.org/info/rfc8392>.
9.2. Informative References 9.2. Informative References
[EAN-13] GS1, "International Article Number - EAN/UPC barcodes", [EAN-13] GS1, "International Article Number - EAN/UPC barcodes",
2019, <https://www.gs1.org/standards/barcodes/ean-upc>. 2019, <https://www.gs1.org/standards/barcodes/ean-upc>.
[IANA-CWT] [IANA-CWT]
skipping to change at page 16, line 21 skipping to change at page 16, line 21
Security Theory LLC Security Theory LLC
lgl@securitytheory.com lgl@securitytheory.com
* Tamas Ban * Tamas Ban
Arm Limited Arm Limited
Tamas.Ban@arm.com Tamas.Ban@arm.com
Appendix B. Reference Implementation Appendix B. Reference Implementation
Trusted Firmware M (TF-M) [TF-M] is the name of the open source Trusted Firmware M (TF-M) [TF-M] is the name of the open source
project that provides a reference implementation of PSA APIs, created project that provides a reference implementation of PSA APIs and an
for the latest Arm v8-M microcontrollers with TrustZone technology. SPM, created for the latest Arm v8-M microcontrollers with TrustZone
TF-M provides foundational firmware components that silicon technology. TF-M provides foundational firmware components that
manufacturers and OEMs can build on (including trusted boot, secure silicon manufacturers and OEMs can build on (including trusted boot,
device initialisation and secure function invocation). secure device initialisation and secure function invocation).
Authors' Addresses Authors' Addresses
Hannes Tschofenig (editor) Hannes Tschofenig (editor)
Arm Limited Arm Limited
EMail: hannes.tschofenig@arm.com EMail: hannes.tschofenig@arm.com
Simon Frost Simon Frost
Arm Limited Arm Limited
skipping to change at line 682 skipping to change at page 17, line 4
Mathias Brossard Mathias Brossard
Arm Limited Arm Limited
EMail: Mathias.Brossard@arm.com EMail: Mathias.Brossard@arm.com
Adrian Shaw Adrian Shaw
Arm Limited Arm Limited
EMail: Adrian.Shaw@arm.com EMail: Adrian.Shaw@arm.com
Thomas Fossati
Arm Limited
EMail: thomas.fossati@arm.com
 End of changes. 36 change blocks. 
124 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/