S
P
E
C
I
F
I
C
A
T
I
O
N

DICE Protection Environment
Version 1.0
Revision 0.6
February 14, 2023
Contact: admin@trustedcomputinggroup.org

Work in ProgressThis document is an intermediate draft forcomment only and is subject to change
without notice. Readers should notdesign products based on this document.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW© TCG 2023

DICE Protection Environment

DISCLAIMERS, NOTICES, AND LICENSE TERMS
THIS SPECIFICATION IS PROVIDED “AS IS” WITH NO WARRANTIES WHATSOEVER, INCLUDING ANYWARRANTY OF MERCHANTABILITY, NONINFRINGEMENT, FITNESS FOR ANY PARTICULAR PURPOSE, OR
ANY WARRANTY OTHERWISE ARISING OUT OF ANY PROPOSAL, SPECIFICATION OR SAMPLE.
Without limitation, TCG disclaims all liability, including liability for infringement of any proprietary rights, relating to useof information in this specification and to the implementation of this specification, and TCG disclaims all liability forcost of procurement of substitute goods or services, lost profits, loss of use, loss of data or any incidental,
consequential, direct, indirect, or special damages, whether under contract, tort, warranty or otherwise, arising in any
way out of use or reliance upon this specification or any information herein.
This document is copyrighted by Trusted Computing Group (TCG), and no license, express or implied, is granted
herein other than as follows: You may not copy or reproduce the document or distribute it to others without written
permission from TCG, except that you may freely do so for the purposes of (a) examining or implementing TCG
specifications or (b) developing, testing, or promoting information technology standards and best practices, so longas you distribute the document with these disclaimers, notices, and license terms.
Contact the Trusted Computing Group at www.trustedcomputinggroup.org for information on specification licensing
through membership agreements.
Any marks and brands contained herein are the property of their respective owners.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 1© TCG 2023

DICE Protection Environment

CHANGE HISTORYREVISIONDATE

DESCRIPTION

1.00/0.1

December 15, 2021

Initial draft

1.00/0.2

June 23, 2022

Final draft – Technical content complete

1.00/0.3/0.4

September 22, 2022

Add session migration, changes in response to comments/feedback

1.00/0.5

January 9, 2023

Multipart cmd/rsp, cleanup based on WG discussions

1.00/0.6

January 26, 2023

Changes in response to TC feedback

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 2© TCG 2023

DICE Protection Environment

CONTENTSDISCLAIMERS, NOTICES, AND LICENSE TERMS ..................................................................................................... 1
CHANGE HISTORY ....................................................................................................................................................... 2
CONTENTS .................................................................................................................................................................... 3
1

SCOPE ................................................................................................................................................................... 5
1.1 Key Words....................................................................................................................................................... 5
1.2 Statement Type............................................................................................................................................... 5

2

REFERENCES ....................................................................................................................................................... 6

3

TERMS AND DEFINITIONS................................................................................................................................... 8
3.1 Acronyms ........................................................................................................................................................ 8
3.2 Nomenclature .................................................................................................................................................. 8

4

INTRODUCTION .................................................................................................................................................... 95

CONCEPTS .......................................................................................................................................................... 11
5.1 DPE and DICE Layering ............................................................................................................................... 11
5.1.1 Example Flow ...................................................................................................................................... 11
5.2 Use Cases..................................................................................................................................................... 12
5.3 Clients ........................................................................................................................................................... 12
5.4 Configuration and Profiles ............................................................................................................................ 12
5.5 Version Compatibility .................................................................................................................................... 12
5.6 Contexts ........................................................................................................................................................ 13
5.6.1 Default Contexts .................................................................................................................................. 13
5.6.2 Simulation Contexts............................................................................................................................. 14
5.6.3 Context Initialization ............................................................................................................................ 14
5.7 Sessions........................................................................................................................................................ 14
5.7.1 Encrypted Sessions ............................................................................................................................. 15
5.7.2 Session Migration ................................................................................................................................ 16
5.8 Interface ........................................................................................................................................................ 20
5.9 Messages ...................................................................................................................................................... 20
5.9.1 Transport ............................................................................................................................................. 20
5.9.2 Encoding .............................................................................................................................................. 20
5.9.3 Session Message Format.................................................................................................................... 21
5.9.4 Command and Response Headers ..................................................................................................... 21
5.9.5 Multi Part Operations ........................................................................................................................... 23
5.9.6 Reserved Command ID Values ........................................................................................................... 24

6

COMMANDS......................................................................................................................................................... 25
6.1 GetProfile ...................................................................................................................................................... 25

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 3© TCG 2023

DICE Protection Environment

6.2 OpenSession................................................................................................................................................. 25
6.3 CloseSession ................................................................................................................................................ 26
6.4 SyncSession ................................................................................................................................................. 26
6.5 ExportSession ............................................................................................................................................... 27
6.6 ImportSession ............................................................................................................................................... 28
6.7 InitializeContext ............................................................................................................................................. 29
6.8 DeriveChild.................................................................................................................................................... 30
6.9 CertifyKey...................................................................................................................................................... 32
6.10 Sign ............................................................................................................................................................ 33
6.11 Seal ............................................................................................................................................................ 34
6.12 Unseal ........................................................................................................................................................ 35
6.13 DeriveSealingPublicKey ............................................................................................................................ 36
6.14 RotateContextHandle ................................................................................................................................ 37
6.15 DestroyContext .......................................................................................................................................... 38
7

PROFILES ............................................................................................................................................................ 39
7.1 Namespaces ................................................................................................................................................. 39
7.2 Profile Attributes............................................................................................................................................ 39
7.3 Sample Profile ............................................................................................................................................... 55
7.4 Profile Descriptors......................................................................................................................................... 62

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 4© TCG 2023

DICE Protection Environment

1 SCOPE
This specification defines requirements for a DICE Protection Environment (DPE).

1.1 Key Words
The key words “MUST,” “MUST NOT,” “REQUIRED,” “SHALL,” “SHALL NOT,” “SHOULD,” “SHOULD NOT,”“RECOMMENDED,” “MAY,” and “OPTIONAL” in this document normative statements are to be interpreted as
described in RFC-2119, Key words for use in RFCs to Indicate Requirement Levels.

1.2 Statement Type
Please note a very important distinction between different sections of text throughout this document. There are two
distinctive kinds of text: informative comment and normative statements. Because most of the text in this specification
will be of the kind normative statements, the authors have informally defined it as the default and, as such, havespecifically called out text of the kind informative comment. They have done this by flagging the beginning and end ofeach informative comment and highlighting its text in gray. This means that unless text is specifically marked as of
the kind informative comment, it can be considered a kind of normative statement.
EXAMPLE:
Start of informative comment
This is the first paragraph of 1–n paragraphs containing text of the kind informative comment ...
This is the second paragraph of text of the kind informative comment ...
This is the nth paragraph of text of the kind informative comment ...
To understand the TCG specification the user must read the specification. (This use of MUST does not require any
action).
End of informative comment

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 5© TCG 2023

DICE Protection Environment

2 REFERENCES[1] Trusted Computing Group, "Hardware Requirements for Device Identifier Composition Engine Level 00,
Revision 78," 22 March 2018. [Online]. Available: https://trustedcomputinggroup.org/wpcontent/uploads/Hardware-Requirements-for-Device-Identifier-Composition-Engine-r78_For-Publication.pdf.
[2] Trusted Computing Group, "DICE Layering Architecture Version 1.0 Revision 0.19," 23 July 2020. [Online].
Available: https://trustedcomputinggroup.org/resource/dice-layering-architecture/.
[3] Trusted Computing Group, "DICE Attestation Architecture Version 1.00 revision 0.23," 1 March 2021. [Online].
Available: https://trustedcomputinggroup.org/resource/dice-attestation-architecture/.
[4] Trusted Computing Group, "DICE Certificate Profiles Version 1.0 Revision 0.01," 23 July 2020. [Online].
Available: https://trustedcomputinggroup.org/resource/dice-certificate-profiles/.
[5] Trusted Computing Group, "TCG Glossary Version 1.1 Revision 1.0," 11 May 2017. [Online]. Available:
https://trustedcomputinggroup.org/resource/tcg-glossary/.
[6] National Institute of Standards and Technology, "SP 800-133 Recommendation for Cryptographic Key
Generation," 2020. [Online]. Available: https://csrc.nist.gov.
[7] National Institute of Standards and Technology, "SP 800-57 Part 1 Rev. 5 Recommendation for Key
Management: Part 1 – General," May 2020. [Online]. Available: https://csrc.nist.gov/publications/detail/sp/80057-part-1/rev-5/final.
[8] T. Perrin, "The Noise Protocol Framework," July 2018. [Online]. Available: https://noiseprotocol.org/noise.html.
[9] Internet Engineering Task Force, "Hybrid Public Key Encryption," February 2022. [Online]. Available:
https://datatracker.ietf.org/doc/rfc9180/.
[10] Internet Engineering Task Force, "Concise Binary Object Representation (CBOR)," December 2020. [Online].
Available: https://datatracker.ietf.org/doc/html/rfc8949.
[11] Internet Engineering Task Force, "Concise Data Definition Language (CDDL) A Notational Convention to
Express Concise Binary Object Representation (CBOR) and JSON Data Structures," June 2019. [Online].
Available: https://datatracker.ietf.org/doc/html/rfc8610.
[12] Internet Engineering Task Force, "Internet X.509 Public Key Infrastructure Certificate and Certificate
Revocation List (CRL) Profile," May 2008. [Online]. Available: https://datatracker.ietf.org/doc/html/rfc5280.
[13] Internet Engineering Task Force, "CBOR Object Signing and Encryption (COSE)," July 2017. [Online].
Available: https://datatracker.ietf.org/doc/rfc8152/.
[14] Internet Assigned Numbers Authority, "Named Information Hash Algorithm Registry," September 2016.
[Online]. Available: https://www.iana.org/assignments/named-information/named-information.txt.
[15] National Institute of Standards and Technology, "SP 800-160 Systems Security Engineering: Considerations
for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems," 2020. [Online]. Available:
https://csrc.nist.gov.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 6© TCG 2023

DICE Protection Environment

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 7© TCG 2023

DICE Protection Environment

3 TERMS AND DEFINITIONS
For the purposes of this specification, the following terms and definitions apply. This specification assumes thereader is familiar with the TCG DICE specifications [1] [2] [3] [4] and common Trusted Computing terminology, as
defined in [5].

3.1 Acronyms
ABBREVIATIONS
CDI
DICE

DESCRIPTION
Compound Device Identifier
Device Identifier Composition Engine [1]DPE

DICE Protection Environment

ECA

Embedded Certificate Authority

HKDF

HMAC-based Key Derivation Function

IPIntellectual Property, e.g., IP Block

IPC

Interprocess Communication

MCU

Microcontroller Unit

RPC

Remote Procedure Call

SPI

Serial Peripheral Interface

SVN

Security (-relevant) Version Number

TCB

Trusted Computing Base, see also [5]TCG

Trusted Computing Group

3.2 NomenclatureThis specification uses the terms child and parent to describe the relationship between two DICE components orlayers. A parent component invokes or spawns a child component. In some cases, a parent component can havemultiple child components, and a child may itself be a parent and spawn additional child components. In graph theory
terms, a DICE layered architecture can be viewed as an arborescence.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 8© TCG 2023

DICE Protection Environment

4 INTRODUCTION
Start of informative comment
This document specifies the command interface, behavior, and profile requirements of a DICE Protection
Environment (DPE). A DICE Protection Environment (DPE) protects DICE-related secrets and helps enforce DICErelated policies. In a layered DICE architecture (see [2]) a component (or layer) employs DICE without a DPE bydirectly handling and processing Compound Device Identifier (CDI) values. CDI values are very sensitive and are
as long-lived as the layers they represent. With a DPE, instead of handling DICE secrets directly, a component
employs DICE by issuing commands to the DPE. The DPE retains possession of secret values (e.g., CDIs andprivate keys) and does not expose sensitive data to any component or client. Instead, the DPE provides each clientwith a context handle that a client uses to refer to the data corresponding to the DICE operations initiated by thatclient.
Context handles are opaque to clients. The value of a context handle may be a simple index to a structure
containing CDI values and other data stored by the DPE, or it may be the actual CDI values and other data that are
encrypted so it can only be decrypted by the DPE. A context handle is less sensitive than a CDI itself because it isephemeral and useful only under limited conditions. A context handle corresponds to only one set of CDI values
for a specific component or layer and, when a context handle is destroyed, the associated CDI values are also
destroyed. Communication between a client and a DPE occurs in a session that might be encrypted. Context
handles are one-time-use and bound to a single session. Commands that consume a context handle permanently
invalidate that handle and generate a new handle for the subsequent command, if appropriate.
Use of a DPE may reduce the following risks:••••

CDI exfiltration by exploiting hardware, firmware, or software vulnerabilities or side channels
CDI leakage during the handoff from one component to another
CDI leakage due to normal system memory management such as swap or hibernation
implementation-specific issues, including cryptographic algorithm implementations, across heterogeneouscomponents or layers

