Identities and Root Keys

Overview

This document describes the composition of the Silicon Creator and Silicon Owner cryptographic identities and the Silicon Owner root key derivation scheme. This scheme is based on a symmetric key manager with support for software binding and key versioning.

This document also defines a non-cryptographic Device Identifier to facilitate silicon tracking during manufacturing flows. The Device Identifier is also mixed into the Creator Identity.

Further, this scheme is compatible with the Open DICE profile.

DICE compatible identity flow: Fig1b

Terminology

Boot stages:

  • ROM: Metal ROM, sometimes known as Boot ROM.
  • ROM_EXT: ROM Extension. Stored in flash and signed by the Silicon Creator1.
  • BL0: Bootloader. Signed by the Silicon Owner.
  • Kernel: Signed by the Silicon Owner.

Key manager operations:

  • KM_DERIVE: Key manager one-way function used to derive a new symmetric key.

Memory state operations:

  • CLEAR_BEFORE_NEXT_BOOT_STAGE: Clear key material before moving to the next boot stage.
  • CLEAR_AFTER_USE: Clear immediately after use.

Device Identifier

The device identifier is a globally unique 256b value provisioned on each device’s OTP memory in early manufacturing stages (e.g. wafer test). It is used to facilitate device tracking during manufacturing and provisioning. This value is also used as a component in the generation of the device’s Silicon Creator Identity, a cryptographically unique identity.

The 256b value is split into two halves. The first contains hardware origin information following a global standard format, while the second one is defined by the device SKU provisioning requirements.

128b Hardware origin information

No. Bits Description
16 Silicon Creator identifier. Assigned by the OpenTitan project.
16 Product identifier. Assigned by the Silicon Creator. Used to identify a class of devices.
64 Individual device identification number. Assigned by the Silicon Creator. For example, the wafer lot number and die's X,Y coordinates may be encoded here to simplify manufacturing tracking. Another option is to use a non cryptographic hash function with collision checks to guarantee global uniqueness.
32 CRC-32 IEEE 802.3. covering the previous bytes.

128b SKU specific device information

The device provisioner information varies for each provisioning use case. Each use case must have a specification defining the allocation of these bits. See the UICC EID Specification as an example.

CreatorRootKey

The following sequence describes the creation of the CreatorRootKey. All inputs into the key manager can be locked down during ROM execution.

The size of the inputs is dependent on the security strength and masking configuration of the implementation. The input concatenation function must be injective. This can be achieved by fixing the width of all the operands.

Note that CreatorRootKey refers to a pair of keys, one used for sealing and the other for attestation purposes. The chain of attestation and sealing keys deviate from each other with the use of SW binding values.

CreatorRootKey = KM_DERIVE(RootKey,
    HardwareRevisionSecret | RomHash | HealthStateMeasurement |
    DeviceIdentifier | SoftwareBindingValue)

Name Encoding Description
RootKey OTP Device root key. Provisioned at manufacturing time by the Silicon Creator.

Hidden from software once personalization is complete.

HardwareRevisionSecret Gates Encoded in gates. Provisioned by Silicon Creator before tapeout. Hidden from software.
RomHash Computed by ROM controller SHA-3-256 hash of the ROM image.
Health State Measurement Computed by Lifecycle controller Comprises the following measurements:
  • Device life cycle state.
  • Debug mode state.

The debug mode shall be used as well if there are multiple debug configurations supported by a single life cycle state.

DeviceIdentifier OTP Provisioned at manufacturing time. Readable from software and JTAG interface.
SoftwareBindingValue SW register For the attestation chain, this register is populated with the hash of the OTP image. Therefore, changes in the OTP configuration will trigger an update of the CreatorIdentity for attestation.

For the sealing chain, this register uses a binding tag stored in the ROM_EXT manifest. This is to retain the same CreatorIdentity across validated updates of the ROM_EXT. This allows sealing keys to be persistent across ROM_EXT updates.

The CreatorRootKey can be used to generate the CreatorIdentity and the OwnerIntermediateKey described in the following sections.

CreatorIdentity

