blob: 12f4fe2d16a3bb09ef9ef3a86a03da77f1f1fd99 [file] [log] [blame]
Jamie Foxd0adc742023-03-28 17:05:28 +01001###########################
2DICE Protection Environment
3###########################
4
5The DICE Protection Environment (DPE) service makes it possible to execute DICE
6commands within an isolated execution environment. It provides clients with an
7interface to send DICE commands, encoded as CBOR objects, that act on opaque
8context handles. The DPE service performs DICE derivations and certification on
9its internal contexts, without exposing the DICE secrets (private keys and CDIs)
10outside of the isolated execution environment.
11
12For a full description of DPE, see the
13`DPE Specification <https://trustedcomputinggroup.org/wp-content/uploads/TCG-DICE-Protection-Environment-Specification_14february2023-1.pdf>`_.
14
15DPE consists of both a runtime service and boot time integration. The DPE
16service is currently a work in progress.
17
18*********
19Boot time
20*********
21
22A platform integrating DPE must perform the following boot-time functions:
23
24- Derive a RoT CDI from the UDS (HUK) provisioned in OTP, lifecycle state and
25 measurement of the first firmware stage after ROM (BL1_2), and store it via a
26 platform-specific mechanism to be retrieved at runtime.
27
28- Store boot measurements and metadata for all images loaded by the bootloaders
29 in the TF-M shared boot data area.
30
31*******************
32Runtime DPE service
33*******************
34
35The runtime DPE service provides the following functionality.
36
37Initialization
38==============
39
40At initialization, DPE completes the following tasks:
41
42- Retrieves and processes offline measurements and metadata from the TF-M shared
43 boot data area.
44
45- Retrieves the RoT CDI generated at boot time by calling the
46 ``dpe_plat_get_rot_cdi()`` platform function.
47
48- Derives DICE contexts for the RoT layer and platform layer, using the values
49 processed from boot data and the RoT CDI.
50
51- Shares the initial context handle, corresponding to the newly-created child
52 context, with the first client (AP BL1), via a platform-specific mechanism.
53
54Context management
55==================
56
57The internal DICE contexts are referred to by clients of the DPE service using
58opaque context handles. Each DPE command generates a new context handle that is
59returned to the client to refer to the new internal state. Each context handle
60can only be used once, so clients must use the "retain context" parameter of the
61DPE commands if they wish to obtain a fresh handle to the same context.
62
63The context handles are 32-bit integers, where the lower 16-bits is the index of
64the context within the service and the upper 16-bits is a random nonce.
65
66The internal contexts are associated with the 32-bit ID of the owner of the
67context. The DPE service only permits the owner to access the context through
68its context handle. In the TF-M integration, the ID is bound to the PSA Client
69ID of the sender of the DPE message.
70
71Client APIs
72===========
73
74The DPE partition in TF-M wraps the DPE commands into PSA messages. The request
75manager abstracts PSA message handling, and the remainder of the service avoids
76coupling to TF-M partition specifics.
77
78The DPE commands themselves are CBOR-encoded objects that the DPE decode layer
79decodes into calls to one of the following supported DICE functions.
80
81DeriveChild
82-----------
83
84Adds a component context to the layer, consisting of:
85
86- Context handle
87- Parent context handle
88- Linked layer
89- Is leaf
90- Client ID
91- DICE input values
92
93 - Code hash
94 - Config value
95 - Authority hash
96 - Operating mode
97
98When a layer is finalized (create_certificate=true), it:
99
100- Computes the Attestation CDI and Sealing CDI.
101
102- Derives an attestation keypair from the Attestation CDI.
103
104- Creates the corresponding certificate and signs it with the previous layer's
105 attestation private key.
106
107- Stores the finalized certificate in DPE partition SRAM.
108
109Certificates are created in the CBOR Web Token (CWT) format, using the QCBOR
110and t_cose libraries. CWT is specified in
111`RFC 8392 <https://www.rfc-editor.org/rfc/rfc8392.html>`_,
112with customization from
113`Open DICE <https://pigweed.googlesource.com/open-dice/+/refs/heads/main/docs/specification.md#CBOR-UDS-Certificates>`_.
114
115CertifyKey
116----------
117
118Generates a leaf certificate and returns the full certificate chain leading to
119it. If a public key is supplied, then it certifies the key.
120
121- Adds label (if supplied) to list of measurements.
122
123- Finalizes the layer (as for DeriveChild above).
124
125- Returns the certificate chain (collection of individual certificates) as a
126 CBOR array with format [+COSE_Sign1, COSE_Key]. The (pre-provisioned) root
127 attestation public key is the first element in the CBOR array.
128
129Seal
130----
131
132Encrypts and authenticates data using two keys derived from the Sealing CDI,
133identifiers of the software components in the chain and a supplied label.
134
135- Not currently implemented.
136
137Unseal
138------
139
140Inverse of Seal.
141
142- Not currently implemented.
143
144--------------
145
146*Copyright (c) 2023, Arm Limited. All rights reserved.*