A DICE-based system may also be able to improve performance by offloading DICE computations to a DPE. A
DPE implementation may perform computations asynchronously or otherwise employ caching techniques, provided
the DPE complies with this specification. For example, a DICE-based system may have booted multiple layers
before DICE computations have completed for the first layer within the DPE.
DICE layering semantics and CDI derivations are the same, or can be the same, whether a DPE is used or not.
Using a DPE does allow for additional DICE features but a direct translation of any existing DICE-based system toan equivalent system that uses a DPE should be possible. In addition to protecting DICE CDIs, a DPE also protects
keys derived from CDIs like private signing keys and sealing keys, as these are part of a client’s DPE context.
However, using a DPE does not fully compensate for potential vulnerabilities in device firmware.
A DPE is not stateless. It tracks all valid context handles, sessions, and the mappings between them. The numberof contexts supported by a DPE is implementation specific. In its simplest form, a DPE supports one context andone plaintext session.
This specification does not define or limit how a DPE can be implemented. Examples of environments that could
be used for a DPE implementation are a secure coprocessor, discrete secure hardware, a Trusted Execution
Environment (TEE), a type-1 hypervisor, operating system kernel, or another type of environment isolated with ahardware-backed mode switch. A DICE-based system could also transition to using a DPE at a particularcomponent or layer.
Because of this flexibility of implementation, no specific hardware requirements are defined in this specification.
Some level of hardware-backed protection is required to isolate the DPE environment and make it useful, but thenature or strength of that isolation is not defined or constrained here. For example, the hardware-backed protection
may be a Memory Management Unit (MMU) for an OS kernel, or a separate IP block or Microcontroller Unit (MCU).

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 9© TCG 2023

DICE Protection Environment

Notably a DPE can be implemented without any persistent storage, true random number generator (TRNG), or areal time clock. However, a DPE implementation may well have such capabilities.
End of informative comment

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 10© TCG 2023

DICE Protection Environment

5 CONCEPTS
This section provides details on the core concepts of a DICE Protection Environment.

5.1 DPE and DICE Layering
Figure 1 illustrates the difference between a simple layered DICE flow with and without help from a DPE. The diagram
is simplified to illustrate the main goal of the DPE: to protect CDI values. The construction of Layer 0 from a UDS,
destruction of CDI values, layer certificates, and other aspects of layered DICE architecture are not shown. Destroyed
CDIs are illustrated with a surrounding dotted line.

Without DPE
Layer 0With DPE
Layer 0

CDI_0

DPE
Handle to CDI_0

CDI_0

DeriveChild

Layer 1

Layer 1

CDI_1

Handle to CDI_1

CDI_1

DeriveChild

Layer 2

Layer 2

CDI_2

Handle to CDI_2

CDI_2

Figure 1: DICE layering with and without a DPE

5.1.1 Example Flow
The following simplified pseudocode flow illustrates a system with two firmware layers using a DPE to perform basic
attestation. Session handshake and encryption details are omitted.
// ROM codesession = dpe.OpenSession()context = dpe.InitializeContext(uds)context = dpe.DeriveChild(context, firmware1_hash)
Run(firmware1, session, context)// Firmware1 code
context = dpe.DeriveChild(context, firmware2_hash, allow-child-to-derive=false)Run(firmware2, session, context)// Firmware2 code

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 11© TCG 2023

DICE Protection Environment

context, cert_chain = dpe.CertifyKey(context)
signature = dpe.Sign(context, attestation_challenge)
attestation_response = cert_chain, signature

5.2 Use Cases
A DPE MUST support at least one of the following use cases:••

Attestation – See [3] [5]Sealing – See [5]5.3 Clients
Clients of a DPE can be in any system that uses a layered DICE architecture for attestation or sealing (see [2]). A
client owns a DPE session endpoint and owns DICE-related information that it delegates to the DPE for safekeeping.
The scope of a client is bounded by access to the DPE session endpoint and context handle. A client wields a session
endpoint and context handle to interact with the DPE. In most cases, a client corresponds directly to a DICE Trusted
Computing Base (TCB) layer or component: see the DICE Layering Architecture specification [2]. However, thisspecification does not define or constrain the nature of a client, how a client manages session endpoints and context
handles, or the communication path between it and a DPE. Calling a DPE may involve an IPC/RPC mechanism, a
SPI interface, or even just a simple function call.
If a DPE uses encrypted sessions, the client that opens the session is responsible for authenticating the DPE. This
may require the initial client to store static identity data (e.g., a public key) for the DPE in such a way that it is available
for authenticating the new session.
Start of informative comment
An initial client (usually the platform RTM) may be responsible for authenticating a DPE before subsequent
components or layers are allowed to execute. For example, this authentication may be performed using a preprovisioned public key corresponding to the DPE identity. Authentication of the DPE only needs to be done once
per session (see OpenSession in section 6.2).
End of informative comment

5.4 Configuration and Profiles
This specification is flexible in order to accommodate a variety of possible implementations. In contrast, a DPE
implementation does not need to be flexible and is expected to have a fixed configuration and fixed capabilities. It is
expected that capabilities and configuration of a DPE will be determined during system design and/or integration
phases, not at runtime. However, a DPE implementation may offer configurability outside the scope of thisspecification, for example, with vendor-specific commands.
To promote compatibility and interoperability, DPE implementations MUST conform to a profile. System integratorsneed to ensure that a DPE and its clients use the same profile. A DPE profile is complete, that is, it specifies all
attributes that this specification leaves up to implementors. This specification lists all attributes that a DPE profile isrequired to specify; see section 7.2.

5.5 Version Compatibility
The versions of this specification are mutually compatible across minor versions from the view of a client. Changes
that introduce incompatibility from the view of the client will be accompanied by a new major version. Minor version
changes introduce requirements on DPE implementations only if the contract with the client is unaffected. In otherwords, there should be no reason for a client to differentiate between different minor versions if the major version is
the same.
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 12© TCG 2023

DICE Protection Environment

5.6 Contexts
A DPE context comprises all the DICE-related information for a particular layer or component, i.e., client. A DPE
context contains, at least, a CDI value, but in practice there is usually additional information. A DPE uses a context
handle to refer to (or to contain) DPE context for a given client. Context handles are opaque to DPE clients. Context
handle values may be a handle, an index into context data held internally by the DPE, or the context handle value
may itself contain the client’s context data encrypted in a way that only the DPE can decrypt it. While a DPE
implementation has flexibility in how it constructs context data and handles, it has the following constraints:
1) The context handle MUST be unguessable in practice. If the context handle value is an index to a client’s DPE
context data, it SHOULD be random and at least 16 bytes in length. The reason for this is that a context handle
authorizes operations on the associated context. So, for example, it’s possible for parent and child components
to share the same encrypted session, but the child should not be able to leverage that shared session toimpersonate the parent.
2) If the context handle value is encrypted data, it MUST use an algorithm with at least 128 bits of security strengthand it MUST be integrity protected. Security strength is used here as defined in NIST SP800-133 [6] and NIST
SP800-57 [7].
3) The context handle MUST comply with size limits imposed by the profile, if any.
4) The context handle MUST be bound to a specific session.
5) The context handle MUST NOT remain valid after it has been used by a command. In other words, context
handles are single use. New context handles are returned by a DPE within a response to a client so it can beused on a subsequent command. Once a context handle is provided to the DPE by a client, the context handle
is invalidated by the DPE.
Multiple contexts can be bound to the same session by invoking InitializeContext multiple times or by invoking the
DeriveChild command with retain-parent-context set to true and the new-session-initiator-handshakeargument omitted.

5.6.1 Default Contexts
DPE client sessions may not require or benefit from multiple distinct DPE contexts. In these scenarios, the default
context may be used. The only distinguishing characteristic of a default context is that there is no client-visible context
handle associated with the default context. A default context is stored internally to the DPE and is indicated in acommand by omitting the context handle argument. The primary benefit of using the default context is that a client is
not required to keep track of or provide context handles.
A DPE SHOULD support default context(s) and may support only default context(s). If a DPE supports default
contexts, it MUST support one default context per session. A DPE MUST NOT allow simultaneous use of a default
context and context handles within the same session: these are mutually exclusive.
A default context can be destroyed like any other context. If a client wishes to transition from a single context session
to a multiple context session, the client can use the RotateContextHandle command to transition the default context
to a context handle. A DPE MUST reject any command that attempts to use a default context after it has been
destroyed (by calling DestroyContext) or rotated (by calling RotateContextHandle) until the default context is explicitly
initialized again by the client.
A default context can be initialized by setting the use-default-context argument to true for the InitializeContext
command. A DPE can support an automatic initialization procedure for default contexts. No initialize command isrequired for an automatic initialization procedure and clients can proceed directly to other commands that require an
initialized context.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 13© TCG 2023

DICE Protection Environment

5.6.2 Simulation Contexts
A DPE may support simulation contexts. A simulation context is used the same way as a normal context but the DPE
disallows operations that use private keys: this includes commands like CertifyKey or Unseal. Using a simulation
context allows a client to derive public keys and certificates associated with different inputs than were used to bootthe currently running system.
Start of informative comment
The primary use case for a simulation context is referred to as predictive sealing. For example, if a client layer
anticipates an update or expects to make a change that would result in a new CDI value for a subsequent
component, that client can use a simulation context to seal data to the expected future measurement (i.e., thepredicted measurement) of the subsequent component. This works because a DPE will allow sealing and publickey derivation but will not allow unsealing for a simulation context.
End of informative comment

5.6.3 Context Initialization
A DPE profile specifies how the initial state of a context is derived. This derivation process is the same whether it isexecuted as part of an InitializeContext command or automatically when a DPE starts. At the end of theinitialization process, the new context contains a UDS or CDI(s). The InitializeContext command has a seedargument that allows the client to provide an input to the derivation.
The following list comprises examples of how a DPE profile might be initialized:••••

The DPE might use the seed argument directly as a UDS or CDI value.
The DPE might use a UDS it has access to internally, ignoring or mixing in the seed argument.
The DPE might use its own internal CDI and certificate chain as the initial state, ignoring or mixing in the seedargument.
The DPE might expect the seed to be a structured type providing multiple CDI values and certificate data.

If a DPE profile specifies an initialization process that involves a DICE UDS, the DICE hardware requirements [1]SHALL apply.
A DPE that supports simulation contexts might retain the InitializeContext seed argument value in association withthe current session to enable the subsequent initialization of simulation contexts. A DPE MUST NOT use the seed
for any other purpose.
If a DPE profile specifies an initialization process that involves an internal UDS, CDI, or other seed, the DPE MUST
prevent access to the value(s) after initialization until the next system reset. A DPE MAY retain the value(s) in
association with the current session for initializing simulation contexts. In these cases, a DPE MUST NOT use theretained value(s) for any other purpose.

5.7 Sessions
A DPE client invokes commands within a session. A DPE keeps a record of all open sessions and each context
handle produced by a DPE is bound to a single session. The DPE maintains the bookkeeping for and enforces thisbinding. For example, if a context handle received by a client in one session is used in another session, the DPE
MUST reject the context handle as invalid. In other words, sessions are independent from each other.
The command/response messages within a particular session are ordered and serialized, e.g., command1,
response1, then command2, response2, and so on. Across different sessions, commands may be interleaved or
concurrent. If a command or response message is not delivered, the session can be brought back in sync with the
SyncSession command.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 14© TCG 2023

DICE Protection Environment

5.7.1 Encrypted Sessions
A session may be encrypted or plaintext. Encrypted sessions are designed for systems where communication
between a client and DPE passes outside of the client’s Trusted Computing Base (TCB). A DPE MUST support aplaintext session with a session ID of zero and can support any number of encrypted sessions. A DPE MUST NOT
support more than one plaintext session. If encrypted sessions are supported, a DPE MUST use an encrypted session
for all commands except OpenSession, and SyncSession. Encrypted sessions are created using the OpenSessioncommand, or as part of a DeriveChild command. A session can be closed using the CloseSession command anddoing so destroys all context data associated with the session.
If encrypted sessions are supported, the Noise_NK_25519_AESGCM_SHA256 protocol [8] SHOULD be supported.
Support for other protocols is allowed, but this specification is optimized for this type of protocol. The number ofencrypted sessions supported and the session protocol, including the format of the handshake and encrypted
messages, is specified by a DPE profile. When using a protocol that specifies a maximum number of messages persession, say due to key exhaustion concerns or counter maximums, etc., a DPE MUST fail all commands on an
exhausted session with a session-exhausted error code (see section 5.9.4).
Protocols used for DPE encrypted sessions MUST have the following security properties:
•
•
•
•
•

Confidentiality: payload data is encrypted
Integrity: payload data includes protection against tampering
Authenticated: clients can authenticate the DPE against a known public key
Key independence: forward and backward secrecy
Privacy: neither client nor DPE can be identified by observing handshake and/or transport messages

A DPE SHOULD NOT authenticate clients, but if a DPE does authenticate clients, the session protocol MUST havethe following additional properties:••

Consistency: two honest endpoints have a consistent view of the identity of each otherResistance to key compromise impersonation: compromise of a static secret does not enable forgedauthentication to the owner of that secret

A DPE that supports encrypted sessions has an identity in the form of a public key that can be authenticated by clients.
The provisioning, rotation, and storage of the identity is implementation-dependent and out of scope of thisspecification. For example, this may be a static identity that is provisioned in the factory and remains the same for a
DPE’s lifetime, or it may be randomly generated when a software DPE is instantiated and provisioned to clients via
an Operating System service. The DPE identity SHOULD be unique per DPE instance.
When using Noise_NK_25519_AESGCM_SHA256 or a similar protocol, the following requirements apply:
1) A DPE SHALL BE the responder for every negotiation and SHOULD NOT authenticate the initiator. In otherwords, the DPE accepts commands from any client and is agnostic of the nature and identity of the client.
2) The client that invokes OpenSession is responsible for authenticating the DPE’s identity.
Start of informative comment
Typically, the DPE identity (i.e., public key) is already known to the client by some other means.
End of informative comment3) A DPE SHALL maintain ordering of messages in a session and MUST support the SyncSession command to
get back in sync if necessary.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 15© TCG 2023