The CreatorIdentity is an asymmetric key derived from the CreatorRootKey. It is used as a cryptographic identifier bound to the device and the Silicon Creator. It is used to attest to the authenticity of the physical device and the ROM and OTP configuration.

CreatorIdentity becomes part of the UDS certificate and it is generated as follows:

CreatorIdentitySeed =
  KM_DERIVE(CreatorRootKey, OTBNDiversificationConstant | IdentityDiversificationConstant)

// ASYM_KDF is a KDF function compliant to the Asymmetric Key
// requirements defined in the Attestation specification document.
CreatorIdentity_Private = ASYM_KDF(CreatorIdentitySeed)
CLEAR_BEFORE_NEXT_BOOT_STAGE(CreatorIdentitySeed, CreatorIdentity_Private)

Name Encoding Description
OTBNDiversificationConstant Gates A constant defined in gates. Used to diversify sideloaded values to OTBN.

Hidden from software.

IdentityDiversificationConstant SW Register A constant public diversification value fixed during provisioning.
CreatorIdentitySeed SW Register Output Seed used to generate the CreatorIdentity asymmetric key.

The CreatorIdentitySeed and the private portion of the Creator Identity shall be cleared before the ROM Extension hands over execution to the Silicon Owner first boot stage.

OwnerIntermediateKey

The OwnerIntermediateKey is used as an intermediate virtual entity between the SiliconCreator and SiliconOwner. It is used to establish a cryptographic link to CreatorSeed as well as the integrity of ROM_EXT image.

The OwnerIntermediateKey is generated as follows:

OwnerIntermediateKey =
   KM_DERIVE(CreatorRootKey, CreatorSeed | SoftwareBindingValue)

Name Encoding Description
id="creator-secret"CreatorSeed Flash Additional diversification key stored in flash. Provisioned at manufacturing time by the Silicon Creator.

Hidden from software once provisioned.

SoftwareBindingValue SW Register
Lockable Input
For the attestation chain, this register is populated with ROM_EXT measurement.

For the sealing chain, this register uses a diversification value determined by ROM_EXT.

OwnerIntermediateIdentity

The OwnerIntermediateIdentity is associated with CDI_0 in the DICE attestation chain.

OwnerIntermediateIdentitySeed =
  KM_DERIVE(OwnerIntermediateKey, OTBNDiversificationConstant)

// ASYM_KDF is a KDF function compliant to the Asymmetric Key
// requirements defined in the Attestation specification document.
OwnerIntermediateIdentity_Private = ASYM_KDF(OwnerIntermediateIdentitySeed)
CLEAR_BEFORE_NEXT_BOOT_STAGE(OwnerIntermediateIdentitySeed, OwnerIntermediateIdentity_Private)

Name Encoding Description
OwnerIntermediateIdentitySeed SW Register Output Seed used to generate the OwnerIntermediateIdentity asymmetric key.
OTBNDiversificationConstant Gates A constant defined in gates. Used to diversify sideloaded values to OTBN.

Hidden from software.

The OwnerIntermediateIdentitySeed and the private portion of the OwnerIntermediateIdentity shall be cleared before the bootloader (BL0) hands over execution to the kernel.

OwnerKey

The OwnerKey is the key diversified with OwnerSeed and it is associated with the CDI_1 certificate. It also provides a cryptographic link to the Owner FW image and Owner Configuration Block.

The OwnerKey is generated as follows:

OwnerKey =
   KM_DERIVE(OwnerIntermediateKey, OwnerSeed | SoftwareBindingValue)

Name Encoding Description
id="creator-secret"OwnerSeed Flash Additional diversification key stored in flash. Provisioned during ownership transfer.

Hidden from software once provisioned.

SoftwareBindingValue SW Register
Lockable Input
For the attestation chain, this register is populated with owner-specific measurements. This measurement is the combination of the Owner Configuration Block and Owner FW.

For the sealing chain, this register uses a diversification value determined by owner. This diversification value is the combination of the application key domain (i.e., which key, from {prod,dev,test}, is used to verify the ROM_EXT to Owner firmware jump), and a diversifier specified by the owner configuration.

OwnerIdentity

