Arm's Platform Security Architecture (PSA) Attestation Token
draft-tschofenig-rats-psa-token-00

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 systems.

This document specifies token format and claims used in the attestation API of the Arm Platform Security Architecture (PSA).

At its core, the Entity Attestation Token (EAT) format is used and populated with a set of claims. This specification describes what claims are used by the PSA 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 September 12, 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
• 2. Conventions and Terminology
• 2.1. Glossary
• 3. Information Model
• 4. Token Encoding
• 5. Claims
• 6. Example
• 7. Security and Privacy Considerations
• 8. IANA Considerations
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Appendix A. Contributors
• Appendix B. Reference Implementation
• Authors' Addresses

1. Introduction

Modern hardware for Internet of Things devices contain trusted execution environments and in case of the Arm v8-M architecture TrustZone support. TrustZone on these low end microcontrollers allows the separation between a normal world and a secure world where security sensitive code resides in the secure world and is executed by applications running on the normal world using a well-defined API. Various APIs have been developed by Arm as part of the Platform Security Architecture [PSA]; 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, interoperability needs arise. In this specification these interoperability needs are addressed by a combination of

• a set of claims encoded in CBOR,
• embedded in a CBOR Web Token (CWT),
• protected by functionality offered by the CBOR Object Signing and Encryption (COSE) specification.

Figure 1 shows the architecture graphically. Apps on the IoT device communicate with services on the secure world using a defined API. The attestation API exposes tokens, as described in this document, and those tokens may be presented to network or application services.

                        +-----------------+------------------+
                        |  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 |  | | TF-M Core|  |
                        | | 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 RFC 2119 [RFC2119].

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 integrity for its runtime state, from software and hardware, outside of the SPE. Contains the Secure Partition Manager, 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 utilized claims.

The PSA lifecycle states consist of the following values:

• UNKNOWN (0x1000u)
• PSA_ROT_PROVISIONING (0x2000u)
• SECURED (0x3000u)
• NON_PSA_ROT_DEBUG (0x4000u)
• RECOVERABLE_PSA_ROT_DEBUG (0x5000u)
• PSA_LIFECYCLE_DECOMMISSIONED (0x6000u)

Table 2 shows the structure of each software component entry in the Software Components claim.

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 represented as a token, which must be formatted in accordance to the Entity Attestation Token (EAT) [I-D.mandyam-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
• origination (recommended); arm_psa_origination 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.

Each map entry of the software component claim MUST have the following types for each key value:

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)

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

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):

    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",
            / 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'
  ]
)

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 single out an individual device for tracking purposes. Implementation must take 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 [RFC8392] created 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

9.2. Informative References

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, 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