DICE Protection Environment4) New sessions created as part of a DeriveChild command use the current session’s binding token as a preshared key in the new session negotiation. Noise_NNpsk0_25519_AESGCM_SHA256 SHOULD be
supported.

5.7.2 Session Migration
Start of Informative Comment
Session Migration is an advanced feature that addresses specific use cases. Readers may skip this section if their
DPE profile does not support migration.
End of Informative Comment
If supported by a DPE profile, a session that has been declared as migratable can be migrated to another DPE. Thismay be useful in a datacenter environment when live-migrating a job from one physical server to another. A migration
flow involves: (1) preparing each context associated with the session with an operation similar to DeriveChild but
using migration-specific information including the identity of both DPEs involved, (2) sending all data associated withthe session to a new DPE encrypted, integrity protected, and authenticated, (3) closing the session on the exporting
DPE, and (4) importing the session into the receiving DPE, providing a new parent context. The ImportSession andExportSession commands are used to construct and process the migration flow messages. This flow is not intended
to achieve a seamless migration from a client’s perspective but rather to make migration possible.
The exporting DPE MUST include the following in migration information:••

The session keys and other state, e.g., counters, so the client’s session endpoint remains valid post-migration
For each context associated with the session:o The context handle, so the client’s context handle remains valid post-migrationo The migration-specific CDI(s) (as defined by the DPE profile)o The context certificate data, if any
o The context policy attributes, e.g., those related to sealing, if any

The exporting DPE MUST NOT include the following in migration information:•••

CDI(s) that are not migration-specificInformation about other active sessions, including other migratable sessions
Information internal to the DPE that is unrelated to the session being exported or unnecessary to perform thesession migration

To facilitate coordination with higher level migration infrastructure, an opaque pre-shared key (PSK) can be provided
to the migration commands. An exporting DPE MUST bind this PSK to the migration blob encryption in such a waythat an import can only succeed if the same PSK is used for both export and import. Figure 2 illustrates a migrationcommand sequence.
This sequence allows for a migration-specific encryption scheme specified in detail by a DPE profile.
Start of Informative Comment
For example, this may be a hybrid public key encryption scheme per RFC 9180 [9]. A DPE profile needs to specify
a scheme with the following security properties:•••

Confidentiality: exported data is encrypted
Integrity: payload data includes protection against tampering
Authenticated: the encryption is bound to a public key that identifies the importing DPE

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 16© TCG 2023

DICE Protection Environment

Note that the exporting DPE does not need to trust or know anything about the public key, it just needs to encryptso that only the corresponding private key can decrypt and include the public key in the CDI derivation and certificate
data if applicable.
End of Informative Comment

Exporting DPE

Importing DPE
importer-identity ← ImportSession(context)

exported-data ← ExportSession(session-id, importer-identity, psk)

ImportSession(context, exported-data, psk)

Exporting DPE

Importing DPE

Figure 2: Example session migration command sequence.

The session that invokes the ExportSession command is referred to as the migration session. The session being
exported by the ExportSession command is referred to as the exported session. The exporting DPE MUST ensurethat the migration session and exported session are different. After the ExportSession command, the exported
session moves into a quiescent state within the exporting DPE and becomes exclusively managed by the migration
session so that only the migration session can use its session ID. The exporting DPE MUST ensure the session IDof the exported session is unavailable for all commands except subsequent ExportSession or CloseSessioncommands initiated by the migration session. For example, multiple ExportSession commands may be useful whenrecovering from an import failure. The exporting DPE MUST close the exported session when it is explicitly closed
using CloseSession or when the associated migration session is closed.
The importing DPE associates the incoming session with an existing context as the new parent context. All contexts
associated with the incoming session become children of this parent context. The importing DPE MUST retain theexporter’s certificate data and represent it in the importer’s new certificate data for each incoming context, as definedby the DPE profile.
The importing DPE MUST ensure that after import each context holds a CDI that is derived using each of the following:•••

The original exported CDI
The importer identity
The importer parent CDI

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 17© TCG 2023

DICE Protection Environment

To do this, the exporting DPE derives a migration CDI using the exported session’s CDI value and the public key ofthe destination DPE. The importer derives a post-migration CDI from the migration CDI and the CDI of the context
that will act as parent to the imported session. In both cases the derivation scheme is defined by the DPE profile.
Figure 4 illustrates a simplified derivation chain across a migration.

Server1

Server2

UDS_Server1

UDS_Server2

CDI_System1

CDI_System2
Encrypted

CDI_Job1

CDI_Job1→2

CDI_Job2 + (1→2)

Figure 3: Simplified session migration derivation chain.

Start of Informative Comment
For example, if a derivation uses HKDF(ikm, info), computation of the CDIs could be as follows:• The original CDI: CDI_Job1 = HKDF(CDI_System1, <Job TCI>)• The migration CDI: CDI_Job1→2 = HKDF(CDI_Job1, <Server2 encryption public key>)• The post-migration CDI: CDI_Job2 + (1→2) = HKDF(CDI_System2, CDI_Job1→2)
End of Informative Comment
When migrating a session:
1) A DPE MUST NOT migrate a session that was not declared as migratable when it was opened, i.e., only migratablesessions can be migrated.
2) Both exporting and importing DPEs MUST use the same DPE profile.
3) To support migration, a DPE MUST store all valid CDIs internally: a DPE MUST NOT store a CDI in encrypted
form as part of a context handle.
4) After migration, the importing DPE MUST ensure that newly derived keys within an imported session are derived
from the new migration CDI and that keys available to the client before the migration are not available after
migration.
Start of informative comment

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 18© TCG 2023

DICE Protection Environment

This implies that a migration is not entirely transparent to a DPE client: for example, in the case of attestation,
signatures after migration will not match certificates generated before migration and certificates will need to berefreshed, and, in the case of sealing, post-migration unseal of data sealed before migration will fail - any sealed
data will need to be separately unsealed, migrated, and re-sealed after migration
End of informative comment5) A migration MUST be transparent to the client of the exported session in terms of session state and context
handles. While CDIs associated with the handles will have changed during migration, the context handles
themselves MUST NOT change across a migration.
6) When attestation is supported, the importing DPE MUST ensure that a migration event is represented in certificate
data for every migrated context. If multiple migrations occur, the importing DPE MUST ensure that each migrationis represented.
7) The exporting DPE MUST ensure that migration event data is part of a signed certificate before export, as opposed
to being cached for a future certificate. A DPE profile defines all certificate details for certificates generated aspart of a migration.
8) The certificate generated by the exporting DPE MUST include the importer’s identity (e.g., public key) to which
the exported data will be encrypted and MUST be a leaf certificate (not an Embedded Certificate Authority (ECA)
certificate).
Start of informative comment
The certificate representing the migration event needs to be a leaf certificate to ensure that the importercannot continue the exporter’s chain post-migration.
End of informative comment9) The exporting DPE MUST ensure that the private key associated with the leaf certificate is derivable from themigration CDI by the importing DPE.
10) The exporting DPE MUST NOT use the private key associated with the leaf certificate for any purpose.
11) The importing DPE MUST include the entire certificate chain from the exporter in the next certificate generated
for the context post-migration, along with a signature over any value that also appears in the certificate being
generated.
Start of Informative Comment
The signature proves possession by the importer of the migration CDI and allows a verifier to analyze both theexporting and importing environments.
End of Informative Comment12) The importing DPE MUST discard the migration CDI and keys derived from it after use, just as it would for any
other CDI.
13) A DPE MUST ensure that each context associated with a migratable session allows additional child layers, i.e., a
DPE MUST ensure that when DeriveChild is invoked, the allow-child-to-derive argument is true.
14) A DPE MUST ensure that Session IDs of migratable sessions are statistically unique so the probability of acollision with another session in the importing DPE is negligible.
A DPE profile specifies whether migration is supported, and if so, specifies the details of CDI derivation, certificate
changes, import identity generation, and the data structure, encoding, and encryption of migration messages.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 19© TCG 2023

DICE Protection Environment

5.8 Interface
There are two categories of interface for a DPE: (1) message-based, or (2) direct. A DPE implementation MUST
support at least one interface.
A message-based interface involves command and response message pairs, where each message is encoded as
described by this specification. Transport of the message is implementation-specific and not constrained. For
example, messages may traverse a network, a bus, or a pipe.
A direct interface involves implementation-specific direct invocation of commands: the nature of the interface is notconstrained. For example, a direct interface could be an API in any programming language.
Start of informative comment
Note that the required commands and functionality implemented by a DPE are not influenced by the interface
definition. The interface definition is simply the mechanism by which a client interacts with a DPE.
Further, it is strongly recommended that, for any direct DPE interface, there is a clear mapping between theimplementer-defined interface and the message-based interface defined in this specification. This mapping istypically referred to as a translation layer.
The goal of providing a translation layer for any direct DPE interface is to promote interoperability and to allow amessage based DPE test harness to work with and validate any DPE implementation.
End of informative comment
In the interest of concision, the remainder of this specification discusses only the message-based interface. For
example, command arguments are defined as fields within a message.

5.9 Messages
This section provides requirements related to command and response messages that comprise the DPE messagebased interface.

5.9.1 Transport
Apart from the encrypted session considerations, message transport is not constrained in any way by thisspecification: it is out of scope.

5.9.2 Encoding
All DPE command and response messages MUST be less than or equal to 65535 bytes in length including encryption
overhead. A DPE implementation SHOULD support messages of at least 4096 bytes. Messages are encoded using
a constrained subset of the RFC8949 CBOR format [10]. The intention of the following additional constraints is topromote implementation simplicity and correctness. The additional constraints are as follows:
1) Deterministically encoded CBOR is REQUIRED, as specified in RFC8949 section 4.2.1 [10]2) Floating point numbers and tags MUST NOT be used
3) Map keys other than integers MUST NOT be used
A DPE MUST follow these rules when generating messages and may enforce these rules on incoming messages by
responding with an error.
Each command and response defines a CBOR map for arguments, with each field being optional. Optional fields
allow for future extensibility at the encoding level, but this does not indicate the fields are optional semantically. Eachcommand specifies whether an input argument field is required and, if not, a default value. Similarly, each response

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 20© TCG 2023

DICE Protection Environment

specifies when an output argument will be omitted. A future version of this specification could make a previously
required argument optional as part of a deprecation process, for example.
Messages are described in this document using CDDL [11]. CDDL sockets are used for indicating where choice types
are expected to be extended in future versions of the specification or with vendor-defined extensions.

5.9.3 Session Message Format
Each command or response message is associated with a session and is encoded as a CBOR array, as illustrated in
the following CDDL snippet:
session-message = [session-id: uint,
message: bytes,; Ciphertext, unless using the plaintext session.

]

For an encrypted session, the entire message is encrypted except for session-id. The message format and encoding
are determined by the session protocol. When using the recommended Noise protocol, the message field is a Noisetransport message, which is simply an AEAD ciphertext.

5.9.4 Command and Response Headers
For every command message, the input fields described for the command are appended to a common header that
identifies the command. Response messages have a similar header with an error code. The format of command andresponse messages, where input-args and output-args are command-specific maps, is illustrated in the following
CDDL snippet:
command-message = [command-id: $command-id,
input-args: $input-args,]
response-message = [error-code: $error-code,
output-args: $output-args,]$command-id /= &(get-profile: 1)$command-id /= &(open-session: 2)$command-id /= &(close-session: 3)$command-id /= &(sync-session: 4)$command-id /= &(export-session: 5)$command-id /= &(import-session: 6)$command-id /= &(initialize-context: 7)$command-id /= &(derive-child: 8)
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 21© TCG 2023

DICE Protection Environment$command-id /= &(certify-key: 9)$command-id /= &(sign: 10)$command-id /= &(seal: 11)$command-id /= &(unseal: 12)$command-id /= &(derive-sealing-public-key: 13)$command-id /= &(rotate-context-handle: 14)$command-id /= &(destroy-context: 15)$error-code /= &(no-error: 0)$error-code /= &(internal-error: 1)$error-code /= &(invalid-command: 2)$error-code /= &(invalid-argument: 3)$error-code /= &(argument-not-supported: 4)$error-code /= &(session-exhausted: 5)$input-args /= get-profile-input-args$input-args /= open-session-input-args$input-args /= close-session-input-args$input-args /= sync-session-input-args$input-args /= initialize-context-input-args$input-args /= derive-child-input-args$input-args /= certify-key-input-args$input-args /= sign-input-args$input-args /= seal-input-args$input-args /= unseal-input-args$input-args /= derive-sealing-public-key-input-args$input-args /= rotate-context-handle-input-args$input-args /= destroy-context-input-args$output-args /= get-profile-output-args$output-args /= open-session-output-args$output-args /= close-session-output-args$output-args /= sync-session-output-args$output-args /= initialize-context-output-args$output-args /= derive-child-output-args$output-args /= certify-key-output-args$output-args /= sign-output-args

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 22© TCG 2023

DICE Protection Environment$output-args /= seal-output-args$output-args /= unseal-output-args$output-args /= derive-sealing-public-key-output-args$output-args /= rotate-context-handle-output-args$output-args /= destroy-context-output-args

