Arm's Platform Security Architecture (PSA) Attestation Verifier EndorsementsArm Ltdthomas.fossati@arm.comArm Ltdyogesh.deshpande@arm.comFraunhofer SIThenk.birkholz@sit.fraunhofer.de
Security
RATSPSA 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 .
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.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
() 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
. Introduction
. Conventions and Definitions
. PSA Endorsements
. PSA Endorsements to PSA RoT Linkage
. Reference Values
. Attestation Verification Claims
. Certification Claims
. Endorsements Block List
. Security Considerations
. IANA Considerations
Acknowledgements
References
Normative References
Informative References
Authors' Addresses
IntroductionPSA 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 .Conventions and DefinitionsThe 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 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
and in Section 4 of .PSA EndorsementsPSA 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 (), i.e., measurements of the PSA RoT
firmware;
Attestation Verification Claims (), 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 (), 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 (),
that is used to invalidate previously provisioned Endorsements.PSA Endorsements to PSA RoT LinkageEach 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 ).
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 ) 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 .Reference ValuesReference 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 ).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: 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
.In order to support PSA Reference Value identifiers, the
$measured-element-type-choice CoMID type is extended as follows: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 shows the PSA Endorsement of type
Reference Value for a firmware measurement associated with Implementation ID
acme-implementation-id-000000001.Attestation Verification ClaimsAn 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
) 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 ;
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 . 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 shows the PSA Endorsement
of type Attestation Verification Claim carrying a secp256r1 EC public IAK
associated with Instance ID 4ca3...d296.Certification ClaimsPSA 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: one-or-more
)
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 shows a Certification Claim for
Certificate Number 1234567890123 - 12345 and Implementation ID
acme-implementation-id-000000001.Endorsements Block ListThe 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.Security ConsiderationsTODOIANA ConsiderationsTODOAcknowledgementsTODOReferencesNormative ReferencesConcise Reference Integrity ManifestFraunhofer SITArm LimitedArm LimitedIntel CorporationHuawei Technologies Abstract
Discussion Venues
This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the RATS Working Group
mailing list (rats@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/rats/.
Source for this draft and an issue tracker can be found at
https://github.com/ietf-rats/draft-birkholz-rats-corim.
Work in ProgressArm's Platform Security Architecture (PSA) Attestation TokenArm LimitedArm LimitedArm LimitedArm LimitedArm Limited The Platform Security Architecture (PSA) is a family of hardware and
firmware security specifications, as well as open-source reference
implementations, to help device makers and chip manufacturers build
best-practice security into products. Devices that are PSA compliant
are able to produce attestation tokens as described in this memo,
which are the basis for a number of different protocols, including
secure provisioning and network access control. This document
specifies the PSA attestation token structure and semantics.
The PSA attestation token is a profiled Entity Attestation Token
(EAT).
This specification describes what claims are used in an attestation
token generated by PSA compliant systems, how these claims get
serialized to the wire, and how they are cryptographically protected.
Work in ProgressKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.CBOR Object Signing and Encryption (COSE)Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need for the ability to have basic security services defined for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR.Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesPSA CertifiedRemote Attestation Procedures ArchitectureFraunhofer SITMicrosoftSandelman Software WorksIntel CorporationHuawei Technologies In network protocol exchanges it is often useful for one end of a
communication to know whether the other end is in an intended
operating state. This document provides an architectural overview of
the entities involved that make such tests possible through the
process of generating, conveying, and evaluating evidentiary claims.
An attempt is made to provide for a model that is neutral toward
processor architectures, the content of claims, and protocols.
Work in ProgressAuthors' AddressesArm Ltdthomas.fossati@arm.comArm Ltdyogesh.deshpande@arm.comFraunhofer SIThenk.birkholz@sit.fraunhofer.de