Internet-Draft PSA Endorsements July 2021
Fossati, et al. Expires 13 January 2022 [Page]
Workgroup:
RATS
Internet-Draft:
draft-xyz-rats-psa-endorsements-00
Published:
Intended Status:
Informational
Expires:
Authors:
T. Fossati
Arm Ltd
Y. Deshpande
Arm Ltd
H. Birkholz
Fraunhofer SIT

Arm's Platform Security Architecture (PSA) Attestation Verifier Endorsements

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.

▲

Table of Contents

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

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:

There is also a fourth category of PSA Endorsements:

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.

/ 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

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.

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

  • 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'
        }
      }
    ]
  }
}
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.

/ 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

[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, , <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, , <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, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8152]
Schaad, J., "CBOR Object Signing and Encryption (COSE)", RFC 8152, DOI 10.17487/RFC8152, , <https://www.rfc-editor.org/info/rfc8152>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.

Informative References

[PSA-CERTIFIED]
"PSA Certified", , <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, , <https://www.ietf.org/archive/id/draft-ietf-rats-architecture-12.txt>.

Authors' Addresses

Thomas Fossati
Arm Ltd
Yogesh Deshpande
Arm Ltd
Henk Birkholz
Fraunhofer SIT