5.9.5 Multi Part Operations
If the transport between a DPE and client is constrained, some command or response arguments may not fit in asingle transport message. While message chunking can be solved entirely at the transport layer, leaving themessages at the endpoints unaffected, this may be undesirable in some cases and a solution at the command layer
is preferred. For this reason, a DPE can support multi-part messages. Whether a DPE supports multi-partmessages is indicated in its DPE profile.
Multi-part messages are simply messages with additional arguments to facilitate the use of multiple commandresponse pairs for a single operation that would otherwise comprise a single command and response. An opaque
operation handle is used to resolve messages for concurrent operations. If a DPE does not support concurrent
operations per its profile, the operation handle can be omitted. If a DPE supports operation handles, each handle
MUST be generated by the DPE with the same security properties as required for a context handle, see section 5.6.
A DPE can use the same operation handle value across multiple messages for the same operation.
The behavioral requirements are the same for the multi-part and single-part variants of a command.
A multi-part message flow consists of a series of command-response pairs. Each command in the series has thesame command ID, and each response has an error code indicating the status so far. In some cases, a message
might have no arguments at all, for example, when all input arguments have been sent by the client but not all
outputs have been fully received the subsequent command message will have no arguments.
Arguments in multi-part messages can differ from those in single-part messages in the following ways:
•

•

•

•

Any argument of type bytes, except the operation-handle argument, can be split across messages asnecessary. For any given message the argument field contains a single chunk of the entire argument value.
Arguments of other types cannot be split and appear in any single message within the multi-part operation. If
an argument of a type other than byte appears in more than one message within the same multi-partoperation, a DPE MUST abort the operation with an invalid-argument error.
An additional Boolean argument named more-data indicates whether more chunks are in any argument in a
subsequent message. The default for more-data is false. If a DPE receives a command message with an
input argument other than the operation-handle after it receives a command message with the more-dataargument set to false, it MUST abort the operation with an invalid-argument error.
If operation handles are used, command messages have an operation-handle argument of type bytes that
contains the handle value returned by the most recent response message of the same operation. An
operation-handle argument cannot be split.
To avoid conflicts, the CBOR map key values for more-data and operation-handle are always 100 and 101
respectively, regardless of which command these are being added to.

A DPE MAY populate output arguments before input arguments have been fully received. For example, a DPE canuse multi-part messages to stream both input and output for sealing or unsealing.
Chunks of a split argument are sent in order. In other words, a recipient can append chunks in the order they arereceived to form the full argument value. A DPE MUST interpret multiple chunks for an input argument as provided
in order by the client. Similarly, a DPE MUST send output argument chunks to a client in order.
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 23© TCG 2023

DICE Protection Environment

A DPE MUST allow a client to send input arguments and input argument chunks in any command message within
the multi-part operation flow until the more-data input argument is set to false. For example, it is valid for a client tointerleave chunks of different split input arguments or to provide a non-split argument between or alongside chunksof a split argument. A DPE implementation has similar flexibility with output arguments.
As an example, the following CDDL snippet demonstrates the addition of multi-part arguments to the unseal-inputargs defined for the Unseal command in section 6.
unseal-input-args-with-multi-part = {? &(more-data: 100) => bool,? &(operation-handle: 101) => bytes,
unseal-input-args}

5.9.6 Reserved Command ID Values
This specification reserves command ID values 0 through 127 for future use. Implementers can use other ID values
for custom commands.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 24© TCG 2023

DICE Protection Environment

6 COMMANDSThis section describes DPE commands, including the format of arguments in command and response messages. A
DPE MUST support the DeriveChild and DestroyContext commands, and at least one of Sign or Unseal. A DPE
supports other commands according to its profile. If a client attempts to invoke an unsupported command, a DPE
SHALL respond with the invalid-command error. If a client includes an unsupported argument, a DPE SHALL respondwith the invalid-argument error. If a client omits a required argument, a DPE SHALL respond with the invalidargument error.

6.1 GetProfile
This command queries a DPE’s profile. Information about a profile is returned as a profile descriptor.
Input Arguments•

None

Output Arguments:•

profile-descriptor: A CBOR-encoded description of the profile. See Section 7.4 for details on the format
and semantics of the descriptor.

Argument Format:
get-profile-input-args = {* &(tstr: uint) => any}
get-profile-output-args = {? &(profile-descriptor: 1) => profile-descriptor,* &(tstr: uint) => any}

6.2 OpenSession
This command establishes a new encrypted session. The initiator and responder messages are formatted according
to the session protocol and MAY be unencrypted or partially encrypted. The responder message of the session
protocol MUST contain the new session ID encoded as a CBOR uint. Protocols that require more than a single roundtrip for session establishment are not supported by this command. When using the recommended session protocol,
each handshake message contains a payload field: the initiator payload is empty, and the responder payload contains
the session ID.
Input Arguments•

initiator-handshake: A handshake message from the initiator to responder. The format and semantics are•

determined by the session protocol. This argument is REQUIRED.
is-migratable: Indicates whether the new session is migratable; if omitted the default value is false. If a
DPE does not support migration, this argument is ignored.

Output Arguments•

responder-handshake: A handshake message from responder to initiator: the format and semantics are
determined by the session protocol. This message contains the new session ID as a payload.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 25© TCG 2023

DICE Protection Environment

Argument Format
open-session-input-args = {? &(initiator-handshake: 1) => bytes,? &(is-migratable: 2) => bool, ; Default = false* &(tstr: uint) => any}
open-session-output-args = {? &(responder-handshake: 1) => bytes,* &(tstr: uint) => any}
responder-handshake-payload = uint

; The new session ID

6.3 CloseSession
This command closes a session, causing any context data bound to the session to be destroyed and invalidating thesession ID. The session to be closed is the session used to send the command. As a result, only a client of a given
session can close that session: knowing or guessing a session ID is insufficient to close the session. A DPE canreuse session IDs. When a plaintext session is closed, all contexts bound to it are destroyed as with any other session.
The plaintext session is always valid. When a DPE supports encrypted sessions, calling CloseSession on the plaintext
session has no effect, since no contexts can be bound to it. While this is not useful, it is not an error.
Input Arguments•

None

Output Arguments•

None

Argument Format
close-session-input-args = {* &(tstr: uint) => any}close-session-output-args = {* &(tstr: uint) => any}

6.4 SyncSession
This command synchronizes an encrypted session and MUST be invoked using the plaintext session. This commandis useful for some session protocols if undelivered messages cause the client and DPE to fall out of sync. The
responder updates its copy of the initiator counter, and initiator updates its copy of the responder counter. In bothcases, the counter is updated if and only if the new counter value is larger than the current value.
If a session protocol does not require message synchronization, or does not do so using counters, this command has
no effect.
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 26© TCG 2023

DICE Protection Environment

This command may be used by a malicious DPE client to mount a denial-of-service attack on another session. For
example, it may force a session out of sync repeatedly, or it may exhaust the counter space.
Input Arguments••

session-id: The session ID of the session to be synchronized. This argument is REQUIRED.
initiator-counter: The initiator’s copy of the session counter for messages originating from the initiator. If
this value is larger than the DPE’s copy of initiator-counter, the DPE updates its copy. The DPE canenforce other requirements on the counter’s value according to the session protocol. If omitted, the default
value is zero.
Output Arguments•

responder-counter: The DPE’s copy of the session counter for messages originating from the DPE. The
client updates its copy of this counter if the new value is larger than the client’s copy of responder-counterand meets other requirements per the session protocol.
Argument Format
sync-session-input-args = {? &(session-id: 1) => uint,? &(initiator-counter: 2) => uint,* &(tstr: uint) => any}
sync-session-output-args = {? &(responder-counter: 1) => uint,* &(tstr: uint) => any}

6.5 ExportSession
This command exports a migratable session as part of a session migration flow. See Section 5.7.2.
Input Arguments•••

session-id: The session ID of the session to be exported. This argument is REQUIRED.
importer-identity: The message from an initial invocation of the ImportSession command on the importing
DPE. The message includes the importing DPE’s identity in the form of a public key and any additional
information as specified by a DPE profile. For example, certificate data associated with the public key may
be included. The structure and encoding of this message is determined by a DPE profile. This argument is
REQUIRED.
psk: A pre-shared key to be used as part of the encryption scheme. Exported data cannot be decrypted
without this key. If omitted, an empty psk is used (zero bytes).

Output Arguments•

exported-data: This is a message to be used in a second invocation of the ImportSession command on theimporting DPE. The message is encrypted and includes all data necessary to complete the session migration.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 27© TCG 2023

DICE Protection Environment

Only the importer identified by the importer-identity argument can decrypt this message. The structure andencoding of this message is determined by a DPE profile.
Argument Format
export-session-input-args = {? &(session-id: 1) => uint,? &(importer-identity: 2) => bytes,? &(psk: 3) => bytes,* &(tstr: uint) => any}
export-session-output-args = {? &(exported-data: 1) => bytes,* &(tstr: uint) => any}

6.6 ImportSession
This command either imports a migratable session exported by another DPE or provides identity information that canbe used by an exporting DPE. During a migration this command is typically invoked twice, once by the exporting DPE
to get the identity information, and subsequently by the importing DPE to import data encrypted to that identity. See
Section 5.7.2 for further details on migration.
Input Arguments•

context-handle: The context handle for the context to be used as the parent for the imported session. If•

retain-context: Indicates whether the imported parent context should be retained for subsequent

omitted, the default context is used.

••commands. If true, a new context handle will be returned to the client as an output argument. If omitted, thedefault is false. This argument is ignored when returning identity information since the context is always
retained to complete the migration operation.
exported-data: Data exported by another DPE via the ExportSession command. This argument is
REQUIRED for an invocation of this command intended to import data encrypted to an identity, and MUST beomitted for an invocation of this command intended to obtain identity information. If omitted, an importeridentity output argument is returned, the psk and retain-context arguments are ignored, and the context
is retained.
psk: A pre-shared key to be used as part of the encryption scheme. If omitted, an empty psk is used (zerobytes). This argument is ignored when the exported-data input argument is omitted.

Output Arguments••

importer-identity: Contains identity information about the current context, including at minimum a public
key, and is used by another DPE when exporting a session. The structure and encoding of this message are
specified by a DPE profile. This argument is only returned when the exported-data input argument is omitted.
new-context-handle: A new handle for the context, if the context is to be retained.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 28© TCG 2023

DICE Protection Environment

Argument Format
import-session-input-args = {? &(context-handle: 1) => bytes,? &(retain-context: 2) => bool, ; Default = false, ignored if returning importer-identity? &(exported-data: 3) => bytes,? &(psk: 4) => bytes,* &(tstr: uint) => any}
import-session-output-args = {? &(importer-identity: 1) => bytes, ; If no exported-data provided? &(new-context-handle: 2) => bytes, ; If retained* &(tstr: uint) => any}

6.7 InitializeContext
This command initializes a new DPE context. See section 5.6 for details on DPE contexts.
Input Arguments•••

simulation: Indicates whether to create a simulation context. If omitted, the default is false.
use-default-context: Indicates whether to use the default context for the current session instead of returninga context handle to the client. If omitted, the default is false.
seed: This argument provides a seed value as an input to the initialization. A DPE profile specifies how thisseed is used and specifies requirements for secure operation, if any. For example, the seed might be used asa UDS.

Output Arguments•

new-context-handle: A context handle for the new context. Omitted if the default context was used.

Argument Format
initialize-context-input-args = {? &(simulation: 1) => bool,; Default = false? &(use-default-context: 2) => bool,; Default = false? &(seed: 3) => bytes,* &(tstr: uint) => any}
initialize-context-output-args = {? &(new-context-handle: 1) => bytes,

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 29© TCG 2023

DICE Protection Environment* &(tstr: uint) => any}

6.8 DeriveChild
This command performs the DICE computation [1] on a given set of inputs. The DeriveChild command is thefundamental DICE operation. It is used to derive the next-layer CDI value for a given set of inputs. Other DPE
commands are either made possible by this command or exist to make this command possible.
Many details of how this command behaves are specified by a DPE profile, including:
•
•
•
•
•
•

The format of input data
The mapping of input data to the derivation computations
The mapping of input data to certificate fields
The availability and semantics of internal inputs
The algorithm to derive new CDIs, asymmetric keys, and other certificate data
The format of the new certificate

Input Arguments
•

•
•

•

•

context-handle: A context handle for the client’s current DPE context, see Section 5.6. This can be asimulation context. If omitted, the default context is used. If retain-parent-context is true, this context will

be retained in its current state for subsequent operations and a new context handle for this context will be
returned to the client. This is useful if a parent program creates multiple child programs and computes CDI(s)for each. If the default context is used and retain-parent-context is true, the input argument new-sessioninitiator-handshake is REQUIRED. The new child context will be stored in the default context of the new
session, and the parent context is retained as the current session’s default context.
retain-parent-context: Indicates whether the parent context is to be retained, as explained in the descriptionof the context-handle input argument. If omitted, the default value is false.
allow-child-to-derive: Indicates whether the child context is allowed to be used in a subsequent invocationof DeriveChild. This is useful if the child context is known to belong to a program that should not derive
additional DPE contexts, for example, an application. The allow-child-to-derive argument is similar to how
a CA can specify pathLen=0 in X.509v3 basicConstraints. If a DPE supports X.509 certificates, the DPESHOULD set pathLen=0 in X.509v3 basicConstraints within the corresponding certificate when this argument
is false. If omitted, the default value is true. If the current session is migratable, this argument MUST be true.
create-certificate: Indicates whether to create an intermediate certificate for this layer, which can be an
ECA certificate as defined by DICE Certificate Profiles. If omitted, the default is true. If this argument is set
to false, no certificate is generated for the layer and any information that would normally have been added tothe certificate is accumulated as part of the context and will appear in the next certificate generated, whether
by a subsequent DeriveChild command or a CertifyKey command. The private key corresponding to themost recent certificate generated MUST be retained, even if retain-parent-context is set to false. It MUSTNOT be possible for the accumulated certificate information to be removed or modified until it is represented
in a certificate via a subsequent invocation of this command.
new-session-initiator-handshake: This argument is used to create a new session for the new child context.
This is the initiator handshake message for the new session and the corresponding handshake response isreturned as an output argument. Session protocols can use binding information from the current session tonegotiate the new session, but the resulting new session MUST be independent of the current session. If
omitted, the new child context will be bound to the current session. See section 5.7.1.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 30© TCG 2023

