[Search] [txt|html|xml|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00                                                            
RATS                                                          T. Fossati
Internet-Draft                                              Y. Deshpande
Intended status: Informational                                   Arm Ltd
Expires: 13 January 2022                                     H. Birkholz
                                                          Fraunhofer SIT
                                                            12 July 2021


    Arm's Platform Security Architecture (PSA) Attestation Verifier
                              Endorsements
                   draft-xyz-rats-psa-endorsements-00

Abstract

   PSA Endorsements include reference values, cryptographic key material
   and certification status information that a Verifier needs in order
   to appraise attestation Evidence produced by a PSA device.  This memo
   defines such PSA Endorsements as a profile of the CoRIM data model.

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 13 January 2022.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.











Fossati, et al.          Expires 13 January 2022                [Page 1]


Internet-Draft              PSA Endorsements                   July 2021


   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  PSA Endorsements  . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  PSA Endorsements to PSA RoT Linkage . . . . . . . . . . .   3
     3.2.  Reference Values  . . . . . . . . . . . . . . . . . . . .   4
     3.3.  Attestation Verification Claims . . . . . . . . . . . . .   6
     3.4.  Certification Claims  . . . . . . . . . . . . . . . . . .   8
     3.5.  Endorsements Block List . . . . . . . . . . . . . . . . .   9
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   9
   References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   9
     Normative References  . . . . . . . . . . . . . . . . . . . . .   9
     Informative References  . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   PSA Endorsements include reference values, cryptographic key material
   and certification status information that a Verifier needs in order
   to appraise attestation Evidence produced by a PSA device
   [PSA-TOKEN].  This memo defines such PSA Endorsements as a profile of
   the CoRIM data model [CoRIM].

2.  Conventions and Definitions

   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.

   The reader is assumed to be familiar with the terms defined in
   Section 2.1 of [PSA-TOKEN] and in Section 4 of [RATS-ARCH].






Fossati, et al.          Expires 13 January 2022                [Page 2]


Internet-Draft              PSA Endorsements                   July 2021


3.  PSA Endorsements

   PSA Endorsements describe an attesting device in terms of the
   hardware and firmware components that make up its PSA Root of Trust
   (RoT).  This includes the identification and expected state of the
   device as well as the cryptographic key material needed to verify
   Evidence signed by the device's PSA RoT.  Additionally, PSA
   Endorsements can include information related to the certification
   status of the attesting device.

   There are three basic types of PSA Endorsements:

   *  Reference Values (Section 3.2), i.e., measurements of the PSA RoT
      firmware;

   *  Attestation Verification Claims (Section 3.3), i.e., cryptographic
      keys that can be used to verify signed Evidence produced by the
      PSA RoT, along with the identifiers that bind the keys to their
      device instances;

   *  Certification Claims (Section 3.4), i.e., metadata that describe
      the certification status associated with a PSA device.

   There is also a fourth category of PSA Endorsements:

   *  Endorsements Block List (Section 3.5),

   that is used to invalidate previously provisioned Endorsements.

3.1.  PSA Endorsements to PSA RoT Linkage

   Each PSA Endorsement - be it a Reference Value, Attestation
   Verification Claim or Certification Claim - is associated with an
   immutable PSA RoT.  A PSA Endorsement is associated to its PSA RoT by
   means of the unique PSA RoT identifier known as Implementation ID
   (see Section 3.2.2 of [PSA-TOKEN]).  Besides, a PSA Endorsement can
   be associated with a specific instance of a certain PSA RoT - as in
   the case of Attestation Verification Claims.  A PSA Endorsement is
   associated with a PSA RoT instance by means of the Instance ID (see
   Section 3.2.1 of [PSA-TOKEN]) and its "parent" Implementation ID.

   These identifiers are typically found in the subject of a CoMID
   triple, encoded in an "environment-map" as shown in Figure 1.








Fossati, et al.          Expires 13 January 2022                [Page 3]


Internet-Draft              PSA Endorsements                   July 2021


   / environment-map / {
     / comid.class / 0 : {
       / comid.class-id / 0 :
         / tagged-impl-id-type / 47115(
           h'61636d652d696d706c656d656e746174696f6e2d69642d303030303030
   303031'
         )
     },
     / comid.instance / 1 :
       / tagged-ueid-type / 48000(
         h'014ca3e4f50bf248c39787020d68ffd05c88767751bf2645ca923f57a98b
   ecd296'
       )
   }

                  Figure 1: Example PSA RoT Identification

3.2.  Reference Values

   Reference Values carry measurements and other metadata associated
   with the updatable firmware in a PSA RoT.  When appraising Evidence,
   the Verifier compares Reference Values against the values found in
   the Software Components of the PSA token (see Section 3.4.1 of
   [PSA-TOKEN]).

   Each measurement is encoded in a "measurement-map" of a CoMID
   "reference-triple-record".  Since a "measurement-map" can encode one
   or more measurements, a single "reference-triple-record" can carry as
   many measurements as needed, provided they belong to the same PSA RoT
   carried in the subject of the "reference value" triple.

   The identifier of a measurement is encoded in a "psa-refval-id"
   object as follows:

   psa-refval-id = {
     ? psa.measurement-type => text
     ? psa.version => text
       psa.signer-id => psa.hash-type
     ? psa.measurement-desc => text
   }

   psa.hash-type = bytes .size 32 / bytes .size 48 / bytes .size 64

   psa.measurement-type = 1
   psa.version = 4
   psa.signer-id = 5
   psa.measurement-desc = 6




Fossati, et al.          Expires 13 January 2022                [Page 4]


Internet-Draft              PSA Endorsements                   July 2021


   The semantics of the codepoints in the "psa-refval-id" map are
   equivalent to those in the "psa-software-component" map defined in
   Section 3.4.1 of [PSA-TOKEN].

   In order to support PSA Reference Value identifiers, the "$measured-
   element-type-choice" CoMID type is extended as follows:

   tagged-psa-refval-id = #6.TBD(psa-refval-id)

   $measured-element-type-choice /= tagged-psa-refval-id

   and automatically bound to the "comid.mkey" in the "measurement-map".

   The raw measurement is encoded in a "digests-type" object in the
   "measurements-value-map".  The "digests-type" array MUST contain only
   one entry.  If multiple digests of the same measured component exist
   (obtained with different hash algorithms), a different
   "psa.measurement-desc" MUST be used in the identifier.

   The example in Figure 2 shows the PSA Endorsement of type Reference
   Value for a firmware measurement associated with Implementation ID
   "acme-implementation-id-000000001".





























Fossati, et al.          Expires 13 January 2022                [Page 5]


Internet-Draft              PSA Endorsements                   July 2021


   / concise-mid-tag / {
     / comid.tag-identity / 1 : {
       / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f'
     },
     / comid.triples / 4 : {
       / comid.reference-triples / 0 : [
         / environment-map / {
           / comid.class / 0 : {
             / comid.class-id / 0 :
               / tagged-impl-id-type / 47115(
                 h'61636d652d696d706c656d656e746174696f6e2d69642d303030
   303030303031'
               )
           }
         },
         / measurement-map / {
           / comid.mkey / 0 : TBD({
             / psa.measurement-type / 1 : "PRoT",
             / psa.version /          4 : "1.3.5",
             / psa.signer-id /        5 : h'acbb11c7e4da217205523ce4ce1
   a245ae1a239ae3c6bfd9e7871f7e5d8bae86b'
           }),
           / comid.mval / 1 : {
             / comid.digests / 2 : [
               / hash-alg-id / 1, / sha256 /
               / hash-value /  h'44aa336af4cb14a879432e53dd6571c7fa9bcc
   afb75f488259262d6ea3a4d91b'
             ]
           }
         }
       ]
     }
   }

                     Figure 2: Example Reference Value

3.3.  Attestation Verification Claims

   An Attestation Verification Claim carries the verification key
   associated with the Initial Attestation Key (IAK) of a PSA device.
   When appraising Evidence, the Verifier uses the Implementation ID and
   Instance ID claims (see Section 3.1) to retrieve the verification key
   that it must use to check the signature on the Evidence.  This allows
   the Verifier to prove (or disprove) the Attester's claimed identity.

   Each verification key is provided alongside the corresponding device
   Instance and Implementation IDs in an "attest-key-triple-record".
   Specifically:



Fossati, et al.          Expires 13 January 2022                [Page 6]


Internet-Draft              PSA Endorsements                   July 2021


   *  The Instance and Implementation IDs are encoded in the
      environment-map as shown in Figure 1;

   *  The IAK public key is carried in the "comid.key" entry in the
      "verification-key-map".  The IAK public key is encoded as a
      COSE_Key according to Section 7 of [RFC8152].  There MUST be only
      one "verification-key-map" in an "identity-triple-record";

   *  The optional "comid.keychain" entry MUST NOT be set by a producer
      and MUST be ignored by a consumer.

   The example in Figure 3 shows the PSA Endorsement of type Attestation
   Verification Claim carrying a secp256r1 EC public IAK associated with
   Instance ID "4ca3...d296".

   / concise-mid-tag / {
     / comid.tag-identity / 1 : {
       / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f'
     },
     / comid.triples / 4 : {
       / comid.attest-key-triples / 3 : [
         / environment-map / {
           / comid.class / 0 : {
             / comid.class-id / 0 :
               / tagged-impl-id-type / 47115(
                 h'61636d652d696d706c656d656e746174696f6e2d69642d303030
   303030303031'
               )
           },
           / comid.instance / 1 :
             / tagged-ueid-type / 48000(
               h'014ca3e4f50bf248c39787020d68ffd05c88767751bf2645ca923f
   57a98becd296'
             )
         },
         / verification-key-map / {
           / comid.key / 0 : {
             / kty /  1 : 2, / EC2 /
             / crv / -1 : 1, / P-256 /
             / x /   -2 : h'30a0424cd21c2944838a2d75c92b37e76ea20d9f008
   93a3b4eee8a3c0aaf',
             / y /   -3 : h'e04b65e92456d9888b52b379bdfbd51ee869ef1f0fc
   65b6659695b6cce08'
           }
         }
       ]
     }
   }



Fossati, et al.          Expires 13 January 2022                [Page 7]


Internet-Draft              PSA Endorsements                   July 2021


              Figure 3: Example Attestation Verification Claim

3.4.  Certification Claims

   PSA Certified [PSA-CERTIFIED] defines a certification scheme for the
   PSA ecosystem.  A product - either a hardware component, a software
   component, or an entire device - that is verified to meet the
   security criteria established by the PSA Certified scheme is
   warranted a PSA Certified Security Assurance Certificate (SAC).  A
   SAC contains information about the certification of a certain product
   (e.g., the target system, the attained certification level, the test
   lab that conducted the evaluation, etc.), and has a unique
   Certificate Number.

   The linkage between a PSA RoT and a related SAC is provided by a
   Certification Claim, which binds the PSA RoT Implementation ID with
   the SAC unique Certificate Number.  When appraising Evidence, the
   Verifier can use the Certification Claims associated with the
   identified Attester as ancillary input to the Appraisal Policy, or to
   enrich the produced Attestation Result.

   A Certification Claim is encoded in an "psa-cert-triple-record",
   which extends the "$$triples-map-extension" socket, as follows:

   comid.psa-cert-triples = 4

   $$triples-map-extension //= (
     comid.psa-cert-triples => one-or-more<psa-cert-triple-record>
   )

   psa-cert-triple-record = [
     tagged-impl-id-type,
     psa-cert-num-type
   ]

   psa-cert-num-type = text .regexp "[0-9]{13} - [0-9]{5}"

   *  The Implementation ID to which the SAC applies is encoded in the
      "tagged-impl-id-type";

   *  The unique SAC Certificate Number is encoded in the "psa-cert-num-
      type".

   A single CoMID can carry one or more Certification Claims.

   The example in Figure 4 shows a Certification Claim for Certificate
   Number "1234567890123 - 12345" and Implementation ID "acme-
   implementation-id-000000001".



