Skip to content

Commit

Permalink
Proposed changes to depend on RATS for attestation
Browse files Browse the repository at this point in the history 
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 <dthaler@microsoft.com>
  • Loading branch information
@dthaler
dthaler committed Nov 26, 2019
1 parent 037c84a commit 0170186
Showing 1 changed file with 46 additions and 206 deletions.
252 changes: 46 additions & 206 deletions draft-ietf-teep-architecture.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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:
Expand Down Expand Up @@ -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.
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand All @@ -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

Expand Down

0 comments on commit 0170186

Please sign in to comment.