DICE Protection Environment•

new-session-is-migratable: Indicates whether the new session is migratable. If new-session-initiatorhandshake is omitted, this argument is ignored. If new-session-is-migratable is omitted, the default value•

input-data: Input from a DICE component/layer (i.e., client) that describes all security-relevant properties ofis false.

•

the child component or layer. How this data is formatted, used in the DICE computation, mapped to certificate
fields, etc. is determined by a DPE profile. This value can be a TCB Component Identifier (TCI); see [2]. This
argument is REQUIRED: there is no default value.
internal-inputs: An array of additional internal inputs to include in the DICE computation. If omitted, nointernal inputs are used. These inputs are stored internally to the DPE, and their availability and behavior isgoverned by a DPE profile. A profile can define arbitrary internal inputs in addition to those defined here.
Uses include anything that needs protection or policy enforcement (e.g., monotonic counters, rotatablesecrets, etc.). Internal inputs indicated in this argument MUST be included in the DICE computation and canbe included in a certificate. The following internal inputs are defined:o dpe-info: This contains basic information about the DPE: version, configuration, profile, etc.
o dpe-dice: This contains internal DICE state of the DPE, including CDI(s), certificate chain, etc.

Output Arguments•

new-context-handle: A context handle for the new child context. This will be omitted if the default context is•

new-session-responder-handshake: If a new session was initiated by including the new-session-initiatorhandshake input argument, this is the corresponding handshake message from the protocol responder. The

used.

•

new session is already fully operational on the DPE side, and the new child context is associated with the new
session.
new-parent-context-handle: If the parent context was retained and the default context was not used, thisargument contains a new context handle for the parent context.

Argument Format
derive-child-input-args = {? &(context-handle: 1) => bytes,? &(retain-parent-context: 2) => bool,; Default = false? &(allow-child-to-derive: 3) => bool,; Default = true

? &(create-certificate: 4) => bool,; Default = true

? &(new-session-initiator-handshake: 5) => bytes,? &(new-session-is-migratable: 6) => bool,; Default = false? &(input-data: 7) => bytes,? &(internal-inputs: 8) => [* $internal-input-type],* &(tstr: uint) => any}$internal-input-type /= &(dpe-info: 1,
dpe-dice: 2,)
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 31© TCG 2023

DICE Protection Environment

derive-child-output-args = {? &(new-context-handle: 1) => bytes,? &(new-session-responder-handshake: 2) => bytes,? &(parent-context-handle: 3) => bytes,; If new session initiated; If retained* &(tstr: uint) => any}

6.9 CertifyKey
This command certifies an attestation key using the given DPE context as the certification authority. If the public key
to certify is not provided as an input argument, a key pair is deterministically derived from the context and the label
argument. This will be the same key derived by Sign for the same label. The new public key is certified and returned
separate from any certificate in the response. In either case, a certificate chain is returned that contains all certificates
generated by the DPE for the given context and the new leaf certificate. If the context contains accumulated certificate
information, that information MUST be represented in the new leaf certificate. The accumulated certificate information
MUST remain in the context unmodified.
The content and format of certificates generated by the DPE, the order and format of the certificate chain, and thetype of asymmetric keys supported, are specified by a DPE profile. Similarly, the connection of the certificate chain
to external infrastructure like a manufacturer-issued certificate is also defined by a profile. A profile can specify that
additional certificates not generated by the DPE are included in the certificate chain returned by this command.
The certificate chain will always have at least one entry: the new leaf certificate. This leaf certificate might follow therequirements specified by DICE Certificate Profiles, and the policies argument can be used to indicate which policies
to apply to the new leaf certificate.
Input Arguments•

context-handle: A handle for the context that will be used to issue a certificate for the attestation key. If

omitted, the default context is used. A DPE MUST NOT allow a simulation context to be used when the
public-key argument is provided by the client, because the corresponding private key is not controlled by theDPE.
•retain-context: Indicates whether the DPE context is to be retained for subsequent commands. If true, a•public-key: The public key to certify. The type and format of the public key is specified by a DPE profile. If

new context handle will be returned to the client as an output argument. If omitted, the default is false.

••

omitted, a key pair is deterministically derived from the context and the label argument.
label: A label to use as additional input to the asymmetric key derivation from the context. If public-key isprovided, there is no derivation, and this argument is ignored. Using the same label with the same context
multiple times will yield the same key pair. Similarly, using the same label with the same context with the Sign
command will yield the same key pair. If omitted, an empty label is used (i.e., a label of zero bytes). A DPE
profile may define a fixed set of supported labels.
policies: A set of policy values that determine the construction of the certificate. When a DPE profile uses
the policies defined by DICE Certificate Profiles [4] this argument specifies which of the policies should apply
to the new leaf certificate. A DPE profile determines which of these policies are supported, if any, and may
define other policies. A DPE profile determines the behavior when this argument is omitted.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 32© TCG 2023

DICE Protection Environment

Output Arguments•

certificate-chain: The certificate chain, including the new leaf certificate and any other certificates•derived-public-key: The public key of the derived key pair, if any. The type and format of the public key is
specified by a DPE profile. If the public-key input argument was provided, there is no derived key pair, andgenerated in the DPE context. The content and format of the certificates depend on the DPE profile.

•

this argument is omitted.
new-context-handle: A new handle for the DPE context if the retain-context argument was set to true.

Argument Format
certify-key-input-args = {? &(context-handle: 1) => bytes,? &(retain-context: 2) => bool,; Default = false? &(public-key: 3) => bytes,? &(label: 4) => bytes,? &(policies: 5) => [* $policy-type],* &(tstr: uint) => any}$policy-type /= &(tcg-dice-kp-identityInit: 6, ; Matches the corresponding OID
tcg-dice-kp-identityLoc: 7,
tcg-dice-kp-attestInit: 8,
tcg-dice-kp-attestLoc: 9,
tcg-dice-kp-assertInit: 10,
tcg-dice-kp-assertLoc: 11,)
certify-key-output-args = {? &(certificate-chain: 1) => [+ bytes],? &(derived-public-key: 2) => bytes,? &(new-context-handle: 3) => bytes,; If retained* &(tstr: uint) => any}

6.10 Sign
This command signs a given message with a key derived from the given DPE context and label. The signaturealgorithm is specified by a DPE profile. A DPE profile may support an asymmetric signature scheme and/or asymmetric signature scheme (e.g., a MAC). For asymmetric signatures, the signing key will be the same key derived
by CertifyKey for the same label. The DPE context MUST NOT be a simulation context.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 33© TCG 2023

DICE Protection Environment

Input Arguments•

context-handle: A handle for the DPE context that will be used to derive a signing key. If omitted, the default•

retain-context: Indicates whether the DPE context is to be retained for subsequent commands. If true, a•label: A label to use as additional input to the asymmetric key derivation from the DPE context. Using the•same label with the same DPE context multiple times will yield the same key pair. Similarly, using the samelabel with the same DPE context with the CertifyKey command will yield the same key pair. If omitted, an
empty label is used (i.e., a label of zero bytes). A DPE profile may define a fixed set of supported labels.
is-symmetric: Indicates whether a symmetric signature scheme should be used. If omitted, the default
value is false.
to-be-signed: The data to be signed. The format of this data is specified by a DPE profile. This argument is
REQUIRED.

context is used. A DPE MUST NOT allow a simulation context to be used.
new context handle will be returned to the client as an output argument. If omitted, the default is false.

•

Output Arguments•

signature: The signature over the data in the to-be-signed input argument. The format of the signature is•

new-context-handle: A new handle for the DPE context if the retain-context argument was set to true.

specified by a DPE profile.
Argument Format
sign-input-args = {? &(context-handle: 1) => bytes,? &(retain-context: 2) => bool, ; Default = false? &(label: 3) => bytes,? &(is-symmetric: 4) => bool, ; Default = false? &(to-be-signed: 5) => bytes,* &(tstr: uint) => any}
sign-output-args = {? &(signature: 1) => bytes,? &(new-context-handle: 2) => bytes,; If retained* &(tstr: uint) => any}

6.11 Seal
This command seals data to a given policy using a symmetric key deterministically derived from the given DPE
context. The sealed data can be unsealed only by calling the Unseal command with the same DPE context and isasymmetric set to false.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 34© TCG 2023

DICE Protection Environment

Input Arguments•

context-handle: A handle for the DPE context that will be used to derive a sealing key. This can be a•retain-context: Indicates whether the DPE context is to be retained for subsequent commands. If true, a•

unseal-policy: This argument describes a policy that constrains the conditions under which the DPE will

simulation context. If omitted, the default context is used.
new context handle will be returned to the client as an output argument. If omitted, the default is false.

••

allow the sealed-data output argument to be unsealed. The format and semantics of this policy value are
specified by a DPE profile.
label: A label to be included in the sealing key derivation. If omitted, an empty label is used (i.e., a label ofzero bytes). A DPE profile may define a fixed set of supported labels.
data-to-seal: The data to be sealed. A DPE profile can place constraints on the length, content, and formatof this data. This argument is REQUIRED.

Output Arguments••

sealed-data: The sealed data as opaque bytes. The format and content are implementation dependent.
new-context-handle: A new handle for the DPE context if the retain-context argument was set to true.

Argument Format
seal-input-args = {? &(context-handle: 1) => bytes,? &(retain-context: 2) => bool,; Default = false? &(unseal-policy: 3) => bytes,? &(label: 4) => bytes,? &(data-to-seal: 5) => bytes,* &(tstr: uint) => any}
seal-output-args = {? &(sealed-data: 1) => bytes,? &(new-context-handle: 2) => bytes,; If retained* &(tstr: uint) => any}

6.12 Unseal
This command unseals data previously sealed to a given policy with a symmetric or asymmetric key derived from thegiven DPE context. With a symmetric key, data previously sealed using the Seal command can be unsealed. Withan asymmetric key, data previously sealed using the Seal command and the public key produced by the
DeriveSealingPublicKey command as specified by a DPE profile can be unsealed.
Input Arguments•

context-handle: A handle for the DPE context that will be used to derive a sealing key. If omitted, the default

context is used. A DPE MUST NOT allow a simulation context to be used.
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 35© TCG 2023

DICE Protection Environment•

retain-context: Indicates whether the DPE context is to be retained for subsequent commands. If true, a•

is-asymmetric: Indicates whether to use a symmetric or asymmetric key to unseal. If omitted, the default

new context handle will be returned to the client as an output argument. If omitted, the default is false.

••

value is false.
label: A label to be included in the sealing key derivation. If omitted, an empty label is used (i.e., a label ofzero bytes). A DPE profile may define a fixed set of supported labels.
data-to-unseal: The data to be unsealed. For symmetric unseal, this is the sealed-data returned by the
Seal command. For asymmetric unseal, the seal algorithm and format of this data are specified by a DPE
profile. This argument is REQUIRED.

Output Arguments••

unsealed-data: The original unsealed data. For symmetric unseal, this is the same data as the data-to-sealargument for the Seal command.
new-context-handle: A new handle for the DPE context if the retain-context argument was set to true.

Argument Format
unseal-input-args = {? &(context-handle: 1) => bytes,? &(retain-context: 2) => bool,; Default = false? &(is-asymmetric: 3) => bool,; Default = false? &(label: 4) => bytes,? &(data-to-unseal: 5) => bytes,* &(tstr: uint) => any}
unseal-output-args = {? &(unsealed-data: 1) => bytes,? &(new-context-handle: 2) => bytes,; If retained* &(tstr: uint) => any}

6.13 DeriveSealingPublicKeyThis command provides a sealing public key derived from the given DPE context for a given policy and a label. Data
sealed with this key can only be unsealed by calling the Unseal command with the same context and is-asymmetric
set to true. A DPE MUST derive a different asymmetric key pair for sealing than it does for signing in CertifyKey and
Sign, even if the CDI is the same.
Input Arguments••

context-handle: A handle for the DPE context that will be used to derive a sealing key. This can be asimulation context. If omitted, the default context is used.
retain-context: Indicates whether the DPE context is to be retained for subsequent commands. If true, a
new context handle will be returned to the client as an output argument. If omitted, the default is false.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 36© TCG 2023

DICE Protection Environment••

unseal-policy: This argument describes a policy that constrains the conditions under which the DPE willallow the sealed-data output argument to be unsealed. The format and semantics of this policy value are
specified by a DPE profile.
label: A label to be included in the sealing key derivation. If omitted, an empty label is used (i.e., a label ofzero bytes). A DPE profile may define a fixed set of supported labels.

Output Arguments•

derived-public-key: The public key of the asymmetric key pair for sealing. The type and format of the public•

key are specified by a DPE profile. How this public key can be used to seal data is also specified by a DPE
profile.
new-context-handle: A new handle for the DPE context if the retain-context argument was set to true.

Argument Format
derive-sealing-public-key-input-args = {? &(context-handle: 1) => bytes,? &(retain-context: 2) => bool,; Default = false? &(unseal-policy: 3) => bytes,? &(label: 4) => bytes,* &(tstr: uint) => any}
derive-sealing-public-key-output-args = {? &(derived-public-key: 1) => bytes,? &(new-context-handle: 2) => bytes,; If retained* &(tstr: uint) => any}

6.14 RotateContextHandle
This command rotates a DPE context handle. The current handle is invalidated, and a new handle is returned. The
context itself is unaffected.
When used with a default context, this command assigns a new handle to the context so it is no longer the default
context. After this the default context is invalid (unusable) until it is initialized again.
Input Arguments•