The OwnerIdentity is used as a cryptographic identifier bound to the device and the SiliconOwner. It is used in Attestation flows.

OwnerIdentitySeed =
  KM_DERIVE(OwnerKey, OTBNDiversificationConstant)

// ASYM_KDF is a KDF function compliant to the Asymmetric Key
// requirements defined in the Attestation specification document.
OwnerIdentity_Private = ASYM_KDF(OwnerIdentitySeed)
CLEAR_BEFORE_NEXT_BOOT_STAGE(OwnerIdentitySeed, OwnerIdentity_Private)

Name Encoding Description
OTBNDiversificationConstant Gates A constant defined in gates. Used to diversify sideloaded values to OTBN.

Hidden from software.

OwnerIdentitySeed SW Register Output Seed used to generate the OwnerIdentity asymmetric key.

The OwnerIdentitySeed and the private portion of the OwnerIdentity shall be cleared after use by the Owner firmware.

Owner Root Key and Versioned Keys

The key manager supports the generation of versioned keys with lineage to the OwnerRootKey for software consumption and sideload operations.

OwnerRootKey =
   KM_DERIVE(OwnerIntermediateKey, OwnerSeed | SoftwareBindingValue)

VersionedKey = KM_DERIVE(OwnerRootKey,
    KeyVersion | KeyID | Salt | SoftwareExportConstant)

The concatenation function must be injective. This can be achieved by fixing the width of all the operands.

Name Encoding Description
OwnerSeed Flash Used as a diversification constant with acceptable entropy. Provisioned at Ownership Transfer time by the Silicon Creator.

The OwnerSeed has different visibility options depending on the level of isolation provided in hardware:

  • The value should be hidden from software after provisioning.
  • The value is visible to ROM and ROM Extension, but hidden from all Silicon Owner software. The ROM Extension implements this property.
OwnerRootKey Internal RAM Owner Root Key bound to the software stack.

Visibility: Hidden from software.

SoftwareBindingValue SW Register
Lockable Input
Software binding value configured during secure boot. See Software Binding for more details.
KeyVersion SW Register Input Key version. The value provided by software may be mixed with a gate constant before key derivation steps.

The value should also pass the version comparison criteria configured during secure boot. See Key Versioning for more details.

KeyID SW Register Input Key identifier. Used to derive a VersionedKey from OwnerRootKey. Processing of this field should provide countermeasures against key recovery attacks.
SoftwareExportConstant Gates The SoftwareExportConstant is a diversification constant with acceptable entropy provisioned in gates. It is used to mitigate key recovery attacks on software inputs.

Visibility: Hidden from software.

Salt SW Register Input Salt input controlled by software.
VersionedKey SW Register Output Output key derived from OwnerRootKey and KeyID. Support for sideloading may require additional support in the key manager, otherwise the software will be in charge of enforcing isolation.

Software Binding

Software binding is used to ensure that the key derivation scheme is only reproducible for a trusted software configuration. This is achieved by having the secure boot implementation configure runtime-irrevocable binding tags in the key derivation scheme. Such tags are usually delivered inside the signed manifest of each code partition.

OpenTitan shall support software binding for at least two Silicon Owner code stages (e.g. bootloader and kernel). It is expected that the kernel will implement binding with the application layer exclusively in software.

Each key manager binding stage shall provide at least 128b of data.

Key Versioning

Key versioning is the mechanism by which software implements key rotation triggered by security updates. Since there may be more than one updateable code partition in the system, the key versioning scheme has to implement at least 8 32b version comparators with lockable controls, which will be configured as part of the secure boot process.

Configuration

The next figure shows an example on how to configure the maximum key version constraints in the key manager. The ROM_EXT software verifies the BL0 manifest, and configures one of the maximum key version registers with the maximum allowable version stored in the BL0 manifest. In the same way, the BL0 software verifies the Kernel manifest and configures a separate key version register. The software implementation is free to allocate more than one maximum key version register per boot stage.

Fig2
Figure: Maximum allowable versions configured as part of the secure boot

Note: The diagram is overly simplified and does not take into account security hardening.

Key Consumption

