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.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 five 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.Software Relations (), used to model upgrade and patch
relationships between software components;Endorsements Block List (), used to invalidate
previously provisioned Endorsements.PSA Endorsement ProfilePSA Endorsements are carried in one or more CoMIDs inside a CoRIM.The profile attribute in the CoRIM MUST be present and MUST have a single entry
set to the uri http://arm.com/psa/iot/1 as shown in .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 ).In order to support PSA Implementation IDs, the CoMID type
$class-id-type-choice is extended as follows: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 .Optional vendor and model can be specified as well. Together, they are
interpreted as a unique identifier of the product that embeds the PSA RoT.
Consistently providing a product identifier is RECOMMENDED.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 identified in the subject of
the "reference value" triple. A single reference-triple-record SHALL
completely describe the updatable PSA RoT.The identifier of a measured software component is encoded in a psa-swcomp-id
object as follows:The semantics of the codepoints in the psa-swcomp-id map are equivalent to
those in the psa-software-component map defined in Section 3.4.1 of
. The psa-swcomp-id MUST uniquely identify a given software
component within the PSA RoT / product.In order to support PSA Reference Value identifiers, the CoMID type
$measured-element-type-choice 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
measurement-values-map. The digests-type array MUST contain at least one
entry. The digests-type array MAY contain more than one entry if multiple
digests (obtained with different hash algorithms) of the same measured
component exist.The example in shows a CoMID a PSA Endorsement of type
Reference Value for a firmware measurement associated with Implementation ID
acme-implementation-id-000000001.Software Upgrades and PatchesIn order to model software lifecycle events such as updates and patches, this
profile defines a new triple that conveys the following semantics:SUBJECT: a software componentPREDICATE: (non-critically / critically) (updates / patches)OBJECT: another software componentThe triple is reified and used as the object of another triple,
psa-swrel-triple-record, whose subject is the embedding environment.An example of a security critical update involving versions "1.3.5" and "1.4.0"
of software component "PRoT" within the target environment associated with
Implementation ID acme-implementation-id-000000001 is shown in
.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 SHALL 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 (and, possibly, a product identifier) 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 a PEM-encoded
SubjectPublicKeyInfo . There MUST be only one
verification-key-map in an attest-key-triple-record;The optional comid.keychain entry MUST NOT be set by a CoMID producer that
uses the profile described in this document, and MUST be ignored by a CoMID
consumer that is parsing according to this profile.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 -- comprising the immutable part as well as zero
or more of the mutable components -- and the associated SAC is provided by a
Certification Claim, which binds the PSA RoT Implementation ID and the software
component identifiers 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:The Implementation ID of the immutable PSA RoT to which the SAC applies is
encoded as a tagged-impl-id-type in the psa.immutable-rot of the
psa-rot-descriptor;Any software component that is part of the certified PSA RoT is encoded as a
psa-swcomp-id (see ) in the psa.mutable-rot of the
psa-rot-descriptor;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 that
associates Certificate Number 1234567890123 - 12345 to Implementation ID
acme-implementation-id-000000001 and a single "PRoT" software component with
version "1.3.5".Endorsements Block ListThis is work in progress. It may change or be removed in the future.The following three "blocklist" claims:reference-blocklist-tripleattest-key-blocklist-triplecert-blocklist-tripleare 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 ConsiderationsCBOR Tag RegistrationsIANA is requested to allocate the following tag in the "CBOR Tags" registry
, preferably with the specified value:TagData ItemSemantics600tagged bytesPSA Implementation ID ( of RFCTHIS)601tagged mapPSA Software Component Identifier ( of RFCTHIS)CoRIM Profile RegistrationIANA is requested to register the following profile value in the
TODO CoRIM registry.Profile ValueTypeSemanticshttp://arm.com/psa/iot/1uriThe CoRIM profile specified by this documentCoMID CodepointsIANA is requested to register the following codepoints to the "CoMID Triples
Map" registry.IndexItem NameSpecification4comid.psa-cert-triplesRFCTHIS5comid.psa-swrel-triplesRFCTHISAcknowledgementsTODOArm'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.
Concise Reference Integrity ManifestFraunhofer SITArm LimitedArm LimitedIntel CorporationHuawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to put
trust in the trustworthiness of a remote Attester and therefore to
decide if to engage in secure interactions with it - or not.
Evidence about trustworthiness can be rather complex, voluminous or
Attester-specific. As it is deemed unrealistic that every Relying
Party is capable of the appraisal of Evidence, that burden is taken
on by a Verifier. In order to conduct Evidence appraisal procedures,
a Verifier requires not only fresh Evidence from an Attester, but
also trusted Endorsements and Reference Values from Endorsers, such
as manufacturers, distributors, or owners. This document specifies
Concise Reference Integrity Manifests (CoRIM) that represent
Endorsements and Reference Values in CBOR format. Composite devices
or systems are represented by a collection of Concise Module
Identifiers (CoMID) and Concise Software Identifiers (CoSWID) bundled
in a CoRIM document.
Key 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.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.Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) ProfileThis memo profiles the X.509 v3 certificate and X.509 v2 certificate revocation list (CRL) for use in the Internet. An overview of this approach and model is provided as an introduction. The X.509 v3 certificate format is described in detail, with additional information regarding the format and semantics of Internet name forms. Standard certificate extensions are described and two Internet-specific extensions are defined. A set of required certificate extensions is specified. The X.509 v2 CRL format is described in detail along with standard and Internet-specific extensions. An algorithm for X.509 certification path validation is described. An ASN.1 module and examples are provided in the appendices. [STANDARDS-TRACK]Concise Binary Object Representation (CBOR) TagsIANARemote 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.
PSA Certified