context-handle: The handle to invalidate. If omitted, the default context is used.

Output Arguments•

new-context-handle: A new handle for the context.

Argument Format
rotate-context-handle-input-args = {DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 37© TCG 2023

DICE Protection Environment? &(context-handle: 1) => bytes,* &(tstr: uint) => any}
rotate-context-handle-output-args = {? &(new-context-handle: 1) => bytes,* &(tstr: uint) => any}

6.15 DestroyContext
This command destroys a DPE context. After this command succeeds, the context handle is no longer usable. If thedefault context is destroyed, it becomes invalid (unusable) until it is initialized again.
Input Arguments•

context-handle: A handle for the context to be destroyed. If omitted, the default context is used.

Output Arguments•

None

Argument Format
destroy-context-input-args = {? &(context-handle: 1) => bytes,* &(tstr: uint) => any}
destroy-context-output-args = {* &(tstr: uint) => any}

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 38© TCG 2023

DICE Protection Environment

7 PROFILESA DPE profile specifies details where a DPE has flexibility. A profile is complete in that if a DPE design decision
impacts interoperability between a client and a DPE, it MUST be specified by a profile. A profile includes attributes
such as which features are supported or not supported, limits such as maximum message size, and formats such as
inputs or public keys.
To define a profile, simply specify every attribute. This specification defines the attributes and provides a sample
value for each attribute. See sections 7.2 and 7.3.

7.1 Namespaces
Names identify profiles and profile attribute values. Names are represented as a text string, a sequence of Unicode
code points. Anyone can define a custom profile including various custom names without any kind of registration for
those names. Names MUST be prefixed with an appropriate namespace to avoid collisions. The namespace
SHOULD align with an internet domain owned by the defining entity. Namespaces prefixed with tcg are reserved foruse by TCG and MUST NOT be used for custom names.

7.2 Profile Attributes
Table 1 describes each profile attribute. Each attribute is denoted with a tag-style name that carries over to the CDDL
definition of a profile descriptor. Each attribute also has an expected type: Boolean, Number, or String. When
attributes are encoded as a descriptor, these types are mapped to the CBOR types bool, uint, and tstr respectively.
Custom string values MUST follow namespace requirements. Each custom name MUST reference one specificimmutable value for the attribute, however complex, which means names are unambiguous. When defining the value
associated with a name, any definition that meets the requirements of the attribute can be specified. Number fields
can use the value ‘Unlimited’ to denote that no explicit constraint is imposed. String fields can use the value ‘Empty’
to denote the empty string.
In some cases, the value of one attribute renders another attribute irrelevant. For example, if encrypted sessions are
not supported, defining a session protocol is not meaningful. In these cases, profiles SHOULD use the value ‘NA’ toindicate an attribute is not applicable and SHOULD omit the irrelevant attributes from the descriptor. In some cases,
the value of one attribute places constraints on the value of another attribute. Both irrelevance and constraint
implications are indicated in Table 1 with an Implications section describing anything that a value for the current
attribute implies about other attributes. For convenience, an Affected By section lists attributes with implications that
affect the current attribute. These documented implications preclude profiles that are inconsistently defined, which
also means that self-consistency of a profile can be programmatically verified using these rules.
Some attributes are logically equivalent, like supports-attestation and supports-sign, but they are still intentionally
included for semantic clarity since the relationship is not always obvious.
Attribute

Type

Description
Generalname

String

The name of the current profile. A profile can be defined without a
name: this is indicated with the empty string. When a name isprovided (i.e., it is not the empty string), it MUST reference one
specific immutable profile. In other words, a non-empty profilename is unambiguous in terms of the associated set of attributevalues.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 39© TCG 2023

DICE Protection Environment

inherits

String

The name of a profile to inherit. When this value is not empty, allattributes omitted from the current profile use the value from thisinherited profile. Any value specified for the current profile
overrides inherited values.
When this value is encoded in a descriptor, an encoded descriptorof the inherited profile is included instead of just the name of theinherited profile.

dpe-spec-version

Number

The supported DPE specification version. Only the major version
is used since minor versions and revisions are mutuallycompatible.

max-message-size

Number

The maximum message size allowed at the transport layer. Notethat this applies to command and response messages when usinga message-based interface. When using a direct interface, thisvalue is not meaningful.

uses-multi-part-messages

BooleanIndicates whether a DPE uses multi-part messages for commands
where these are defined.
Implications● If false, supports-concurrent-operations is irrelevant

supports-concurrentoperations

BooleanIndicates whether a DPE supports concurrent multi-part commandsequences.
Affected By● uses-multi-part-messages
Sessions

supports-encrypted-sessions

BooleanIndicates whether a DPE supports encrypted sessions. Note thisalso implies whether multiple sessions are supported, since there
is only one plain-text session (session ID zero).
Implications• When false, supports-derived-sessions and supportssession-sync MUST be false• When false, the following attributes are irrelevant and
SHOULD be omitted:
o
o
o

•

max-sessions
session-protocol
session-sync-policy

When true, supports-open-session and supports-closesession MUST be true

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 40© TCG 2023

DICE Protection Environment•

supports-derived-sessions

BooleanWhen false, supports-open-session, supports-closesession, supports-sync-session, and supportssession-migration MUST be false

Indicates whether a DPE supports the creation of new sessions
via the DeriveChild command.
Affected By•

max-sessions

Numbersupports-encrypted-sessions

The maximum number of open sessions supported.
Affected By•

session-protocol

Stringsupports-encrypted-sessions

Names the session protocol for encrypted sessions. The protocol
MUST define these elements:••••

The content and format of handshake messages, including
the session ID payload on response
The content and format of transport messages
The content and format of handshake messages forderived sessions via the DeriveChild command
The maximum number of ciphertext messages that can beexchanged per session, or a rotation scheme to handle
key exhaustion if applicable

Affected By•
supports-session-sync

Booleansupports-encrypted-sessions

Indicates whether a DPE supports session synchronization via the
SyncSession command.
Implications• When false, session-sync-policy is irrelevant and
SHOULD be omitted
Affected By•

supports-encrypted-sessions

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 41© TCG 2023

DICE Protection Environment

session-sync-policy

StringNames a policy enforced on the counters when synchronizing asession. The policy MUST define all checks required before
accepting the new counter value.
Affected By••

supports-session-migration

Booleansupports-encrypted-sessions
supports-session-sync

Indicates whether a DPE supports session migration via the
ExportSession and ImportSession commands.
Implications• If true, supports-export-session MUST be true
• If true, supports-import-session MUST be true
• If false, session-migration-protocol is irrelevant and
SHOULD be omitted
Affected By•••

session-migration-protocol

Stringsupports-export-session
supports-import-session
supports-encrypted-sessions

Names a migration protocol that defines details of a migration
flow, including the importer-identity and exported-data
messages. The protocol MUST define these elements:• The content and format of the importer-identity message
returned by the ImportSession command• The content and format of the exported-data message
returned by the ExportSession command• The encryption scheme used to encrypt exported data,
including:o Cryptographic algorithms
o Key sizeso The encryption and decryption processes end-toend• The input content and format for CDI derivations:o When the exporter derives a migration CDI; this
MUST contain the importer’s identity in some form
o When the importer derives a CDI for the postmigration context; this MUST contain the migration
CDI in some form
Affected By•

supports-session-migration

Contexts
supports-default-context

BooleanIndicates whether a DPE supports default contexts.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 42© TCG 2023

DICE Protection Environment

Implications• At least one of supports-default-context or supportscontext-handles MUST be true
• If false, supports-auto-init MUST be false
Affected By••
supports-context-handles

Booleansupports-context-handles
supports-initialize-context

Indicates whether a DPE supports context handles, as opposed toonly default contexts.
Implications• At least one of supports-context-handles or supportsdefault-context MUST be true
• If false, supports-simulation MUST be false• If false, max-context-handle-size is irrelevant and
SHOULD be omitted
Affected By•

supports-default-context

max-contexts-per-session

Number

How many contexts can be associated with a single session.

max-context-handle-size

Number

The maximum size of context handles produced by a DPE. This isalways subject to the max-message-size in a particular message.
Affected By•

supports-auto-init

Booleansupports-context-handles

Indicates whether a DPE supports automatic initialization of a
default context.
Affected By••

supports-simulation

Booleansupports-default-context
supports-initialize-context

Indicates whether a DPE supports simulation contexts.
Affected By•

supports-context-handles

Use Cases
supports-attestation

BooleanIndicates whether a DPE supports attestation use cases.
Implications• If true, supports-sign MUST be true
• If false, supports-certify-key, supports-sign, andsupports-certificates MUST be false

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 43© TCG 2023

DICE Protection Environment

•

•

•

If false and supports-asymmetric-unseal is also false,
asymmetric-derivation is irrelevant and SHOULD beomittedIf false and supports-symmetric-sign is also false,
symmetric-derivation is irrelevant and SHOULD beomittedAt least one of supports-attestation or supportssealing MUST be true

Affected By•••
supports-sealing

Booleansupports-sealing
supports-certify-key
supports-sign

Indicates whether a DPE supports sealing use cases.
Implications• If true, supports-unseal MUST be true
• If false, the following MUST also be false:
o
o
o
o
o

•

supports-seal
supports-unseal
supports-sealing-public
supports-unseal-policy
supports-asymmetric-unseal

At least one of supports-sealing or supportsattestation MUST be true

Affected By••••

supports-attestation
supports-seal
supports-unseal
supports-sealing-publicCommands 1
supports-get-profile

BooleanIndicates whether a DPE supports the GetProfile command.

supports-open-session

BooleanIndicates whether a DPE supports the OpenSession command.
Implications• If true, supports-encrypted-sessions MUST be true
Affected By•

supports-close-session

Booleansupports-encrypted-sessions

Indicates whether a DPE supports the CloseSession command.

1 Note: mandatory commands not represented in this section.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 44© TCG 2023

DICE Protection Environment

Implications• If true, supports-encrypted-sessions MUST be true
Affected By•
supports-sync-session

Booleansupports-encrypted-sessions

Indicates whether a DPE supports the SyncSession command.
Implications• If true, supports-encrypted-sessions MUST be true
Affected By•

supports-export-session

Booleansupports-encrypted-sessions

Indicates whether a DPE supports the ExportSession command.
Implications• If true, supports-encrypted-sessions MUST be true
• If true, supports-session-migration MUST be true
• If true, supports-import-session MUST be true
Affected By•••

supports-import-session

Booleansupports-encrypted-sessions
supports-session-migration
supports-import-session

Indicates whether a DPE supports the ImportSession command.
Implications• If true, supports-encrypted-sessions MUST be true
• If true, supports-session-migration MUST be true
• If true, supports-export-session MUST be true
Affected By•••

supports-initialize-context

Booleansupports-encrypted-sessions
supports-session-migration
supports-export-session

Indicates whether a DPE supports the InitializeContext
command.
Implications• If false, supports-default-context and supports-autoinit MUST be true

supports-certify-key

BooleanIndicates whether a DPE supports the CertifyKey command.
Implications

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 45© TCG 2023

DICE Protection Environment•

If true, supports-certificates and supportsattestation MUST be true

Affected By••
supports-sign

Booleansupports-attestation
supports-certificatesIndicates whether a DPE supports the Sign command.
Implications• If true, supports-attestation MUST be true
• If false, supports-attestation MUST be false• If false, the following are irrelevant and SHOULD beomitted:o to-be-signed-format
o signature-format
o supports-symmetric-sign
Affected By•

supports-seal

Booleansupports-attestation

Indicates whether a DPE supports the Seal command.
Implications• If true, supports-sealing MUST be true
Affected By•

supports-unseal

Booleansupports-sealing

Indicates whether a DPE supports the Unseal command.
Implications• If true, supports-sealing MUST be true
• If false, supports-asymmetric-unseal and supportssealing MUST be false
Affected By•

supports-sealing-public

Booleansupports-sealing

Indicates whether a DPE supports the DeriveSealingPublicKey
command.
Implications• If true, supports-sealing MUST be true
• If false, supports-asymmetric-unseal MUST be false
Affected By••

supports-sealing
supports-asymmetric-unseal

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 46© TCG 2023

DICE Protection Environment

supports-rotate-contexthandle

BooleanIndicates whether a DPE supports the RotateContextHandle
command.
Derivation

dice-derivation

StringNames a scheme for how input data is mixed with a UDS or CDI
to produce a new CDI. The scheme MUST define:• Cryptographic algorithms• A deterministic process from input to CDI

asymmetric-derivation

StringNames a scheme for how an asymmetric key pair is derived froma CDI. The scheme MUST define:• Cryptographic algorithms including:o Key type, size, and domain parameters, for bothsigning and sealingo Signature schemeo Asymmetric sealing scheme• A deterministic derivation process from CDI to key pair for
all supported derivations. For example, ECA keys, signingkeys, sealing keys, and import identity keys.
Affected By••

symmetric-derivation

Stringsupports-attestation
supports-asymmetric-unseal

Names a scheme for how a symmetric key is derived from a CDI.
The scheme MUST define:• Cryptographic algorithms including:o Key type and size for both signing and sealingo Signature schemeo Sealing scheme• A deterministic derivation process from CDI to key material
for all supported derivations. For example, MAC keys andsealing keys.
Affected By••

supports-any-label

Booleansupports-sealing
supports-symmetric-sign

Indicates whether a DPE allows arbitrary labels or a fixed set oflabels. If a DPE supports only a fixed set, the supported-labels
attribute defines that fixed set.
Implications• If true, supported-labels is irrelevant and SHOULD beomitted• If false, supported-labels MUST be provided

supported-labels

