Automatic Integration of Secure Silicon (AISS) Attestation TokenArm LimitedHannes.Tschofenig@arm.comSynopsysarto.kankaanpaa@synopsys.comSynopsysnick.bowler@synopsys.comArm LimitedTushar.Khandelwal@arm.com
Security
RATSInternet-DraftThis specification defines a profile of the Entity Attestation Token (EAT) for use in
special System-on-Chip (SoC) designs that are generated automatically utilizing a
methodology currently developed in a DARPA funded project.The DARPA-funded project Automated Implementation of Secure Silicon (AISS) is aimed at
making scalable on-chip security pervasive. The objective is to develop ways to automate
the process of adding security into integrated circuits.If successful, AISS will allow security to be inexpensively incorporated into chip designs
with minimal effort and expertise, ultimately making scalable on-chip security ubiquitous.
The project seeks to create a novel, automated chip design flow that will allow the security
mechanisms to scale consistently with the goals of the design.As a minimal component, the generated chip designs must offer attestation capabilities.This specification describes the minimal claim set offered by an attestation token
conforming to the Entity Attestation Token (EAT) specification. This attestation
token is, on request, provided to a Verifier.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 when, and only when, they
appear in all capitals, as shown here.The following term is used in this document:
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. An example of RoT is an initial bootloader in ROM, which contains
cryptographic functions and credentials, running on a specific hardware
platform.This section describes the claims to be used in an AISS attestation token.CDDL along with text descriptions is used to define each claim
independent of encoding. The following CDDL type(s) are reused by different
claims:The Nonce claim is used to carry the challenge provided by the caller to
demonstrate freshness of the generated token.The EAT nonce (claim key 10) is used. The following
constraints apply to the nonce-type:The length MUST be either 32, 48, or 64 bytes.Only a single nonce value is conveyed. Per the array
notation is not used for encoding the nonce value.This claim MUST be present in an AISS attestation token.The Instance ID claim represents the unique identifier of the
attestation key.The EAT ueid (claim key 256) of type RAND is used. The following
constraints apply to the ueid-type:The length MUST be 17 bytes.The first byte MUST be 0x01 (RAND) followed by the 16-bytes random
value, which may be created by hashing the key identifier or may be
the key identifier itself.This claim MUST be present in an AISS attestation token.The Implementation ID claim uniquely identifies the implementation of the
immutable RoT. A verification service uses this claim to locate the
details of the RoT implementation from a manufacturer. Such details are used
by a verification service to determine the security properties or
certification status of the RoT implementation.The value and format of the ID is decided by the manufacturer or a
particular certification scheme. For example, the ID could take the
form of a product serial number, database ID, or other appropriate
identifier.This claim MUST be present in an AISS attestation token.Note that this identifies the RoT implementation, not a particular instance.
The Instance ID claim, see , uniquely identifies an
instance.The Security Lifecycle claim represents the current lifecycle state of the
RoT. The state is represented by an unsigned integer.The lifecycle states are illustrated in . When the
device is deployed, a Verifier can only trust reports when the lifecycle
state is in “Secured” and “Non-RoT Debug” states. The states “Testing”
and “Provisioning” are utilized during manufacturing. A device is in
“Decommisioned” state when it is retired.This claim MUST be present in an AISS attestation token.The Boot Odometer claim contains a value that represents the number of
times the entity or submod has been booted.The EAT boot-seed-label (claim key TBD) of type unsigned integer is used.This claim MUST be present in an AISS attestation token.Watermarking, the process of marking an asset with a known structure,
is used to detect intellectual property (IP) theft and overuse. Watermarking
in hardware IPs is the mechanism of embedding a unique “code” into IP
without altering the original functionality of the design. The ownership
of the IP can be later verified when the watermark is extracted.The Watermark claim contains a code extracted from the watermarking
hardware identified by an identifier. This identifier is formated
as a type 4 UUID .This claim MUST be present in an AISS attestation token when the
attestation token request asked for a watermark to be present.The Profile Definition claim encodes the unique identifier that corresponds to
the EAT profile described by this document. This allows a receiver to assign
the intended semantics to the rest of the claims found in the token.The EAT profile (claim key 265) is used. The following constraints
apply to its type:The URI encoding MUST be used.The value MUST be http://aiss/1.0.0.This claim MUST be present in an AISS attestation token.The AISS attestation token is encoded in CBOR format. Only
definite-length string, arrays, and maps are allowed.Cryptographic protection is accomplished by COSE. The signature
structure MUST be COSE_Sign1. Only the use of asymmetric key algorithms is
envisioned.The CWT CBOR tag (61) is not used. An application that needs to exchange PSA
attestation tokens can wrap the serialised COSE_Sign1 in a dedicated media
type, as for example defined in defined in or the CoAP Content-Format defined in
.The AISS attestation token supports the freshness models for attestation Evidence
based on nonces (Section 10.2 and 10.3 of ) using
the nonce claim to convey the nonce supplied by the Verifier. No further
assumption on the specific remote attestation protocol is made.To verify the token, the primary need is to check correct encoding and signing
as detailed in . In particular, the Instance
ID claim is used (together with the kid in the COSE header, if present)
to assist in locating the public key used to verify the signature covering the token.
The key used for verification is supplied to the Verifier by an authorized
Endorser along with the corresponding Attester’s Instance ID.In addition, the Verifier will typically operate a policy where values of some
of the claims in this profile can be compared to reference values, registered
with the Verifier for a given deployment, in order to confirm that the device
is endorsed by the manufacturer supply chain. The policy may require that the
relevant claims must have a match to a registered reference value.The protocol used to convey Endorsements and Reference Values to the Verifier
is not in scope for this document.This specification requests IANA to register the following claims in the “CBOR
Web Token (CWT) Claims” registry .Claim Name: aiss-security-lifecycleClaim Description: AISS Security LifecycleJWT Claim Name: N/AClaim Key: TBD (requested value: 2500)Claim Value Type(s): unsigned integerChange Controller: [[Authors of this RFC]]Specification Document(s): of [[this RFC]]Claim Name: aiss-implementation-idClaim Description: AISS Implementation IDJWT Claim Name: N/AClaim Key: TBD (requested value: 2501)Claim Value Type(s): byte stringChange Controller: [[Authors of this RFC]]Specification Document(s): of [[this RFC]]Claim Name: aiss-watermarkClaim Description: AISS WatermarkJWT Claim Name: N/AClaim Key: TBD (requested value: 2502)Claim Value Type(s): byte stringChange Controller: [[Authors of this RFC]]Specification Document(s): of [[this RFC]]IANA is requested to register the “application/aiss-attestation-token” media
type in the “Media Types” registry in the
manner described in RFC 6838 , which can be used to indicate that
the content is an AISS Attestation Token.Type name: applicationSubtype name: aiss-attestation-tokenRequired parameters: n/aOptional parameters: n/aEncoding considerations: binarySecurity considerations: See the Security Considerations section
of [[this RFC]]Interoperability considerations: n/aPublished specification: [[this RFC]]Applications that use this media type: Attesters and Relying Parties sending
AISS attestation tokens over HTTP(S), CoAP(S) and other transports.Fragment identifier considerations: n/aAdditional information: Magic number(s): n/aFile extension(s): n/aMacintosh file type code(s): n/aPerson & email address to contact for further information:
Hannes Tschofenig, Hannes.Tschofenig@arm.comIntended usage: COMMONRestrictions on usage: noneAuthor: Hannes Tschofenig, Hannes.Tschofenig@arm.comChange controller: IESGProvisional registration? NoIANA is requested to register the CoAP Content-Format ID for the
“application/aiss-attestation-token” media type in the “CoAP Content-Formats”
registry .Media Type: application/aiss-attestation-tokenEncoding: -Id: [[To-be-assigned by IANA]]Reference: [[this RFC]]CBOR Web Token (CWT) ClaimsIANAKey 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.Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data StructuresThis document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.The Entity Attestation Token (EAT)Security Theory LLCQualcomm Technologies Inc.Qualcomm Technologies Inc. An Entity Attestation Token (EAT) provides an attested claims set
that describes state and characteristics of an entity, a device like
a phone, IoT device, network equipment or such. This claims set is
used by a relying party, server or service to determine how much it
wishes to trust the entity.
An EAT is either a CBOR Web Token (CWT) or JSON Web Token (JWT) with
attestation-oriented claims. To a large degree, all this document
does is extend CWT and JWT.
A Universally Unique IDentifier (UUID) URN NamespaceThis specification defines a Uniform Resource Name namespace for UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally Unique IDentifier). A UUID is 128 bits long, and can guarantee uniqueness across space and time. UUIDs were originally used in the Apollo Network Computing System and later in the Open Software Foundation\'s (OSF) Distributed Computing Environment (DCE), and then in Microsoft Windows platforms.This specification is derived from the DCE specification with the kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been incorporated into this document. [STANDARDS-TRACK]Concise Binary Object Representation (CBOR)The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format.Multipurpose Internet Mail Extensions (MIME) Part Two: Media TypesThis second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK]Media Type Specifications and Registration ProceduresThis document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice.Media TypesIANACoAP Content-FormatsIANARemote 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.
The following example shows an AISS attestation token for an hypothetical system.
The attesting device is in a lifecycle state of
SECURED.The claims in this example are:The resulting COSE object is:We would like to thank Rob Aitken, Mike Borza, Liam Dillon, Dale Donchin, John Goodenough, and Oleg Raikhman for their feedback.Work on this document has in part been supported by the DARPA AISS project (grant agreement HR0011-20-9-0043).