RATS H. Tschofenig, Ed.
Internet-Draft S. Frost
Intended status: Standards Track M. Brossard
Expires: May 23, 2020 A. Shaw
T. Fossati
Arm Limited
November 20, 2019
Arm's Platform Security Architecture (PSA) Attestation Token
draft-tschofenig-rats-psa-token-04
Abstract
The insecurity of IoT systems is a widely known and discussed
problem. The Arm Platform Security Architecture (PSA) is being
developed to address this challenge by making it easier to build
secure IoT systems.
This document specifies token format and claims used in the
attestation API of the Arm Platform Security Architecture (PSA).
At its core, the CWT (COSE Web Token) format is used and populated
with a set of claims, in a way similar to EAT (Entity Attestation
Token). This specification describes what claims are used by PSA
compliant systems and what has been implemented within Arm Trusted
Firmware-M.
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 May 23, 2020.
Tschofenig, et al. Expires May 23, 2020 [Page 1]
Internet-Draft PSA Attestation Token November 2019
Copyright Notice
Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
2.1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Information Model . . . . . . . . . . . . . . . . . . . . . . 5
3.1. PSA Lifecycle States . . . . . . . . . . . . . . . . . . 7
3.2. PSA Software Components . . . . . . . . . . . . . . . . . 7
4. Token Encoding . . . . . . . . . . . . . . . . . . . . . . . 9
5. Claims . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Security and Privacy Considerations . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16
Appendix B. Reference Implementation . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Tschofenig, et al. Expires May 23, 2020 [Page 2]
Internet-Draft PSA Attestation Token November 2019
1. Introduction
Modern hardware for Internet of Things devices contain trusted
execution environments and in case of the Arm v8-M architecture
TrustZone support. On these low end microcontrollers, TrustZone
enables the separation between a "normal world" and a "secure world"
where security sensitive code resides in the "secure world" and
applications running in the "normal world" request secure services
using a well-defined API. Various APIs have been developed by Arm as
part of the Platform Security Architecture [PSA] programme; this
document focuses on the functionality provided by the attestation
API. Since the tokens exposed via the attestation API are also
consumed by services outside the device, there is an actual need for
making them interoperable. In this specification these
interoperability needs are addressed by describing the exact syntax
and semantics of the attestation claims, and defining the way these
claims are encoded and cryptographically protected.
Further details on concepts expressed below can be found in the PSA
Security Model documentation [PSA-SM].
Figure 1 provides a view of the architectural components and how they
interact. Applications on the IoT device communicate with services
residing in the "secure world" by means of a well-defined API. The
attestation API produces tokens, as described in this document, and
those tokens may be presented to network or application services.
Tschofenig, et al. Expires May 23, 2020 [Page 3]
Internet-Draft PSA Attestation Token November 2019
.-----------------+------------------.
| Normal World | Secure World |
| | .-. |
| | |A| |
| | |T| |
| | |T| |
| | |E| .-. |
| | .-. |S| |S| |
| | |C| |T| |T| |
.----------. | | |R| |A| |O| |
| Network | | .----------. | |Y| |T| |R| |
| and App |<-------------+ Apps | .--+--. |P| |I| |A| |
| Services | | '----------' |P | | |T| |O| |G| |
'----------' | .----------. |S | | |O| |N| |E| |
| |Middleware| |A | | '-' '-' '-' |
| '----------' | | | .----------. |
| .----------. |A | | | | |
| | | |P | | | SPM | |
| | RTOS and | |I | | '----------' |
| | Drivers | '--+--' .----------. |
| | | | | Boot | |
| '----------' | | Loader | |
| | '----------' |
+-----------------+------------------+
| H A R D|W A R E |
'-----------------+------------------'
Internet of Things Device
Figure 1: Software Architecture
2. Conventions and Terminology
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.
2.1. Glossary
RoT Root of Trust, the minimal set of software, hardware and data
that has to be implicitly trusted in the platform - there is no
software or hardware at a deeper level that can verify that the
Root of Trust is authentic and unmodified.
SPE Secure Processing Environment, a platform's processing
environment for software that provides confidentiality and
Tschofenig, et al. Expires May 23, 2020 [Page 4]
Internet-Draft PSA Attestation Token November 2019
integrity for its runtime state, from software and hardware,
outside of the SPE. Contains the Secure Partition Manager (SPM),
the Secure Partitions and the trusted hardware.
NSPE Non Secure Processing Environment, the security domain outside
of the SPE, the Application domain, typically containing the
application firmware and hardware.
3. Information Model
Table 1 describes the mandatory and optional claims in the report.
+----------------+--------------+-----------------------------------+
| Claim | Mandatory | Description |
+----------------+--------------+-----------------------------------+
| Auth Challenge | Yes | Input object from the caller. For |
| | | example, this can be a |
| | | cryptographic nonce, a hash of |
| | | locally attested data. The length |
| | | must be 32, 48, or 64 bytes. |
| | | |
| Instance ID | Yes | Represents the unique identifier |
| | | of the instance. It is a hash of |
| | | the public key corresponding to |
| | | the Initial Attestation Key. The |
| | | full definition is in [PSA-SM]. |
| | | |
| Verification | No | A hint used by a relying party to |
| Service | | locate a validation service for |
| Indicator | | the token. The value is a text |
| | | string that can be used to locate |
| | | the service or a URL specifying |
| | | the address of the service. A |
| | | verifier may choose to ignore |
| | | this claim in favor of other |
| | | information. |
| | | |
| Profile | No | Contains the name of a document |
| Definition | | that describes the 'profile' of |
| | | the report. The document name may |
| | | include versioning. The value for |
| | | this specification is |
| | | PSA_IOT_PROFILE_1. |
| | | |
| Implementation | Yes | Uniquely identifies the |
| ID | | underlying immutable PSA RoT. A |
| | | verification service can use this |
| | | claim to locate the details of |
Tschofenig, et al. Expires May 23, 2020 [Page 5]
Internet-Draft PSA Attestation Token November 2019
| | | the verification process. Such |
| | | details include the |
| | | implementation's origin and |
| | | associated certification state. |
| | | |
| Client ID | Yes | Represents the Partition ID of |
| | | the caller. It is a signed |
| | | integer whereby negative values |
| | | represent callers from the NSPE |
| | | and where positive IDs represent |
| | | callers from the SPE. The full |
| | | definition of the partition ID is |
| | | given in [PSA-FF]. |
| | | |
| Security | Yes | Represents the current lifecycle |
| Lifecycle | | state of the PSA RoT. The state |
| | | is represented by an integer that |
| | | is divided to convey a major |
| | | state and a minor state. A major |
| | | state is mandatory and defined by |
| | | [PSA-SM]. A minor state is |
| | | optional and 'IMPLEMENTATION |
| | | DEFINED'. The encoding is: |
| | | version[15:8] - PSA security |
| | | lifecycle state, and version[7:0] |
| | | - IMPLEMENTATION DEFINED state. |
| | | The PSA lifecycle states are |
| | | listed in Section 3.1. For PSA, a |
| | | remote verifier can only trust |
| | | reports from the PSA RoT when it |
| | | is in SECURED or |
| | | NON_PSA_ROT_DEBUG major states. |
| | | |
| Hardware | No | Provides metadata linking the |
| version | | token to the GDSII that went to |
| | | fabrication for this instance. It |
| | | can be used to link the class of |
| | | chip and PSA RoT to the data on a |
| | | certification website. It must be |
| | | represented as a thirteen-digit |
| | | [EAN-13] |
| | | |
| Boot Seed | Yes | Represents a random value created |
| | | at system boot time that will |
| | | allow differentiation of reports |
| | | from different boot sessions. |
| | | |
| Software | Yes (unless | A list of software components |
Tschofenig, et al. Expires May 23, 2020 [Page 6]
Internet-Draft PSA Attestation Token November 2019
| Components | the No | that represent all the software |
| | Software | loaded by the PSA Root of Trust. |
| | Measurements | This claim is needed for the |
| | claim is | rules outlined in [PSA-SM]. The |
| | specified) | software components are further |
| | | detailed in Section 3.2. |
| | | |
| No Software | Yes (if no | In the event that the |
| Measurements | software | implementation does not contain |
| | components | any software measurements then |
| | specified) | the Software Components claim |
| | | above can be omitted but instead |
| | | it will be mandatory to include |
| | | this claim to indicate this is a |
| | | deliberate state. This claim is |
| | | intended for devices that are not |
| | | compliant with [PSA-SM]. |
+----------------+--------------+-----------------------------------+
Table 1: Information Model of PSA Attestation Claims.
3.1. PSA Lifecycle States
The PSA lifecycle states consist of the following values:
- PSA_LIFECYCLE_UNKNOWN (0x0000u)
- PSA_LIFECYCLE_ASSEMBLY_AND_TEST (0x1000u)
- PSA_LIFECYCLE_PSA_ROT_PROVISIONING (0x2000u)
- PSA_LIFECYCLE_SECURED (0x3000u)
- PSA_LIFECYCLE_NON_PSA_ROT_DEBUG (0x4000u)
- PSA_LIFECYCLE_RECOVERABLE_PSA_ROT_DEBUG (0x5000u)
- PSA_LIFECYCLE_DECOMMISSIONED (0x6000u)
3.2. PSA Software Components
Each software component in the Software Components claim MUST include
the required properties of Table 2.
+-----+-------------+-----------+-----------------------------------+
| Key | Type | Mandatory | Description |
| ID | | | |
+-----+-------------+-----------+-----------------------------------+
Tschofenig, et al. Expires May 23, 2020 [Page 7]
Internet-Draft PSA Attestation Token November 2019
| 1 | Measurement | No | A short string representing the |
| | Type | | role of this software component |
| | | | (e.g. 'BL' for Boot Loader). |
| | | | |
| 2 | Measurement | Yes | Represents a hash of the |
| | value | | invariant software component in |
| | | | memory at startup time. The value |
| | | | must be a cryptographic hash of |
| | | | 256 bits or stronger. |
| | | | |
| 3 | Reserved | No | Reserved |
| | | | |
| 4 | Version | No | The issued software version in |
| | | | the form of a text string. The |
| | | | value of this claim will |
| | | | correspond to the entry in the |
| | | | original signed manifest of the |
| | | | component. |
| | | | |
| 5 | Signer ID | No | The hash of a signing authority |
| | | | public key for the software |
| | | | component. The value of this |
| | | | claim will correspond to the |
| | | | entry in the original manifest |
| | | | 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 way in which |
| | description | | the measurement value of the |
| | | | software component is computed. |
| | | | The value will be a text string |
| | | | containing an abbreviated |
| | | | description (or name) of the |
| | | | measurement method which can be |
| | | | used to lookup the details of the |
| | | | method in a profile document. |
| | | | This claim will normally be |
| | | | excluded, unless there was an |
| | | | exception to the default |
| | | | measurement described in the |
| | | | profile for a specific component. |
+-----+-------------+-----------+-----------------------------------+
Table 2: Software Components Claims.
Tschofenig, et al. Expires May 23, 2020 [Page 8]
Internet-Draft PSA Attestation Token November 2019
The following measurement types are current defined:
- 'BL': a Boot Loader
- 'PRoT': a component of the PSA Root of Trust
- 'ARoT': a component of the Application Root of Trust
- 'App': a component of the NSPE application
- 'TS': a component of a Trusted Subsystem
4. Token Encoding
The report is encoded as a COSE Web Token (CWT) [RFC8392], similar to
the Entity Attestation Token (EAT) [I-D.ietf-rats-eat]. The token
consists of a series of claims declaring evidence as to the nature of
the instance of hardware and software. The claims are encoded in
CBOR [RFC7049] format.
5. Claims
The token is modelled to include custom values that correspond to the
following claims suggested in the EAT specification:
- nonce (mandatory); arm_psa_nonce is used instead
- UEID (mandatory); arm_psa_UEID is used instead
Later revisions of this documents might phase out those custom claims
to be replaced by the EAT standard claims.
As noted, some fields must be at least 32 bytes long to provide
sufficient cryptographic strength.
Tschofenig, et al. Expires May 23, 2020 [Page 9]
Internet-Draft PSA Attestation Token November 2019
+-------+-------------+------------------------+--------------------+
| Claim | Claim | Claim Name | CBOR Value Type |
| Key | Description | | |
+-------+-------------+------------------------+--------------------+
| -7500 | Profile | arm_psa_profile_id | Text string |
| 0 | Definition | | |
| | | | |
| -7500 | Client ID | arm_psa_partition_id | Unsigned integer |
| 1 | | | or Negative |
| | | | integer |
| | | | |
| -7500 | Security | arm_psa_security_lifec | Unsigned integer |
| 2 | Lifecycle | ycle | |
| | | | |
| -7500 | Implementat | arm_psa_implementation | Byte string (>=32 |
| 3 | ion ID | _id | bytes) |
| | | | |
| -7500 | Boot Seed | arm_psa_boot_seed | Byte string (>=32 |
| 4 | | | bytes) |
| | | | |
| -7500 | Hardware | arm_psa_hw_version | Text string |
| 5 | Version | | |
| | | | |
| -7500 | Software | arm_psa_sw_components | Array of map |
| 6 | Components | | entries (compound |
| | | | map claim). See |
| | | | below for allowed |
| | | | key-values. |
| | | | |
| -7500 | No Software | arm_psa_no_sw_measurem | Unsigned integer |
| 7 | Measurement | ents | |
| | s | | |
| | | | |
| -7500 | Auth | arm_psa_nonce | Byte string |
| 8 | Challenge | | |
| | | | |
| -7500 | Instance ID | arm_psa_UEID | Byte string (the |
| 9 | | | type byte of the |
| | | | UEID should be set |
| | | | to 0x01. The type |
| | | | byte is described |
| | | | in [I-D.ietf-rats- |
| | | | eat].) |
| | | | |
| -7501 | Verificatio | arm_psa_origination | Byte string |
| 0 | n Service | | |
| | Indicator | | |
+-------+-------------+------------------------+--------------------+
Tschofenig, et al. Expires May 23, 2020 [Page 10]
Internet-Draft PSA Attestation Token November 2019
When using the Software Components claim each key value MUST
correspond to the following types:
1. Text string (type)
2. Byte string (measurement, >=32 bytes)
3. Reserved
4. Text string (version)
5. Byte string (signer ID, >=32 bytes)
6. Text string (measurement description)
6. Example
The following example shows an attestation token that was produced
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
the device management client form a single binary.
EC key using curve P-256 with:
- x:
0xdcf0d0f4bcd5e26a54ee36cad660d283d12abc5f7307de58689e77cd60452e75
- y:
0x8cbadb5fe9f89a7107e5a2e8ea44ec1b09b7da2a1a82a0252a4c1c26ee1ed7cf
- d:
0xc74670bcb7e85b3803efb428940492e73e3fe9d4f7b5a8ad5e480cbdbcb554c2
Key using COSE format (base64-encoded):
pSJYIIy621/p+JpxB+Wi6OpE7BsJt9oqGoKgJSpMHCbuHtfPI1ggx0ZwvLfoWzgD77Q
olASS5z4/6dT3taitXkgMvby1VMIBAiFYINzw0PS81eJqVO42ytZg0oPRKrxfcwfeWG
ied81gRS51IAE=
Example of EAT token (base64-encoded):
Tschofenig, et al. Expires May 23, 2020 [Page 11]
Internet-Draft PSA Attestation Token November 2019
0oRDoQEmoFkCIqk6AAEk+1ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8
6AAEk+lggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk/YSkAlggAA
ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EZTMuMS40BVggAAECAwQFBgcIC
QoLDA0ODxAREhMUFRYXGBkaGxwdHh8BYkJMpAJYIAABAgMEBQYHCAkKCwwNDg8QERIT
FBUWFxgZGhscHR4fBGMxLjEFWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0
eHwFkUFJvVKQCWCAAAQIDBAUGBwgJCgsMDQ4PEBESExQVFhcYGRobHB0eHwRjMS4wBV
ggAAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8BZEFSb1SkAlggAAECAwQFB
gcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8EYzIuMgVYIAABAgMEBQYHCAkKCwwNDg8Q
ERITFBUWFxgZGhscHR4fAWNBcHA6AAEk+RkwADoAAST/WCAAAQIDBAUGBwgJCgsMDQ4
PEBESExQVFhcYGRobHB0eHzoAASUBbHBzYV92ZXJpZmllcjoAAST4IDoAASUAWCEBAA
ECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh86AAEk93FQU0FfSW9UX1BST0ZJT
EVfMVhAWIYFCO5+jMSOuoctu11pSlQrEyKtDVECPBlw30KfBlAcaDqVEIoMztCm6A4J
ZvIr1j0cAFaXShG6My14d4f7Tw==
Same token using extended CBOR diagnostic format:
18(
[
/ protected / h'a10126' / {
\ alg \ 1: -7 \ ECDSA 256 \
} / ,
/ unprotected / {},
/ payload / h'a93a000124fb5820000102030405060708090a0b0c0d0e0f1011121
31415161718191a1b1c1d1e1f3a000124fa5820000102030405060708090a0b0c0d0e
0f101112131415161718191a1b1c1d1e1f3a000124fd84a4025820000102030405060
708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0465332e312e34055820
000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f01624
24ca4025820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c
1d1e1f0463312e31055820000102030405060708090a0b0c0d0e0f101112131415161
718191a1b1c1d1e1f016450526f54a4025820000102030405060708090a0b0c0d0e0f
101112131415161718191a1b1c1d1e1f0463312e30055820000102030405060708090
a0b0c0d0e0f101112131415161718191a1b1c1d1e1f016441526f54a4025820000102
030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f0463322e320
55820000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f
01634170703a000124f91930003a000124ff5820000102030405060708090a0b0c0d0
e0f101112131415161718191a1b1c1d1e1f3a000125016c7073615f76657269666965
723a000124f8203a00012500582101000102030405060708090a0b0c0d0e0f1011121
31415161718191a1b1c1d1e1f3a000124f7715053415f496f545f50524f46494c455f
31' / {
/ arm_psa_boot_seed / -75004: h'000102030405060708090a0b0c0d0e0f10
1112131415161718191a1b1c1d1e1f',
/ arm_psa_implementation_id / -75003: h'000102030405060708090a0b0c
0d0e0f101112131415161718191a1b1c1d1e1f',
/ arm_psa_sw_components / -75006: [
{
/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
131415161718191a1b1c1d1e1f',
/ version / 4: "3.1.4",
Tschofenig, et al. Expires May 23, 2020 [Page 12]
Internet-Draft PSA Attestation Token November 2019
/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
415161718191a1b1c1d1e1f',
/ type / 1: "BL"
},
{
/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
131415161718191a1b1c1d1e1f',
/ version / 4: "1.1",
/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
415161718191a1b1c1d1e1f',
/ type / 1: "PRoT"
},
{
/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
131415161718191a1b1c1d1e1f',
/ version / 4: "1.0",
/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
415161718191a1b1c1d1e1f',
/ type / 1: "ARoT"
},
{
/ measurement / 2: h'000102030405060708090a0b0c0d0e0f101112
131415161718191a1b1c1d1e1f',
/ version / 4: "2.2",
/ signerID / 5: h'000102030405060708090a0b0c0d0e0f101112131
415161718191a1b1c1d1e1f',
/ type / 1: "App"
}
],
/ arm_psa_security_lifecycle / -75002: 12288 / SECURED /,
/ arm_psa_nonce / -75008: h'000102030405060708090a0b0c0d0e0f10111
2131415161718191a1b1c1d1e1f',
/ arm_psa_origination / -75010: "psa_verifier",
/ arm_psa_partition_id / -75001: -1,
/ arm_psa_UEID / -75009: h'01000102030405060708090a0b0c0d0e0f1011
12131415161718191a1b1c1d1e1f',
/ arm_psa_profile_id / -75000: "PSA_IoT_PROFILE_1"
}),
} / ,
/ signature / h'58860508ee7e8cc48eba872dbb5d694a542b1322ad0d51023c197
0df429f06501c683a95108a0cced0a6e80e0966f22bd63d1c0056974a11ba332d7877
87fb4f'
]
)
Tschofenig, et al. Expires May 23, 2020 [Page 13]
Internet-Draft PSA Attestation Token November 2019
7. Security and Privacy Considerations
This specification re-uses the CWT and the EAT specification. Hence,
the security and privacy considerations of those specifications apply
here as well.
Since CWTs offer different ways to protect the token this
specification profiles those options and only uses public key
cryptography. The token MUST be signed following the structure of
the COSE specification [RFC8152]. The COSE type MUST be COSE-Sign1.
Attestation tokens contain information that may be unique to a device
and therefore they may allow to single out an individual device for
tracking purposes. Implementation must take appropriate measures to
ensure that only those claims are included that fulfil the purpose of
the application and that users of those devices consent to the data
sharing.
8. IANA Considerations
IANA is requested to allocate the claims defined in Section 5 to the
CBOR Web Token (CWT) Claims registry [IANA-CWT]. The change
controller are the authors and the reference is this document.
9. References
9.1. Normative References
[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/info/rfc2119>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC8152] Schaad, J., "CBOR Object Signing and Encryption (COSE)",
RFC 8152, DOI 10.17487/RFC8152, July 2017,
<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,
"CBOR Web Token (CWT)", RFC 8392, DOI 10.17487/RFC8392,
May 2018, <https://www.rfc-editor.org/info/rfc8392>.
Tschofenig, et al. Expires May 23, 2020 [Page 14]
Internet-Draft PSA Attestation Token November 2019
9.2. Informative References
[EAN-13] GS1, "International Article Number - EAN/UPC barcodes",
2019, <https://www.gs1.org/standards/barcodes/ean-upc>.
[I-D.ietf-rats-eat]
Mandyam, G., Lundblade, L., Ballesteros, M., and J.
O'Donoghue, "The Entity Attestation Token (EAT)", draft-
ietf-rats-eat-01 (work in progress), July 2019.
[IANA-CWT]
IANA, "CBOR Web Token (CWT) Claims", 2019,
<https://www.iana.org/assignments/cwt/cwt.xhtml>.
[PSA] Arm, "Platform Security Architecture Resources", 2019,
<https://www.arm.com/why-arm/architecture/
platform-security-architecture/psa-resources>.
[PSA-FF] Arm, "Platform Security Architecture Firmware Framework
1.0 (PSA-FF)", February 2019,
<https://pages.arm.com/psa-resources-ff.html>.
[PSA-SM] Arm, "Platform Security Architecture Security Model 1.0
(PSA-SM)", February 2019,
<https://pages.arm.com/psa-resources-sm.html>.
[TF-M] Linaro, "Trusted Firmware", 2019,
<https://www.trustedfirmware.org>.
Tschofenig, et al. Expires May 23, 2020 [Page 15]
Internet-Draft PSA Attestation Token November 2019
Appendix A. Contributors
We would like to thank the following supporters for their
contributions:
* Laurence Lundblade
Security Theory LLC
lgl@securitytheory.com
* Tamas Ban
Arm Limited
Tamas.Ban@arm.com
Appendix B. Reference Implementation
Trusted Firmware M (TF-M) [TF-M] is the name of the open source
project that provides a reference implementation of PSA APIs and an
SPM, created for the latest Arm v8-M microcontrollers with TrustZone
technology. TF-M provides foundational firmware components that
silicon manufacturers and OEMs can build on (including trusted boot,
secure device initialisation and secure function invocation).
Authors' Addresses
Hannes Tschofenig (editor)
Arm Limited
EMail: hannes.tschofenig@arm.com
Simon Frost
Arm Limited
EMail: Simon.Frost@arm.com
Mathias Brossard
Arm Limited
EMail: Mathias.Brossard@arm.com
Adrian Shaw
Arm Limited
EMail: Adrian.Shaw@arm.com
Tschofenig, et al. Expires May 23, 2020 [Page 16]
Internet-Draft PSA Attestation Token November 2019
Thomas Fossati
Arm Limited
EMail: thomas.fossati@arm.com
Tschofenig, et al. Expires May 23, 2020 [Page 17]