StringNames a fixed set of labels that are supported by the DPE. The
list MUST specify for each label the exact bytes supported as a

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 47© TCG 2023

DICE Protection Environment

label argument. For example, if the list is described using text
strings, the encoding must be specified as well.
Affected By•
initial-derivation

Stringsupports-any-label

Names a scheme for deriving an initial state, for example a UDS
or CDI(s), when a context is initialized. This can incorporate theseed argument to the InitializeContext command and/or values
available internally to the DPE. The scheme MUST cover:• Cryptographic algorithms• A deterministic process from seed(s) to UDS or CDI(s) andcertificates if applicable• Whether the seed argument is used and, if so:o The format of the seed argumento Any requirements on the seed argument for secure
operation
Input

input-format

StringNames a scheme for how input data is formatted when passed to
the DeriveChild command. The scheme MUST define:• Unambiguous definition of the structure of the data:o As it appears in the DPE input argumento As it is processed by the DICE derivation• Canonical encoding(s) of the data:o As it appears in the DPE input argumento As it is processed by the DICE derivation• For each field, whether the field is used for the attestation
derivations and/or sealing derivations, where applicable• Basic attributes of each field, if applicable, including
whether it is optional, repeatable, typed, or has value
constraints (e.g. max size)
How the input is presented in a certificate is defined by thecertificate format attributes.

supports-internal-inputs

BooleanIndicates whether a DPE supports internal inputs.
Implications• If false, supports-internal-dpe-info and supportsinternal-dpe-dice MUST be false• If false, internal-inputs is irrelevant and SHOULD beomittedsupports-internal-dpe-info

BooleanIndicates whether a DPE supports the dpe-info internal input.
Implications

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 48© TCG 2023

DICE Protection Environment•

If false, internal-dpe-info-type is irrelevant and
SHOULD be omitted

Affected By•
supports-internal-dpe-dice

Booleansupports-internal-inputs

Indicates whether a DPE supports the dpe-dice internal input
Implications• If false, internal-dpe-dice-type is irrelevant and
SHOULD be omitted
Affected By•internal-dpe-info-type

Stringsupports-internal-inputs

Names a type that defines properties of the dpe-info internal
input. The definition MUST define the same elements as otherinternal input definitions. See the internal-inputs attribute.
Affected By•internal-dpe-dice-type

Stringsupports-internal-dpe-infoNames a type that defines properties of the dpe-dice internal
input. The definition MUST define the same elements as otherinternal input definitions. See the internal-inputs attribute.
Affected By•internal-inputs

Stringsupports-internal-dpe-dice

A comma-separated list of internal inputs that are supported. The
pre-defined dpe-info and dpe-dice inputs SHOULD NOT be inthis list. Each item in the list MUST name an internal input that iswell defined. An internal input definition MUST define:• The semantics of the input, or the semantics of each field if
the input is composed of multiple fields• The structure of the input• The encoding of the input as it is processed by the DICE
derivation• Basic attributes of each field, if applicable, including
whether it is optional, repeatable, typed, or has value
constraints (e.g. max size)• Whether the input appears in certificates, per field if
applicableAs with all other inputs, how an internal input is presented in a
certificate is defined by the certificate format attributes.
Affected By•

supports-internal-inputs

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 49© TCG 2023

DICE Protection Environment

Certificates
supports-certificates

BooleanIndicates whether a DPE supports generating certificates.
Implications● If false, the following MUST also be false:●●●

supports-certify-key
supports-certificate-policies
supports-eca-certificates
supports-external-key
If true, supports-certify-key MUST be true○○○○

If false, the following attributes are irrelevant and SHOULD
be omitted:
max-certificate-size
max-certificate-chain-size
appends-more-certificatesleaf-certificate-format
If false and supports-asymmetric-unseal is also false,
public-key-format is irrelevant and SHOULD be omitted○○○○

Affected By●●
max-certificate-size

Numbersupports-attestation
supports-certify-key

The maximum certificate size, in bytes.

Affected By●
max-certificate-chain-size

Numbersupports-certificates

The maximum number of certificates in a chain, per context.
Affected By●

appends-more-certificates

Booleansupports-certificatesIndicates whether a DPE appends more certificates to each chain
after those generated by the DPE. For example, whether a static
manufacturer certificate chain is appended that anchors the chain
to a self-signed root.
Affected By●

supports-certificate-policies

Booleansupports-certificatesIndicates whether a DPE supports any certificate policies via thepolicies argument to the CertifyKey command.
Implications● If false, the following MUST also be false:○○

supports-policy-identity-init
supports-policy-identity-loc

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 50© TCG 2023

DICE Protection Environment●

supports-policy-attest-init
supports-policy-attest-loc
supports-policy-assert-init
supports-policy-assert-loc
If false, certificate-policies is irrelevant and SHOULD○○○○

be omitted
Affected By●
supports-policy-identity-init

Booleansupports-certificatesIndicates whether a DPE supports the tcg-dice-kp-identityInit
policy.
Affected By●

supports-policy-identity-loc

Booleansupports-certificate-policies

Indicates whether a DPE supports the tcg-dice-kp-identityLoc
policy.
Affected By●

supports-policy-attest-init

Booleansupports-certificate-policies

Indicates whether a DPE supports the tcg-dice-kp-attestInit
policy.
Affected By●

supports-policy-attest-loc

Booleansupports-certificate-policies

Indicates whether a DPE supports the tcg-dice-kp-attestLoc
policy.
Affected By●

supports-policy-assert-init

Booleansupports-certificate-policies

Indicates whether a DPE supports the tcg-dice-kp-assertInit
policy.
Affected By●

supports-policy-assert-loc

Booleansupports-certificate-policies

Indicates whether a DPE supports the tcg-dice-kp-assertLoc
policy.
Affected By●certificate-policies

Stringsupports-certificate-policies

A comma-separated list of policies that are supported. The predefined tcg-* policies SHOULD NOT be in this list. Each item inthe list MUST name a policy that is well defined. A policy
definition MUST define:

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 51© TCG 2023

DICE Protection Environment

●
●
●
●

The semantics of the policy: what it authorizes
The identifier of the policy (e.g. ASN.1 OID)
Any changes to how a certificate is generated when thispolicy is specified
Any implications to other policies or options

Affected By●
supports-eca-certificates

Booleansupports-certificate-policies

Indicates whether the DeriveChild command supports thecreate-certificate argument set to true, causing an ECA
certificate to be created.
Implications● If false, eca-certificate-format is irrelevant and
SHOULD be omitted
Affected By●

eca-certificate-format

Stringsupports-certificatesNames a certificate format that describes how an intermediate
certificate is generated in association with a CDI that represents aparticular DICE layer or component. This is the certificate that is
generated by DeriveChild when the create-certificate
argument is true. The certificate profile MUST define:● Certificate structure (e.g. X.509, CWT)
● Certificate encoding (e.g. ASN.1 DER, CBOR)● Certificate content (e.g. subject, issuer, policies)● How input data maps to certificate fields● How accumulated certificate information from multiple
layers or components is combined and mapped tocertificate fields● If migration is supported, how migration related certificate
information is combined with accumulated certificate
information, if any, and mapped to certificate fields as partof an ExportSession operation.
Affected By●leaf-certificate-format

Stringsupports-eca-certificatesNames a certificate format that describes how a leaf certificate is
generated in association with a CDI that represents a particular
DICE layer or component. This is the certificate that is generated
by the CertifyKey command. The certificate profile MUST define:● Certificate structure (e.g. X.509, CWT)
● Certificate encoding (e.g. ASN.1 DER, CBOR)● Certificate content (e.g. subject, issuer, policies)

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 52© TCG 2023

DICE Protection Environment

●
●

●
●

How accumulated certificate information from multiple
layers or components is combined and mapped tocertificate fields
For each supported policy for the CertifyKey policies
argument, how the certificate changes when the policy is
specified or omitted, and whether the policy has
implications on other policies
Behavior when no policies are specified, e.g. the policies
argument is omitted when invoking CertifyKey
Whether and how the label argument is used in thecertificate

Affected By●

supports-certificates

Signatures
public-key-format

StringNames a format that describes how public keys are formatted in
DPE arguments. The format MUST define:● Public key structure and encoding● Algorithm identification
Affected By●●

supports-external-key

Booleansupports-certificates
supports-asymmetric-unseal

Indicates whether a DPE supports certifying external public keys.
If supported, a DPE MUST support certification of any type of
public key that can be represented by the public key format.
The key type used by a DPE when deriving asymmetric keys
internally and the corresponding signature and encryption
algorithms are described by the asymmetric-derivation attribute.
This does not change based on the external key type, so theissuer and subject of the certificate may have different key types.
Affected By●

to-be-signed-format

Stringsupports-certificatesNames a format for the Sign command to-be-signed argument.
The format MUST define:● The structure and encoding of the data
● Any processing of the data by the DPE
Affected By●

signature-format

Stringsupports-sign

Names a format for the signature returned by the Sign command.
The format MUST define the structure and encoding of the data

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 53© TCG 2023

DICE Protection Environment

for all types of supported signatures (i.e., symmetric andasymmetric).
Affected By●
supports-symmetric-sign

Booleansupports-sign

Whether a DPE supports generating symmetric signatures, e.g.,
MACs.
Affected By•

supports-sign

Sealing
supports-asymmetric-unseal

BooleanIndicates whether a DPE supports asymmetric unsealing via the
Unseal command and the derivation of public keys for asymmetricsealing.
Implications● If false, supports-sealing-public MUST be false● If true, supports-sealing-public MUST be true
● If false and supports-attestation is also false,
asymmetric-derivation is irrelevant and SHOULD beomitted● If false and supports-certificates is also false, publickey-format is irrelevant and SHOULD be omitted
Affected By●●●

supports-unseal-policy

Booleansupports-sealing
supports-unseal
supports-sealing-public

Indicates whether a DPE supports an unseal policy.
Implications● If false, unseal-policy-format is irrelevant
Affected By●

unseal-policy-format

Stringsupports-sealing

Names a format for the unseal-policy argument for the Seal or
DeriveSealingPublicKey command. The format MUST cover:• The structure and encoding of the data
• The semantics of the data in terms of how a DPE enforces
the policy
Affected By●

supports-unseal-policy

Table 1: DPE profile attributes
DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 54© TCG 2023

DICE Protection Environment

7.3 Sample Profile
Table 2 is an example of a profile. For convenience the definition of named values are provided inline in the table.
The cryptographic algorithms chosen target at least 128 bits of strength. Other profiles can use the names defined inthis section, provided the definition remains as specified here.
Attribute

Description
Generalnametcg.sample.1

inherits

Empty

dpe-spec-version

1

max-message-size

65535

uses-multi-part-messages

False

supports-concurrentoperations

NA
Sessions

supports-encrypted-sessions

True

supports-derived-sessions

True

max-sessions

Unlimitedsession-protocol

tcg.protocol.noise-nk
The protocol tcg.protocol.noise-nk is defined as follows:● Noise_NK_25519_AESGCM_SHA256 for initial handshake andtransport● Noise_NNpsk0_25519_AESGCM_SHA256 for derived handshake● The PSK for the derived handshake is the channel binding token of
the existing session● In both handshakes, the session ID is contained in the responder
payload field● Each session can send up to 2^64 ciphertext messages

supports-session-sync

Truesession-sync-policy

tcg.monotonic-sync
The policy tcg.monotonic-sync is defined as requiring only that the new valueof the counter is greater than or equal to the existing value of the counter.

supports-session-migration

True

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 55© TCG 2023

DICE Protection Environment

session-migration-protocol

tcg.migration.cbor-hpke-curve25519-aesgcm
The scheme “tcg.migration.cbor-hpke-curve25519-aesgcm” is defined asfollows:• The import-identity message contains a single curve25519 public
key formatted per the public-key-format attribute; this key pair isderived from the importing context with no label (see asymmetricderivation)• The exported-data encryption scheme is hybrid encryption using
single-shot PSK mode with:o Algorithms DHKEM(X25519, HKDF-SHA256) + HKDFSHA256 + AES-256-GCM
o A zero-padded 32-byte psk argument if the psk argument toExportSession is less than 32 bytes
o An empty psk_id argumento An empty info argument• When the exporter derives a migration CDI to send to the importer,
the import-identity message, unmodified, is used as input to themigration CDI derivation function• When the importer derives a CDI for the post-migration context, themigration CDI sent by the exporter, unmodified, is used as input to thepost-migration CDI derivation funvtion.
• The exported-data plaintext is a CBOR encoded session-migrationdata structure defined as follows:
session-migration-data = [k1: bytes, ; Noise transport CipherState fields
n1: bytes,
k2: bytes,
n2: bytes,
contexts: { ; Map of context handle to internal context fields* bytes => [cdi: bytes,
certificate-chain: bytes,]},]

Contexts
supports-default-context

True

supports-context-handles

True

max-contexts-per-session

Unlimited

max-context-handle-size

Unlimitedsupports-auto-init

False

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 56© TCG 2023

DICE Protection Environment

supports-simulation

True
Use Cases

supports-attestation

True

supports-sealing

True
Commands 2

supports-get-profile

True

supports-open-session

Truesupports-close-session

Truesupports-sync-session

Truesupports-export-session

Truesupports-import-session

Truesupports-initialize-context

True

supports-certify-key

Truesupports-signTruesupports-seal

Truesupports-unseal

True

supports-sealing-publicTruesupports-rotate-contexthandle

True
Derivation

dice-derivation

