From 0170186ff872af640b269949aa2285773d491d90 Mon Sep 17 00:00:00 2001 From: Dave Thaler Date: Mon, 25 Nov 2019 18:52:10 -0800 Subject: [PATCH] Proposed changes to depend on RATS for attestation Align picture with diagrams used in the TEEP WG at IETF 105 THis addresses issues #17, #31, and the part of #70 that talks about digital signature formats. Per discussion at IETF 106, the direction is that the architecture document should explain the relationship between TEEP and attestation, and leave protocol details to the TEEP protocol spec. It should NOT discuss attestation details, including anything about signing with any attestation key, seeding of attestation keys, or using specific crypto algorithms for attestation. Signed-off-by: Dave Thaler --- draft-ietf-teep-architecture.md | 252 ++++++-------------------------- 1 file changed, 46 insertions(+), 206 deletions(-) diff --git a/draft-ietf-teep-architecture.md b/draft-ietf-teep-architecture.md index 268b75a..4fd4f0f 100644 --- a/draft-ietf-teep-architecture.md +++ b/draft-ietf-teep-architecture.md @@ -60,7 +60,6 @@ informative: I-D.ietf-teep-opentrustprotocol: I-D.ietf-suit-manifest: I-D.ietf-teep-otrp-over-http: - I-D.mandyam-eat: RFC7696: GPTEE: author: @@ -568,13 +567,6 @@ provide each TAM that it places in the Client App's manifest all the TAs that th requires. There is no benefit to going to multiple different TAMs, and there is no need for a special TAM to be contacted for a specific TA. -\[Note: This should always be the case. When a particular device or TEE supports -only a special proprietary attestation mechanism, then a specific TAM will be -needed that supports that attestation scheme. The TAM should also support standard -attestation signatures as well. It is highly unlikely that a set of TAs would use -different proprietary attestation mechanisms since a TEE is likely to support only -one such proprietary scheme.\] - Separate from the Client App's manifest, this framework relies on the use of the manifest format in {{I-D.ietf-suit-manifest}} for expressing how to install the TA as well as dependencies on other TEE components and versions. @@ -1108,34 +1100,43 @@ standard interface to a Client Application or TAM SDK. Only one Broker is generally expected in a device. # Attestation -Attestation is the process through which one entity (an attester) presents a series of -claims to another entity (a verifier), and provides sufficient proof that the claims +Attestation is the process through which one entity (an Attester) presents "evidence", in the form +of a series of claims, to another entity (a Verifier), and provides sufficient proof that the claims are true. Different verifiers may have different standards for attestation proofs -and not all attestations are acceptable to every verifier. TEEP attestations are based -upon the use of an asymmetric key pair under the control of the TEE to create digital -signatures across a well-defined claim set. - -In TEEP, the primary purpose of an attestation is to allow a device to prove to TAMs -and SPs that a TEE in the device has particular properties, was built by a particular -manufacturer, or is executing a particular TA. Other claims are possible; this architecture -specification does not limit the attestation claims, but defines a minimal set of claims -required for TEEP to operate properly. Extensions to these claims are possible, but are not -defined in the TEEP specifications. Other standards or groups may define the format and semantics -of extended claims. The TEEP specification defines the claims format such that these extended claims -may be easily included in a TEEP attestation message. +and not all attestations are acceptable to every verifier. A third entity (a Relying Party) +can then use "attestation results", in the form of another series of claims, from a Verifier +to make authorization decisions. + +In TEEP, as depicted in {{attestation}}, +the primary purpose of an attestation is to allow a device (the Attester) to prove to TAMs +(the Relying Parties) that a TEE in the device has particular properties, was built by a particular +manufacturer, or is executing a particular TA. Other claims are possible; TEEP +does not limit the claims that may appear in evidence or attestation results, +but defines a minimal set of attestation result claims +required for TEEP to operate properly. Extensions to these claims are possible. +Other standards or groups may define the format and semantics +of extended claims. + +~~~~ + +----------------+ + | Device | +----------+ + | +------------+ | Evidence | TAM | Evidence +----------+ + | | TEE |------------->| (Relying |-------------->| Verifier | + | | (Attester) | | | Party) |<--------------| | + | +------------+ | +----------+ Attestation +----------+ + +----------------+ Result +~~~~ +{: #attestation title="TEEP Attestation Roles"} As of the writing of this specification, device and TEE attestations have not been standardized across the market. Different devices, manufacturers, and TEEs support different attestation -algorithms and mechanisms. In order for TEEP to be inclusive, the attestation format shall -allow for both proprietary attestation signatures, as well as a standardized form of attestation -signature. Either form of attestation signature may be applied to a set of TEEP claims, and -both forms of attestation shall be considered conformant with TEEP. However, it should be recognized -that not all TAMs or SPs may be able to process all proprietary forms of attestations. All TAMs -and SPs MUST be able to process the TEEP standard attestation format and attached signature. - -The attestation formats and mechanisms described and mandated by TEEP shall convey a particular -set of cryptographic properties based on minimal assumptions. The cryptographic properties are -conveyed by the attestation; however the assumptions are not conveyed within the attestation itself. +algorithms and mechanisms. In order for TEEP to be inclusive, it is agnostic to the format of evidence, +allowing proprietary or standardized formats to be used between a TEE and a verifier (which may or may not +be colocated in the TAM). However, it should be recognized +that not all verifiers may be able to process all proprietary forms of attestation evidence. +Similarly, the TEEP protocol is agnostic as to the format of attestation results, and the protocol +(if any) used between the TAM and a verifier, as long as they convey at least the required set of claims +in some format. The assumptions which may apply to an attestation have to do with the quality of the attestation and the quality and security provided by the TEE, the device, the manufacturer, or others involved @@ -1156,99 +1157,20 @@ Some of the assumptions that might apply to an attestations include (this may no - Assumptions regarding the revocation and recovery process of TEE attestation keys. -TAMs and SPs must be comfortable with the assumptions that are inherently part of any attestation -they accept. Alternatively, any TAM or SP may choose not to accept an attestation generated from +TAMs must be comfortable with the assumptions that are inherently part of any attestation result +they accept. Alternatively, any TAM may choose not to accept an attestation result generated using evidence from a particular manufacturer or device's TEE based on the inherent assumptions. The choice and policy -decisions are left up to the particular TAM/SP. +decisions are left up to the particular TAM. -Some TAMs or SPs may require additional claims in order to properly authorize a device or TEE. These -additional claims may help clear up any assumptions for which the TAM/SP wants to alleviate. The specific +Some TAMs may require additional claims in order to properly authorize a device or TEE. These +additional claims may help clear up any assumptions for which the TAM wants to alleviate. The specific format for these additional claims are outside the scope of this specification, but the TEEP protocol -SHALL allow these additional claims to be included in the attestation messages. - -The following sub-sections define the cryptographic properties conveyed by the TEEP attestation, -the basic set of TEEP claims required in a TEEP attestation, the TEEP attestation flow between the -TAM the device TEE, and some implementation examples of how an attestation key may be realized in -a real TEEP device. - -## Attestation Cryptographic Properties -The attestation constructed by TEEP must convey certain cryptographic properties from the attester to -the verifier; in the case of TEEP, the attestation must convey properties from the device to the TAM -and/or SP. The properties required by TEEP include: - - - Non-repudiation, Unique Proof of Source - the cryptographic digital signature across the attestation, - and optionally along with information in the attestation itself SHALL uniquely identify a specific TEE - in a specific device. - - - Integrity of claims - the cryptographic digital signature across the attestation SHALL cover the entire - attestation including all meta data and all the claims in the attestation, ensuring that the attestation - has not be modified since the TEE signed the attestation. - -Standard public key algorithms such as RSA and ECDSA digital signatures convey these properties. Group public key -algorithms such as EPID can also convey these properties, if the attestation includes a unique device identifier -and an identifier for the TEE. Other cryptographic operations used in other attestation schemes may also convey -these properties. - -The TEEP standard attestation format SHALL use one of the following digital signature formats: +allows these additional claims to be included in the attestation messages. - - RSA-2048 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS format - - - RSA-3072 with SHA-256 or SHA-384 in RSASSA-PKCS1-v1_5 or PSS format - - - ECDSA-256 using NIST P256 curve using SHA-256 - - - ECDSA-384 using NIST P384 curve using SHA-384 - - - HashEdDSA using Ed25519 with SHA-512 (Ed25519ph in RFC8032) and context="TEEP Attestation" - - - EdDSA using Ed448 with SHAK256 (Ed448ph in RFC8032) and context="TEEP Attestation" - -All TAMs and SPs MUST be able to accept attestations using these algorithms, contingent on their acceptance of -the assumptions implied by the attestations. - -## TEEP Attestation Structure -For a TEEP attestation to be useful, it must contain an information set allowing the TAM and/or SP to assess -the attestation and make a related security policy decision. The structure of the TEEP attestation is shown -in the diagram below. - -~~~~ - +------(Signed By)-----------+ - | | - /--------------------------\ V -+---------------+-------------+--------------------------+ -| Attestation | The | The | -| Header | Claims | Attestation Signature(s) | -+---------------+-------------+--------------------------+ - | - | - +----------+--(Contains)-----+-------------+-------------+ - | | | | | - V V V V V -+------------+ +-------------+ +----------+ +-----------+ +------------+ -| Device | | TEE | | | | Action or | | Additional | -| Identifying| | Identifying | | Liveness | | Operation | | or | -| Info | | Info | | Proof | | Specific | | Optional | -| | | | | | | Claims | | Claims | -+------------+ +-------------+ +----------+ +-----------+ +------------+ -~~~~ -{: #attestationstructure title="Structure of TEEP Attestation"} - -The Attestation Header SHALL identify the "Attestation Type" and the "Attestation Signature Type" along -with an "Attestation Format Version Number." The "Attestation Type" identifies the minimal set of claims -that MUST be included in the attestation; this is an identifier for a profile that defines the claims -that should be included in the attestation as part of the "Action or Operation Specific Claims." -The "Attestation Signature Type" identifies the type of attestation signature that is attached. -The type of attestation signature SHALL be one of the standard signatures types identified by an IANA -number, a proprietary signature type identified by an IANA number, or the generic "Proprietary Signature" -with an accompanying proprietary identifier. Not all TAMs may be able to process proprietary signatures. - -The claims in the attestation are set of mandatory and optional claims. The claims themselves SHALL be -defined in an attestation claims dictionary. See the next section on TEEP Attestation Claims. -Claims are grouped in profiles under an identifier (Attestation Type), however all attestations require -a minimal set of claims which includes: +## Information Required in TEEP Claims - Device Identifying Info: TEEP attestations must uniquely identify a device to the TAM and SP. This - identifier allows the TAM/SP to provide services unique to the device, such as managing installed + identifier allows the TAM to provide services unique to the device, such as managing installed TAs, and providing subscriptions to services, and locating device-specific keying material to communicate with or authenticate the device. Additionally, device manufacturer information must be provided to provide better universal uniqueness qualities without requiring globally unique @@ -1257,97 +1179,15 @@ a minimal set of claims which includes: - TEE Identifying info: The type of TEE that generated this attestation must be identified. Standard TEE types are identified by an IANA number, but also must include version identification information such as the hardware, firmware, and software version of the TEE, as applicable by the - TEE type. Structure to the version number is required. TEE manufacturer information for the TEE is + TEE type. TEE manufacturer information for the TEE is required in order to disambiguate the same TEE type created by different manufacturers and resolve potential assumptions around manufacturer provisioning, keying and support for the TEE. - - Liveness Proof: a claim that includes liveness information SHALL be included which may be a large nonce - or may be a timestamp and short nonce. - - - Action Specific Claims: Certain attestation types shall include specific claims. For example an attestation - from a specific TA shall include a measurement, version and signing public key for the TA. - - - Additional Claims: (Optional - May be empty set) A TAM or SP may require specific additional claims in order - to address potential assumptions, such as the requirement that a device's REE performed a secure boot, - or that the device is not currently in a debug or non-productions state. A TAM may require a device to - provide a device health attestation that may include some claims or measurements about the REE. - These claims are TAM specific. - -## TEEP Attestation Claims -TEEP requires a set of attestation claims that provide sufficient evidence to the TAM and/or SP that the device -and its TEE meet certain minimal requirements. Because attestation formats are not yet broadly standardized across -the industry, standardization work is currently ongoing, and it is expected that extensions to the attestation -claims will be required as new TEEs and devices are created, the set of attestation claims required by TEEP SHALL -be defined in an IANA registry. That registry SHALL be defined in the TEEP protocol with sufficient elements -to address basic TEEP claims, expected new standard claims (for example from {{I-D.mandyam-eat}}), -and proprietary claim sets. - -## TEEP Attestation Flow -Attestations are required in TEEP under the following flows: - - - When a TEE responds with device state information (dsi) to the TAM or SP, including a "GetDeviceState" - response, "InstallTA" response, etc. - - - When a new key pair is generated for a TA-to-TAM or TA-to-SP communication, the keypair must be covered by - an attestation. - -## Attestation Key Example - -The attestation hierarchy and seed required for TAM protocol -operation must be built into the device at manufacture. Additional -TEEs can be added post-manufacture using the scheme proposed, but it -is outside of the current scope of this document to detail that. - -It should be noted that the attestation scheme described is based on -signatures. The only decryption that may take place is through the -use of a bootloader key. - -A boot module generated attestation can be optional where the -starting point of device attestation can be at TEE certificates. A TAM -can define its policies on what kinds of TEE it trusts if TFW -attestation is not included during the TEE attestation. - -### Attestation Hierarchy Establishment: Manufacture - -During manufacture the following steps are required: - -1. A device-specific TFW key pair and certificate are burnt into the - device. This key pair will be used for - signing operations performed by the boot module. - -2. TEE images are loaded and include a TEE instance-specific key - pair and certificate. The key pair and certificate are included - in the image and covered by the code signing hash. - -3. The process for TEE images is repeated for any subordinate TEEs, - which are additional TEEs after the root TEE that some devices - have. - -### Attestation Hierarchy Establishment: Device Boot - -During device boot the following steps are required: - -1. The boot module releases the TFW private key by decrypting it with - the bootloader key. - -2. The boot module verifies the code-signing signature of the active TEE and - places its TEE public key into a signing buffer, along with its - identifier for later access. For a TEE non-compliant to this - architecture, the boot module leaves the TEE public key field blank. - -3. The boot module signs the signing buffer with the TFW private key. - -4. Each active TEE performs the same operation as the boot module, building - up their own signed buffer containing subordinate TEE - information. - -### Attestation Hierarchy Establishment: TAM + - Liveness Proof: A claim that includes liveness information must be included, such as a nonce + or timestamp. -Before a TAM can begin operation in the marketplace, -it must obtain a TAM certificate from a CA -that is registered in the trust store of devices. In -this way, the TEE can check the intermediate and root CA and verify -that it trusts this TAM to perform operations on the TEE. + - Requested Components: A list of zero or more components (TAs or other dependencies needed by a TEE) + that are requested by some depending app, but which are not currently installed in the TEE. # Algorithm and Attestation Agility