[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04

RATS                                                  H. Tschofenig, Ed.
Internet-Draft                                                  S. Frost
Intended status: Standards Track                             M. Brossard
Expires: September 12, 2019                                      A. Shaw
                                                             Arm Limited
                                                          March 11, 2019


      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.




Tschofenig, et al.     Expires September 12, 2019               [Page 1]


Internet-Draft            PSA Attestation Token               March 2019


   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
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
     2.1.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Information Model . . . . . . . . . . . . . . . . . . . . . .   5
   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

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.



Tschofenig, et al.     Expires September 12, 2019               [Page 2]


Internet-Draft            PSA Attestation Token               March 2019


   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.

































Tschofenig, et al.     Expires September 12, 2019               [Page 3]


Internet-Draft            PSA Attestation Token               March 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 |  | | 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,



Tschofenig, et al.     Expires September 12, 2019               [Page 4]


Internet-Draft            PSA Attestation Token               March 2019


      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.

   +----------------+--------------+-----------------------------------+
   | Claim          |  Mandatory   | Description                       |
   +----------------+--------------+-----------------------------------+
   | Challenge      |     Yes      | Input object from the caller. For |
   |                |              | example, this can be a            |
   |                |              | cryptographic nonce, a hash of    |
   |                |              | locally attested data, or both.   |
   |                |              | 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.      |
   |                |              |                                   |
   | Verification   |      No      | Information used by a relying     |
   | Service        |              | party to locate a validation      |
   | Indicator      |              | service for 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.                          |
   |                |              |                                   |
   | 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      | Represents the original           |
   | ID             |              | implementation signer of the      |
   |                |              | attestation key and identifies    |
   |                |              | the contract between the report   |
   |                |              | and verification. A verification  |
   |                |              | service will use this claim to    |
   |                |              | locate the details of the         |



Tschofenig, et al.     Expires September 12, 2019               [Page 5]


Internet-Draft            PSA Attestation Token               March 2019


   |                |              | verification process.             |
   |                |              |                                   |
   | 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 |
   |                |              | defined in the PSA Firmware       |
   |                |              | Framework (PSA-FF) [PSA-FF].      |
   |                |              |                                   |
   | Security       |     Yes      | Represents the current lifecycle  |
   | Lifecycle      |              | state of the PSA RoT. The state   |
   |                |              | is represented by a 16-bit        |
   |                |              | unsigned integer that is divided  |
   |                |              | to convey a major state and a     |
   |                |              | minor state. A major state is     |
   |                |              | defined by [PSA-SM]. A minor      |
   |                |              | state is 'IMPLEMENTATION          |
   |                |              | DEFINED'. The encoding is:        |
   |                |              | version[15:8] - PSA lifecycle     |
   |                |              | state, and version[7:0] -         |
   |                |              | IMPLEMENTATION DEFINED state. The |
   |                |              | PSA lifecycle states are listed   |
   |                |              | below. For PSA, a remote verifier |
   |                |              | can only trust reports from the   |
   |                |              | PSA RoT when it is in SECURED,    |
   |                |              | NON_PSA_ROT_DEBUG or              |
   |                |              | RECOVERABLE_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 system sessions.   |
   |                |              |                                   |
   | Software       | Yes (unless  | A list of software components     |
   | Components     |    the No    | that represent the entire         |



Tschofenig, et al.     Expires September 12, 2019               [Page 6]


Internet-Draft            PSA Attestation Token               March 2019


   |                |   Software   | software state of the system.     |
   |                | Measurements | This claim is recommended in      |
   |                |   claim is   | order to comply with the rules    |
   |                |  specified)  | outlined in the [PSA-SM]. The     |
   |                |              | software components are further   |
   |                |              | explained below.                  |
   |                |              |                                   |
   | 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.                 |
   +----------------+--------------+-----------------------------------+

           Table 1: Information Model of PSA Attestation 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.

   +-----+-------------+-----------+-----------------------------------+
   | Key |     Type    | Mandatory | Description                       |
   | ID  |             |           |                                   |
   +-----+-------------+-----------+-----------------------------------+
   | 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   |



Tschofenig, et al.     Expires September 12, 2019               [Page 7]


Internet-Draft            PSA Attestation Token               March 2019


   |     |             |           | 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  |    Yes    | 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.                |
   |     |             |           |                                   |
   | 6   | Measurement |     No    | Description of the software       |
   |     | description |           | component, which represents the   |
   |     |             |           | way in which 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.

   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




Tschofenig, et al.     Expires September 12, 2019               [Page 8]


Internet-Draft            PSA Attestation Token               March 2019


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

























Tschofenig, et al.     Expires September 12, 2019               [Page 9]


Internet-Draft            PSA Attestation Token               March 2019


   +--------+--------------+----------------------------+--------------+
   | Claim  |    Claim     |         Claim Name         | CBOR Value   |
   |  Key   | Description  |                            | Type         |
   +--------+--------------+----------------------------+--------------+
   | -75000 |   Profile    |     arm_psa_profile_id     | Text string  |
   |        |  Definition  |                            |              |
   |        |              |                            |              |
   | -75001 |  Client ID   |    arm_psa_partition_id    | Unsigned     |
   |        |              |                            | integer or   |
   |        |              |                            | Negative     |
   |        |              |                            | integer      |
   |        |              |                            |              |
   | -75002 |   Security   | arm_psa_security_lifecycle | Unsigned     |
   |        |  Lifecycle   |                            | integer      |
   |        |              |                            |              |
   | -75003 |   Impl. ID   | arm_psa_implementation_id  | Byte string  |
   |        |              |                            | (>=32 bytes) |
   |        |              |                            |              |
   | -75004 |  Boot Seed   |     arm_psa_boot_seed      | Byte string  |
   |        |              |                            | (>=32 bytes) |
   |        |              |                            |              |
   | -75005 |   Hardware   |     arm_psa_hw_version     | Text string  |
   |        |   Version    |                            |              |
   |        |              |                            |              |
   | -75006 |   Software   |   arm_psa_sw_components    | Array of map |
   |        |  Components  |                            | entries.     |
   |        |              |                            | (compound    |
   |        |              |                            | map claim)   |
   |        |              |                            |              |
   | -75007 | No Software  | arm_psa_no_sw_measurements | Unsigned     |
   |        | Measurements |                            | integer      |
   |        |              |                            |              |
   | -75008 |  Challenge   |       arm_psa_nonce        | Byte string  |
   |        |              |                            |              |
   | -75009 | Instance ID  |        arm_psa_UEID        | Byte string  |
   |        |              |                            |              |
   | -75010 | Verification |    arm_psa_origination     | Byte string  |
   |        |   Service    |                            | or           |
   |        |  Indicator   |                            | StringOrURI  |
   +--------+--------------+----------------------------+--------------+

   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)




Tschofenig, et al.     Expires September 12, 2019              [Page 10]


Internet-Draft            PSA Attestation Token               March 2019


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











Tschofenig, et al.     Expires September 12, 2019              [Page 11]


Internet-Draft            PSA Attestation Token               March 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 September 12, 2019              [Page 12]


Internet-Draft            PSA Attestation Token               March 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 September 12, 2019              [Page 13]


Internet-Draft            PSA Attestation Token               March 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 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

   [I-D.mandyam-eat]
              Mandyam, G., Lundblade, L., Lundblade, L., Ballesteros,
              M., and J. O'Donoghue, "The Entity Attestation Token
              (EAT)", draft-mandyam-eat-01 (work in progress), November
              2018.

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





Tschofenig, et al.     Expires September 12, 2019              [Page 14]


Internet-Draft            PSA Attestation Token               March 2019


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

9.2.  Informative References

   [EAN-13]   GS1, "International Article Number - EAN/UPC barcodes",
              2019, <https://www.gs1.org/standards/barcodes/ean-upc>.

   [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 September 12, 2019              [Page 15]


Internet-Draft            PSA Attestation Token               March 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, 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 September 12, 2019              [Page 16]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/