tcg.derive.hkdf-sha256
The scheme tcg.derive.hkdf-sha256 is defined as follows:● The algorithm is HKDF with SHA256 as the Hash option● The scheme produces a CDI using HKDF with these arguments:○ length (L): 32○ input key material (IKM): the DICE secret (UDS or CDI)
○ information: the input, encoded for derivation○ salt: ASCII encoded string of “CDI_Attest” for an attestation
CDI or “CDI_Seal” for a sealing CDI

2 Note: mandatory commands not represented in this section.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 57© TCG 2023

DICE Protection Environment

asymmetric-derivation

tcg.derive.hkdf-sha256-curve25519
The scheme tcg.derive.hkdf-sha256-curve25519 is defined as follows:● The derivation algorithm is HKDF with SHA256 as the Hash option● The asymmetric key type is curve25519● Signature scheme is Ed25519● Sealing scheme is hybrid encryption using DHKEM(X25519, HKDFSHA256) + HKDF-SHA256 + AES-256-GCM● The HKDF information argument is a SHA256 hash of the label
argument, if applicable, even if the label is empty. When there is no
notion of label, leave the information empty (zero bytes).
● The derivation scheme produces a 32-byte private key using HKDF
with these arguments:○ length (L): 32○ input key material (IKM): the CDI○ information: the label-based information value○ salt: SHA256 hash of one of the following ASCII encoded
strings, without a null terminator:■ “Key_Pair_25519_Attest” for attestation■ “Key_Pair_25519_Seal” for sealing■ “Key_Pair_25519_ECA” for an embedded CA key■ “Key_Pair_25519_Migration” for a migration import
identity key

symmetric-derivation

tcg.derive.hkdf-sha256-aes128-gcm-siv-hmac-sha256
The scheme tcg.derive.hkdf-sha256-aes256-gcm-hmac-sha256 is defined asfollows:• The derivation algorithm is HKDF with SHA256 as the Hash option• The HKDF information argument is a SHA256 hash of the label
argument, if applicable, even if the label is empty. When there is no
notion of label, information SHALL be empty (zero bytes).
• For sealing, the encryption scheme is AEAD_AES_256_GCM_SIV asdefined in RFC 8452. The 96-bit nonce is randomly generated andprepended to the ciphertext.
• For signing, the scheme is HMAC-SHA256 with a 256-bit key• The sealing and signing keys are derived using these HKDF
arguments:o length (L): 32
o input key material (IKM): the CDI
o information: the label-based information value
o salt: SHA256 hash of one of the following ASCII encoded
strings, without a null terminator:
 “Key_HMAC_Sign” for the signing “Key_AES_Seal” for the sealing

supports-any-label

True

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 58© TCG 2023

DICE Protection Environment

supported-labels

Ignored (supports-any-label, true)

initial-derivation

tcg.init.combined-uds.hkdf-sha256
The scheme tcg.init.combined-uds.hkdf-sha256 is defined as follows:● The DPE combines an internal seed with the seed argument from theclient to derive a UDS that comprises the initial context state● HKDF-SHA256 is used with these arguments:○ length (L): 32○ input key material (IKM): the internal seed value○ information: the seed argument value○ salt: none
● The internal seed meets all requirements for a UDS in terms ofentropy and availability● The seed argument:○ is a raw value: it is not interpreted○ is expected to be no more than 32 bytes in length○ has no security requirements: it can be empty
Input

input-format

tcg.format.tcb-info
The scheme “tcg.format.tcb-info” is defined as follows:● The input is a DiceTcbInfo ASN.1 structure as defined by [3]● The input is encoded using ASN.1 DER for DPE input, derivation, andcertificates● All fields are used for attestation derivation● All fields except FWIDs are used for a sealing derivation

supports-internal-inputs

True

supports-internal-dpe-info

Truesupports-internal-dpe-dice

Trueinternal-dpe-info-type

tcg.basic-dpe-info
The tcg.basic-dpe-info type is defined as follows:● The information is a profile descriptor, exactly as it would be returnedby the GetProfile command in terms of semantics, structure, andencoding● The information appears in its entirety in certificatesinternal-dpe-dice-type

tcg.basic-dpe-dice
The tcg.basic-dpe-dice type is defined as follows:● There are two elements: (1) a CDI and (2) a certificate chain that
represent the current identity of the DPE

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 59© TCG 2023

DICE Protection Environment●●●

internal-inputs

The CDI is an input for an attestation derivation, but does not appear
in the certificate
The certificate chain is not included in a derivation, but appears in thecertificate, if applicable
The semantics, structure, and encoding of the certificate chain are
entirely implementation-dependent and help from the DPE vendor isnecessary to parse/verify it

Empty
Certificates

supports-certificatesTruemax-certificate-size

Unlimited

max-certificate-chain-size

Unlimited

appends-more-certificates

False

supports-certificate-policies

Truesupports-policy-identity-init

Truesupports-policy-identity-loc

Truesupports-policy-attest-init

Truesupports-policy-attest-loc

Truesupports-policy-assert-init

False

supports-policy-assert-loc

False

certificate-policies

Empty

supports-eca-certificatesTrue

eca-certificate-format

tcg.certificate.basic-eca
The profile tcg.certificate.basic-eca is designed to work with the
tcg.format.tcb-info input format and is defined as follows:● An X.509 ECA certificate as defined by [4]● The key usage field MUST contain only keyCertSign● The basic constraints path length should be set to zero if the allowchild-to-derive argument to DeriveChild is false, otherwise omitted● The tcg-dice-kp-eca policy MUST be the only tcg-* policy● One tcg-dice-TcbInfo extension MUST be added using the TcbInfo
from the input-data argument, and one additional tcg-dice-TcbInfo
extension MUST be added for each accumulated TcbInfo from

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 60© TCG 2023

DICE Protection Environment

●

●

●

leaf-certificate-format

previous invocations of DeriveChild with create-certificate set tofalse, if any
If internal inputs were indicated in the internal-inputs argument toDeriveChild, a tcg-dice-DpeInternal extension MUST be added
whose content is a CBOR map with each key being an internalinput-type value (e.g., dpe-info = 1) and each value being thecorresponding data as bytes
If internal inputs have been accumulated, one additional tcg-diceDpeInternal extension MUST be added for each set, i.e., for eachtime DeriveChild was called with internal inputs selected andcreate-certificate set to false.
When importing as part of a migration flow, a tcg-diceDpePostMigration extension MUST be added where the content is a
CBOR array with the first element being the certificate chain sent by
the exporter, and the second element being a signature by thecorresponding private key over the subject public key of the certificate
being generated; both elements are of type ‘bytes’.

tcg.certificate.basic-leaf
The profile tcg.certificate.basic-leaf is designed to work with the
tcg.format.tcb-info input format and is defined as follows:● An X.509 certificate meeting the requirements of [4] according to theCertifyKey policies argument● If multiple policies are specified, the certificate contains the policy OID
for each and MUST meet the requirements for each corresponding
certificate type, e.g. if the tcg-dice-kp-attestLoc policy is set, anattestation certificate is generated● If no policies are selected, the tcg-dice-kp-attestLoc policy is used
as a default● The key usage field MUST contain only digitalSignature● The certificate MUST NOT contain basic constraints● The tcg-dice-kp-eca policy MUST NOT be included● One tcg-dice-TcbInfo extension MUST be added for eachaccumulated TcbInfo from previous invocations of DeriveChild withcreate-certificate set to false, if any● One tcg-dice-DpeInternal extension MUST be added for eachaccumulated set of internal inputs● The label is not used in the certificate● When exporting as part of a migration flow, a tcg-diceDpePreMigration extension MUST be added if the content is theexact identity message from the importer (i.e., the importer’s public
key).
Signatures

public-key-format

tcg.key-format.x509

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 61© TCG 2023

DICE Protection Environment

The format tcg.key-format.x509 uses the X.509 SubjectPublicKeyInfo ASN.1
sequence as defined by [12]. It is encoded using ASN.1 DER.
supports-external-key

True

to-be-signed-format

tcg.tbs-format.raw
The format tcg.tbs-format.raw is defined as opaque raw bytes that will besigned directly using the signing scheme with no additional processing.

signature-format

tcg.signature.raw
The format tcg.signature.raw uses raw signature bytes as defined by thesignature scheme.

supports-symmetric-sign

True
Sealing

supports-asymmetric-unseal

True

supports-unseal-policy

Trueunseal-policy-format

tcg.unseal-policy.tcb-info-layer-svn-clamp
This policy is used to limit which component versions are allowed to unseal.
The policy format is a CBOR map where the keys each identify a component
and the value is an integer value indicating the minimum version of thatcomponent. At the time of unseal, if and only if, for each component thatappears in the map, the current version of the component is greater than orequal to the minimum version that appears in the policy, the unseal will beallowed.
The values of the component identifiers correspond to the ‘layer’ field of the
DiceTcbInfo structure and the value of the versions correspond to the ‘svn’
field of the DiceTcbInfo structure.
Table 2: Sample DPE profile attributes

7.4 Profile Descriptors
A profile descriptor describes all attributes of a profile. Like a profile, a profile descriptor is complete. A profile
descriptor can describe a profile by name or by full attribute list. A profile descriptor MUST include the full attributelist when a profile has no name. A profile descriptor SHOULD include the full attribute list when a profile name is notwell known to all potential clients.
A profile descriptor is encoded as a CBOR map with each attribute assigned a key. If a profile is described by name,the name MUST be the only item in the map. A profile descriptor MAY be tagged using the CBOR tag TBD. When
returned by a GetProfile command a DPE MUST NOT tag the descriptor.

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 62© TCG 2023

DICE Protection Environment

The descriptor format is as follows:
profile-descriptor = {* $attribute-bool => bool,* $attribute-number => uint,* $attribute-string => tstr,? &(inherits: 0) => bytes,* tstr => any}$attribute-string /= &(name: 1)$attribute-number /= &(dpe-spec-version: 2)$attribute-number /= &(max-message-size: 3)$attribute-bool /= &(uses-multi-part-messages: 4)$attribute-bool /= &(supports-concurrent-operations: 5)$attribute-bool /= &(supports-encrypted-sessions: 6)$attribute-bool /= &(supports-derived-sessions: 7)$attribute-number /= &(max-sessions: 8)$attribute-string /= &(session-protocol: 9)$attribute-bool /= &(supports-session-sync: 10)$attribute-string /= &(session-sync-policy: 11)$attribute-bool /= &(supports-session-migration: 12)$attribute-string /= &(session-migration-protocol: 13)$attribute-bool /= &(supports-default-context: 14)$attribute-bool /= &(supports-context-handles: 15)$attribute-number /= &(max-contexts-per-session: 16)$attribute-number /= &(max-context-handle-size: 17)$attribute-bool /= &(supports-auto-init: 18)$attribute-bool /= &(supports-simulation: 19)$attribute-bool /= &(supports-attestation: 20)$attribute-bool /= &(supports-sealing: 21)$attribute-bool /= &(supports-get-profile: 22)

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 63© TCG 2023

DICE Protection Environment$attribute-bool /= &(supports-open-session: 23)$attribute-bool /= &(supports-close-session: 24)$attribute-bool /= &(supports-sync-session: 25)$attribute-bool /= &(supports-export-session: 26)$attribute-bool /= &(supports-import-session: 27)$attribute-bool /= &(supports-init-context: 28)$attribute-bool /= &(supports-certify-key: 29)$attribute-bool /= &(supports-sign: 30)$attribute-bool /= &(supports-seal: 31)$attribute-bool /= &(supports-unseal: 32)$attribute-bool /= &(supports-sealing-public: 33)$attribute-bool /= &(supports-rotate-context-handle: 34)$attribute-string /= &(dice-derivation: 35)$attribute-string /= &(asymmetric-derivation: 36)$attribute-string /= &(symmetric-derivation: 37)$attribute-bool /= &(supports-any-label: 38)$attribute-string /= &(supported-labels: 39)$attribute-string /= &(initial-derivation: 40)$attribute-string /= &(input-format: 41)$attribute-bool /= &(supports-internal-inputs: 42)$attribute-bool /= &(supports-internal-dpe-info: 43)$attribute-bool /= &(supports-internal-dpe-dice: 44)$attribute-string /= &(internal-dpe-info-type: 45)$attribute-string /= &(internal-dpe-dice-type: 46)$attribute-string /= &(internal-inputs: 47)$attribute-bool /= &(supports-certificates: 48)$attribute-number /= &(max-certificate-size: 49)$attribute-number /= &(max-certificate-chain-size: 50)$attribute-bool /= &(appends-more-certificates: 51)$attribute-bool /= &(supports-certificate-policies: 52)

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 64© TCG 2023

DICE Protection Environment$attribute-bool /= &(supports-policy-identity-init: 53)$attribute-bool /= &(supports-policy-identity-loc: 54)$attribute-bool /= &(supports-policy-attest-init: 55)$attribute-bool /= &(supports-policy-attest-loc: 56)$attribute-bool /= &(supports-policy-assert-init: 57)$attribute-bool /= &(supports-policy-assert-loc: 58)$attribute-string /= &(certificate-policies: 59)$attribute-bool /= &(supports-eca-certificates: 60)$attribute-string /= &(eca-certificate-format: 61)$attribute-string /= &(leaf-certificate-format: 62)$attribute-string /= &(public-key-format: 63)$attribute-bool /= &(supports-external-key: 64)$attribute-string /= &(to-be-signed-format: 65)$attribute-string /= &(signature-format: 66)$attribute-bool /= &(supports-symmetric-sign: 67)$attribute-bool /= &(supports-asymmetric-unseal: 68)$attribute-bool /= &(supports-unseal-policy: 69)$attribute-string /= &(unseal-policy-format: 70)

DICE Protection Environment | Version 1.0 | Revision 0.6 | 2/14/2023 | PUBLIC REVIEW

Page 65© TCG 2023