Fossati, et al.          Expires 13 January 2022                [Page 8]


Internet-Draft              PSA Endorsements                   July 2021


   / concise-mid-tag / {
     / comid.tag-identity / 1 : {
       / comid.tag-id / 0 : h'3f06af63a93c11e4979700505690773f'
     },
     / comid.triples / 4 : {
       / comid.psa-cert-triples / 4 : [
         / tagged-impl-id-type / 47115(
           h'61636d652d696d706c656d656e746174696f6e2d69642d303030303030
   303031'
         ),
         / psa-cert-num-type / "1234567890123 - 12345"
       ]
     }
   }

   Figure 4: Example Certification Claim with `supplement` Link-Relation

3.5.  Endorsements Block List

   The following three "blocklist" claims:

   *  "reference-blocklist-triple"

   *  "attest-key-blocklist-triple"

   *  "cert-blocklist-triple"

   are defined with the same syntax but opposite semantics with regards
   to their "positive" counterparts to allow invalidating previously
   provisioned endorsements from the acceptable set.

4.  Security Considerations

   TODO

5.  IANA Considerations

   TODO

Acknowledgements

   TODO

References

Normative References





Fossati, et al.          Expires 13 January 2022                [Page 9]


Internet-Draft              PSA Endorsements                   July 2021


   [CoRIM]    Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
              W. Pan, "Concise Reference Integrity Manifest", Work in
              Progress, Internet-Draft, draft-birkholz-rats-corim-00, 12
              July 2021, <https://www.ietf.org/archive/id/draft-
              birkholz-rats-corim-00.txt>.

   [PSA-TOKEN]
              Tschofenig, H., Frost, S., Brossard, M., Shaw, A., and T.
              Fossati, "Arm's Platform Security Architecture (PSA)
              Attestation Token", Work in Progress, Internet-Draft,
              draft-tschofenig-rats-psa-token-08, 24 March 2021,
              <https://www.ietf.org/archive/id/draft-tschofenig-rats-
              psa-token-08.txt>.

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

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

Informative References

   [PSA-CERTIFIED]
              "PSA Certified", 2021, <https://www.psacertified.org>.

   [RATS-ARCH]
              Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
              W. Pan, "Remote Attestation Procedures Architecture", Work
              in Progress, Internet-Draft, draft-ietf-rats-architecture-
              12, 23 April 2021, <https://www.ietf.org/archive/id/draft-
              ietf-rats-architecture-12.txt>.

Authors' Addresses

   Thomas Fossati
   Arm Ltd

   Email: thomas.fossati@arm.com






Fossati, et al.          Expires 13 January 2022               [Page 10]


Internet-Draft              PSA Endorsements                   July 2021


   Yogesh Deshpande
   Arm Ltd

   Email: yogesh.deshpande@arm.com


   Henk Birkholz
   Fraunhofer SIT

   Email: henk.birkholz@sit.fraunhofer.de









































Fossati, et al.          Expires 13 January 2022               [Page 11]