Secrets wrapped with versioned keys shall have additional metadata including Key Version, Key ID and salt information.

The versioned key generation is gated on the version comparison check enforced by the key manager implementation. The following set of operations will only succeed if the key version set by software is valid.

Fig3
Figure: Key version is set during key configuration

Note: The diagram is overly simplified and does not take into account security hardening.

Recommendations for Programming Model Abstraction

High Level Key Manager States

The hardware may opt to implement a software interface with higher level one-way step functions to advance the internal state of the key manager. The following are the minimum set of steps required:

  1. CreatorRootKey
  2. OwnerIntermediateKey
  3. OwnerRootKey
Fig4
Figure: Minimum set of high level one-way step functions.

Instantiations of the key manager can be conditioned to start at the current internal state of the key manager, for example, kernel-level instantiations may always start at the OwnerRootKey level, assuming the previous boot stages advanced the state of the key manager.

Versioned Keys

The following high level software interface may be supported by hardware to generate versioned keys. The hardware may opt to implement versioned key functionality at each of the high level key manager states.

/**
 * Generate versioned key for a given |key_id|.
 *
 * Generates a versioned key rooted in the current state of the
 * key manager. Requires the key manager to be in one of the
 * following states:
 *    CreatorRootKey, OwnerIntermediateKey, OwnerRootKey
 *
 * @param kmgr Key Manager state data.
 * @param key_version Key version. Each version 32b word shall
 *  be less than its associated max version value. Requires the
 *  maximum version registers to be configured before calling this
 *  function
 * @param key_id Key identifier.
 * @param versioned_key Key output.
 * @return true if the function was successful, false otherwise.
 */
bool keymgr_generate_vk(const kmgr_t *kmgr,
                        const uint32_t key_version[8],
                        const uint32_t key_id[8]
                        uint32_t *versioned_key[8]);

Requirements

KM_DERIVE function and security strength claims

The Key Manager derive function should support at least 256b of security strength.

Note on standards: The key derivation function (KM_DERIVE), when instantiated with a Pseudorandom Function (PRF), shall be compatible with NIST SP 800-133r22 section 6.3: Symmetric Keys Produced by Combining (Multiple) Keys and Other Data. This imposes provisioning requirements for the root keys, which are covered in the Provisioning specification.

Security strength for the KM_DERIVE function based on a Pseudorandom Function (PRF)3:

PRF Security Strength Notes
KMAC256 256 1. NIST 800-108, which focuses on PRF key derivation functions, lists KMAC as a primitive.

Key recovery attacks on user inputs

The hardware shall support countermeasures against key recovery attacks for all software controlled inputs.

Version comparison registers

The hardware shall support at least 8 32b write-lockable version comparison registers to provide key versioning functionality.

Software-Hardware binding registers

The hardware shall support at least 256b of software write-lockable registers to implement software-hardware key manager binding as part of the secure boot implementation.

Support for key IDs (key handles or salt value)

The hardware shall support versioned key derivations for software provided key IDs. A key ID is defined as a 256b value used as a key handle.

Root secrets isolation from software

The hardware shall isolate the RootKey and other provisioned secrets from software after completion of personalization at manufacturing time.

Isolation between boot stages

Later boot stages shall have no access to secrets maintained by previous boot stages.

Lockable inputs

The software shall configure runtime lockable inputs as part of the secure boot implementation to fix the construction of identities and root keys in the key manager.

Integrity and confidentiality of secret values

Hardware secrets stored in OTP and flash shall be scrambled to increase the difficulty of physical attacks.

Silicon Creator identity invalidation (optional)

ROM Extension updates may invalidate the Silicon Owner and Silicon Creator identities as well as the root keys.

Fallback support

The implementation should consider a software based backup mechanism to mitigate security and/or certification issues with the main implementation. The backup mechanism shall not rely on secrets from the main implementation.

Notes

1

The Silicon Creator is the logical entity, or logical collection of entities that manufactures, packages, tests and provisions the chip with its first identity.

3

Security strengths for PRF functions as documented in: Recommendation for Key-Derivation Methods in Key-Establishment Schemes (NIST 800-56Cr1)