Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT)

Revision 2.1

Version 0.1

Introduction

Caliptra¹ was originally created as part of the Open Compute Project (OCP). The major revisions of the Caliptra specifications are published at OCP. The evolving source code and documentation for Caliptra are in this repository within the CHIPS Alliance Project, a Series of LF Projects, LLC.

The objective of Caliptra is to define core RoT capabilities that must be implemented in the System on Chip (SoC) or ASIC of any device in a cloud platform. The collection of these RoT capabilities is referred to as the Silicon RoT Services (Silicon RoT).

Background

The overall security posture of silicon devices depends on establishing a core root of trust (RoT) and chain of trust. The core root of trust and chain of trust must attest to the integrity of configuration and mutable code.

Traditional RoT architectures offer many intrinsic security services and hosted security applications on a trusted execution environment (TEE). These architectures include (but are not limited to) hardware capabilities (cryptographic and microprocessor), ROM, firmware, and API infrastructure. These solutions are instantiated in discrete or integrated forms in various platform and component architectures.

Some of these solutions are either proprietary or aligned to specific parts of industry standards, consortium, or association specifications; for example, National Institutes of Standards and Technology (NIST), Open Compute Project (OCP), Trusted Computing Group (TCG), Distributed Management Task Force (DMTF), Institute of Electrical and Electronics Engineers (IEEE), etc. These solutions may be certified to conform to various standards; for example, the NIST cryptographic algorithm Validation program (CAVP).

Establishing a consistent RoT on very different hardware configurations while maintaining configuration and deployment flexibility is challenging. There is no uniform configuration across Cloud Service Providers (CSPs). For example, a system with host processors has very different firmware security measures when compared to a system without head-nodes or host processors.

The OCP Security WG specifications are making progress toward establishing the platform and peripheral security architecture recommendations that are necessary to attain the desired consistency in platform security orchestration.

Silicon RoT goals

To drive agility of specification definition and to maximize applicability, the scope of Caliptra is deliberately minimalistic. This minimalist approach drives industry alignment, consistency, and faster adoption of foundational device security primitives. A well and narrowly defined specification maximizes architectural composability; reusability across CSPs, products, and vendors; and feasibility of open sourcing.

Enhancements and advanced use cases and applications are outside the scope of this specification and may be developed in the form of a roadmap for the Silicon RoT and community engagement.

Caliptra 2.0 defines a design standard for a Silicon internal RoT baseline. This standard satisfies a Root of Trust for Measurement (RTM) and cryptographic services for the SoC. The SoC must measure the code and configuration it boots into Caliptra in this configuration. Caliptra must store these measurements and report them with signed attestations rooted in unique per-asset cryptographic entropy. As such, Caliptra serves as a Root of Trust for Identity (RTI) for the SoC.

The Caliptra Subsystem further standardizes SoC protection mechanisms with Root of Trust for Update (RTU) and Root of Trust for Recovery (RTRec). The open-source implementation of Caliptra drives transparency and consistency into the root of trust mechanisms that anchor foundational security services for the SoC.

Within this scope, the goals for a Caliptra 2.0 specification with subsystem include:

• Definition and design of the standard silicon internal RoT baseline:
  • Reference functional specification:
    • Scope including RTM, RTU and RTRec capabilities
    • Control over SoC non-volatile state, including per asset entropy
  • Reference APIs:
    • Attestation APIs
    • Authentication APIs
    • Recovery APIs
    • Internal SoC Cryptographic services
  • Reference implementation
  • Open source reference (including RTL and firmware reference code):
    • For implementation consistency, using open source dynamics to avoid pitfalls and common mistakes
    • For accelerated adoption, so that future products can leverage existing designs and avoid having to start the design process from scratch
    • For greater transparency, to avoid fragmentation in the implementation space
  • Firmware and RTL logical design are open, managed by consortium
• Consistency - across the industry in the internal RoT (iRoT) architecture and implementation:
  • DICE identity, measurement, and recovery
• The silicon iRoT scope includes all datacenter-focused server class SoC / ASIC (datacenter focused) devices (SSD - DC, NIC, CPU, GPU - DC):
  • Critical priority are devices with the ability to handle user plain text data
    • Top priority are CPU SoCs
    • Other examples include SmartNIC and accelerators
  • 2.0 scope includes further datacenter devices such as
    • SSD, HDD, BMC, DIMM, PSU, CPLD etc.

Note that Caliptra reference code (including RTL and firmware) is intended to be adopted as-is, without modification.

Explicitly out of scope is how silicon integration into backend work is performed such as:

• Foundry IP integration
• Physical design countermeasures
• Analog IPs
• Post manufacture test and initialization (OSAT)
• Certification

Use cases

The Silicon RoT use cases can be supported through the adoption of specific industry standards, and association and consortium specifications. For more information, see specific documents in References.

In this version of the specification, the desired capabilities address the basics of supply chain security use cases.

Supply chain security

• Mutable code integrity: The objective is to prove the device is running genuine firmware such that the device manufacturer can vouch for its authenticity and integrity, and the device owner can ensure only authorized updates are applied to the device. This flow is aligned with Reference 9 and can be achieved with dual signature verification of equal imposition.
• Configuration and lifecycle management: The objective is to allow the platform owner to securely configure the RoT capabilities, and to enable and authorize lifecycle state transitions of the SoC.

DICE Protection Environment

Caliptra implements the DICE Protection Environment (DPE) API, allowing it to derive and wield a DICE identity on behalf of other elements within the SoC. Use cases for this API include serving as a signing oracle for a Security Protocol and Data Model (SPDM) responder that is executing in a SoC application processor (in passive mode) or in the Manufacturer Control Unit (MCU in subsystem mode), as well as authentication to a discrete TPM device.

Industry standards and specifications

This specification follows the industry standards and specifications listed in References.

NIST SP 800-193 Platform Firmware Resiliency

Per Reference 1, RoT subsystems are required to fulfill three principles: protection, detection and recovery. The associated RoT services are referred to as:

• The Root of Trust for Update (RTU) is responsible for authenticating firmware updates and critical data changes to support platform protection capabilities.
• The Root of Trust for Detection (RTD) is responsible for firmware and critical data corruption detection capabilities.
• The Root of Trust for Recovery (RTRec) is responsible for recovery of firmware and critical data when corruption is detected, or when instructed by an administrator.

These RoT services can be hosted by a complex RoT as a whole or these services can be spread across one or more components within a platform. This determination has a basis in physical risk. Physical adversaries with reasonable skill can bypass a discrete RoT’s detection capabilities, for example, with SPI interposers.

However, a RoT embedded within a SoC or ASIC represents a much higher detection bar for a physical adversary to defeat. For this reason in Caliptra 2.0 Core, the cryptographic module shall deliver the Detection capability for itself while providing Measurement and Identity services for the rest of the SoC. The Measurement and Identity services that Caliptra provides can be used by the SoC to create Detection capability for the measured firmware and configuration data.

The objectives of Caliptra Core are minimalistic scope and maximum applicability. To that end, Update and Recovery are decoupled from Caliptra Core and are expected to be provided either by Caliptra 2.0 Subsystem or are expected to be provided by an external RoT subsystem, such as a discrete RoT board element on a datacenter platform (passive mode). Because a physical adversary can trivially nullify any recovery or update capabilities, no matter where implemented, decoupling represents no regression in a security posture, while enabling simplicity and applicability for the internal SoC Silicon RoT.

Detection of corrupted critical code and data (configuration) requires strong end to end cryptographic integrity verification. To meet the RTD requirements, Silicon RoT shall:

• Cryptographically verify & measure its code and configuration
• Sign these measurements with a unique attestation key
• Report measurements to a host or external entity, which can further verify the authenticity and integrity of the device (also known as attestation)
• Recovery follows Open Compute Project Secure Recovery flows and Streaming Boot. (FIXME: Add links to released specs; they are in draft mode now)

Measurements and Verification include Code and Configuration. Configuration includes invasive capabilities that impact the user service level agreement (SLA) on confidentiality; for example, the enablement of debug capabilities that grant an operator access to raw, unencrypted registers for any tenant context. In order to measure and attest configuration, the Silicon RoT must be in control of the configuration.

As an extension to controlling configuration, the Silicon RoT must control the security states (for more information, see Caliptra Security States). Certain security states by design grant full invasive capabilities to an external operator, for debug or field analysis.

Measurements must be uniquely bound to the device and its manufacturer at a minimum. This establishes the need for Identity services in the Silicon RoT, which serve as the basis for key derivation and attestation authenticity.

For further details about how Caliptra addresses NIST SP 800-193, see Device Resilience.

Trusted Computing Group (TCG) DICE Attestation

In accordance with OCP Attestation specification Reference 8, devices must have a cryptographic identity for the endorsement of attestation quotes. The RTM implementation follows TCG DICE (for information, see Reference 4, Reference 5, and Reference 6). One of the benefits of TCG DICE device identities is having renewable security. This renewability complements ownership transfer and circular economy. The new owner is not burdened with the identity of the previous owner, nor is the new owner burdened with trusting an irrevocable hardware identity certificate. This benefits the transferee, as their identities can be revoked through standard PKI mechanisms. DICE based certificates are fully compatible with Public Key Infrastructure (PKI), including full lifecycle management and PKI Certificate Revocation List (CRL).

Operational security during the manufacturing process is critical, to ensure the DICE entropy is securely initialized, certified, and registered. Operational security avoids any pilfering of this asset by eavesdroppers. Operational security is outside the scope of this specification.

Threat model

The Caliptra threat model describes attacker profiles, assets and attack surfaces, and paths to these assets based on attacker profiles. Subsections provide further details.

Threat scenarios as comprehended by assets and possible attack paths are as complete as possible but focus on the worst case scenarios. Thus not every attack path to asset is captured in this threat model.

Attacker profiles

An attacker profile is based on factors like the tools that are accessible to the attacker, the level of access to the target of evaluation, and expertise of the attacker to use these methods. These factors are described in the following tables.

Table 1: Tools accessible to attacker

Table 2: Type of access to level of access

Table 3: Definition of expertise (JIL)

Types of attacks

Physical attacks

A physical attacker has full access to the electrical and physical components. This includes access to interfaces, connectors, and ports of the SoC/ASIC in which Caliptra is integrated without restriction.

Invasive attacks that involve depackaging or delayering of the SoC/ASIC are out-of-scope. Non-invasive attacks are in scope.

• Fault injection attacks
  • Counter measurements - as strong recommendation
• Power and electromagnetic analysis attacks
  • Counter measurements - as strong recommendation

Table 4: Attack types

Table 5: Logical attacks

Trust boundaries

The following figure shows trust boundaries for the discussion of threat modeling. SoCs based on Caliptra are expected to have Caliptra as silicon RoT, and are expected to have a platform or SoC security engine to orchestrate SoC security needs for the rest of the SoC.

Trust levels of Caliptra and the SoC security engine are not hierarchical. These two entities are responsible for different security aspects of the chip.

Figure 1: Caliptra trust boundaries

Caliptra interactions

The Caliptra Core blocks consume the Tc and Tcw trust level components. This boundary includes crypto accelerators, hardware key sequencer, key vault, Caliptra microcontroller, ROM, and subsystem interconnects. The Caliptra Core provides deterministic Caliptra behavior. Caliptra Core interacts with components in the Tse and Trs trust levels; while Caliptra Subsystem abosrbs the Tse functions.

Caliptra assets and threats

Assets are defined to be secrets or abilities that must be protected by an owner or user of the asset. Ownership means that the owner has the responsibility to protect these assets and must only make them available based on a defined mechanism while protecting all other assets.

An example of when an owner must protect assets is moving from secure mode to insecure mode. Another example is moving from one owner to another. Before moving through these transitions, the owner must ensure all assets are removed, disabled, or protected based on how the use case is defined.

Table 6: Assets

High level architecture

The following figure shows the basic high-level blocks of Caliptra.

Figure 2: Caliptra high level blocks

See the hardware section for a detailed discussion.

From Caliptra 2.x onwards, Caliptra introduces two modes of operation. Passive mode which was supported in 1.x architecture and Subsystem mode. Fundamental difference between passive mode and subsystem mode is that in the subsystem mode Caliptra is the RoT for the SoC and provides streaming boot, secure boot and attestation. In Subsystem mode, Caliptra also provides various crypto API services such as encryption/decryption of SoC FWs, Key releases, Key wraps, hashing etc. to name a few. Please see Caliptra subsystem mode Crypto API section for more details (FIXME: section name & details).

Passive Mode High Level Flow

Caliptra is among the first microcontrollers taken out of reset by the power-on reset logic. Caliptra coordinates the start of the firmware chain-of-trust with the immutable component of the SoC ROM. After the Caliptra ROM completes initialization, it provides a "stash measurement" API and callback signals for the SoC ROM (passive mode) to proceed with the boot process. Caliptra ROM supports stashing of at most eight measurements prior to the boot of Caliptra RT firmware. The SoC then may choose to boot Caliptra firmware. Any security-sensitive code or configuration loaded by the SoC prior to Caliptra firmware boot must be stashed within Caliptra. If the SoC exceeds Caliptra ROM's measurement stash capacity, attestation must be disabled until the next cold reset. The boot process is as follows:

1. Hardware executes SoC power-on reset logic. This logic starts the execution of SoC ROM and Caliptra ROM.
2. SoC ROM waits for the ready_for_fw signal from Caliptra ROM.
3. SoC ROM fetches the FMC.
   1. If the FMC is Caliptra firmware:
      1. SoC ROM loads the Caliptra firmware into the Caliptra mailbox and issues the Caliptra "firmware load" command.
      2. Caliptra ROM authenticates, measures, and starts the Caliptra firmware.
   2. If the FMC is not Caliptra firmware:
      1. SoC ROM measures that firmware as the SoC FMC, and issues the Caliptra "stash measurement" command prior to executing SoC FMC.
4. SoC ROM executes SoC FMC.
5. SoC FMC continues the boot process, forming a boot firmware chain-of-trust: each firmware fetches, authenticates, measures, and executes the next firmware needed to establish the device operating environment. Each firmware deposits the next firmware's measurements into Caliptra prior to execution. The exception is Caliptra's firmware: SoC firmware delegates the measurement and execution of Caliptra's firmware to Caliptra ROM.
6. Upon eventual initialization, Caliptra firmware presents attestation APIs using the deposited measurements.

See Error Reporting and Handling for details about Caliptra and SoC firmware load and verification error handling.

Figure 3: Passive Caliptra boot flow

Subsystem Mode Boot Flow

MCU (Manufacturer Control Unit), that is holds platform & SoC specific FW and Caliptra are among the first microcontrollers taken out of reset by the power-on reset logic. Caliptra is responsible for the start of the firmware chain-of-trust with the immutable component of the MCU ROM. After the Caliptra ROM completes initialization, it provides a "stash measurement" API and callback signals for MCU ROM (subsystem mode) to proceed with the boot process. Caliptra ROM supports stashing of at most eight measurements prior to the boot of Caliptra RT firmware. Then Caliptra FW is loaded through OCP streaming boot flow. The OCP streaming boot flow uses an I3C controller with commands defined by the OCP Recovery specification. This controller constitutes the streaming boot interface in the boot flow below. Any security-sensitive code (eg. PLL programming) or configuration (eg. Fuse based Patching) loaded by the MCU prior to Caliptra firmware boot must be stashed within Caliptra. If the MCU exceeds Caliptra ROM's measurement stash capacity, attestation must be disabled until the next cold reset.

Note: This is extremely high level flow, please see the Subsystem Mode Section below for next level specifics.

The high level boot process is as follows:

1. Hardware executes SoC power-on reset logic. This logic starts the execution of MCU ROM and Caliptra ROM.
2. Streaming boot interface is gated until ready for recovery is written into streaming boot interface registers from Caliptra ROM. This happens at the same time as passive mode's ready_for_fw signal.
3. Caliptra firmware is streamed & then pulled into Caliptra MB SRAM through the OCP streaming boot interface by a platform component (typically a BMC-like component). 1. Caliptra ROM authenticates, measures, and activates the Caliptra firmware.
4. SoC manifest is streamed next via the streaming boot interface, which Caliptra authenticates & measures
5. This is followed by MCU RT FW through the streaming boot protocol which Caliptra routes to MCU SRAM, authorizes and activates MCU to execute it.
6. MCU RT FW will go through MCTP enumeration and fetch the remaining SoC blobs (FW, data etc.) using DSP0267 PLDM for Firmware Update over MCTP and uses Caliptra to authorize each of them. Note that MCU may also retrieve some non-FW blobs from a NVM while using Caliptra to perform security operations like integrity verification, decryption etc.

FIXME: ADD a pic

Identity

Caliptra must provide its runtime (RT) code with a cryptographic identity in accordance with the TCG DICE specification. This identity must be rooted in ROM, and provides an attestation over the security state of the RTM as well as the code that the RTM booted.

To ensure quantum-resistant RTM, each certificate includes a dual signatures based on ECC Secp384r1 and PQC MLDSA-87.

Figure 4: DICE Cert/Key generation

UDS

A combination of mask ROM and HW macros must implement the DICE key derivation and power-on latch, hiding the UDS seed and only making the CDI-derived signing key 'handle' visible to ROM. Real UDS will only be calculated during the cold boot in hardware, used for CDI derivation and immediately gets cleared.

The Caliptra UDS seed is stored as ciphertext in fuses, deobfuscated only on cold boot using a obfuscation key² known only to the Caliptra Hardware. Once read by Caliptra HW at boot, the unobfuscated UDS is then used to derive the IDevID identity and immediately cleared by hardware.

IDevID key

Caliptra's IDevID key is a hardware identity generated by Caliptra ROM during manufacturing. This key "handle" must be solely wielded by Caliptra ROM, and shall never be exposed externally at any phase of the Caliptra lifecycle. IDevID is used to endorse LDevID. Caliptra supports both classic and post-quantum algorithms for endorsement based on ECDSA Secp384r1 and PQC MLDSA-87, respectively. The IDevID certificate is endorsed by the vendor’s provisioning CA (pCA) that is implemented via a HSM appliance connected to High Volume Manufacturing (HVM) flows (see provisioning CA in Reference 8).

See Provisioning IDevID During Manufacturing for further details on IDevID provisioning.

LDevID key

Caliptra shall support field-programmable entropy, which factors into the device's LDevID identity. The LDevID certificate is endorsed by IDevID and in turn endorses the FMC alias key. Caliptra supports both classic and post-quantum algorithms for endorsement based on ECDSA Secp384r1 and PQC MLDSA-87, respectively.

Caliptra's field-programmable entropy shall consist of two 16-byte slots. All slots are used to derive LDevID. An owner may decide to program as few or as many slots as they wish. Upon programming new entropy, on the next reset the device begins wielding its fresh LDevID. Owners need to validate the new LDevID by using IDevID.

Commentary: threat analysis

An ideal IDevID has the following properties:

• Cannot be altered by entities besides Caliptra in manufacturing security state.
• Cannot be impersonated by entities that are not a Caliptra instatiation for that device class.
• Cannot be cloned to additional devices of the same class.
• Private component cannot be extracted from Caliptra.

Caliptra 2.0 provides integrity over IDevID Certificate Signing Requests (CSRs).

Caliptra 1.0 alone does not fully address these properties. For example, a person-in-the-middle supply chain adversary could impersonate Caliptra by submitting its own IDevID CSR to the pCA. Vendors should threat model the IDevID generation and endorsement flows for their SoC. Threat actors to consider are the following:

• Components involved in UDS injection flows: can they inject the same obfuscated UDS to multiple devices, or to devices of different classes? Can they wield the obfuscation key to leak the UDS?
• Components servicing the connectivity between the Caliptra instantiation and the HSM applicance performing IDevID endorsement: can they alter or impersonate Caliptra's IDevID CSR?
• Physical attackers: see Physical Attack Countermeasures.

Vendors have incentives to mitigate these threats. The vendor identity chain secures RMA and confidential computing workflows.

Ultimately though, IDevID is not renewable. Renewable security, often referred to as trusted computing base recovery, is a base design principle in Caliptra. Therefore, it is a design goal to reduce the operational dependency on IDevID. Field entropy and LDevID satisfy this need.

Field entropy is a limited resource, consisting of only two 16-byte slots of one-time programmable fuses. It is not generally expected that a second-hand purchaser can program all or even any of these slots. Caliptra's DICE identity remains usable even after all field entropy slots are programmed, so this feature does not preclude a circular economy. Field entropy is a feature primarily designed for users who purchase new parts.

Field entropy and LDevID are intended to hedge against attackers with the following abilities:

• Can obtain UDS before the part first arrives at the owner's facility.
• Can wield that stolen UDS to impersonate the part after it is deployed within the owner's facility. The attacker can derive and wield IDevID to mint an attacker-controlled DICE hierarchy; for example, LDevID, FMC alias key, or Runtime firmware alias key.
• Cannot fully impersonate the part during initial onboarding within the owner's facility.
• Cannot extract field entropy after initial onboarding.

During initial onboarding, the owner is expected to instruct the device to program field entropy. Upon device reset, this results in a fresh LDevID. Attackers that have previously obtained UDS are not able to derive this LDevID. The owner is expected to register the new LDevID and subsequently validate all future DICE keys for the device against that LDevID.

When registering LDevID during device onboarding, the owner is expected to rely on IDevID as an authenticity signal over LDevID. It is assumed that the attacker has obtained UDS at this point, and therefore can themselves wield IDevID. Therefore, the authenticity signal granted by IDevID cannot be the only signal used to determine LDevID's trustworthiness. The owner's device onboarding flow must be resistant to remote person-in-the-middle attackers that may attempt to use a previously exfiltrated UDS to register a forged LDevID.

After an owner registers a device's LDevID as part of their device onboarding flow, and unless the device again passes through the owner's device onboarding flow, the owner should not trust IDevID to endorse any other LDevIDs.

This approach does not defend against supply-chain attackers that obtain fuse data for devices that enter the supply chain after their field entropy has been programmed, such as during RMA flows. The LDevID certificate also does not support revocation because there is no generic Caliptra OCSP service. Owners should either maintain an allowlist of LDevID certificates or revoke any of the upstream certificate authorities.

Owners are not required to program field entropy. Caliptra generates LDevID from the value of the field entropy fuses, which could be all zeroes or ones. Caliptra LDevID derivation descends from UDS so that LDevID properties are no worse than IDevID. Field entropy is expected to be stored in fuses to achieve an equivalent physical attack barrier to UDS.

It is the responsibility of the owner or the user to identify the certificate they wish to trust, and to potentially endorse with their own certificate authority: pCA, IDevID, LDevID, or Alias_FMC.

FMC alias key

The LDevID CDI is mixed with a hash of FMC, as well as the security state of the device, via a FIPS-compliant HMAC, to produce CDI_FMC. ROM uses CDI_FMC to derive the Alias_FMC keypair. ROM wields LDevID to issue a certificate for Alias. The Alias_FMC certificate includes measurements of the security state and FMC. ROM makes CDI_FMC, Alias_FMC, and its certificate, available to FMC.

FMC mixes CDI_FMC with a hash of runtime firmware to produce CDI_RT. FMC uses CDI_RT to derive the Alias_RT alias keypair. FMC wields Alias_FMC to issue a certificate for Alias_RT. This alias certificate includes measurements of runtime firmware. FMC makes CDI_RT, Alias_RT, and its certificate, available to application firmware, while withholding CDI_FMC and Alias_FMC.

Security state

Devices may support features like debug unlock, DFT, or DFD flows that globally affect SoC state. These features, when enabled, significantly alter the security state of the device. The configuration of these features shall be captured in the device's DICE identity. The security state shall be captured as an input to the FMC's CDI, and represented within the FMC's alias certificate.

Owner authorization

Caliptra firmware shall be signed by the vendor. In addition, this firmware shall also be signed by an owner key. Caliptra must extract the owner's public key from the firmware image during cold boot, and latch the owner key into Caliptra's RAM for the remainder of its uptime³. Caliptra then uses both the vendor key and owner key to verify hitless firmware updates.

Caliptra shall attest to the value of the owner key, enabling external verifiers to ensure that the correct owner key was provisioned into the device. To perform this attestation, Caliptra includes the owner key as an input to the FMC's CDI (as part of "other attributes" from Figure 4 above), and represents it within the FMC's alias certificate.

The SoC may support a fuse bank for representing the hash of the owner's public key. If the SoC reports this value to Caliptra, Caliptra refuses to boot firmware unless the firmware was dual-signed by the key reported by SoC ROM's fuse registers.

The owner key, when represented in fuses or in the FMC's alias certificate, is a SHA384 hash of a structure that contains a list of owner public keys. This supports key rotation.

Provisioning UDS during Manufacturing (Subsystem Mode)

Note: In passive mode, SoC follows the same flows/restrictions as Caliptra 1.x

Figure 6: Subsystem Mode: UDS manufacturing flow

There are three ways of generating a UDS_SEED Use the internal TRNG to directly generate a 384-bit random number. Use an entity external to Caliptra such as an HSM or SoC-specific methodology to produce UDS-seed 384-bit random number that is pushed into the fuse controller (same as Caliptra 1.0). Combine the internal TRNG output with a Manufacturing time provided value to produce a 384-bit output.

UDS Manufacturing

1. When SoC life cycle is in MANUFACTURING MODE, manufacturing service register bit [CPTRA_DBG_MANUF_SERVICE_REG[2]] is set to request for UDS seed programming flow.
2. Caliptra ROM will sample this bit on power up; when this bit is set and Caliptra ROM rechecks that the life cycle state is manufacturing mode, it reads the iTRNG for a 512-bit value.
3. Caliptra ROM writes the 512-bit value to the address available through a register named UDS_SEED_OFFSET which is strapped by SoC at integration time by using DMA HW assist macro available at ROM’s disposal.
4. Caliptra ROM sets the corresponding status bit in CPTRA_DBG_MANUF_SERVICE_REG to indicate the flow completion.
5. Manufacturing flow will poll/read this bit and then do the fuse burning flow as specified by the fuse controller spec and SoC specific VR methodologies (eg. Fuse macro voltage elevation flows etc.).

Provisioning IDevID during manufacturing

Figure 7: Passive Mode: Device manufacturing identity flow

1. High Volume Manufacturing (HVM) programs the IDevID certificate attributes fuses. See IDevID Certificate for encodings.
2. HVM programs NIST compliant UDS into fuses using SoC-specific fuse programming flow. Note that this UDS goes through an obfuscation function within Caliptra IP.
3. SoC drives the security state, which indicates that it's a manufacturing flow. See Caliptra Security States for encodings.
4. SoC (using a GPIO pin or SoC ROM) drives BootFSMBrk (this is also used for debug cases). This can be driven at any time before cptra_rst_b is deasserted.
5. SoC follows the boot flow as defined in Caliptra IP HW boot flow to assert cptra_pwrgood and deassert cptra_rst_b, followed by writing to the fuse registers.
6. HVM, through JTAG or using the Caliptra SoC interface, sets “CPTRA_DBG_MANUF_SERVICE_REG” bit 0 to request a CSR.
7. HVM, through JTAG or using the Caliptra SoC interface, writes to “CPTRA_BOOTFSM_GO” to allow Caliptra’s internal BootFSM to continue to bring up microcontroller out of reset.
8. ROM reads the manufacturing state encoding from the “CPTRA_DBG_MANUF_SERVICE_REG” register, acquires the mailbox lock, and populates the Caliptra internal SRAM (the mailbox SRAM hardware structure is reused) with the CSR.
9. HVM, through JTAG or using the SoC interface, polls for the “IDevID CSR ready" bit 24 that is set in “CPTRA_FLOW_STATUS” register.
10. HVM reads mbox_status[3:0] to check if the data is ready to be read (DATA_READY encoding).
11. HVM must clear bit 0 of CPTRA_DBG_MANUF_SERVICE_REG, indicating that it completed reading the CSR.
12. Caliptra ROM opens the Caliptra Mailbox for SoC usages, such as FW loading (if required in some HVM flows). The SoC is only allowed to request a lock of the AXI-exposed mailbox interface after this CSR operation is complete.

Certificate format

Caliptra certificates follow the X.509 v3 format described in RFC 5280. After vendor provisioning, Caliptra's certificate chain contains the following certificates:

1. Provisioner CA (may be one or more certificates)
2. IDevID
3. LDevID
4. Alias_FMC
5. Alias_RT
6. DPE

After owner provisioning, an Owner CA may endorse the IDevID, LDevID, or Alias_FMC public keys. Owner CA provisioning is outside the scope of this specification.

Caliptra generates the LDevID, Alias_FMC, Alias_RT, and DPE certificates. The vendor, and optionally the owner, generate all other certificates.

Serial number algorithm

Caliptra uses certificate templates to avoid implementing fully capable X.509 v3 parsers and generators. Templates require certificates to be fixed length. This imposes constraints on the certificate serial numbers:

• Positive integer
• First octet as non-zero
• 20 octets in length

All Caliptra certificate serial numbers are generated with the following algorithm. The input is the certificate ECDSA or PQC MLDSA-87 public key in uncompressed form:

1. Convert to DER format.
2. Compute SHA256 digest.
3. AND the least-significant-byte with ~0x80.
4. OR the least-significant-byte with 0x04.
5. Perform byte-wise copies of the least-significant 20 bytes into the certificate template.

Provisioner CA

Provisioner CA (pCA) is a set of one or more certificates issued by the vendor. The vendor is responsible for provisioning pCA to the SoC. Caliptra does not consume pCA. See Reference 5 for guidance on pCA.

IDevID certificate

The vendor issues the IDevID certificate during SoC manufacturing. As part of provisioning IDevID during manufacturing, Caliptra uses the UDS to derive the IDevID key pair and generate a CSR. The vendor's pCA uses the CSR to generate and sign the IDevID certificate. The CSR uses the format defined in PKCS#10.

For IDevID to endorse LDevID, Caliptra requires the vendor to implement an X.509 v3 IDevID certificate described in RFC 5280 with the field values specified in Table 7: IDevID certificate fields. The vendor shall also populate all extensions from the "Requested Extensions" attribute in the CSR. It is also recommended that the vendor add the Authority Information Access (AIA) extension to the IDevID certificate and maintain an Online Certificate Status Protocol (OCSP) responder with a URL pointed to by the AIA extension.

Table 7: IDevID certificate fields

Caliptra does not consume the IDevID certificate. Caliptra needs attributes of the IDevID certificate in order to generate the Authority Key Identifier extension for the LDevID and to populate the TCG Universal Entity ID (UEID) extension for Caliptra-generated certificates. The vendor must fuse these attributes into the IDevID attribute fuses for Caliptra to consume. The encoding of these attribute fuses is as follows:

• Flags (byte 0, bits [1:0]): Key ID algorithm for IDevID Subject Key Identifier.
  • 0 = SHA1 of DER-formatted IDevID public key in uncompressed form
  • 1 = First 20 bytes of SHA256 of DER-formatted IDevID public key in uncompressed form
  • 2 = First 20 bytes of SHA384 of DER-formatted IDevID public key in uncompressed form
  • 3 = raw
• Reserved (bytes 1 to 3)
• Subject Key ID (bytes 4 to 23): if Flags = 3, the IDevID Subject Key Identifier to use as the LDevID Authority Key Identifier.
• UEID type (byte 24): UEID type as defined in IETF RATS specification. Used for TCG UEID extension.
• Reserved (bytes 25 to 27)
• Manufacturer Serial Number (bytes 28 to 43): the 128-bit unique serial number of the device to be used for the TCG UEID extension in the Caliptra-generated LDevID, Alias_FMC, and Alias_RT certificates.

The IDevID certificate is unique for each device and non-renewable. The SoC must be able to retrieve the IDevID certificate at runtime. To save flash space and aid in recoverability, it is recommended that the vendor define an IDevID certificate template such that the SoC at runtime can reconstruct the same certificate that the pCA endorsed. The SoC is recommended to store the IDevID certificate signature in fuses and the IDevID certificate template in the firmware image. Caliptra runtime firmware provides APIs to aid in reconstructing the certificate:

• GET_IDEV_INFO to return the IDevID public key.
• GET_IDEV_CERT to return the certificate given a to-be-signed (TBS) payload and the certificate signature from fuses. The TBS is the certificate template already patched with the IDevID public key, Subject Key Identifier, serial number, and any extensions that are unique to the device that the vendor may have included.

Caliptra does not allocate fuses in its fuse map for the IDevID certificate signature. Caliptra allocates "IDEVID MANUF HSM IDENTIFIER" fuses that the vendor can use to aid certificate reconstruction.

LDevID certificate

Caliptra ROM generates the LDevID certificate and endorses it with the IDevID private key. The LDevID certificate implements the following field values:

Table 8: LDevID certificate fields

Caliptra does not generate an LDevID CSR. Owners that wish to endorse LDevID must do so with proprietary flows.

Alias_FMC certificate

Caliptra ROM generates the Alias_FMC certificate and endorses it with the LDevID private key. The Alias_FMC certificate implements the following field values:

Table 9: Alias_FMC certificate fields

Caliptra does not generate an Alias_FMC CSR. Owners that wish to endorse Alias_FMC must do so with proprietary flows.

Alias_RT certificate

Caliptra FMC generates the Alias_RT certificate and endorses it with the Alias_FMC private key. The Alias_RT certificate implements the following field values:

Table 10: Alias_RT certificate fields

Caliptra does not generate an Alias_RT CSR. Owners that wish to endorse Alias_RT must do so with proprietary flows.

DPE certificate

Caliptra RT generates the DPE certificate and endorses it with the Alias_RT private key. The DPE certificate fields are described in the Caliptra Runtime specification. DPE also supports issuance of CSRs.

Caliptra security states

Figure 6: Caliptra security states

Definitions

• Non-Debug: Caliptra JTAG is not open for microcontroller and HW debug. Alias: DebugLocked
• Debug: Caliptra JTAG is open for microcontroller and HW debug. Alias: DebugUnlocked
• Unprovisioned: Blank/unprogrammed fuse part.
• Manufacturing: Device is in the manufacturing flow where HVM Caliptra fuses are programmed.
• Production: All of Caliptra’s HVM fuses are programmed.
• Secure: Any security state that restricts access to Caliptra from an external entity and has a known, specified function in the device lifecycle. Requires DebugLocked and either the Manufacturing or Production configuration.
• Insecure: Any security state other than those deemed secure. This includes all undefined states, all states with DebugUnlocked, and the Unprovisioned state. In accordance with the threat model, these states are considered a potential risk due to attacks via DFT or DFD channels, exploitation of unforeseen logic issues, or undefined behavior. These insecure states necessitate flushing of Caliptra secrets.

Notes:

• Caliptra’s security state is determined by the SoC’s security state and the SoC device lifecycle state.
• Caliptra’s state is considered a mode of operation.
  • Caliptra security state is defined by the uppermost bit of the encoding below; 1=DebugLocked and 0=DebugUnlocked.
  • Lower 2 bits are mapped to device lifecycle (unprovisioned, manufacturing, production).
• SoC’s security state may also be influenced by its own device lifecycle. A HW state machine must drive the SoC security state.
• Caliptra’s security state determines Caliptra’s debug state and the state of its security assets.
• In general, if Caliptra is in an insecure state, all keys and assets are ‘zeroized’. Zeroized may mean switching to all 0s, 1s, or debug keys based on the key. See Caliptra Assets for information.

Table 11: Security states

Notes:

• End-of-life state is owned by SoC. In end-of-life device lifecycle state, Caliptra shall not not be brought out of reset.
• Other encodings are reserved and always assumed to be in a secure state.

Each of these security states may be mapped to different SoC level debug and security states. SoC’s requirement is that if the SoC enters a debug state, then Caliptra must also be in an insecure state where all assets are cleared. Caliptra security state is captured by hardware on every warm reset; therefore SoC integrators enforce the security state transition policies for cold boot events. These policies are described in the preceding table.

Service surface

The service surface of Caliptra has multiple vectors. All use cases are control plane services, useful to power on a system or start a task. Supporting line rate high performance IO cryptography or any other data path capability is not required.

• Logic IOs: Required to indicate status of the IP, availability of a message through AXI, and to enable or disable certain debug capabilities (like JTAG enable or disable).
• Command mailbox: Caliptra shall offer services to other parts of the SoC. The APIs are documented in the Caliptra Runtime specification and summarized below:
  • Loading firmware: Caliptra firmware is loaded via the mailbox at cold boot. In addition, Caliptra firmware can be loaded at runtime to support hitless or impactless updates.
  • DICE-as-a-Service: Caliptra shall expose the TCG DICE Protection Environment iRoT Profile API, allowing Caliptra to derive and wield a DICE identity on behalf of other elements within the SoC. For example, Caliptra can sign messages for an SPDM responder.
  • Measurement Vault: Caliptra shall support stashing of measurements for the code and configuration of the SoC. Caliptra can provide these measurements via PCR Quote API or via DPE.
  • FW Authentication: Caliptra supports ECDSA and PQC MLDSA-87 verification for SoC firmware beyond its own. The SHA384 block exposes a HW API for hashing firmware. The runtime firmware exposes an ECDSA and MLDSA-87 verification API that uses the hash computed by the SHA384 block.

Device resilience

As noted earlier, Caliptra plays a role in maintaining the resilience posture of the SoC as defined by NIST SP 800-193 Platform Firmware Resiliency Guidelines (see Reference 1). As the Silicon RTM and RTI, Caliptra is either responsible for, or participates in, various protection and detection requirements described in the NIST publication.

The following table describes the NIST SP 800-193 requirements that Caliptra shall meet, either on its own or in conjunction with other components within the SoC or platform. Requirements not listed are assumed to be not covered and out-of-scope for Caliptra. In particular, most requirements related to firmware update and recovery are out-of-scope and must be handled by other components of the system.

Table 12: NIST SP 800-193 requirements

Secure boot flow

Caliptra shall follow and implement the secure boot guidelines as described in Reference 3.

For the detailed flow, see the hardware section and firmware verifcation section.

Hitless update

A ‘hitless’ (aka ‘impactless’) update occurs when an update is applied to Caliptra’s executing firmware without requiring a SoC or machine reboot. A hitless update allows Caliptra FW⁴ to remain up to date with FW security and/or functional patches while preventing or reducing machine downtime. Hitless update shall take effect immediately upon application (post-cryptographic verification). Updates to the machine’s persistent storage are still required because they ensure that Caliptra reboots to the latest FW if the system requires a restart or reboot.

Caliptra contains multiple hardware isolated registers for Platform Configuration Registers (PCR). These PCRs serve as volatile storage for concise cryptographic measurement of security state, including Caliptra’s own firmware.

Journey measurements matter because hitless updates are a challenge for devices that only capture their current firmware version and state. This is particularly true when the previous state may have impacted the current state of dependent components within the SoC. For example, a device might move from firmware version A to firmware version B without assuming a clean start to flush state. Vulnerabilities in firmware version A might impact version B. Preserving a device boot measurement and currently running measurement can highlight differences, but preserving these measurements does not distinguish between transitional states, such as when intermediate updates have the potential to expose the device to vulnerabilities. For example, a device may move from firmware version A, to B, and then to C without a restart, whereas another device of the same type might transition from A to C without transitioning through B. If tracking only the boot and current firmware version, should a vulnerability be found in version B, it is impossible to identify which devices transitioned through B compared to devices that transitioned from A to C directly.

To capture all firmware and configuration changes, Caliptra tracks and attests to both current measurements and cumulative measurement PCR banks. The current measurement is a snapshot of the currently running firmware and configuration. This provides easy reference for the current version. If the current and cumulative measurements are different, it can safely be assumed that the device has undergone some update. The cumulative measurement captures all of the firmware and state transitions from a clean cold boot to the current version. The cumulative measurement must be accompanied by a log structure that describes the path from boot to current measurement using hash extensions. A verifier can understand a device’s path to its current state by replaying log entries to reconstruct the cumulative measurement.

The log and cumulative measurement mechanism is similar to that used in TPM. In this model, Caliptra only needs to securely manage the measurements; the log does not need to be secured or maintained by Caliptra or the SoC. The construction of measurements through cryptographic hash extensions means that the log must provide the exact order and evidence needed to reconstruct the measurement. As such, the log is tamper evident by design and does not need to be kept secure.

Caliptra contains 32 384-bit PCR banks that are extendable by the SHA engine, and readable by Caliptra firmware. The usage of the PCR banks is as follows:

Table 13: PCR bank usage

For PCR0 and PCR1, ROM issues the following extend operations in order:

1. An array containing the following fields as 8-bit values:
   1. Lifecycle state
   2. Debug locked state
   3. Anti-rollback disable fuse
   4. ECDSA vendor public key index
   5. MLDSA-87 vendor public key index
   6. Cold-boot firmware SVN
   7. Effective Fuse SVN (i.e., 0 if anti-rollback disable is set)
   8. LMS vendor public key index
   9. LMS verification enable fuse
   10. Boolean indicating whether the owner public key hash is in fuses
2. Vendor public key hash
3. Owner public key hash
4. Digest of FMC

Caliptra ROM fails to boot if the following values do not remain constant across a hitless update:

• Owner public key hash
• ECDSA vendor public key index
• MLDSA-87 vendor public key index
• LMS vendor public key index
• FMC digest

Attestation of Caliptra's update journey

Upon every cold boot and hitless update, Caliptra ROM extends Caliptra's FMC measurement and ROM policy configuration into PCR0 (current) and PCR1 (cumulative). Upon every cold boot and hitless update, Caliptra FMC extends Caliptra's runtime firmware and firmware manifest measurements into PCR2 (current) and PCR3 (cumulative). The current measurement of the FMC, ROM policy configuration, RT, and FW manifest are used to derive a CDI and an alias key given to runtime firmware. FMC places runtime firmware's measurements into runtime firmware's alias key certificate, and signs that certificate with FMC's alias key.

When runtime firmware boots following a hitless update, it will use the following pieces of data for building the DPE nodes and certificate chain:

• Its CDI, derived by FMC
• Its alias key, generated by FMC
• Its alias certificate, signed by FMC
• Its journey measurements in PCR3, extended by FMC
• SRAM state, established by the prior runtime firmware image

SRAM state consists of measurements captured by prior runtime firmware images, and does not contain secrets or executable data⁵. Therefore, the trustworthiness of runtime firmware is reflected in the measurements captured by FMC and is evident in the runtime firmware alias certificate.

Caliptra firmware will attest to PCR3 by including it as an input in all DPE leaf key derivations and as evidence in all DPE leaf key certificates.

Commentary: recovery from a bad hitless update

Suppose the following Caliptra firmware images exist:

• Version A: presumed-good
• Version B: known-bad
• Version C: presumed-good

A remote verifier wishes to confirm that a given Caliptra device has not run version B since cold boot. The remote verifier can challenge the SoC with a freshness nonce; higher-layer software passes that freshness nonce as a request to Caliptra's DPE for signing. The remote verifier receives the following pieces of evidence:

1. An endorsement over LDevID, which may take a number of forms, including:
   1. Caliptra's vendor-signed certificate over IDevID, and an IDevID-signed certificate over LDevID.
   2. An owner-signed certificate over IDevID, and an IDevID-signed certificate over LDevID.
   3. An owner-signed certificate over LDevID.
2. An LDevID-signed certificate over Alias_FMC, which includes FMC's measurements as captured by ROM.
3. An Alias_FMC-signed certificate over Alias_RT, which includes runtime firmware's measurements as captured by FMC.
4. An Alias_RT-signed certificate over a leaf DPE key, which includes PCR3 as read by runtime firmware, along with other measurements previously stashed in SRAM.
5. A log structure⁶ that represents the measurements that have been extended into PCR3.
6. A leaf-DPE-signed blob⁷ containing the freshness nonce.

The remote verifier evaluates (1) according to ownership policies to determine whether the Caliptra device is trustworthy, before proceeding to verify the rest of the attestation response.

Thus satisfied in the trustworthiness of the Caliptra device, the remote verifier can then evaluate the trustworthiness of FMC by inspecting the measurements in (2), Alias_FMC's certificate. The verifier can reject the attestation if those measurements do not conform to a known-good value.

Thus satisfied in the trustworthiness of FMC, the remote verifier can then evaluate the trustworthiness of runtime firmware by inspecting the measurements in (3), Alias_RT's certificate. If version A or C is running, then the PCR3 measurement present in (4), the leaf DPE key certificate, is presumed to be an honest reflection of the hardware register as read by runtime firmware. The verifier can reject the attestation if Alias_RT's certificate indicates that version B is currently running.

Thus satisfied that version B is not currently running and that PCR3 is an accurate reflection of the hardware register, the remote verifier can then compare the log in (5) to PCR3 in (4) to confirm its authenticity, then walk the log to confirm that FMC never launched version B since cold-boot. If version B did run, that firmware could have maliciously modified DPE measurements stashed in SRAM, but could not have modified the contents of PCR3 to erase the evidence that version B ran at all, and could not have influenced the behavior of firmware versions A or C to prevent them from accurately reporting the contents of PCR3.

Thus satisfied that version B has not run since power-on, the verifier can also optionally inspect other measurements in (4) to evaluate the journey of other SoC components, whose measurements were previously stored within Caliptra's SRAM.

Finally, the verifier can confirm freshness by comparing the nonce in (6) to the one emitted in the original challenge. Because DPE only allows a derived leaf key to be used if the measurements present in its leaf certificate are a reflection of the current state, the fact that the freshness nonce was signed by DPE is evidence that the measurements in (4) are fresh.

Commentary: maintaining sealed secrets across a power cycle

Caliptra does not seal secrets directly. However, Caliptra does implement DPE, which allows secrets to be sealed to an external sealer such as a TPM, with a policy that only allows those secrets to be unsealed if Caliptra allows the host to wield a particular leaf DPE key. This leaf DPE key is permuted based on the hitless update journey of the various components whose measurements are stored within Caliptra.

This poses a challenge for maintaining sealed secrets across a power cycle. Suppose the SoC cold booted CPU microcode A, then hitlessly updated to B, and then to C. The measurements stored within Caliptra's SRAM will represent the [A->B->C] update journey, and DPE's leaf key is derived based on this journey.

Let us assume that upon each hitless update, the firmware update is also written to persistent storage, such that on the next cold boot the new firmware will run. Thus, on the next boot, the SoC's microcode update journey is simply [C]. This is a different journey than [A->B->C], and so DPE's leaf key will differ. The old secret sealed to the old DPE leaf key is no longer accessible to the SoC.

To anticipate this eventuality, before a power cycle, the SoC can instruct DPE to predict what the DPE leaf public key will be if the microcode journey is simply [C], using DPE's simulation context. The SoC can then reseal secrets to the external sealer with a policy that can be satisfied if the computed public key is used.

Note: as all DPE leaf keys are derived using Caliptra runtime firmware's CDI, a DPE simulation context cannot predict the leaf key that would be available if a different Caliptra firmware image were to boot (because one Caliptra firmware image does not have access to a different image's CDI). Therefore, if a different Caliptra firmware image is staged to persistent storage, Caliptra must first be hitlessly updated to that image before a simulation context can be used to predict public keys that will be available to that image on the next cold boot.

Attestation of SoC update journey

Caliptra shall also attest to the journeys of SoC components. A SoC component's journey may change independently of other components. For example, SoC components may implement partial resets or hitless updates that cause the component's firmware or configuration to reload.

Caliptra shall maintain a reboot counter for each component. Caliptra shall increment the reboot counter and update the journey measurement for calls that indicate that the component's state changed. Caliptra shall attest the journey measurement and report the counter value on-demand. The verifier is assumed to have knowledge of update events at an associated reboot counter (via an event log) but not have knowledge of reset events. The verifier can compute the journey measurement via multiplicatively extending the current measurement by the reset counter. For example:

1. Upon cold boot, SoC component boots firmware A. Reboot counter is 0. The tuple of (0,A) is in the event log.
2. SoC component is partial reset once. Reboot counter is 1.
3. SoC component is hitlessly updated to firmware B. Reboot counter is 2. The tuple of (2,B) is in the event log.
4. SoC component is partial reset twice. Reboot counter is 4.

The corresponding journey measurement computation is the chained extension of [A->A->B->B->B]. The verifier can ascertain this through the two event log entries.

Anti-rollback support

Caliptra shall provide fuse banks (refer to Table 21: Caliptra Fuse Map) that are used for storing monotonic counters to provide anti-rollback enforcement for Caliptra mutable firmware. Each distinctly signed boot stage shall be associated with its own anti-rollback fuse field. Together with the vendor, Caliptra allows owners to enforce strong anti-rollback requirements, in addition to supporting rollback to a previous firmware version. This is a critical capability for hyperscalers.

Caliptra firmware shall include an SVN value in the signed header. If the firmware's SVN value is less than the current counter value in the fuse bank, Caliptra shall refuse to boot that firmware, regardless of whether the signature is valid.

Alternatively, platform vendors may prefer to manage firmware storage and rollback protection in a different manner, such as through a dedicated Platform RoT. In such cases, the vendor may wish to disable anti-rollback support from Caliptra entirely. This disable support is available via an OTP/fuse setting.

Each of Caliptra's internal anti-rollback fuse banks shall support a minimum counter value of 64. This feature is expected to be used sparingly.

Physical attack countermeasures

Caliptra shall implement countermeasures designed to deter both glitching (also referred to fault-injection (FI)) and side-channel attacks (simple power analysis (SPA) and differential power analysis (DPA)).

The Caliptra threat model guides the priority of which physical countermeasures are based on a specific physical implementation.

From the top, an adversary in the supply chain has essentially unlimited time to glitch the chip and make it reveal any private key material or symmetric secrets. One Glitch To Rule Them All is one example with recency bias. The most critical countermeasures must prevent non-destructive extraction of those secrets. Otherwise, an adversary who succeeds can silently impersonate production-serving assets at a later time.

Randomly generated per-part entropy is subject to physical inspection attacks in the supply chain as well. The fuses that store the UDS entropy shall be protected to a degree that forces an attacker to perform a destructive operation to read their values. Decapping and fibbing attacks should at least penetrate enough layers and metal shielding to render the part useless, if not being outright impossible to carry out. Entropy tied to a damaged asset typically requires injection of counterfeit devices in the supply chain, which is a very powerful adversary model.

Another way to obtain access to secret entropy with “unlimited supply chain time” is to observe side channels while the SoC is executing. Because Caliptra is expected to be a <1 mm² fraction of a large SoC, side-channel mitigation is required only against extremely resourceful attackers that can wade through and discern a large number of confounding signals and power profiles. With that priority in mind, DPA and DMA attacks should be mitigated via decoy value generation.

Any private key material or symmetric key material embedded in the RTL (and therefore “global”) must be treated as having low value, reaching zero value in a number of quarters. A supply chain attacker can destructively obtain the key material, and loss of one part is not going to trigger any alarms.

Mitigation against SCA is not trivial and may be implemented in a variety of ways. Reference 7 provides a comprehensive overview of methods and techniques used in various SCA as well as recommendations for countermeasures against such attacks (including feasibility and applicability). Additionally, there are academic papers available from NIST and other resources that discuss SCA and their countermeasures.

Compliance and certification requirements

Due to the identity service surface offered to other SoC subsystems, Caliptra may fall under the Target of Evaluation (ToE) of an application that wishes to attain a specific compliance level for business reasons.

It is important to highlight that it’s not necessary for the RTM itself to unilaterally attain (for example, FIPS 140-3 L3). It is only relevant when the RTM is included in the “bag” that wants to obtain a compliance certification. For example, it is relevant when a cloud provider wants to FIPS-certify PCIe link encryption in transit rooted to an ASIC identity emanating from a Caliptra instance.

See Reference 8 for requirements related to keys, entropy, random bits, cryptographic modules, and algorithms.

Known Answer Test (KAT) support

To certify a cryptographic module, pre-operational self-tests must be performed when the system is booted. Implementing KATs is required for FIPS certification. However, regardless of FIPS certification, it is considered a security best practice to ensure that the supported cryptographic algorithms are functioning properly to guarantee correct security posture.

KAT execution is described as two types:

• Pre-operational Self-Test (POST)
• Conditional Algorithm Self-Test (CAST)

A detailed description of the POST and CAST KATs can be found at csrc.nist.gov.

Table 14: KAT failure mitigations

Table 15: POST/CAST usage

As shown in Table 15: POST/CAST usage, since the cryptographic algorithms required by the Caliptra Boot ROM are considered POSTs, and those same algorithms are used by Caliptra FMC and FW, there is no requirement that FMC and Runtime FW implement CASTs for those algorithms.

Firmware image format and verification

Caliptra supports verifying firmware with ECDSA P384 and MLDSA-87 signatures and Leighton-Micali Hash-based Signatures (LMS) in accordance with the requirements described in Reference 3.

Caliptra firmware is composed of two images: an FMC image and an application firmware image. A single firmware manifest describes these images. The manifest consists of a preamble (Table 16), a header (Table 17), and a Table of Contents (TOC) (Table 18). The image layout is shown in Figure 7: firmware image layout.

Figure 7: Firmware image layout

To verify the firmware, Caliptra ROM performs the following steps:

1. Calculates the hash of the vendor key descriptors in the preamble and compares it against the hash in fuses (key_manifest_pk_hash). If the lifecycle is not "unprovisioned" and the hashes do not match, the boot fails.
2. Calculates the hashes of the active vendor public keys and compares it against the hashes in the key descriptors identified by the corresponding active key indices.
3. Calculates the hash of the owner public keys in the preamble and compares it against the hash in fuses (owner_pk_hash). If the owner_pk_hash fuse is not zero (i.e., unprovisioned) and hashes do not match, the boot fails. See the Owner authorization section.
4. Ensures the vendor public key(s) selected by the preamble indices are not revoked based on fuse: key_manifest_pk_hash_mask for ECDSA public key, pqc_revocation for LMS or MLDSA public key.
5. Calculates the hash of the first byte through the vendor data field of the header (this includes the TOC digest). This is the vendor firmware digest.
6. Calculates the hash of the first byte through the owner data field of the header (this includes the TOC digest). This is the owner firmware digest.
7. Verifies the vendor signature using the vendor firmware digest from step 5 and the vendor key(s) from step 4.
8. Verifies the owner signature using the owner firmware digest from step 6 and the owner key(s) from step 3.
9. Verifies the TOC against the TOC digest that was verified in steps 6 and 7. The TOC contains the SVN and digests for the FMC and runtime images.
10. Verifies the FMC against the FMC digest in the TOC.
11. Verifies the runtime against the runtime digest in the TOC.
12. If Caliptra is not in "unprovisioned" lifecycle state or "anti-rollback disable" state, ROM compares the firmware's SVN against the SVN fuse (fuse_firmware_svn).

In addition to cold boot, Caliptra ROM performs firmware verification on hitless updates. See the hitless update section for details.

Table 16: Firmware manifest preamble

Fields are little endian unless described otherwise.

Table 17: Public Key Descriptor

Fields are little endian unless described otherwise.

Table 18: Firmware manifest header

Fields are little endian unless described otherwise.

Table 19: Table of contents

Fields are little endian unless described otherwise.

Post-Quantum Cryptography (PQC) requirements

Recent guidance from the US Government, CNSA 2.0, requests the use of LMS by 2025. Caliptra has an option to require LMS signatures in addition to ECDSA signatures (vendor and owner).

Based on the recommendation in CNSA 2.0, Caliptra uses the SHA256/192 algorithm. To provide a balance between the number of signatures allowed and signature size, Caliptra uses an LMS tree height of 15. This is referred to in NIST SP 800-208 as the LMOTS_SHA256_N24_W4 and LMS_SHA256_M24_H15 parameter sets.

Caliptra supports 32 LMS trees for the vendor and 1 tree for the owner. The SoC can support multiple trees for the owner via ownership transfer. It is recommended that the LMS trees are created from multiple HSMs that are geographically distributed.

Caliptra has an option starting in 2.0 to use ML-DSA-87 signatures in addition to ECDSA to support FIPS 204 and CNSA 2.0 requirements for category 5.

Caliptra provides cryptographic services to support ML-KEM (in addition to ECDH) key exchanges.

Key rotation

Firmware signing key rotation shall follow the requirements described in Reference 3.

Hardware

Please refer to Caliptra HW specification -> https://github.com/chipsalliance/caliptra-rtl/blob/main/docs/CaliptraHardwareSpecification.md

Passive Caliptra FW Load flow

Figure 10: Passive Caliptra FW load flow

1. After the Caliptra microcontroller is out of reset, ROM starts executing and triggers the crypto block to run the UDS decrypt flow.
2. Caliptra ROM enables the mailbox. (Until this point, any accidental or non-accidental writes that target the mailbox are dropped by the hardware.)
3. Caliptra ROM asserts READY_FOR_FW wire. This is done by writing an internal register. This register is also visible to read on the AXI interface. SoC can choose to poll on this bit instead of using the wire (it is the SoC integration choice).
4. SoC follows the mailbox protocol and pushes Caliptra FW into the mailbox.
5. Caliptra’s mailbox HW asserts an interrupt to the microcontroller after the GO is written, per mailbox protocol. See Mailbox for specifics.
6. After Caliptra’s FW is authenticated and loaded into ICCM, microcontroller runs the firmware and asserts READY_FOR_RTFLOWS wire.

Subsystem FW Load flow for Subsystem Mode

Please see the subsystem architecture section below.

CPU warm reset or PCIe hot reset flow → Caliptra IP reset

Figure 11: Hardware reset flow

Note: Since Caliptra IP may be placed in an ACPI S5 domain of the device, there may be devices where Caliptra IP may not go through reset on a device hot reset or CPU warm reset. But the flow shows what happens when such a reset happens.

1. Caliptra IP’s reset is asserted by the SoC.
2. Caliptra’s internal BootFSM resets the microcontroller and then resets all of the logic (including the SoC-facing AXI interface). Only registers or flops that are sitting on powergood are left with the same value. Note that SRAMs do not have a reset.
3. Caliptra IP’s reset is deasserted by the SoC.
4. At this point, the HW boot flow is the same as the cold boot flow. SoC is required to configure the internal TRNG and ROM WDT and then set CPTRA_FUSE_WR_DONE. This causes Caliptra IP to deassert the Ready_for_Fuse wire.
5. Caliptra’s ROM reads an internal register to differentiate between warm, cold, and impactless flow. If it's a warm reset flow, then it skips DICE key generation and FW load flows (because keys were already derived and FW is already present in ICCM). This is an important reset time optimization for devices that need to meet the hot reset specification time.

Because warm reset is a pin input to Caliptra, Caliptra may not be idle when a warm reset occurs. If a warm reset occurs while Caliptra ROM, FMC, or RT initialization code is executing, Caliptra may be inoperable until a subsequent cold reset. If a warm reset occurs while Caliptra runtime is servicing a request, Caliptra shall remain operable but may refuse to wield production assets for subsequent requests.

Note: The cold reset flow is not explicitly mentioned but it is the same as the cold boot flow because Caliptra IP has no state through a cold reset. Note: Subsystem mode's warm reset flow is the same as above, except the warm reset action is triggered/managed by MCU.

Random Number Generator

TRNG is the digital logic and algorithms that are required for random number generation. It requires a physical entropy source input. See the Caliptra hardware specification and integration specification here for more information on the implementation and connectivity of TRNG.

• For SoCs that want to use their own legacy TRNG, Caliptra provides a HW API to push the random number on the request/response handshake. Details on this are also available in the Caliptra hardware specification and integration specification. This mode is advised for early development but discouraged for production tape outs due to the lower security assurances of an external TRNG.
• In Subsystem mode, Caliptra integrators are required to use the internal TRNG.

Mailbox

The Caliptra Mailbox is a 128 KiB buffer that is used to exchange data between the SoC and the Caliptra microcontroller.

The SoC communicates with the mailbox over an AXI interface. This allows the SoC to identify the device that is using the interface. This ensures that the mailbox, control registers, and fuses are read or written only by the appropriate device.

When a mailbox is populated by SoC, an interrupt to the FW occurs. This indicates that a command is available in the mailbox. The microcontroller is responsible for reading from and responding to the command.

When a mailbox is populated by the microcontroller, Caliptra sends a wire indication to the SoC that a command is available in the mailbox as well as updating the MAILBOX STATUS register. The SoC is responsible for reading from and responding to the command.

Mailboxes are generic data passing structures, and the Caliptra hardware only enforces the protocol for writing to and reading from the mailbox. How the command and data are interpreted by the FW and SoC are not enforced in Caliptra.

Sender protocol

Sending data to the mailbox:

1. Requester queries the mailbox by reading the LOCK control register.
   1. If LOCK returns 0, LOCK is granted and is set to 1.
   2. If LOCK returns 1, MBOX is locked for another device.
2. Requester writes the command to the COMMAND register.
3. Requester writes the data length in bytes to the DLEN register.
4. Requester writes data packets to the MBOX DATAIN register.
5. Requester writes to the EXECUTE register.
6. Requester reads the STATUS register until a value other than CMD_BUSY is detected. This is also indicated by a dedicated wire that asserts when STATUS is changed. STATUS can return:
   1. DATA_READY – Indicates the return data is in the mailbox for the requested command.
   2. CMD_COMPLETE – Indicates the successful completion of the requested command.
   3. CMD_FAILURE – Indicates the requested command failed.
   4. CMD_BUSY – Indicates the requested command is still in progress.
7. If response data is expected and the requester reads a STATUS of DATA_READY:
   1. Requester reads from the DLEN register to ascertain the size of the response data.
   2. Requester reads data from the DATAOUT register until DLEN bytes are read.
8. After reading the response data, if any, requester writes 0 to the EXECUTE register to clear LOCK.

Notes on behavior: After LOCK is granted, the mailbox is locked until that device has concluded its operation. The mailbox is responsible only for accepting writes from the device that requested and locked the mailbox.

Figure 12: Mailbox sender flow

Receiver protocol

Upon receiving an indication that the mailbox is populated, the appropriate device can read the mailbox. This is indicated by a dedicated wire that is asserted when Caliptra populates the mailbox for SoC consumption.

Receiving data from the mailbox:

1. Receiver reads the COMMAND register.
2. Receiver reads the DLEN register.
3. Receiver reads the MBOX DATAOUT register.
   1. Continues reading MBOX DATAOUT register until DLEN bytes are read.
4. If response data is required:
   1. Receiver writes the size of the response data to the DLEN register.
   2. Receiver writes to the DATAIN register until DLEN bytes are written.
   3. Note: Response data is only supported for Caliptra, to SoC-initiated commands. SoC cannot provide response data for Caliptra-initiated commands.
5. Receiver writes to the STATUS register.
   1. If response data was provided, STATUS should be written to DATA_READY.
   2. Otherwise, STATUS should be written to CMD_COMPLETE (or CMD_FAILURE).

Figure 13: Mailbox receiver flow

User attributes

The AXI_USER field of the AXI interface is used to encode device attributes for the requester that is utilizing the SoC interface. These values can be used for:

• Ensuring the device that was granted the LOCK is the one that accesses the MBOX, DLEN, COMMAND, and STATUS registers.
• Prioritizing who is next granted the LOCK.
• Mailbox user 0xFFFF_FFFF is reserved for Caliptra internal use. Caliptra firmware will fail any SoC requests from this user.

Mailbox commands

The Caliptra mailbox commands are specified in the Caliptra runtime firmware specification.

Cryptographic mailbox commands

Cryptographic mailbox (CM) commands are a flexible set of mailbox commands that provide access to Caliptra's cryptographic cabilities. This is meant for key storage and use to support protocols like SPDM and OCP LOCK.

These commands are not meant to be high-performance as they are accessed via mailbox commands.

Key material and data will be stored in an encrypted and authenticated section of DCCM. Keys are used via handles that refer to portions of DCCM.

These mailbox commands extend Caliptra's cryptographic support to include SHA, HMAC, HKDF, AES, ECDH, ML-KEM, and RNG services in addition ECDSA and ML-DSA.

The runtime firmware specification contains further details.

Hash calculation HW API (Subsystem mode only)

Caliptra provides a HW API to do a SHA384 hash calculation. The SoC can access the accelerator through the Caliptra FW API only in subsystem mode. Caliptra FW API uses the internal SHA accelerator and its DMA widget be hash the required data and present it back to Calitpra FW.

JTAG/TAP debug

Figure 14: Debug flow

1. SoC drives the security state indicating that it is a debug flow. See Caliptra security states for encodings.
2. SoC (using a GPIO pin or SoC ROM) drives BootFSMBrk (this is also used for debug cases). This can be driven at any time before cptra_rst_b is deasserted.
3. SoC follows the boot flow as defined in Caliptra IP HW boot flow to assert cptra_pwrgood and deassert cptra_rst_b, followed by writing to the fuse registers.
4. HVM, through JTAG or through the Caliptra SoC interface, writes to “CPTRA_DBG_MANUF_SERVICE_REG”, requesting the appropriate debug service (see the ROM/Runtime specifications for bit definitions).
5. HVM, through JTAG, can also inject microcontroller TAP commands at this point following the VeeR Specification.
6. HVM, through JTAG or through the Caliptra SoC interface, writes to “CPTRA_BOOTFSM_GO” to allow Caliptra’s internal BootFSM to continue to bring up microcontroller out of reset.
7. Microcontroller executes the appropriate debug service.
8. Specific SoC interface registers are accessible over the JTAG interface in debug (or manufacturing mode). The following are the JTAG register addresses for these registers.

Table 20: JTAG accessible registers

Note: These are injected as TAP register read/write commands as defined in the VeeR Specification.

Notes:

1. The security state is latched at cptra_rst_b deassertion. If the security state is unlocked at this time, only TAP is opened.
2. Changing the security state at a random time after cptra_rst_b deassertion (Caliptra in passive mode): does not unlock Caliptra JTAG.
3. Changing the security state at a random time after cptra_rst_b deassertion (Caliptra in passive mode): transition from debug locked to debug unlocked has no effect until next reset.
4. Changing the security state at a random time after cptra_rst_b deassertion (Caliptra in subsystem mode): Refer to Production Debug Unlock Architecture for details of the full procedure.
5. Setting scan mode at a random time after cptra_pwrgood: flushes out all internal Caliptra secrets, assets, key vault, and crypto intermediate state.
6. Scan mode assertion does not automatically open Caliptra JTAG.

Architectural registers

These registers are accessible over AXI to be read according to the register access permissions. For more information, see the register reference manual at https://ereg.caliptra.org.

Fuse requirements

Fuse registers are programmable whenever IP goes through reset (after cptra_rst_b asserts and de-asserts) and before the fuse registers are locked from writes. If the lock was set, the writes are dropped. The lock is sticky across a warm reset.

To ensure that the security claims of Caliptra are achieved, specific fuse protection capabilities must be supported:

• Fuses that hold Caliptra secrets shall not be readable by any mutable code in the SoC. The intent is to provide defense-in-depth for the UDS.
  • For SoCs that intend to achieve FIPS 140-3 CMVP certification with Caliptra, SoC shall implement a HW state machine for copying the uds_seed, field_entropy, and key_manifest_pk_hash fuses from the fuse controller into Caliptra's fuse shadow registers. Only the fuse controller, this state machine, and Caliptra shall be able to access these fuse values. The intent is to not include the SoC ROM as part of the cryptographic module boundary.
• For the production lifecycle state, if JTAG is enabled pre or post SoC reset, then Caliptra's dedicated fuses shall not be accessible (shall not be readable, shall not be writable) by Caliptra or other SoC IP. This restriction shall be applicable to Caliptra's fuse shadow registers as well (see Physical Attack Countermeasures).
• SoC should ensure that the integrity of each fuse is maintained through the life of the part. The integrity of the fuses can be maintained by fuse redundancy, ECC, or other means determined sufficient by the SoC.

Fuse programming

All fuse based cryptographic keying material and seeds (for example, UDS Seed) shall be generated (on-chip or off-chip) per requirements described in Reference 8.

SoC shall support in-field programmable fusing. Fuse Map shows which fuses are expected to be in-field programmable. SoCs shall implement authorization for in-field programmable fusing to mitigate denial-of-service attacks. Authorization design is outside the scope of this specification. In Subsystem mode, SoC may use MCU RT FW for these actions.

SoC shall support a field entropy programming API. The API shall support retrieving an input value from an external interface. It should cryptographically mix that value with the output of an on-die TRNG to generate the field entropy value. The API implementation shall burn the field entropy value into the first available field entropy fuse slot (or fail if no slots are available). Caliptra is expected to be in any security state. The device owner is expected to call this API in a “clean room environment” to minimize risk of attack on the programming process. In Subsystem mode, SoC may use MCU RT FW for these actions.

Fuse zeroing

Caliptra assumes that the unfused value in fuses is '0' and the fused value is '1'. With this context, zeroization refers to destroying a secret value by fusing it to all ones.

For SoCs that intend to achieve FIPS 140-3 CMVP certification with Caliptra:

• SoC shall implement zeroization for uds_seed and field_entropy such that the fuse rows holding these secrets contain all ones.
• SoC shall expose and document an API for a tester to invoke zeroization.
• SoC shall indicate that zeroization has occurred by statically asserting GENERIC_INPUT_WIRE[0] to Caliptra.
• SoC shall set Caliptra’s security state to DebugUnlock by ORing it with the zeroization status signal.
• SoC shall expose Caliptra architectural registers as API for a tester to read.
• SoC shall ensure authorization for this API to guard against denial-of-service attacks. The authorization design is left to the vendor.
• Note: In Subsystem mode, SoC should use MCU RT FW with the corresponding subsystem HW components for these actions.

Fuse map

FIXME: Needs updates for Caliptra 2p0 & Subsystem The following table describes Caliptra's fuse map:

Table 21: Caliptra Fuse Map

Error reporting and handling

This section describes Caliptra error reporting and handling.

Table 22: Hardware and firmware error types

Fatal errors

• Fatal errors log the FATAL ERROR reasons into an architectural register that is RW from the external world. This register must be sticky (as in, reset is on powergood).
• This register may be cleared at any time via register write (W1C).
• Caliptra signals fatal errors using a cptra_error_fatal wire.
  • SoCs should connect this into their SoC error handling logic. Upon detection of a FATAL ERROR in Caliptra, SoC shall treat any outstanding commands with Caliptra as failed, and SoC may recover by performing a Caliptra reset using the signal cptra_rst_b.
  • This signal prevents forward progress of the boot process if measurement submission to Caliptra fails. If SoC detects a Caliptra fatal error while the SoC is in steady state, then there is no obligation for the SoC to immediately address that error. If rebooting the SoC for such failures is deemed unacceptable to uptime, the SoC should implement the ability to trigger a Caliptra warm reset independently of the SoC, and may use this mechanism to recover.
  • Error mask registers (writable only by Caliptra microcontroller) may be used to prevent error signal assertion per-event. Mask registers only impact interrupts when they are set prior to the error occurrence.
  • cptra_error_fatal remains asserted until Caliptra is reset. Note that, although the HW FATAL ERROR register fields may be cleared at any time, a reset is still required to clear the interrupt.
• When a fatal error occurs, all volatile assets that are stored in key vault are cleared.

Non-fatal errors

• Non-fatal errors log the NON-FATAL ERROR reasons into an architectural register that is RW from the external world. This register must be sticky (as in, reset is on powergood).
• This register may be cleared at any time via register write (W1C).
• Caliptra signals non-fatal errors using a cptra_error_non_fatal wire.
• Caliptra reset via cptra_rst_b, or a write to clear the NON-FATAL ERROR register, cause the interrupt to deassert.
• It is optional for SoCs to include this signal in their logic.

Firmware errors

Please refer to the Caliptra code base for a list of the error codes.

Caliptra Security Subsystem

The Caliptra subsystem offers a complete RoT subsystem, with open source programmable components for customization of SoC boot flows.

Figure: Caliptra security subsystem

Caliptra Subsystem Trademark Compliance

• Caliptra subsystem trademark compliance shall have Caliptra Core 2.0, Life Cycle Controller, Fuse Controller, I3C with OCP streaming boot interface, Manufacture Control Unit (MCU) and Manufacturer Control Interface (MCI) taken as is without change to ensure there is hardware transparency and consistency.
• Caliptra subsystem provides life cycle state to the SoC.

SoC Integration Flexibility

• SoC may choose to add PLLs (Phase Locked Loop for stable clock generation), SoC specific mailboxes, SoC specific firewalls & address translations, environmental circuitry as some examples.
• Caliptra subsystem provides flexibility to SoC to remap subsystem driven debug levels to SoC specific debug policies.
• Please see Subsystem hardware and integration specifications for additional details on subsystem configurability (FIXME: Add md versions once available; right now they are uploaded as pdfs in Caliptra-SS repository's doc folder).

Caliptra Subsystem Architectural Flows

Subsystem (Pre-FW Load) Boot Flow

Note: Any step done by MCU HW/ROM would have been performed by “SoC Manager” in Caliptra 1p0.

1. SoC (using its HW or MCU ROM) performs pre-steps like bringing up CRO or PLL, MBIST flows on SRAMs, SRAM Init etc.
2. SoC will assert MCU & Caliptra pwrgood and after 10 cycles MCU
3. MCU ROM or SoC Manager wrapper will bring up fuse controller and any other SoC specific infrastructure RTL modules (I3C, GPIO programming, Glitch detector programming etc.)
4. MCU ROM or SoC Manager wrapper will deassert Caliptra reset.
5. Caliptra HW will read the security centric (secret) fuses.
6. MCU ROM waits for ready_for_fuses to be asserted.
7. MCU ROM or SoC Manager will populate the remaining fuses of Caliptra and reads its own fuses (if any). Note that this step is gated behind the completion of security fuse writes to ensure the step has completed.
8. MCU ROM will write “fuse done” to Caliptra.
9. Caliptra will go through its boot flow of bringing up uC.
10. Caliptra ROM starts and executes various KATs flows.

Subsystem Boot Flow

If (Caliptra-Passive-Mode)

1. SoC Manager goes through Caliptra 1.x flows => loads Caliptra FW using Caliptra 1.x flows, Caliptra sets RT ready and SOC <-> Caliptra boot flow is done.

(Caliptra-Subsystem-Mode)

1. Caliptra ROM waits for SoC infrastructure readiness indication. If this indication is set, Caliptra will do the identity derviation flows. If it is not set, then this flow is run when the SoC infrastructure readiness indication is set.
2. Caliptra ROM uses the streaming boot interface to load its firmware. Please see the specific section for next level specifics; At a high level, Caliptra ROM sets the device ready in the I3C controller and poll I3C for the payloads.
3. BMC or a similar platform component will send the image (code or data) through OCP streaming boot interface. 1.Caliptra ROM uses the streaming boot interface to receive 'data' from the BMC or MCU. Examples include SoC specific configuration. Caliptra ROM operation of the streaming boot interface will be identical for receiving either 'code' or 'data'. The data flow and code flow over streaming boot interface is the same from physical interface point of view and follows the OCP recovery spec for streaming boot support as implemented in Caliptra subsystem documentation (please see the recovery section). 2. This need for data flow (from flash or BMC) is indicated by a SOC configuration bit to Caliptra ROM. 3. This ‘data’ flow is possible only before SOC infra readiness is set. This is specifically used for scenarios where PUF or other characterization data is coming off-chip (say a flash or BMC). FIXME: Security and operations impact of this step/flow is being analyzed. This capability/flexibility will be updated or removed once that is finalized. 4. This data must be hashed into PCR0 5. To keep the scope limited, only one ‘data’ flow is allowed
4. If the data was required to be run (is indicated by a SOC configuration bit to Caliptra ROM), Caliptra ROM waits for SOC infrastructure readiness to be set. Once set, it will do the required key derivations.
5. Caliptra ROM will read the streaming boot interface registers (data payload registers) over AXI manager interface and write into Caliptra MB SRAM. The offset of the streaming boot interface registers are available through a config register that is set at SOC integration time or by MCU ROM.
   1. Note that an intelligent I3C peripheral could “stream” the image. This is a future enhancement.
6. Caliptra ROM will authenticate its image sitting in Caliptra MB SRAM
7. Caliptra ROM flow will be similar to Caliptra 1.0 flow with PQC FW Authentication.
8. Caliptra ROM will derive required keys similar to Caliptra 1.0 flow (while accounting for PQC)
9. Caliptra ROM will switch to RT image.
10. Caliptra RT FW will set the Streaming boot interface to allow BMC’s Recovery Agent (RA) to send the next image (which MUST be SOC image manifest).
    1. BMC RA is required to know the different component of the images using the similar manifestation as DSP0267 PLDM for Firmware Update over MCTP components.
11. Caliptra RT FW will read the Streaming boot interface registers over AXI manager interface and write the image to its mailbox.
12. Caliptra RT FW will authenticate SoC manifest using the keys available through Caliptra Image, authenticate the image, capture the measurement and capture the relevant information into DCCM.
13. Caliptra RT FW will set the Streaming boot interface to allow BMC’s Recovery Agent (RA) to send the next image (which MUST be MCU image manifest).
    1. BMC RA is required to know the different component of the images using the similar manifestation as DSP0267 PLDM for Firmware Update over MCTP components.
14. Caliptra RT FW will read the Streaming boot interface registers over AXI manager interface and write the image to MCU SRAM aperture (that is open to Caliptra only by HW construction).
    1. The address of the MCU SRAM is provided to Caliptra’s RT FW through SOC manifest.
    2. Note: From validation front, need to ensure the Caliptra ROM and MCU are aligned in endianness.
15. Caliptra RT FW will instruct Caliptra HW to read MCU SRAM and generate the hash (Caliptra HW will use the SHA accelerator and AXI mastering capabilities to do this)

    Open: Should we have a capability to do something like this for decryption too? (Key to be provided by MCU/SOC before running the decryption flow?)

16. Caliptra RT FW will use this hash and verify it against the hash in the SOC manifest.
17. Caliptra RT FW after verifying/authorizing the image and if it passes, it will set EXEC/GO bit into the register as specified in the previous command. This register write will also assert a Caliptra interface wire.
    1. MCU ROM will be polling the breadcrumb that the MCU SRAM has valid content and will jump to the MCU SRAM to execute from it. NOTE: This breadcrumb should be one of the status bits available on the MCU interface that is set by Caliptra GO bit wires.
    2. Until this step MCU SRAM aperture that holds the MCU RT FW and certain Streaming boot interface registers are not accessible to MCU.
18. MCU RT FW will now set Streaming boot flow is completed.
19. BMC or a similar platform component will now do MCTP enumeration flow to MCU over I3C.
20. MCU RT FW is responsible for responding to all MCTP requests.
21. MCU RT FW will do the PLDM T5 flow, extract FW or configuration payload, use Caliptra to authenticate and deploy the rest of the images as described in run-time authentication flows.

Figure: Subsystem Boot Flow

Common Run-time Authentication Flows

1. MCU RT FW will do PLDM T5 flow to obtain the FW images for downstream uControllers (or other SoC configuration)
2. MCU RT FW will send/stream the (FW or config) payload to Caliptra SHA Acc to perform hash measurements as the payload comes through the MCTP transport.
3. MCU RT FW can either stage the entire image or write to the final destination as a part of the previous step depending on the SOC construction.
   1. Note: By SOC security/design construction, the FW/payload that is loaded must NOT be allowed to execute or be used until Caliptra authorizes that the FW/payload.
4. MCU RT FW will issue the imageID & GO-field bit (bit that Caliptra RT FW would set if the image authorization is successful) to Caliptra RT FW to start off the process of image authorization of the image that was hashed.
5. Caliptra RT FW will obtain this hash from the internal SHA accelerator register that was used to hash in the previous step.
6. Caliptra RT FW after verifying/authorizing the image and if it passes, it will set EXEC/GO bit into the register as specified in the previous command. This register write will also assert a Caliptra interface wire.
7. MCU RT FW has an option of looking at the Mailbox command success or read the register or use the wire that the register will drive to allow the execution of the FW. This wire allows SOCs to construct a hardened logic of allowing executions from ICCM/TCMs only after the wire is set.
   1. SOC construction outside of MCU SRAM is SOC specific construction and the spec here provides recommendations on using MCU and Caliptra to build such a logic. Please refer to Caliptra subsystem hardware specification for construction specifics (Hint: These functions are integrated into Manufacturer Control Interface [MCI]).
   2. Any logic outside of the Caliptra Subsystem boundary is SoC specific and will be custom to the SoC design. This specification provides recommendations for how Caliptra and MCU may be integrated into the SoC.

FIXME: Add the visio flow picture

Subsystem support for Hitless Updates

Caliptra Hitless Update

1. Payloads of all hitless update come over DSP0267 PLDM for Firmware Update over MCTP flow to the MCU similar to the boot time flows.
2. MCU provides SOC manifest to Caliptra and waits for authentication to be successful. If this wasn’t provided Caliptra will use the latest SOC manifest available.
   1. If failed, MCU uses DSP0267 PLDM for Firmware Update over MCTP to report the same to the update agent using PLDM protocol
3. MCU provides the Caliptra FW using Caliptra Mailbox using the hitless update flows documented in the Caliptra specification

MCU Hitless Update

1. Payloads of all hitless update come over DSP0267 PLDM for Firmware Update over MCTP flow to the MCU similar to the boot time flows.
2. MCU provides SOC manifest to Caliptra and waits for authentication to be successful. If this wasn’t provided Caliptra will use the latest SOC manifest available.
   1. If failed, MCU uses DSP0267 PLDM for Firmware Update over MCTP to report the same to the update agent using PLDM protocol
3. MCU stages the incoming FW payload in an SOC-defined staging SRAM and provides the MMIO address of the staging memory to Caliptra. It is better to keep this as a part of the authenticated SOC manifest (as a configuration) from a security perspective.
4. Caliptra RT FW will use the Caliptra DMA engine to issue the read and hash the image (note that the length of the image must be part of the SOC manifest)
5. Caliptra RT FW after verifying/authorizing the image and if it passes, waits for activate command to be issued from MCU. MCU will get this command over DSP0267 PLDM for Firmware Update over MCTP flow; At this point, Caliptra will reset EXEC/GO bit into the register as specified in the previous command. This register write will also deassert a Caliptra interface wire.
6. MCU HW logic will use this indication to initiate MCU uC reset flow
   1. MCU HW logic sends a reset-go-req to MCU uC (an interrupt)
   2. MCU HW logic waits for reset-go-ack from MCU uC (Note that this handshake exists to ensure uController is in an appropriate quiescent state to take the reset)
   3. MCU HW logic will assert the reset to the MCU uC
7. Caliptra RT FW will wait for reset assertion and then read the staged SRAM over AXI manager interface and write the image to the MCU SRAM aperture (that is open to Caliptra only by HW construction).
   1. The address of the MCU SRAM is provided to Caliptra’s RT FW through SOC manifest.
   2. Note: From the validation front, need to ensure the Caliptra ROM and MCU are aligned in endianness.
   3. Note: True downtime of MCU is from when its reset is asserted; It is SOC implementation requirement that it handles (eg. through buffering) all transactions to MCU while it is going through a hitless update.
8. After the MCU SRAM is populated, Caliptra RT FW will set EXEC/GO bit into the register as specified in the previous command. This register write will also assert a Caliptra interface wire.
9. MCU HW logic will use this indication to deassert the MCU reset.
10. MCU ROM will look at the breadcrumb that the MCU SRAM has valid content and will start the execution from it directly. NOTE: This breadcrumb should be one of the status bits available on the MCU interface that is set by Caliptra GO bit wires.

SoC-FW Hitless Update

SoC may have other components that may need to be updated at run-time in a hitless/impactless manner.

The update flow will follow the same sequence as MCU Hitless update except they are executed by the MCU by using Caliptra as the RoT engine for doing all the required authentication/authorization flows.

Further SoCs may require the hitless update without impacting the workloads/VMs running on the host or the VMs using the devices. This essentially means that impactless update must happen without causing any timeouts to the in-flight transactions. While the treatment of those transactions are device dependent, Caliptra subsystem must provide a way to be able to authenticate and activate the FW in the shortest time possible.

Caliptra subsystem provides this architectural capability as follows:

1. MCU provides SOC manifest to Caliptra and waits for authentication to be successful. If this wasn’t provided Caliptra will use the latest SOC manifest available.
   1. If failed, MCU uses DSP0267 PLDM for Firmware Update over MCTP to report the same to the update agent using PLDM protocol
2. MCU stages all the incoming FW payload in an SOC-defined staging memory and provides the MMIO address of the staging SRAM to Caliptra. It is better to keep this as a part of the authenticated SOC manifest (as a configuration) from security perspective. (FW Arch requirement: This SOC-defined staging RAM MMIO offset which can be one for all the images or it could be per image, recommended to keep it the later way, should be defined in the SOC manifest.)
3. Caliptra RT FW will use the Caliptra DMA engine to issue the read and hash the image (note that the length of the each image must be part of the SOC manifest)
4. Caliptra RT FW will verify & authorize the images. It will also compare the hash of the images against the “current” hash of each of the image.
5. MCU will send the ‘activate’ command to Caliptra (which is part of PLDM spec that MCU understands)
6. If MCU FW is updated/new, Caliptra will execute the MCU Hitless update flow.
7. Caliptra RT FW will then set the GO bits for all the SoC FWs that are updated (vs what was already running)
8. SoC specific logic & MCU RT FW will use this information to update the remaining FW using SoC specific architectural flows. Note: Since this work is mainly distribution of the FW to the destination uCs, SoC should be built to do this flow as fast as possible to meet workload non-interruption/impactless requirements.

Multi-Chiplet Flows

This section explain how generic FW Load Flows would function for SoCs with multiple chiplets that are required to have their security controller functions. It is plausible that a SoC is built with a single security controller active on one chiplet and that serves all other chiplets.

Note: Additional control signals that MCU would control are SoC specific and are implemented through SoC widget(s).

1. Primary tile uses Caliptra-Subsystem-Mode at its silicon boot time
2. Secondary tile’s MCU ROM will go through the same common boot flow as the primary tile (except the peripheral could be inter-chiplet link).
3. Secondary tile’s MCU ROM will wait for inter-chiplet link to be available for use (this would be an indication to MCU ROM)
4. Primary tile’s MCU RT FW will fetch the secondary tile’s FW using DSP0267 PLDM for Firmware Update over MCTP T5 flow and ‘stream’ using the streaming boot interface protocol to the secondary tile(s).
5. Based on SOC integration, inter-chiplet could be an intelligent peripheral that can DMA or implement data payload registers for Caliptra to read.
   1. Note that the indication from Caliptra for “next-image” follows the same streaming boot interface protocol.
   2. Note that to load the remaining images of a secondary tile, SOC can choose to do streaming boot flow for rest of the remaining images. Depending on the SOC architecture and chiplets, MCU RT FW may coordinate the SOC to boot in such a way that it “broadcasts” the same image to multiple chiplets that require the same image. This is a SOC optimized flow outside of Caliptra or Subsystem Context.

Caliptra Subsystem I3C Streaming Boot Interface

The streaming boot interface is implemented as an I3C target with commands defined by the OCP Recovery specification. It will have a unique address compared to any other I3C endpoint for the device. It will comply with I3C Basic v1.1.1 specification. It will support I3C read and write transfer operations. It must support Max read and write data transfer of 1-260B excluding the command code (1 Byte), length (2 Byte), and PEC (1 Byte), total 4 Byte I3C header. Therefore, max streaming boot data per transfer will be limited to 256-byte data.

I3C streaming boot interface is responsible for the following list of actions:

1. Responding to command sent by Recovery Agent (RA)
2. Updating status registers based on interaction of AC-RoT and other devices
3. Asserting / Deasserting “payload_available” & “image_activated” signals

OCP Recovery Interface Hardware Specifications

• Reference specifications for streaming boot sequence,
  • OCP Secure Firmware recovery Spec rev 1.1-rc6
  • I3C core specification
  • Flashless Boot using OCP, PCIe, and DMTF Standards

Caliptra Subsystem Streaming Boot Interface Hardware

Please refer to Caliptra subsystem Hardware specification.

Caliptra Subsystem Streaming Boot Sequence

1. MCU ROM initializes the PROT_CAP, DEVICE_STATUS, DEVICE_ID, and HW_STATUS registers. Any other I3C initialization settings must be confirmed against I3C core specification.
2. Caliptra ROM updates the PROT_CAP register to set "Flashless boot (From RESET)", "FIFO CMS Support", and "Push-C-Image Support".
3. To start streaming boot, Caliptra ROM updates the DEVICE_STATUS register to "Recovery mode - ready to accept recovery image” for Device status byte (for the first image only) and "Flashless/Streaming Boot (FSB)" for Recovery reason codes.
4. Caliptra ROM updates the RECOVERY_STATUS register to "Awaiting Recovery Image" for Device recovery status and "image index" for Recovery image index.
5. BMC or a similar platform component sends an INDIRECT_FIFO_CTRL write command with Component Memory Space (CMS) set to 0x0, reset set to 0x1, and image size set to streaming boot image size.
6. BMC or a similar platform component sends an INDIRECT_FIFO_DATA write command. I3C device shall return a NACK response for any transfer that would cause the Head Pointer to advance to equal the Tail Pointer. BMC can implement flow control through NACK responses or by monitoring the FIFO space remaining via the Head and Tail Pointers.
7. The I3C device keeps head and tail pointers along with FIFO status up to date in the INDIRECT_FIFO_STATUS register. I3C streaming boot interface HW waits for an update to INDIRECT_FIFO_DATA with exactly 256 bytes of data or less if remaining image data is less than 256 bytes. BMC could send multiple commands to INDIRECT_FIFO_DATA register to fill the FIFO, but it must be a multiple of 4 bytes. The I3C device indicates payload availability only if the FIFO is full (256 bytes) or if BMC writes to image activation byte in RECOVERY_CTRL register.
8. If INDIRECT_FIFO_DATA has 256B available to read, I3C device indicates data availability via side channel implemented as wire payload_available to Caliptra. For more information, see Requirement for payload available signal Implementation. Caliptra HW latches this wire into the register for Caliptra ROM/firmware to read.
9. If payload_available is asserted for the first time, Caliptra ROM reads INDIRECT_FIFO_CTRL_IMG_SIZE for the image size. For each payload_available assertion including the first one, Caliptra ROM continues to read the image data from the INDIRECT_FIFO_DATA register until it finishes reading the data count specified as the image size.
10. Steps 8 and 9 repeat until all the image bytes are pushed over I3C and it matches the image size initialized in the INDIRECT_FIFO_CTRL_IMG_SIZE register.
11. When all the image bytes are received, Caliptra ROM sets DEVICE_STATUS to "Recovery Pending (waiting for activation)". During image authentication, DEVICE_STATUS register field device status remains "Recovery Pending (waiting for activation)".
12. After the above steps, Caliptra ROM/Firmware waits for BMC to activate the image. Image activation is indicated to Caliptra via either of the following methods:

• Side channel image_activated signal. For more information, see Requirement for image activation signal implementation.
• Caliptra ROM polls on RECOVERY_CTRL register for image activation status.

13. When the image is activated, Caliptra ROM updates RECOVERY_STATUS to “Booting recovery image” and moves to image authentication.
14. Irrespective of success or failure from image authentication (step 15 or 16), Caliptra ROM clears the image activation status before updating RECOVERY_STATUS & DEVICE_STATUS registers.
15. If the image activation is successful, and another recovery image stage is expected, then Caliptra RT firmware shall increment the “Recovery image index” in RECOVERY_STATUS register and set the RECOVERY_STATUS to indicate “Awaiting recovery image” (0x1). If no other stages are expected, then Caliptra RT firmware shall set the RECOVERY_STATUS to “Recovery successful”. Also, Caliptra ROM/Caliptra RT must update the DEVICE_STATUS register to indicate "Running Recovery Image".
16. If the image consumption fails for any reason (for example, image authentication failure), Caliptra ROM/firmware updates RECOVERY_STATUS register to indicate appropriate recovery status and DEVICE_STATUS register to "Fatal Error (Recover Reason Code not populated)".
17. BMC or a similar platform component sends the next image as requested in the image index, upon observing “Awaiting recovery image” in RECOVERY_STATUS register, and Caliptra RT FW and I3C HW go through the same flow as above.

Streaming Boot Sequence notes

• ROM refers to I3C registers by offset, and any change to the offset results in ROM failure or unexpected behavior.
• SoC is responsible for booting the I3C Core by configuring clock frequency/sampling rate with the following registers and any other requirements specified in I3C core specifications.
• SoC is responsible for assigning static addresses to the I3C Core.
• Caliptra ROM/runtime firmware updates the RECOVERY_STATUS with the recovery image index.
  • For recovery image index:
    • 0x0: Caliptra firmware
    • 0x1: SoC Manifest
    • 0x2: MCU firmware
• SoC/MCU ROM sets the HW_STATUS register per recovery spec at any time based on SoC-specific conditions.
• MCU ROM programs DEVICE_ID register value based on associated fuse values.
• SoC/MCU ROM initializes the PROT_CAP, DEVICE_ID, and DEVICE_STATUS registers.
• Caliptra ROM performs only read-modify-write (RMW) for updates to registers.
• I3C device must update FIFO size (1-256 Byte), Max transfer size and type of region (tie this to 0x1) to INDIRECT_FIFO_STATUS register, which could be read by BMC firmware to understand the size of the FIFO and max transfer size.
• BMC is responsible for re-sending the transaction if it fails due to PEC error.
• ALL Caliptra ROM accesses to recovery interface are completed via DMA assist.

Requirement for Payload Available Signal Implementation

• Name: payload_available
• Type: 1 bit wire
• Source: Recovery Interface / I3C Core
• Destination: Caliptra core

Assertion

• The payload_available signal must assert under either of the following conditions:
  • If the recovery FIFO indicates full (256 bytes).
  • If the image activation status is asserted and the recovery FIFO indicates not empty for the last transfer.

De-assertion

• The payload_available signal must reset if recovery FIFO indicates empty.

Requirement for Image Activation Signal Implementation

• Name: image_activated
• Type: 1 bit wire
• Source: Recovery Interface
• Destination: Caliptra core

Assertion

• The image_activated signal must assert when RECOVERY_CTRL register byte 2 has value 0xf (indicating image activation).

De-assertion

• The image_activated signal must deassert when the RECOVERY_CTRL register byte 2 has value 0x0 (indicating image activation is cleared).

Platform component requirements for recovery support

1. The BMC, or a similar platform, should not send payload to streaming boot interface (/I3C target) device if RECOVERY_CTRL register has byte 2 indicating Image Activated. BMC must wait to clear the byte 2. (Streaming boot interface is responsible for clearing this byte by writing 1).
2. The BMC, or a similar platform, sends payload to I3C target device in chunks of 256 bytes (header (4B) + FW bytes(256B) as I3C target transfer) only, unless it is the last write for the image. Before sending the payload, it reads FIFO empty status from INDIRECT_FIFO_STATUS register.
3. After the last write for the image, the BMC, or a similar platform, activates the image.

Life Cycle Controller & SoC Debug Architecture

Please refer to Caliptra subsystem hardware specification.

OCP L.O.C.K. HW Architecture and Security Claims

Please refer to Caliptra and Caliptra subsystem hardware specification for HW implementation details and Key Vault (KV) rules.

Security Claims and Assumptions

• The OCP LOCK implementation employs NIST approved algorithms (e.g., AES, SHA‑2/HMAC)
• Certain secret keys involved in OCP LOCK (HEK/HEK_SEED, de‑obf key, MEK, etc.) are never readable by firmware and are only usable by cryptographic engines or DMA via KV references. KV entries carry lock bits (lock‑write, lock‑use) that enforce non‑observability and immutability until uC reset.
• If Caliptra runtime firmware (RT FW) is compromised, it can generate an arbitrary new MEK and release it via the allowed DMA path; this does not break confidentiality of media encrypted under earlier MEKs, because ciphertext written prior to FW compromise remains bound to different keys.
• MEK generation flow is not isolated from RT FW. MEK load flow is protected from RT FW and this FW can generate a new MEK (e.g., for rotation) but cannot re‑materialize a previous MEK except by executing the OCP LOCK MEK load flow under ROM‑enabled KV rules and secrets. Recovering a MEK from its wrapped/encrypted form uses LOCK‑scoped KV slots, filtering, and AES write‑path policy; the unwrap/decryption outputs to the designated KV slot, not to FW.
• DMA offset used to send MEK is locked when the FUSE_WR_DONE is set to high and cannot be changed until the next cold boot.
• Caliptra subsystem’s security boundary ends at the Caliptra core DMA write of MEK into the required destination (offset determined through strap by integrator); confidentiality/integrity beyond that destination is the SoC owner’s responsibility.
• KV rules ensure that a KV slot can be used as AES key but cannot be used as AES plaintext or ciphertext, except for MEK encryption KV slot which has its own unique rule.
• ROM sequencing & enablement: Caliptra ROM sets OCP_LOCK_IN_PROGRESS before any RT FW OCP LOCK operation, which enables the KV filtering/isolation logic and the Key Release path; if not set, OCP LOCK data paths are disabled. If the OCP LOCK is intended to be used, Caliptra ROM MUST set the OCP_LOCK_IN_PROGRESS to high.
• The integrator sets OCP_LOCK enable strap pin (a HW tieoff pin, not modifiable by SW) at integration time and Caliptra ROM sets OCP_LOCK_IN_PROGRESS before any OCP LOCK operation, which enables the KV Slot filtering/isolation logic and the Key Release path; if not set, OCP LOCK data paths are disabled. This rule also ensures that any potential security issue comes from OCP LOCK is under the quarantine of OCP LOCK boundary and does not affect Caliptra’s rest of KV slots. However, KV 16 has a different rule because it is populated by Caliptra ROM, which sets OCP_LOCK_IN_PROGRESS bit. Thus, KV 16 is restricted with OCP_LOCK_ENABLE strap pin but not by OCP_LOCK_IN_PROGRESS.
• While OCP LOCK is in progress, AES operations cannot be abused by malicious FW to perform arbitrary AES operation into KV to exfiltrate or implant-control data if it is not for MEK decryption process and MEK decryption KV slots. KV write‑path restrictions are enforced in HW: mode check + key/slot policy; destination is forced to a designated LOCK slot; other AES ops route only to FW data‑out, not KV; write‑enable hardened to prevent mid‑transfer changes.
• DMA data FIFOs are flushed after every DMA transfer, ensuring that there is no residue data remaining from MEK after the OCP LOCK flow completion
• Caliptra top enforces mutual exclusion (BUSY checks / HW_ERROR) while LOCK flows are active; KV rules enforce single active engine for read/write correctness.
• Any KV slot that stores a secret value can be partially overwritten by the HMAC core, since HMAC writes 384 bits of a 512-bit slot. However, the HMAC core always sets the last valid d-word flag when performing this partial overwrite. This flag ensures that any remaining 128 bits in the slot are treated as invalid, preventing an adversary from exploiting the unchanged portion for pre-image recovery. If the last valid d-word flag is set for 384-bit and HMAC is triggered for 512-bit, HMAC core generates an error signal. Similarly, AES cannot perform arbitrary encryption or decryption using partially overwritten KV slots because AES keys are at most 256 bits and always start from the least significant bits (LSB) of the slot. Since HMAC writes a minimum of 384 bits, any AES operation will necessarily use the updated portion of the slot, not any stale data. The same KV slot may also be reused for ML-KEM or ECC operations. These are asymmetric cryptographic operations where the secret is either a private key or a seed used to derive the private key. Partial overwrites do not expose these secrets. While it could be argued that such secrets might be manipulated to sign arbitrary data or perform unauthorized decapsulation, these operations can only occur after ROM execution—at which point Caliptra secrets are either cleared or locked, eliminating this risk. OCP LOCK utilizes ML-KEM and ECDH for the key wrapping operations however these operations do not go through KV and managed by RT FW and thus these are out of scope of this partial write feature.
• MEK, HEK seed, MEK encryption key cannot be copied. This is an important isolation guarantee.
• Single-encrypted ("obfuscated") MEK is exposed to RT FW of Caliptra. If malicious firmware gains access to the obfuscated MEK it can successfully derive the MEK to KV23 and release it to the SSD controller without requiring any other security inputs (Access Keys, MPK, EPK, etc). Firmware must clear it from memory immediately after use.

Terminology

The following acronyms and abbreviations are used throughout this document.

References

1. NIST Special Publication 800-193 Platform Firmware Resiliency Guidelines
2. Global Platform Technology Root of Trust Definitions and Requirements Version 1.1 Public
3. Open Compute Project Secure Boot Specification
4. TCG DICE Layering Architecture Version 1.0 Revision 0.19 July 23, 2020
5. TCG DICE Attestation Architecture Version 1.00 Revision 0.23 March 1, 2021
6. TCG Hardware Requirements for a Device Identifier Composition Engine Family “2.0” Level
7. Side-Channel Attacks: Ten Years After Its Publication and the Impacts on Cryptographic Module Security Testing
8. Attestation of System Components v1.0 Requirements and Recommendations
9. OCP Security WG: Ownership Transfer

Acknowledgments

The Caliptra Workgroup acknowledges the following individuals for their contributions to this specification.

CONTRIBUTORS

• Akash Singh (NVIDIA)
• Alex Tzonkov (AMD)
• Andrés Lagar-Cavilla (Google)
• Anjana Parthasarathy (Microsoft)
• Anthony Rocha (AMD)
• Avirup Mullick (NVIDIA)
• Bharat Pillilli (Microsoft)
• Bryan Kelly (Microsoft)
• Caleb Whitehead (Microsoft)
• Clayton Kuchta (Microsoft)
• Emre Karabulut (Microsoft)
• Howard Tran (Google)
• James Zhang (NVIDIA)
• Jeff Andersen (Google)
• John Traver (AMD)
• Jordan Hand (Google)
• Kiran Upadhyayula (Microsoft)
• Kor Nielsen (Google)
• Louis Ferraro (AMD)
• Marius Schilder (Google)
• Matt Cockrell (Google)
• Michael Norris (Microsoft)
• Mojtaba Bisheh Niasar (Microsoft)
• Nathan Nadarajah (AMD)
• Nilesh Patel (Microsoft)
• Norman Stewart (AMD)
• Paul Chou (NVIDIA)
• Piotr Kwidzinski (AMD)
• Prabhu Jayana (AMD)
• Rob Strong (AMD)
• Sudhir Mathane (AMD)
• Stephanie Morton (Google)
• Steven Bellock (NVIDIA)
• Varun Sampath (NVIDIA)
• Vishal Soni (Microsoft)
• Vishal Mhatre (Microsoft)

Footnotes

Version History

License

Open Web Foundation (OWF) CLA

Contributions to this Specification are made under the terms and conditions set forth in Modified Open Web Foundation Agreement 0.9 (OWFa 0.9). (As of October 16, 2024) (“Contribution License”) by:

• Google
• Microsoft
• Samsung
• Kioxia
• Solidigm

Usage of this Specification is governed by the terms and conditions set forth in Modified OWFa 0.9 Final Specification Agreement (FSA) (As of October 16, 2024) (“Specification License”).

You can review the applicable Specification License(s) referenced above by the contributors to this Specification on the OCP website at https://www.opencompute.org/contributions/templates-agreements.

For actual executed copies of either agreement, please contact OCP directly.

NOTWITHSTANDING THE FOREGOING LICENSES, THIS SPECIFICATION IS PROVIDED BY OCP "AS IS" AND OCP EXPRESSLY DISCLAIMS ANY WARRANTIES (EXPRESS, IMPLIED, OR OTHERWISE), INCLUDING IMPLIED WARRANTIES OF MERCHANTABILITY, NON-INFRINGEMENT, FITNESS FOR A PARTICULAR PURPOSE, OR TITLE, RELATED TO THE SPECIFICATION. NOTICE IS HEREBY GIVEN, THAT OTHER RIGHTS NOT GRANTED AS SET FORTH ABOVE, INCLUDING WITHOUT LIMITATION, RIGHTS OF THIRD PARTIES WHO DID NOT EXECUTE THE ABOVE LICENSES, MAY BE IMPLICATED BY THE IMPLEMENTATION OF OR COMPLIANCE WITH THIS SPECIFICATION. OCP IS NOT RESPONSIBLE FOR IDENTIFYING RIGHTS FOR WHICH A LICENSE MAY BE REQUIRED IN ORDER TO IMPLEMENT THIS SPECIFICATION. THE ENTIRE RISK AS TO IMPLEMENTING OR OTHERWISE USING THE SPECIFICATION IS ASSUMED BY YOU. IN NO EVENT WILL OCP BE LIABLE TO YOU FOR ANY MONETARY DAMAGES WITH RESPECT TO ANY CLAIMS RELATED TO, OR ARISING OUT OF YOUR USE OF THIS SPECIFICATION, INCLUDING BUT NOT LIMITED TO ANY LIABILITY FOR LOST PROFITS OR ANY CONSEQUENTIAL, INCIDENTAL, INDIRECT, SPECIAL OR PUNITIVE DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS SPECIFICATION, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND EVEN IF OCP HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Acknowledgements

The Contributors of this Specification would like to acknowledge the following:

• Andrés Lagar-Cavilla (Google)
• Amber Huffman (Google)
• Carl Lundin (Google)
• Charles Kunzman (Google)
• Chris Sabol (Google)
• Jeff Andersen (Google)
• Srini Narayanamurthy (Google)
• Zach Halvorsen (Google)
• Anjana Parthasarathy (Microsoft)
• B Keen (Microsoft)
• Bharat Pillilli (Microsoft)
• Bryan Kelly (Microsoft)
• Christopher Swenson (Microsoft)
• Eric Eilertson (Microsoft)
• Lee Prewitt (Microsoft)
• Michael Norris (Microsoft)
• Eric Hibbard (Samsung)
• Gwangbae Choi (Samsung)
• Jisoo Kim (Samsung)
• Michael Allison (Samsung)
• Festus Hategekimana (Solidigm)
• Gamil Cain (Solidigm)
• Scott Shadley (Solidigm)
• Fred Knight (Kioxia)
• James Borden (Kioxia)
• John Geldman (Kioxia)
• Paul Suhler (Kioxia)
• Artem Zankovich (Micron)
• Bharath Madanayakanahalli Gururaj (Micron)
• Jef Munsil (Micron)
• Jimmy Ruane (Micron)
• Jonathan Chang (Micron)
• Rob Strong (Micron)

Compliance with OCP Tenets

Openness

OCP L.O.C.K. source for RTL and firmware will be licensed using the Apache 2.0 license. The specific mechanics and hosting of the code are work in progress due to CHIPS alliance timelines. Future versions of this spec will point to the relevant resources.

Efficiency

OCP L.O.C.K. is used to generate and load keys for use of encrypting user data prior to storing data at rest and decrypting stored user data at rest when read. So, it cannot yield a measurable impact on system efficiency.

Impact

OCP L.O.C.K. enables consistency and transparency to a foundational area of security of media encryption keys such that no drive firmware in the device ever has access to a media encryption key. Furthermore, no decrypted media encryption key exists in the device when power is removed from the device.

Scale

OCP L.O.C.K. is a committed intercept for storage products for Google and Microsoft. This scale covers both a significant portion of the hyperscale and enterprise markets.

Sustainability

The goal of OCP L.O.C.K. is to eliminate the need for cloud providers to destroy storage devices (e.g., SSDs) by providing a mechanism that increases the confidence that a media encryption key within the device is deleted during cryptographic erase. This enables repurposing the device and or components on the device at end of use or end of life. Given the size of the market serving cloud providers, this provides a significant reduction of e-waste.

Base specification

Introduction

OCP L.O.C.K. (Layered Open-source Cryptographic Key management) provides secure key management for Data-At-Rest protection in self-encrypting storage devices.

OCP L.O.C.K. was originally created as part of the Open Compute Project (OCP). The major revisions of the OCP L.O.C.K. specifications are published as part of Caliptra at OCP, as OCP L.O.C.K. is an extension to Caliptra. The evolving source code and documentation for Caliptra are in the repository within the CHIPS Alliance Project, a Series of LF Projects, LLC.

OCP L.O.C.K. may be integrated within a variety of self-encrypting storage devices, and is not restricted exclusively to NVMe™. OCP L.O.C.K. is designed for compatibility with the TCG Storage Architecture TCG Storage Architecture Core Specification, including support for TCG Opal¹ TCG Storage Security Subsystem Class: Opal Specification, Enterprise TCG Storage Security Subsystem Class: Enterprise, and Key Per I/O TCG Storage Security Subsystem Class (SSC): Key Per I/O specifications.

Background

In the life of a storage device in a datacenter, the device leaves the supplier, a customer writes user data to the device, and then the device is decommissioned. Customer data is not allowed to leave the data center. The cloud provider needs high confidence that the storage device leaving the datacenter is secure. The current default cloud provider policy to ensure this level of security is to destroy the drive. Other policies may exist that leverage drive capabilities (e.g., cryptographic erase), but are not generally deemed inherently trustworthy by these cloud providers Self-encrypting deception: weaknesses in the encryption of solid state drives. This produces significant e-waste and inhibits any re-use/recycling.

Self-encrypting drives (SEDs) store data encrypted at rest using media encryption keys (MEKs). SEDs include the following building blocks:

• The storage media that holds data at rest.
• An encryption engine which performs line-rate encryption and decryption of data as it enters and exits the drive.
• A drive controller which exposes host-side APIs for managing the lifecycle of MEKs.

MEKs may be bound to user credentials, which the host must provide to the drive in order for the associated data to be readable. A given MEK may be bound to one or more credentials. This model is captured in the TCG Opal and Enterprise specifications.

MEKs may be erased, to cryptographically erase all data which was encrypted to the MEK. To erase an MEK, it is sufficient for the drive to erase all copies of it, or all copies of a key with which it was protected.

Threat model

The protected asset is the user data stored at rest on the drive. The adversary profile extends up to nation-states in terms of capabilities.

Adversary capabilities include:

• Interception of a storage device in the supply chain.
• Theft of a storage device from a data center.
• Destructively inspecting a stolen device.
• Running arbitrary firmware on a stolen device.
  • This includes attacks where vendor firmware signing keys have been compromised.
• Attempting to glitch execution of code running on general-purpose cores.
• Stealing debug core dumps or UART/serial logs from a device while it is operating in a data center, and later stealing the device.
• Gaining access to any class secrets, global secrets, or symmetric secrets shared between the device and an external entity.
• Executing code within a virtual machine on a multi-tenant host offered by the cloud provider which manages an attached storage device.
• Accessing all device design documents, code, and RTL.

Given this adversary profile, the following are a list of vulnerabilities that OCP L.O.C.K. is designed to mitigate.

• MEKs managed by storage drive firmware are compromised due to implementation bugs or side-channels.
• MEKs erased by storage drive firmware are recoverable via invasive techniques.
• MEKs are not fully bound to user credentials due to implementation bugs.
• MEKs are bound to user credentials which are compromised by a vulnerable host.
• Cryptographic erase was not performed properly due to a buggy host.

OCP L.O.C.K. goals

OCP L.O.C.K. is being defined to improve drive security. In an SED that integrates Caliptra with OCP L.O.C.K. features enabled, Caliptra will act as a Key Management Block (KMB). The KMB will be the only entity that can read MEKs and program them into the SED's encryption engine. The KMB will expose services to drive firmware which will allow the drive to transparently manage each MEK's lifecycle, without being able to access the raw MEK itself.

The OCP L.O.C.K. KMB satisfies the following properties:

• Prevents leakage of media keys via firmware vulnerabilities or side-channels, by isolating MEKs to a trusted component.
• Binds MEKs to a given set of externally-supplied access keys, provisioned with replay-resistant transport security such that they can be injected without trusting the host.
• Uses epoch keys for attestable epoch-based cryptographic erase.

Non-goals

The following areas are out of scope for this project.

• Compliance with IEEE 1619^TM^-2025 IEEE Draft Standard for Cryptographic Protection of Data on Block-Oriented Storage Devices requirements around key scope, i.e. restricting a given MEK to only encrypt a maximum of 2^44^ 128-bit blocks. Drive firmware will be responsible for enforcing this.
• Compliance with Common Criteria requirement FCS_CKM.1.1(c) collaborative Protection Profile for Full Drive Encryption - Encryption Engine when supporting derived MEKs. Key Per I/O calls for DEKs to be injected into the device. To support OCP L.O.C.K.'s goals around enabling cryptographic erase, before the injected DEK is used to encrypt user data, the DEK is first conditioned with an on-device secret that can be securely zeroized. FCS_CKM.1.1(c) currently does not allow injected keys to be thus conditioned and therefore does not allow for cryptographic erase under the Key Per I/O model. A storage device that integrates OCP L.O.C.K. and aims to be compliant with this Common Criteria requirement may not support Key Per I/O.
• Authorization for EPK/DPK/MPK rotation, or binding a given MEK to a particular locking range. Drive firmware is responsible for these.
• Mitigation against availability attacks carried out by attackers with physical presence.

Integrating OCP L.O.C.K.

OCP L.O.C.K. is a feature set conditionally compiled into Caliptra Subsystem 2.1+. It consists of functionality in Caliptra ROM and Runtime Firmware along with a hardware interface from Caliptra Core to a vendor-implemented encryption engine, which is the path by which Caliptra Core programs MEKs. This hardware interface leverages the AXI Manager which is only available in Caliptra Subsystem.

OCP L.O.C.K.'s KMB offers cryptographic services for drive firmware, which implements a host-facing storage interface, such as TCG Opal, Enterprise, or Key Per I/O. The host will interact with drive firmware to configure the storage device and actuate storage lifecycle events, such as MEK loading / unloading and cryptographic erase. Certain of these lifecycle events are handled by KMB on behalf of drive firmware.

In Caliptra Subsystem, drive firmware runs within the Manufacturer Control Unit (MCU) Caliptra 2.0 Subsystem Specification.

Integration verification

A product that integrates OCP L.O.C.K. will be expected to undergo an OCP S.A.F.E. review to ensure that L.O.C.K. is correctly integrated and that drive firmware correctly invokes L.O.C.K. services.

Architecture

{#architecture-diagram}

To safeguard user data stored on the drive, KMB defines a set of "protection keys", each of which must be available in order for an MEK to be accessible.

• The data protection key (DPK), which is managed by the nominal owner of the data. A given MEK is bound to a single DPK.

  • In Opal or Enterprise the DPK may be protected by the user's C_PIN, while in Key Per I/O the DPK may be the DEK associated with a given key tag.

• A configurable number of Multi-party Protection Keys (MPKs), which are each managed by an additional entity that must assent before user data is available. A given MEK may be bound to zero or more MPKs.

  • Each multi-party entity grants access to the data by providing an access key to the drive. Each MPK is protected by a distinct access key, which is never stored persistently within the drive. MPK access keys are protected in transit using HPKE Hybrid Public Key Encryption. This enables use-cases where the access key is served to the drive from a remote key management service, without revealing the access key to the drive's host.
  • Binding an MEK to zero MPKs allows for legacy Opal, Enterprise, or Key Per I/O support.

• A composite epoch protection key (EPK), which is the output of a KDF of two "component epoch keys" held within the device: the Soft Epoch Key (SEK) and the Hard Epoch Key (HEK). The EPK is managed by the storage device itself, and all MEKs in use by the device are bound to it.

  • All MEKs in use by the drive can be cryptographically erased by zeroizing either the SEK or HEK. New MEKs shall not be loadable until the zeroized epoch keys are regenerated.
  • KMB reports the zeroization state of the SEK and HEK, and therefore whether the drive is in a cryptographically erased state.
  • The SEK is managed by drive firmware and shall be held in rewritable storage, e.g. in flash memory.
  • The HEK is derived from a seed held in fuses and is only visible to KMB hardware. This provides assurance that an advanced adversary is unable to recover key material that had been in use by the drive prior to HEK seed zeroization.

The EPK, DPK, and set of configured MPKs are used together to derive an MEK secret, which protects a given MEK. The MEK protection is implemented as one of two methods:

• MEK encryption - the drive obtains a random MEK from KMB, encrypted by two keys: the MEK secret and the MEK Deobfuscation Key (MDK), and is allowed to load that wrapped MEK into the encryption engine via KMB. This supports Opal or Enterprise use-cases.

• MEK derivation - the drive instructs KMB to derive an MEK from the MEK secret and load the MEK into the encryption engine. This may support either Opal, Enterprise, or Key Per I/O use-cases.

MEKs are never visible to drive firmware. Drive firmware instructs KMB to load MEKs into the key cache of the encryption engine, using standard interfaces described in Section. Each MEK has associated vendor-defined metadata, e.g. to identify the namespace and LBA range to be encrypted by the MEK.

KMB shall not cache MEKs in memory. The encryption engine shall remove all MEKs from the encryption engine on a power cycle or upon request from drive firmware.

All keys randomly generated by KMB are generated using a DRBG seeded by Caliptra's TRNG. The DRBG may be updated using entropy provided by the host.

Key hierarchy

{#key-hierarchy}

Table enumerates the CSPs (Critical Security Parameters) used by KMB, along with where each CSP is held in the Key Vault (KV). KV slots 16-23 are reserved for OCP L.O.C.K.

Table: Critical Security Parameters {#critical-security-parameters}

Key Vault

Some elements of the OCP L.O.C.K. key hierarchy are held in the Caliptra Key Vault. Such keys are wielded directly by hardware and cannot be read by firmware.

Other elements of the key hierarchy are not thus protected, and are held in KMB's memory instead. Table describes why each such CSP is held outside of the Key Vault.

Table: CSPs visible to KMB firmware {#fw-visible-csps}

All keys held by KMB firmware are protected by Caliptra, and cannot be viewed by drive firmware.

Key Derivation

In this specification, several flows involve deriving keys via a key derivation function (KDF). This specification leverages the KDF in Counter Mode defined in NIST SP 800-108 Recommendation for Key Derivation Using Pseudorandom Functions (Rev. 1) section 4.1, where the PRF is HMAC512. As each key produced by this KDF is no larger than 512 bits, a single invocation of the underlying PRF is needed. Therefore, each instance of `SP 800-108 KDF` in subsequent flows deconstructs to the following operation:

\(K_{OUT}\) = HMAC512(\(K_{IN}\), 0x01 || Label [ || 0x00 || Context])

There is one exception to this in Section, where CMAC instead of HMAC is used as the PRF for a particular instance of KDF. See Section for details.

Preconditioned AES

In this specification, several flows involve deriving a key for use in AES-GCM. In AES-GCM it is critical that IV collisions be avoided. To that end SP 800-38D Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC section 8.3 stipulates that AES-GCM-Encrypt may only be invoked at most \(2^{32}\) times with a given AES key. One approach to address this constraint is to maintain counters to track the usage count of a given key. Such tracking would be difficult for Caliptra, which lacks direct access to rewritable storage which would be needed to maintain a counter that preserves its value across power cycles.

To elide the need for maintaining counters, this specification defines the "preconditioned AES-Encrypt" and "preconditioned AES-Decrypt" operations, illustrated in Figures [-Figure] and [-Figure]. These operations are similar in principle to XAES-256-GCM The XAES-256-GCM extended-nonce AEAD.

{#preconditioned-aes-encrypt}

{#preconditioned-aes-decrypt}

Each encryption key is preconditioned using a randomly-generated 96-bit salt to compute a subkey, which is used with AES-GCM-Encrypt. This ensures that it is safe to use a given input encryption key in approximately \(2^{80}\) preconditioned AES-Encrypt operations before an IV collision is expected to occur with probability greater than \(2^{-32}\). The \(2^{80}\) limit is large enough that a given storage device will experience hardware failure well before that limit is reached. Ergo, usage counters within the drive are not needed for these keys. See [Appendix Section] for additional details on the calculations behind this figure.

In addition to a plaintext message, this operation supports optional metadata for the message, which is attached as AAD.

VEK

The Volatile Escrow Key (VEK) is held in the Key Vault and is used to protect volatile keys held outside of the Key Vault, specifically Enabled MPKs.

The VEK is lazily generated upon first use and is lost when the drive shuts down. Lazy generation allows injected host entropy to contribute to the key's generation.

The VEK is randomly generated and held in a Key Vault slot. There does not exist a hardware data path directly between Caliptra's DRBG and Key Vault. Therefore, KMB firmware will read random data from the DRBG and send it to the Key Vault. To prevent KMB firmware from seeing the actual VEK, the randomness obtained by firmware is permuted using the HEK, as illustrated in Figure.

{#vek-generation}

MPKs

Multi-party Protection Keys (MPKs) are the mechanism by which KMB enforces multi-party authorization as a precondition to loading an MEK. MPKs exist in one of two states: locked or enabled. In both these states the MPK is encrypted to a secret known only to KMB.

• A Locked MPK's encryption key is derived from the HEK, SEK, and an externally-supplied access key to which the MPK is bound. The Locked MPK is held at rest by drive firmware.
• An Enabled MPK's encryption key is a common volatile secret held within KMB which is randomly generated and is lost when the drive shuts down. See Section for details on how this key is generated. Enabled MPKs are held in drive firmware memory.

The externally-supplied access key is encrypted in transit using an HPKE public key held by KMB. The "enabled" state allows the HPKE keypair to be rotated after the access key has been provisioned to the storage device, without removing the ability for KMB to decrypt the MPK when later loading an MEK bound to that MPK.

For each MPK to which a given MEK is bound, the host is expected to supply the MPK's encrypted access key to drive firmware via a host-facing API. Upon receipt, drive firmware passes that encrypted access key to KMB, along with the Locked MPK, to produce the Enabled MPK which is cached in drive memory. This is performed once for each MPK to which the MEK is bound, prior to drive firmware instructing KMB to program the MEK. See Section for details on how host-facing APIs map to KMB mailbox commands.

Transport encryption for MPK access keys

KMB maintains a set of HPKE keypairs, one per HPKE algorithm that KMB supports. Each HPKE public key is endorsed with a certificate that is generated by KMB and signed by Caliptra's DICE TCG DICE identity. HPKE keypairs are randomly generated on KMB startup, and mapped to unique handles. Keypairs may be periodically rotated. Drive firmware is responsible for enumerating the available HPKE public keys and exposing them to the user via a host interface. See Section for how the public keys may be presented to the host.

When a user wishes to generate or enable an MPK (which is required prior to loading any MEKs bound to that MPK), the user performs the following steps:

1. Select the HPKE public key and obtain its certificate from the storage device.
2. Validate the HPKE certificate and attached DICE certificate chain.
3. Decode the HPKE capabilities of the storage device based on the HPKE certificate.
4. Seal their access key using the HPKE public key.
5. Transmit the sealed access key to the storage device.

Upon receipt, KMB will unwrap the access key and proceed to generate or enable the MPK.

Upon Caliptra cold reset or firmware-update reset, the HPKE keypairs are autonomously regenerated. See Section.

HPKE algorithm support

An HPKE variant relies on three types of algorithms: KEM, KDF, and AEAD. Table describes the HPKE algorithms that KMB supports.

Table: HPKE algorithm support {#hpke-algorithm-support}

| +---------------------+-----------+-------------------------------+ || P-384 | 0x0011 | RFC 9180 Hybrid Public Key Encryption |

+-----------+---------------------+-----------+ | | KDF | HKDF-SHA384 | 0x0002 ||

+-----------+---------------------+-----------+ | | AEAD | AES-256-GCM | 0x0002 ||

+-----------+---------------------+-----------+-------------------------------+

The definitions for the post-quantum KEMs are currently distributed across a number of documents. Hybrid PQ/T Key Encapsulation Mechanisms contains generic constructions, Concrete Hybrid PQ/T Key Encapsulation Mechanisms contains concrete parameterizations, and Post-Quantum and Post-Quantum/Traditional Hybrid Algorithms for HPKE contains HPKE IANA code-point assignments.³

Figures [-Figure], [-Figure], and [-Figure] illustrate each KEM algorithm. The details of how the AES-GCM key and IV are derived are illustrated in Figure.

{#hpke-kem-mlkem}

{#hpke-kem-hybrid}

{#hpke-kem-ecdh}

{#hpke-key-derivation}

The HPKE sequence number is incremented for each decryption operation performed with keys derived from a given HPKE context. With the exception of MPK access key rotation as described in Section, all flows that accept HPKE payloads will perform a single decryption operation with the computed context. MPK access key rotation will perform two decryption operations and will increment the sequence number between them.

HPKE public key endorsement

Upon request, KMB can issue an endorsement for a given HPKE public key, signed by Caliptra runtime firmware's DICE alias key. The endorsement and its fields are populated by KMB firmware. This is illustrated in Figure.

{#hpke-pub-key-endorsement}

The endorsement includes the HPKEIdentifiers extension as defined in TCG Storage Feature Set: Media Encryption Key Multiparty Authorization, with the `kem_id`, `kdf_id`, and `aead_id` identifiers populated based on the HPKE keypair's algorithms. See Table for the algorithm identifiers supported by KMB.

MPK lifecycle

MPKs can be generated, enabled, and have their access keys rotated and tested.

MPK generation

Drive firmware may request that KMB generate an MPK, bound to a given access key.

To identify an MPK, at creation time drive firmware can provide "metadata" for the MPK, which is included in the generated Locked MPK and bound to the ciphertext as AAD. See Section for guidance on how drive firmware should populate the metadata field for the MPK. Note that "metadata" in this context refers to metadata about the MPK, and bears no relation to metadata about an MEK.

KMB performs the following steps:

1. Unwrap the given MPK access key using the HPKE keypair held within KMB.
2. Randomly generate an MPK.
3. Derive an MPK encryption key from the HEK, SEK, and decrypted access key.
4. Encrypt the MPK to the MPK encryption key, attaching the given metadata as AAD.
5. Return the encrypted MPK to drive firmware.

Drive firmware may then store the encrypted MPK in persistent storage.

{#mpk-generation}

MPK enabling

Encrypted MPKs stored at rest in persistent storage are considered "locked", and must be enabled before they can be used to load an MEK. Enabled MPKs are encrypted to the VEK when handled by drive firmware. Enabled MPKs are invalidated when the VEK is rotated, which occurs on Caliptra cold reset. See Section.

To enable an MPK, KMB performs the following steps:

1. Unwrap the given MPK access key using the HPKE keypair held within KMB.
2. Derive the MPK encryption key from the HEK, SEK, and decrypted access key.
3. Decrypt the MPK using the MPK encryption key.
4. Encrypt the MPK using the VEK, preserving the MPK metadata.
5. Return the re-encrypted "enabled" MPK to drive firmware.

Drive firmware may then stash the encrypted Enabled MPK in volatile storage, and later provide it to KMB when loading an MEK, as described in Section.

{#mpk-enabling}

MPK access key rotation

The access key to which an MPK is bound may be rotated. The user must prove that they have knowledge of both the current and new access key before a rotation is allowed. This is accomplished by the user wrapping both their current and new access key in the same HPKE payload. KMB performs the following steps:

1. Unwrap the given current access key and new access key using the HPKE keypair held within KMB, incrementing the HPKE sequence number between each decryption operation. Note that the sequence number increment is a side-effect of the `ContextR.Open()` HPKE operation.
2. Derive the current MPK encryption key from the HEK, SEK, and decrypted current access key.
3. Derive the new MPK encryption key from the HEK, SEK, and decrypted new access key.
4. Decrypt the MPK using the current MPK encryption key.
5. Encrypt the MPK using the new MPK encryption key, preserving the MPK metadata.
6. Return the re-encrypted MPK to drive firmware.

Drive firmware then zeroizes the old encrypted MPK and stores the new encrypted MPK in persistent storage.

{#mpk-access-key-rotation}

MPK access key testing

A user that has bound an access key to an MPK may wish to confirm that their access key is in fact bound to the MPK. This can be useful after an access key rotation, to ensure that the rotation executed successfully on the storage device.

To test an MPK, KMB receives a wrapped MPK, wrapped MPK access key, and freshness nonce. KMB then performs the following steps:

1. Unwrap the given MPK access key using the HPKE keypair held within KMB.
2. Derive the MPK encryption key from the HEK, SEK, and decrypted access key.
3. Verify the integrity of the MPK ciphertext and AAD using the MPK encryption key, discarding the decrypted MPK in the process.
4. Calculate and return the digest SHA2-384(MPK metadata || access key || nonce).

The user can then verify that the returned digest matches their expectation.

{#mpk-access-key-testing}

DPKs

Drive firmware provides a Data Protection Key (DPK) to KMB when generating, loading, or deriving an MEK. The DPK is used in a KDF, along with the HEK, SEK, and MPKs, to derive the MEK secret, as illustrated in Section.

Example flow when generating or loading an MEK

In this flow, the DPK may be encrypted by a user's C_PIN. Drive firmware logic which decrypts MEKs can be repurposed to produce the DPK. This flow may be used to support TCG Opal or Enterprise.

{#dpk-decryption}

Example flow when deriving an MEK

In this flow, the DPK may be the imported key associated with a Key Per I/O key tag.

{#dpk-injection}

HEKs and SEKs

KMB supports a pair of epoch keys: the Hard Epoch Key (HEK) and Soft Epoch Key (SEK). Both must be available, i.e. non-zeroized, in order for MEKs to be loaded.

• The HEK is derived from seeds held in Caliptra's fuse block, and is never visible outside of Caliptra. If the HEK is zeroized, KMB does not allow MEKs to be loaded, with edge cases detailed in Section.
• The SEK is managed by drive firmware, and may be stored in flash. If the SEK is not randomized, drive firmware is responsible for enforcing that MEKs are not loaded.

Zeroizing either the HEK or SEK is equivalent to performing a cryptographic erase. HEK zeroization is effectively a "hard" cryptographic erase, as it is highly difficult to recover secrets from a zeroized fuse bank.

The drive must only provide HEK seeds or SEKs to KMB that are cryptographically-strong random values, because otherwise it is not possible to cryptographically erase data through zeroization of those values. Note: as depicted in Figure, MCU ROM may provide an all-zeroes HEK seed to KMB, provided that it correctly indicates to KMB that the HEK seed is not randomized.

HEK lifecycle

Caliptra with L.O.C.K. features a series of n 256-bit HEK slots present in a fuse bank, dubbed HEK~0~..HEK~n-1~, where 4 ≤ n ≤ 16. The vendor is responsible for determining the number of HEK slots available in fuses. These HEK slots are programmed and read by MCU, via the Caliptra fuse controller. MCU is responsible for transitioning each HEK slot individually from blank → randomized → zeroized. HEK~x~ shall only be randomized once HEK~x-1~ has been zeroized. MCU shall zeroize a HEK slot by blowing every bit.

Each HEK slot contains a HEK seed. MCU ROM reads the currently-randomized HEK slot from fuses during cold reset, and passes its contents to Caliptra Core via a fuse register.

There are two edge cases where the HEK is available even if there is no randomized seed available in the HEK fuse bank. In both cases, the HEK is derived from an all-zeroes HEK seed.

• To enable pre-production testing, if Caliptra is in the Unprovisioned or Manufacturing lifecycle state, the HEK is available.

• To enable lengthening the useful lifespan of the storage device, once all HEK slots have been zeroized, the device can be permanently transitioned into a mode where the HEK is available. A field-programmable "permanent-HEK" logical fuse bit is allocated to determine whether this mode is active.

Table describes the states between which the HEK transitions over the lifespan of the device. The lifecycle state of the HEK is determined by Caliptra's lifecycle state as well as the state of the HEK fuse bank.

Table: HEK lifecycle states {#hek-lifecycle-states}

In addition to the HEK seed, the HEK is derived from Caliptra's DICE UDS. The mechanism used to compute the HEK is described in Figure. This flow is performed across MCU ROM and Caliptra ROM upon KMB startup.

{#hek-derivation}

MCU ROM is responsible for invoking the REPORT_HEK_METADATA command exactly once, after cold reset and before Caliptra FMC/runtime firmware is first loaded. If REPORT_HEK_METADATA is not invoked, KMB will zeroize the HEK and runtime functions which rely on it will be disabled.

By deriving the HEK in ROM based on secrets that are not available to runtime firmware, KMB ensures that compromised runtime firmware cannot derive the HEK using replayed HEK seed values.

Note: the HEK is derived before REPORT_HEK_METADATA is invoked due to IDevID having been zeroized from the Key Vault by the time Caliptra ROM is ready to handle mailbox commands.

HEK and SEK lifecycle

Figure illustrates the case where a drive ships with four HEK slots.

{#hek-sek-rotation}

Drive firmware is responsible for performing each state transition, including programming and zeroizing HEK seeds and entering perma-HEK mode.

A device out of manufacturing must be in the production lifecycle state and have a randomized HEK.

Drive firmware is responsible for enforcing that HEK and SEK programming / zeroization follows the state machine illustrated in Figure. Specifically:

• The SEK shall only be programmed once the HEK is available.
• The HEK seed shall only be zeroized once the SEK is zeroized.
• The HEK seed shall only be zeroized after it has been randomized or corrupted.
• The next HEK seed shall only be programmed once the prior HEK seed has been zeroized.
• Perma-HEK mode shall only be enabled once all HEK seeds have been zeroized.

Drive firmware is responsible for zeroizing the encryption engine's key cache when the SEK transitions from randomized to zeroized. HEK transitions involve power cycles and therefore the key cache is implicitly zeroized across such transitions.

MEKs

KMB can encrypt randomly-generated MEKs, or compute derived MEKs.

Figure provides details on how the SEK, HEK, DPK, and MPKs are used to produce the MEK secret, which then either encrypts/decrypts a random MEK or is used to compute a derived MEK.

{#mek-secret-derivation}

Note: it is drive firmware's responsibility to ensure that MPKs are mixed in the correct order for a given MEK.

See Section for how the MEK secret is used to generate and load random MEKs. See Section for how the MEK secret is used to derive deterministic MEKs.

Support for non-MPA storage API flows

KMB allows an MEK to be bound to zero MPKs, which supports TCG flows that do not interact with the TCG MEK-MPA specification. The process for establishing such an MEK is illustrated in Figure.

{#mek-secret-derivation-no-mpks}

Protecting MEKs with the MDK

Randomly-generated MEKs are encrypted at rest with AES-GCM, as illustrated in Section. During initial MEK encryption, Caliptra's AES engine accepts the MEK plaintext from KMB firmware and returns the ciphertext back to KMB firmware. Later, during MEK decryption, Caliptra's AES engine accepts the MEK ciphertext from KMB firmware and writes the decrypted plaintext to the Key Vault. From Caliptra hardware's perspective, AES-GCM encryption and decryption are the same operation. Therefore, if the MEK were protected with only a single layer of AES-GCM encryption, compromised KMB firmware could instruct Caliptra's AES engine to treat decryption like encryption and return the decrypted plaintext to KMB firmware, trivially disclosing the MEK.

To mitigate this, Caliptra hardware enforces that before an MEK can be loaded into the Key Vault, it must first pass through an AES-ECB decryption operation keyed using the MEK Deobfuscation Key (MDK). The MDK is derived in ROM upon cold reset, as described in Section and illustrated in Figure.

Unlike with AES-GCM, Caliptra's AES engine can differentiate between encryption and decryption in AES-ECB mode. Hardware enforces that for any AES-ECB decryption operation using the Key Vault slot that holds the MDK, the result is always routed to the Key Vault. The MDK encryption layer therefore ensures that the plaintext MEK is never visible to KMB firmware once the MEK has been decrypted.

By deriving the MDK in ROM based on secrets that are not available to runtime firmware, KMB ensures that compromised runtime firmware cannot re-derive the MDK into a separate Key Vault slot, which could have looser protections for whether firmware can see the results of an AES-ECB decryption operation.

{#mdk-derivation}

Generating and loading a random MEK

Figures [-Figure] and [-Figure] elide the process of deriving the MEK secret, as those details are captured in Figure. When an MEK is generated or loaded, the inputs given in Figure are provided by drive firmware so that KMB may derive the MEK secret.

Randomly-generated MEKs are given two layers of at-rest encryption: an inner AES-ECB layer using the MDK, and an outer AES-GCM layer using the MEK secret. The wrapped MEK's integrity tag is associated with the outer layer. The inner AES-ECB layer does not have its own MAC. Therefore the extra layer of encryption does not modify the size of the wrapped MEK. See Section for details on the format and layout of the wrapped MEK.

{#mek-generate}

{#mek-load}

Deriving an MEK

Figure elides the process of deriving the MEK secret, as those details are captured in Figure. When an MEK is derived, the inputs given in Figure are provided by drive firmware so that KMB may derive the MEK secret.

{#mek-derive}

Deobfuscating MEK seeds with the MDK

The MEK seed is calculated via CMAC instead of HMAC, and then "decrypted" via the MDK, for the following reasons:

• As described in Section, the only way to populate the Key Vault slot that holds the MEK is via the AES engine operating in ECB-decrypt mode (where the key is taken from the Key Vault slot that holds the MDK).
• The AES engine does not allow messages to be read from the Key Vault. Therefore KMB must derive a key from the MEK secret that is readable by firmware, so firmware can pass it as an AES message to compute the MEK.
• Since the MEK secret is in the Key Vault, the result of any HMAC operations would be required to go back to the Key Vault, and not be available to firmware.
• The CMAC operation, by contrast, utilizes the AES engine in a manner that allows the results to be readable by firmware. Therefore CMAC is used to compute the MEK seed from the MEK secret.
• The resulting MEK seed is then passed as an AES message to the AES engine, which uses it in a decryption operation to produce the derived MEK.

Derived MEK checksums

When deriving an MEK, drive firmware provides an MEK checksum to KMB. See Figure for details on how the checksum is derived. If the provided checksum is non-zero, it is compared with the calculated checksum. The operation fails (and the derived MEK is not sent to the encryption engine) if the provided checksum does not match the calculated checksum. This check is skipped if the provided checksum is all-zeroes.

Upon success, the calculated checksum is returned to drive firmware. Drive firmware may choose to store the checksum persistently and use it for future derivations, or may discard the returned checksum. The checksum allows drive firmware to ensure that an MEK derived in the future matches a given MEK derived previously. This check would be a precaution against mistakes or bit flips that would result in an incorrect MEK being programmed to the encryption engine, which could lead to data loss. This specification does not define how drive firmware should react to a checksum mismatch.

The checksum is not derived from the MEK directly, because Caliptra hardware restricts what operations can be done with the Key Vault slot that holds the MEK.

An example flow where the MEK checksum would be useful is as follows:

1. Drive firmware is instructed to establish a new MEK.
2. Drive firmware instructs KMB to produce the new MEK via DERIVE_MEK, as part of the sequence specified in Section.
3. Upon success, drive firmware is given the derived-MEK's checksum, which it stores in non-volatile memory.
4. On a subsequent boot, drive firmware reads the SEK into volatile memory, and is later asked to re-establish the MEK it derived in step 2.
5. The copy of the SEK held in volatile memory has suffered corruption since it was last read from persistent storage, and a bit has flipped.
6. Drive firmware invokes DERIVE_MEK. As part of this command, drive firmware provides the derived-MEK checksum it saved in non-volatile storage.
7. KMB detects the checksum mismatch and refuses to program the derived MEK. Drive firmware surfaces this failure to the host.

In this example, if the user had proceeded to write data to the disk using the MEK derived in step 6, that data would not be recoverable on subsequent boots unless the SEK experienced the exact same bit flip pattern as in step 5. The derived-MEK checksum allows the drive to detect this scenario and alert the user. Note that there are other possible mechanisms for mitigating this risk. The use of derived-MEK checksums is optional.

Note: a checksum is not produced for wrapped MEKs. For wrapped MEKs, any change in the inputs which produce the MEK secret would result in an error during AES-GCM decryption of the provided MEK.

MEK command sequence

KMB exposes the following mailbox commands for establishing an MEK:

• INITIALIZE_MEK_SECRET
• MIX_MPK
• GENERATE_MEK
• LOAD_MEK
• DERIVE_MEK

Figure illustrates how these commands are used in sequence.

{#mek-command-sequence}

Integrators may elect to utilize either MEK generation or MEK derivation when establishing an MEK.

AES-XTS considerations

The MEK sent to the encryption engine may be used as an AES-XTS key. FIPS 140-3 IG Implementation Guidance for FIPS 140-3 and the Cryptographic Module Validation Program section C.I states that in AES-XTS, the key is "parsed as the concatenation of two AES keys, denoted by Key_1 and Key_2, that are 128 [or 256] bits long... Key_1 and Key_2 shall be generated and/or established independently according to the rules for component symmetric keys from NIST SP 800-133rev2, Sec. 6.3. The module shall check explicitly that Key_1 ≠ Key_2, regardless of how Key_1 and Key_2 are obtained."

SP 800-133 Recommendation for Cryptographic Key Generation (Rev. 2) section 6.3 states: "The independent generation/establishment of the component keys K~1~, ..., K~n~ is interpreted in a computational and a statistical sense; that is, the computation of any particular K~i~ value does not depend on any one or more of the other K~i~ values, and it is not feasible to use knowledge of any proper subset of the K~i~ values to obtain any information about the remaining K~i~ values."

SP 800-108 Recommendation for Key Derivation Using Pseudorandom Functions (Rev. 1) section 4 states that "the output of a key-derivation function is called the derived keying material and may subsequently be segmented into multiple keys. Any disjoint segments of the derived keying material (with the required lengths) can be used as cryptographic keys for the intended algorithms."

As the MEK sent to the encryption engine is either randomly or pseudorandomly generated, it satisfies the above constraints. Disjoint segments of derived keying material computed from a pseudorandom function are statistically and computationally independent.

When in AES-XTS mode, the encryption engine will be responsible for performing the inequality check for Key_1 and Key_2 stipulated by FIPS 140-3 IG section C.I. If this check fails, the encryption engine must report a vendor-defined error. This document does not specify how drive firmware should handle this error case.

Random key generation via DRBG

KMB generates multiple kinds of random keys. It does so using randomness obtained from a DRBG, which is seeded from a TRNG and which may be updated with entropy from the host.

Caliptra hardware Caliptra 2.0 Hardware Specification supports either an integrated or external DRBG. Caliptra Subsystem requires leveraging the integrated DRBG. This construction is illustrated in Figure.

{#drbg-internal}

Host-provided entropy can be mixed into the DRBG state via the CM_RANDOM_STIR Caliptra mailbox command.

Drive firmware can obtain randomness from Caliptra's DRBG via the CM_RANDOM_GENERATE Caliptra mailbox command.

Authorization

KMB exposes commands that allows drive firmware to manage the lifecycle of MPKs, HEKs, and MEKs. These lifecycle events have the potential to (and are in many cases designed to) trigger user data loss. The host interface that allows the host to trigger these lifecycle events must therefore implement authorization controls to ensure user data is not improperly destroyed. Drive firmware is responsible for implementing this authorization layer, the details of which are outside the scope of this specification.

Reset behavior

This section defines expected behavior for KMB across each Caliptra reset type, as defined in Caliptra 2.0 Integration Specification.

Table: Behavior on Caliptra reset types {#caliptra-reset-types}

Caliptra cold boot / cold reset shall only be triggered by an NVMe subsystem reset NVM Express Base Specification, Revision 2.2 caused by main power being applied to the subsystem.

A given integration may trigger a Caliptra warm reset in response to other reset events.

Interfaces

OCP L.O.C.K. defines two interfaces:

• The encryption engine interface is exposed from the vendor-implemented encryption engine to KMB, and defines a standard mechanism for programming MEKs and control messages.
• The mailbox interface is exposed from KMB to storage drive firmware, and enables the drive to manage MEKs and associated keys.

Note: as of this specification's publication, KMB firmware has not yet been implemented. As such, certain details of the interface specification are subject to change. This notice will be removed once firmware has been implemented.

Encryption engine interface

This section defines the interface between KMB and an encryption engine. An encryption engine is used to encrypt/decrypt user data. Its design and implementation are vendor specific. MEKs are generated or derived within KMB and used by the encryption engine to encrypt and decrypt user data. The interface defined in this section is used to load MEKs from KMB to the encryption engine or to cause the encryption engine to unload (i.e., remove) loaded MEKs. MEKs shall not be accessible to drive firmware as they are being transferred between KMB and the encryption engine.

Overview

The encryption engine uses an MEK stored in volatile memory to encrypt and decrypt user data. For the purposes of this specification, the entity within the encryption engine used to store the MEKs is called the key cache. Each encryption and decryption of user data is coupled to a specific MEK which is stored in the key cache bound to a unique identifier, called metadata. Each (metadata, MEK) pair is also associated with additional information, called aux, which is used neither as MEK nor an identifier, but has some additional information about the pair. Therefore, the key cache as an entity which stores (metadata, aux, MEK) tuples.

To ensure that MEKs are only ever visible to KMB and the encryption engine, KMB is the only entity which can load and unload (metadata, aux, MEK) tuples. Drive firmware arbitrates all operations in the KMB → encryption engine interface, and is therefore responsible for managing which MEK is loaded in the key cache. Drive firmware has full control on metadata and optional aux. Figure is an illustration of the KMB → encryption engine interface which shows:

• The tuple for loading an MEK.
• The metadata for unloading an MEK.
• An example of a key cache configuration within the encryption engine.

{#encryption-engine}

The behavior of I/O through the encryption engine during the execution of an SFR command is vendor-defined.

Special Function Registers

KMB uses Special Function Registers (SFRs) to communicate with the encryption engine as shown in Table and each of the following subsections which describe the registers.

The OCP_LOCK_MEK_ADDRESS register represents the combined registers SS_KEY_RELEASE_BASE_ADDR_L and SS_KEY_RELEASE_BASE_ADDR_H and shall contain the fixed base address of the MEK register.

The SS_KEY_RELEASE_SIZE register shall contain the size of the MEK, in bytes. This shall be set to 40h by the MCU ROM.

MCU ROM is responsible for configuring SS_KEY_RELEASE_BASE_ADDR_L, SS_KEY_RELEASE_BASE_ADDR_H and SS_KEY_RELEASE_SIZE, prior to setting CPTRA_FUSE_WR_DONE to prevent further modifications.

Table: KMB to encryption engine SFRs {#kmb-ee-sfrs}

OCP_LOCK_MEK_ADDRESS contains the base address for the SFRs shown in Table. The vendor is responsible for ensuring that KMB can access these SFRs through these addresses.

For alignment, offsets OCP_LOCK_MEK_ADDRESS + OCP_LOCK_MEK_LENGTH + 14h..20h (inclusive) are intentionally unallocated.

In the register definitions that follow, the "Type" column indicates whether KMB may read from or write to the given register.

Media Encryption Key register

Table: OCP_LOCK_MEK_ADDRESS: MEK – Media Encryption Key {#ee-mek-sfr}

The encryption engine is free to interpret the provided key in a vendor-defined manner. One sample interpretation for AES-XTS-256 is presented in Figure.

{#mek-format-example-for-aes}

If an algorithm used by the encryption engine does not require 512 bits of key material, the encryption engine is free to disregard unused bits.

Within KMB, loaded MEKs are only ever present in the Key Vault, so that they can be protected against firmware-level attacks. KMB will write MEKs into the encryption engine's key cache using the DMA engine. The DMA engine will copy the key value stored in Key Vault slot 23 to the destination address, specified by OCP_LOCK_MEK_ADDRESS.

Metadata register

Table defines the Metadata register used to pass additional data related to the MEK.

Table: Offset OCP_LOCK_MEK_ADDRESS + 40h: METD – Metadata {#ee-metd-sfr}

KMB and the encryption engine must be the only components which have access to MEKs. Each MEK is associated with non-secret metadata, in order for the MEK to be used for any key-related operations including data I/O. The METD field is used to convey this metadata.

When loading or deriving an MEK, KMB takes an METD value as input from drive firmware and writes it to the METD register without any modification. This allows the vendor full control of the MEK indexing algorithm.

Two examples of how a storage device might leverage the METD field are provided: Logical Block Addressing (LBA) range-based metadata, and key-tag based metadata.

When an SSD stores data with address-based encryption, an MEK can be uniquely identified by an (LBA range, Namespace ID) pair. Then, the (LBA range, Namespace ID) pair can be leveraged into METD as illustrated in Figure.

{#lba-nsid-layout}

Address-based encryption is not the only encryption mechanism in SSDs. For example, in TCG Key Per I/O, an MEK is selected by a key tag, which does not map to an address. Figure shows an example of METD in such cases.

{#key-tag-layout}

The above examples are not the only possible values of METD. Vendors may design and use their own METD if it is more suitable for their system.

Auxiliary Data register

Table defines the Auxiliary Data register used to pass additional vendor-specific data related to the MEK.

Table: OCP_LOCK_MEK_ADDRESS + 60h: AUX – Auxiliary Data {#ee-aux-sfr}

The AUX field supports vendor-specific features on MEKs. KMB itself only supports fundamental functionalities in order to minimize attack surfaces on MEKs. Moreover, vendors are free to design and implement their own MEK-related functionality within the encryption engine, as long as that functionality cannot be used to exfiltrate MEKs. In order to support these functionalities, some data may be associated and stored with an MEK, and the AUX field facilitates this association.

When drive firmware instructs KMB to load an MEK, drive firmware is expected to provide an AUX value. Similar to the METD field, KMB will write the AUX value into the Auxiliary Data register without any modification.

One simple use case of the AUX field is to store an offset of initialization vector or nonce. It can also be used in a more complicated use case. Here is an example. Suppose that there exists a vendor who wants to design a system which supports several modes of operation through the encryption engine while using KMB. Then, a structure of AUX value as on Figure can be used.

{#aux-register-format-example}

When drive firmware instructs KMB to load an MEK, drive firmware can use the AUX value to specify which mode of operation should be used and which value should be used as an initialization vector or a nonce with the generated MEK.

Control register

Table defines the Control register used to sequence the execution of a command and obtain the status of that command.

Table: Offset OCP_LOCK_MEK_ADDRESS + 80h: CTRL – Control {#ee-ctrl-sfr}

Table: CTRL error codes {#ee-ctrl-err-codes}

Table: CTRL command codes {#ee-ctrl-cmd-codes}

From KMB, the Control register is the register to write a command and receive its execution result. From its counterpart, the encryption engine, the Control register is used to receive a command and write its execution result.

The expected change flow of the Control register to handle a command is as follows:

1. If RDY is set to 1b, then KMB writes CMD and EXE
   1. CMD: either 1h, 2h or 3h
   2. EXE: 1b
2. The encryption engine writes ERR and DONE
   1. ERR: either 0b or a non-zero value depending on the execution result
   2. DONE: 1b
3. KMB writes DONE
   1. DONE: 1b
4. The encryption engine writes CMD, ERR, DONE and EXE
   1. CMD: 0h
   2. ERR: 0h
   3. DONE: 0b
   4. EXE: 0b

KMB therefore interacts with the Control register as follows in the normal circumstance:

1. KMB writes CMD and EXE
   1. CMD: either 1h, 2h or 3h
   2. EXE: 1b
2. KMB waits for DONE to be 1
3. KMB writes DONE
   1. DONE: 1b
4. KMB waits for DONE to be 0

Since the Control register is a part of the encryption engine whose implementation can be unique to each vendor, behaviors of the Control register with respect to unexpected flows are left for vendors. For example, a vendor who wants robustness might integrate a write-lock into the Control register in order to prevent two almost simultaneous writes on the EXE bit. Vendors shall ensure that any customizations remain compatible with the interface defined in this specification.

Control register state machine

Figure illustrates the control register's state machine as it transitions from power-on to executing a command.

{#ctrl-reg-state-machine}

KMB command sequence

Figure shows a sample command execution. This is an expected sequence when drive firmware instructs KMB to load an MEK. This sequence would occur as part of the DERIVE_MEK or LOAD_MEK mailbox commands. The internal behavior of the encryption engine is one of several possible mechanisms, and can be different per vendor.

PlantUML rendering error: PlantUML did not generate an image, did you forget the @startuml, @enduml block (java -jar ./plantuml-asl-1.2025.0.jar -tsvg -nometadata /tmp/.tmpjvNI2V/7028d09e983102582e39f5c9d214261a378690fa.puml)?

Mailbox interface

This section provides the mailbox commands exposed by Caliptra as part of OCP L.O.C.K.

FIPS status indicator

Each mailbox command returns a `fips_status` field. This provides an indicator of whether KMB is operating in FIPS mode. Table provides the possible values for this field.

Note: all multi-byte fields (i.e. `u16` and `u32`) that are not byte arrays are interpreted as little endian.

Table: Values for the FIPS status field {#fips-status-values}

Encryption engine timeout

Each mailbox command that causes a command to execute on the encryption engine includes a `cmd_timeout` value indicating the amount of time KMB firmware will wait until the command has completed. If this timeout is exceeded, KMB aborts the command and reports a `LOCK_ENGINE_TIMEOUT` result code.

For such commands, KMB firmware will return a `LOCK_EE_NOT_READY` error immediately if the encryption engine is not ready to execute a command.

Side-channel mitigations

Several mailbox commands invoke ECDH and/or ML-KEM Decaps. These operations involve deterministic data-dependent operations and are potentially susceptible to timing attacks and power analysis. To mitigate such attacks, Caliptra leverages masking in hardware, and introduces random jitter delays in firmware before handling mailbox commands.

REPORT_HEK_METADATA

This command is exposed by Caliptra ROM and allows MCU ROM to report metadata about the HEK. This command must be called exactly once after each cold reset and before loading Caliptra's FMC and runtime firmware.

By exposing this command in ROM, Caliptra de-privileges runtime compromise of drive firmware that might cause it to mis-report the HEK seed state, which could lead to incorrect device state attestations.

Command Code: 0x5248_4D54 ("RHMT")

Table: REPORT_HEK_METADATA input arguments {#report-hek-metadata-input-args}

Table: HEK seed state values {#hek-seed-state-values}

MCU ROM shall adhere to Table when populating the HEK metadata.

Table: Conditions for setting seed_state and active_slot {#hek-metadata-conditions}

Table: REPORT_HEK_METADATA output arguments {#report-hek-metadata-output-args}

Table: REPORT_HEK_METADATA output flags {#report-hek-metadata-output-flags}

GET_STATUS

Allows drive firmware to determine if the encryption engine is ready to process commands as well as vendor-defined drive encryption engine status data.

Command Code: 0x4753_5441 ("GSTA")

Table: GET_STATUS input arguments {#get-status-input-args}

Table: GET_STATUS output arguments {#get-status-output-args}

GET_ALGORITHMS

Allows drive firmware to determine the types of algorithms supported by KMB for endorsement, KEM, MPK, and access key generation.

Command Code: 0x4741_4C47 ("GALG")

Table: GET_ALGORITHMS input arguments {#get-algorithms-input-args}

Table: GET_ALGORITHMS output arguments {#get-algorithms-output-args}

Each of the `endorsement_algorithms`, `hpke_algorithms`, and `access_key_sizes` fields shall be reported as a non-zero value.

CLEAR_KEY_CACHE

This command unloads all MEKs in the encryption engine.

Command Code: 0x434C_4B43 ("CLKC")

Table: CLEAR_KEY_CACHE input arguments {#clear-key-cache-input-args}

Table: CLEAR_KEY_CACHE output arguments {#clear-key-cache-output-args}

ENUMERATE_HPKE_HANDLES

This command returns a list of all currently-active HPKE handles for resources held by KMB.

Command Code: 0x4548_444C ("EHDL")

Table: ENUMERATE_HPKE_HANDLES input arguments {#enumerate-hpke-handles-input-args}

Table: ENUMERATE_HPKE_HANDLES output arguments {#enumerate-hpke-handles-output-args}

Table: HpkeHandle contents {#hpke-handle-contents}

ENDORSE_HPKE_PUB_KEY

This command generates a signed certificate for the specified HPKE public key using the specified endorsement algorithm.

Command Code: 0x4548_504B ("EHPK")

Table: ENDORSE_HPKE_PUB_KEY input arguments {#endorse-hpke-pub-key-input-args}

Table: ENDORSE_HPKE_PUB_KEY output arguments {#endorse-hpke-pub-key-output-args}

ROTATE_HPKE_KEY

This command rotates the HPKE keypair indicated by the specified handle and stores the new HPKE keypair in volatile memory within KMB.

Command Code: 0x5248_504B ("RHPK")

Table: ROTATE_HPKE_KEY input arguments {#rotate-hpke-key-input-args}

Table: ROTATE_HPKE_KEY output arguments {#rotate-hpke-key-output-args}

GENERATE_MPK

This command unwraps the specified access key, generates a random MPK, then encrypts the MPK with a Locked MPK encryption key. The Locked MPK is returned for the drive to persistently store. The given `metadata` is placed in the `metadata` field of the returned MPK to cryptographically tie them together.

Command Code: 0x474D_504B ("GMPK")

Table: GENERATE_MPK input arguments {#generate-mpk-input-args}

Table: GENERATE_MPK output arguments {#generate-mpk-output-args}

REWRAP_MPK

This command unwraps current_access_key and encrypted new_access_key from sealed_access_keys. Then current_access_key is used to decrypt new_access_key. The specified MPK is decrypted using its current Locked MPK encryption key, then re-encrypted with its new Locked MPK encryption key. The new Locked MPK is returned.

The drive stores the returned Locked MPK and zeroizes the old Locked MPK.

Command Code: 0x5245_5750 ("REWP")

Table: REWRAP_MPK input arguments {#rewrap-mpk-input-args}

Table: REWRAP_MPK output arguments {#rewrap-mpk-output-args}

ENABLE_MPK

This command decrypts `sealed_access_key`, then uses it to derive a Locked MPK encryption key, which is used to decrypt `locked_mpk`. The MPK is then re-encrypted with the VEK. The Enabled MPK is returned.

Command Code: 0x524D_504B ("RMPK")

Table: ENABLE_MPK input arguments {#enable-mpk-input-args}

Table: ENABLE_MPK output arguments {#enable-mpk-output-args}

INITIALIZE_MEK_SECRET

This command shall initialize the MEK secret seed as described in Figure.

Command Code: 0X494D_0B53 ("IMKS")

Table: INITIALIZE_MEK_SECRET input arguments {#initialize-mek-secret-input-args}

Table: INITIALIZE_MEK_SECRET output arguments {#initialize-mek-secret-output-args}

MIX_MPK

This command decrypts the specified MPK with the VEK, and then updates the MEK secret seed in KMB by performing a KDF with the MEK secret seed and the decrypted MPK.

When generating an MEK, one or more MIX_MPK commands are processed to modify the MEK secret seed.

The MEK secret seed must already be initialized by INITIALIZE_MEK_SECRET or this command shall return an error.

Command Code: 0x4D4D_504B ("MMPK")

Table: MIX_MPK input arguments {#mix-mpk-input-args}

Table: MIX_MPK output arguments {#mix-mpk-output-args}

TEST_ACCESS_KEY

This command is used by the host to check the input access key is associated with the given MPK. The `nonce` is a random value to be included in the digest calculation to prevent response replay attacks. The output is calculated as SHA2-384(metadata || decrypted access key || nonce). The metadata is taken from the provided MPK's `metadata` field.

Command Code: 0x5441_434B ("TACK")

Table: TEST_ACCESS_KEY input arguments {#test-access-key-input-args}

Table: TEST_ACCESS_KEY output arguments {#test-access-key-output-args}

GENERATE_MEK

This command generates a random 512-bit MEK and encrypts it using the MEK secret.

INITIALIZE_MEK_SECRET must be invoked prior to this command or an error shall be returned.

Command Code: 0x474D_454B ("GMEK")

Table: GENERATE_MEK input arguments {#generate-mek-input-args}

Table: GENERATE_MEK output arguments {#generate-mek-output-args}

LOAD_MEK

This command decrypts the given encrypted 512-bit MEK using the MEK secret.

The decrypted MEK, specified metadata, and aux_metadata are loaded into the encryption engine key cache. The metadata format is vendor-defined and specifies the information to the encryption engine on where within the key cache the MEK is loaded.

INITIALIZE_MEK_SECRET must be invoked prior to this command or an error shall be returned.

Command Code: 0x4C4D_454B ("LMEK")

Table: LOAD_MEK input arguments {#load-mek-input-args}

Table: LOAD_MEK output arguments {#load-mek-output-args}

DERIVE_MEK

This command derives an MEK using the MEK secret.

The derived MEK, specified metadata, and aux_metadata are loaded into the encryption engine key cache. The metadata format is vendor-defined and specifies the information to the encryption engine on where within the key cache the MEK is loaded.

INITIALIZE_MEK_SECRET must be invoked prior to this command or an error shall be returned.

Command Code: 0x444D_454B ("DMEK")

Table: DERIVE_MEK input arguments {#derive-mek-input-args}

Table: DERIVE_MEK output arguments {#derive-mek-output-args}

UNLOAD_MEK

This command causes the MEK associated to the specified metadata to be unloaded for the key cache of the encryption engine. The metadata format is vendor-defined and specifies the information to the encryption engine on where within the key cache, the MEK is loaded.

Command Code: 0x554D_454B ("UMEK")

Table: UNLOAD_MEK input arguments {#unload-mek-input-args}

Table: UNLOAD_MEK output arguments {#unload-mek-output-args}

GET_EPOCH_KEY_STATE

This command reports the state of the epoch keys. The drive indicates the state of the SEK, while KMB internally senses the state of the HEK.

Command Code: 0x4745_4B53 ("GEKS")

Table: GET_EPOCH_KEY_STATE input arguments {#get-epoch-key-state-input-args}

Table: GET_EPOCH_KEY_STATE output arguments {#get-epoch-key-state-output-args}

Table: SEK state values {#sek-state-values}

The value reported from Table depends on Caliptra's current lifecycle state as well as the `seed_state` value from REPORT_HEK_METADATA.

Table: HEK state values {#hek-state-values}

Operations that use the HEK are disallowed in all `HEK_UNAVAIL_*` states.

See Table for more information about the relationship between HEKs and Caliptra lifecycle states.

HEK_AVAIL_UNERASABLE → HEK_UNAVAIL_EMPTY is a one-way transition that the device vendor is expected to trigger by advancing the Caliptra lifecycle state to Production.

HEK_UNAVAIL_ZEROIZED → HEK_AVAIL_UNERASABLE is a one-way transition that the device owner can trigger once all HEK slots have been zeroized.

See Figure for more details about the transitions between HEK states.

Calculation of hek_erasures_remaining

The `hek_erasures_remaining` field in GET_EPOCH_KEY_STATE is based on the following values from REPORT_HEK_METADATA:

• total_slots
• active_slot
• seed_state

The calculation is as follows:

\[ \text{seed_is_erased}= \begin{cases} true & \text{if seed_state}=\text{HEK_SEED_UNAVAIL_ZEROIZED}\ true & \text{if seed_state}=\text{HEK_SEED_AVAIL_UNERASABLE}\ false & \text{otherwise} \end{cases} \] \[ \text{hek_erasures_remaining}=\text{total_slots}-\text{active_slot}- \begin{cases} 1 & \text{if seed_is_erased}\ 0 & \text{otherwise} \end{cases} \]

Common mailbox types

This section defines common types used to interface between drive firmware and KMB. These types are common patterns found in both requests and responses.

SealedAccessKey type

This type holds an HPKE-wrapped access key.

Table: SealedAccessKey contents {#sealed-access-key-contents}

`Nenc` and `Nt` are HPKE values associated with the `kem_id` and `aead_id` identifiers from the given `hpke_algorithm`. For example, if byte 0 bit 0 of `hpke_algorithm` is set (indicating `kem_id` 0x0011 and `aead_id` 0x0002), then according to Hybrid Public Key Encryption, `Nenc` and `Nt` would be 97 and 16, respectively.

WrappedKey type

AES-256-GCM is used for all wrapping and unwrapping.

Table: WrappedKey contents {#wrapped-key-contents}

The AAD for the encrypted message is constructed as `key_type` || `salt` || `metadata_len` || `metadata`.

Variants of WrappedKey will be used to reduce duplicating information in commands. The following names will be used for WrappedKeys of a specific `key_type` and `key_len`:

Table: WrappedKey variants {#wrapped-key-variants}

Fault handling

A KMB mailbox command can fail to complete in the following ways:

• An ill-formed command.
• Encryption engine timeout.
• Encryption engine reported error.

In all of these cases, the error is reported in the command return status.

KMB mailbox errors should generally result in an error being surfaced to the host.

Table: KMB mailbox command result codes {#kmb-mailbox-codes}

Host APIs

In addition to supporting TCG Opal, Enterprise, and Key Per I/O, OCP L.O.C.K. provides underlying support for the Media Encryption Key Multiparty Authorization (MEK-MPA) Opal feature-set TCG Storage Feature Set: Media Encryption Key Multiparty Authorization. These bindings are described in Table.

Table: Mapping between KMB mailbox commands and host-facing storage APIs {#host-api-mapping}

Rotation of the HEK and SEK and injection of host entropy require additional host APIs beyond those available in TCG Opal, Enterprise, or Key Per I/O. Such APIs are beyond the scope of the present document.

Terminology

Table: Acronyms and abbreviations used throughout this document {#abbreviations}

Compliance

This section enumerates requirements for devices that integrate OCP L.O.C.K.

Table: Compliance requirements {#compliance-requirements}

Repository location

See https://github.com/chipsalliance/Caliptra/tree/main/doc/ocp_lock.

Preconditioned AES-Encrypt calculations

This appendix expands on Section and provides additional details behind the claim that approximately \(2^{80}\) preconditioned AES-Encrypt operations for a given encryption key are needed before an IV collision is expected to occur with probability greater than \(2^{-32}\).

To satisfy FIPS, it is sufficient to demonstrate that no single AES-GCM key will be used more than \(2^{32}\) times. With a 96-bit salt, a given encryption key can be expanded to up to \(2^{96}\) possible subkeys. This can be put in terms of the "Balls into bins" problem Balls into bins problem, where we are looking for the number of balls (\(m\)) required for the maximum load across \(2^{96}\) bins (\(n\)) to be \(2^{32}\). An approximation for the maximum load where \(m>n\) is given as \(m/n+\sqrt{m·log(n)/n}\). Rearranging to solve for \(m\) via the quadratic formula yields \(m≈2^{128}\). Therefore a given encryption key may be used in at most \(2^{128}\) preconditioned AES-Encrypt operations before any subkey derived from that key is used in more than \(2^{32}\) AES-GCM-Encrypt operations.

However, the \(2^{32}\) encryption limit is a means to an end, namely ensuring a low probability of IV collisions. The Birthday paradox Birthday problem implies that the probability of a collision between \(n\) generated IVs where \(d\) is the number of possible IVs is approximately \(n^2/(2d)\). The chances of a 96-bit IV collision across \(2^{32}\) IVs is therefore approximately \(2^{2·32}/2^{96+1}=2^{-33}\) for a given subkey. If each of the \(2^{96}\) derived subkeys might be used up to \(2^{32}\) times, the expected number of derived subkeys that experience a collision is approximately \(2^{96}·2^{-33}=2^{63}\). Clearly a limit of \(2^{128}\) encryption operations for a given encryption key, while meeting the letter of the FIPS requirements, is too large for safety.

We can calculate the safe margin by simply considering the 96-bit salt concatenated to the 96-bit IV. What we are really after is the maximum number of preconditioned AES-Encrypt invocations with a given encryption key such that the likelihood of experiencing a collision of the 192-bit (salt || IV) pair is at most \(2^{-32}\). Leveraging the Birthday paradox equation where \(p(n,d)≈n^2/(2d)\), \(n≈\sqrt{2d·p}=\sqrt{2^{192+1}·2^{-32}}=2^{80.5}\).

Therefore a given encryption key may safely be used in at most \(2^{80.5}\) preconditioned AES-Encrypt operations before an IV collision is expected to occur with probability greater than \(2^{-32}\) across all of the AES-GCM subkeys derived from the encryption key.

EAT format for attesting to the epoch key state

This format is currently under development within TCG as part of the Hard Cryptographic Purge feature set⁴.

Caliptra Hardware Specification

Revision 2.1

Scope

This document defines technical specifications for a Caliptra RoT for Measurement (RTM)^[1] cryptographic subsystem used in the Open Compute Project (OCP). This document, along with Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT), shall comprise the Caliptra technical specification.

Overview

This document provides definitions and requirements for a Caliptra cryptographic subsystem. The document then relates these definitions to existing technologies, enabling device and platform vendors to better understand those technologies in trusted computing terms.

Caliptra Core

For information on the Caliptra Core, see the High level architecture section of Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT).

Key Caliptra Core 2.0 Changes

• AXI subordinate replaces APB interface of Caliptra 1.x hardware
• SHA Accelerator functionality now available exclusively to Caliptra
  • Caliptra uC may use internally in mailbox mode or via the Caliptra AXI DMA assist engine in streaming mode
  • SHA Accelerator adds new SHA save/restore functionality
• Adams Bridge Dilithium/ML-DSA (refer to Adams bridge spec)
• Subsystem mode support (refer to Subsystem Specification for details)
  • ECDH hardware support
  • HMAC512 hardware support
  • AXI Manager with DMA support (refer to DMA Specification)
  • Manufacturing and Debug Unlock
  • UDS programming
  • Read logic for Secret Fuses
  • Streaming Boot Support
• RISC-V core PMP support
• CSR HMAC key for manufacturing flow

Key Caliptra 2.1 Changes

• AXI Manager DMA AES feature for OCP L.O.C.K. support (refer to DMA Specification)
• AES Big Endian mode
• External Staging Area
• OCP LOCK Support
• SHA3
• ML-KEM

Boot FSM

The Boot FSM detects that the SoC is bringing Caliptra out of reset. Part of this flow involves signaling to the SoC that Caliptra is awake and ready for fuses. After fuses are populated and the SoC indicates that it is done downloading fuses, Caliptra can wake up the rest of the IP by de-asserting the internal reset.

The following figure shows the state transitions and associated actions in Caliptra's boot state machine.

Figure: Caliptra Boot FSM state diagram

The Boot FSM first waits for the SoC to assert cptra_pwrgood and de-assert cptra_rst_b. In the BOOT_FUSE state, Caliptra signals to the SoC that it is ready for fuses. After the SoC is done writing fuses, it sets the fuse done register and the FSM advances to BOOT_DONE.

Once in the BOOT_DONE state, Caliptra de-asserts resets through a two flip-flop synchronizer.

FW update reset (Impactless FW update)

When a firmware update is initiated, Runtime FW writes to fw_update_reset register to trigger the FW update reset. When this register is written, only the RISC-V core is reset using cptra_uc_rst_b pin and all AHB targets are still active. All registers within the targets and ICCM/DCCM memories are intact after the reset. Reset is deasserted synchronously after a programmable number of cycles; the minimum allowed number of wait cycles is 5, which is also the default configured value. Reset de-assertion is done through a two flip-flop synchronizer. Since ICCM is locked during runtime, the boot FSM unlocks it when the RISC-V reset is asserted. Following FW update reset deassertion, normal boot flow updates the ICCM with the new FW from the mailbox SRAM.

Impactless firmware updates may be initiated by writing to the fw_update_reset register after Caliptra comes out of global reset and enters the BOOT_DONE state. In the BOOT_FWRST state, only the reset to the RISC-V core is asserted and the wait timer is initialized. After the timer expires, the FSM advances from the BOOT_WAIT to BOOT_DONE state where the reset is deasserted and ICCM is unlocked.

Breakpoints for Debug

Integrators may connect a breakpoint input to Caliptra, which is intended to connect to a chip GPIO pin. When asserted, this pin causes the Caliptra boot FSM to follow a modified arc. Instead of transitioning immediately to the BOOT_DONE state upon completion of fuse programming, the state machine transitions from BOOT_FUSE to BOOT_WAIT. Here, the state machine halts until the Caliptra register CPTRA_BOOTFSM_GO is set, either by AXI or TAP access.

RISC-V core

The RISC-V core is VeeR EL2 from CHIPS Alliance. It is a 32-bit CPU core that contains a 4-stage, scalar, in-order pipeline. The core supports RISC-V’s integer(I), compressed instruction(C), multiplication and division (M), instruction-fetch fence, CSR, and subset of bit manipulation instructions (Z) extensions. A link to the RISC-V VeeR EL2 Programmer’s Reference Manual is provided in the References section.

Configuration

The RISC-V core is highly configurable and has the following settings.

Embedded memory export

Internal RISC-V SRAM memory components are exported from the Caliptra subsystem to support adaptation to various fabrication processes. For more information, see the Caliptra Integration Specification.

Memory map address regions

The 32-bit address region is subdivided into 16 fixed-sized, contiguous 256 MB regions. The following table describes the address mapping for each of the AHB devices that the RISC-V core interfaces with.

Cryptographic subsystem

The following table shows the memory map address ranges for each of the IP blocks in the cryptographic subsystem.

Peripherals subsystem

The following table shows the memory map address ranges for each of the IP blocks in the peripherals’ subsystem.

SoC interface subsystem

The following table shows the memory map address ranges for each of the IP blocks in the SoC interface subsystem.

RISC-V core local memory blocks

The following table shows the memory map address ranges for each of the local memory blocks that interface with RISC-V core.

Interrupts

The VeeR-EL2 processor supports multiple types of interrupts, including non-maskable interrupts (NMI), software interrupts, timer interrupts, external interrupts, and local interrupts. Local interrupts are events not specified by the RISC-V standard, such as auxiliary timers and correctable errors.

Caliptra uses NMI in conjunction with a watchdog timer to support fatal error recovery and system restart. For more information, see the Watchdog timer section.

Software and local interrupts are not implemented in the first generation of Caliptra. Standard RISC-V timer interrupts are implemented using the mtime and mtimecmp registers defined in the RISC-V Privileged Architecture Specification. Both mtime and mtimecmp are included in the soc_ifc register bank, and are accessible by the internal microprocessor to facilitate precise timing tasks. Frequency for the timers is configured by the SoC using the dedicated timer configuration register, which satisfies the requirement prescribed in the RISC-V specification for such a mechanism. These timer registers drive the timer_int pin into the internal microprocessor.

Non-maskable interrupts

Caliptra's RISC-V processor has access to an internal register that allows configuration of the NMI vector. When an NMI occurs, the program counter jumps to the address indicated by the contents of this register. For more information, see NMI Vector.

External interrupts

Caliptra uses the external interrupt feature to support event notification from all attached peripheral components in the subsystem. The RISC-V processor supports multiple priority levels (ranging from 1-15), which allows firmware to configure interrupt priority per component.

Errors and notifications are allocated as interrupt events for each component, with error interrupts assigned a higher priority and expected to be infrequent.

Notification interrupts are used to alert the processor of normal operation activity, such as completion of requested operations or arrival of SoC requests through the shared interface.

Vector 0 is reserved by the RISC-V processor and may not be used, so vector assignment begins with Vector 1. Bit 0 of the interrupt port to the processor corresponds with Vector 1. The following table shows assignment of interrupt vectors to the corresponding IP block. The illustrated interrupt priority assignment is only an example, and does not correspond with actual priorities assigned in the final Caliptra firmware. These interrupt priorities are used in the validation firmware that tests the RTL, and are defined in caliptra_defines.h.

Watchdog timer

The primary function of Caliptra Watchdog Timer (WDT) is to reset the microcontroller (Caliptra), in the event of a software malfunction, by resetting the device if it has not been cleared in software. It is a two-stage timer, independent of the RISCV core.

Operation

The WDT consists of two timers. When enabled in cascade mode (done by enabling Timer 1 alone), the WDT increments Timer 1 until the counter rolls over or times out. Typically, the timer is serviced at regular intervals to prevent it from overflowing or rolling over. If Timer 1 has not timed out, Timer 2 is disabled and held at its initial value. However, when Timer 1 does roll over, it triggers an error interrupt to the RISC-V core. In parallel, Timer 2 is enabled and begins counting. If the interrupt is serviced before Timer 2 times out, the timers are reset and continue to operate normally. If Timer 2 times out, it asserts an SoC fatal error and an NMI. The SoC fatal error is also captured in the CPTRA_HW_ERROR_FATAL register, which can be cleared by the SoC by writing a 1. A warm reset is required by the SoC to reset the timers when Timer 2 times out.

The WDT timers can be configured to operate independent of each other. When the enable register for Timer 2 is set, the default configuration of cascaded timers is disabled and both timers count independently of each other. In this case, a timeout on Timer 2 causes an error interrupt to the RISC-V core similar to Timer 1. Disabling Timer 2 configures the timers back into the default cascaded mode.

Each timer has an enable bit, a restart bit, and a 64-bit timeout value register that can be programmed as needed. The restart bit is used to service the timers and restart counting. The timeout period registers can be configured to the desired upper bound of timers.

If the WDT timers are disabled and then re-enabled with a new timeout period, they must be restarted by setting the appropriate control register (restart bit). If the timers are temporarily disabled and re-enabled with the same timeout period, they resume counting and do not restart from 0.

For more details regarding the register interface to control the WDT, see the register documentation published in the RTL GitHub repository.

The following figure shows the two timers.

Figure: Caliptra Watchdog Timer

Prescale settings

Assuming a clock source of 500 MHz, a timeout value of 32’hFFFF_FFFF results in a timeout period of ~8.5 seconds. Two 32-bit registers are provided for each timer, allowing a 64-bit timeout period to be programmed for each timer. This accommodates a maximum timeout value of over 1000 years for the same 500 Mhz clock source.

Microcontroller interface

The Caliptra microcontroller communicates with the mailbox through its internal AHB-Lite fabric.

AHB-lite interface

AHB-lite is a subset of the full AHB specification. It is primarily used in single initiator systems. This interface connects VeeR EL2 Core (LSU initiator) to the target devices. See Caliptra Core for information.

The interface can be customized to support variable address and data widths, and a variable number of target devices. Each target device is assigned an address range within the 32-bit address memory map region. The interface includes address decoding logic to route data to the appropriate AHB target device based on the address specified.

The integration parameters for Caliptra’s AHB-lite interface are shown in the following table.

Each IP component in the Caliptra system uses a native AHB data width of 32-bits (1 dword). The AHB responder logic in each IP component contains width conversion logic that transforms from the fabric data width of 64-bits to this native 32-bit width. The conversion involves calculating the dword offset (either 0 or 1) relative to the native 64-bit width by evaluating bit [2] of the address line. This information is used to extract the correct 32-bits from the native write data line. If there is a data offset, data is shifted down by 32-bits; otherwise, the upper 32-bits are simply truncated. This new dword-address is passed to the internal register interface along with the dword-sized data. A similar conversion works in reverse to correctly place read data in the response data line from the responder.

As a result of this implementation, 64-bit data transfers are not supported on the Caliptra AHB fabric. Firmware running on the internal microprocessor may only access memory and registers using a 32-bit or smaller request size, as 64-bit transfer requests will be corrupted.

All AHB requests internal to Caliptra must be to an address that is aligned to the native data width of 4-bytes. Any AHB read or write by the Caliptra RISC-V processor that is not aligned to this boundary will fail to decode to the targeted register, will fail to write the submitted data, and will return read data of all zeroes. All AHB requests must also use the native size of 4 bytes (encoded in the hsize signal with a value of 2). The only exception to this is when the RISC-V processor performs byte-aligned, single-byte reads to the Mailbox SRAM using the direct-access mechanism described in SoC Mailbox. In this case, a byte-aligned address must be accompanied by the correct size indicator for a single-byte access. Read addresses for byte accesses are aligned to the 4-byte boundary in hardware, and will successfully complete with the correct data at the specified byte offset. Direct mode SRAM writes must be 4-bytes in size and must be aligned to the 4-byte boundary. Hardware writes the entire dword of data to the aligned address, so attempts to write a partial word of data may result in data corruption.

Cryptographic subsystem

For details, see the Cryptographic subsystem architecture section.

SoC mailbox

For more information on the mailbox protocol, see Mailbox in the Caliptra Integration Specification. Mailbox registers accessible to the Caliptra microcontroller are defined in internal-regs/mbox_csr.

The RISC-V processor is able to access the SoC mailbox SRAM using a direct access mode (which bypasses the defined mailbox protocol). The addresses for performing this access are described in SoC interface subsystem and in mbox_sram. In this mode, firmware must first acquire the mailbox lock. Then, reads and writes to the direct access address region will go directly to the SRAM block. Firmware must release the mailbox lock by writing to the mbox_unlock register after direct access operations are completed.

Security state

Caliptra uses the MSB of the security state input to determine whether or not Caliptra is in debug mode.

When Caliptra is in debug mode:

• Security state MSB is set to 0.

• Caliptra JTAG is opened for the microcontroller and HW debug.

• Device secrets (UDS, FE, key vault, csr hmac key and obfuscation key) are programmed to debug values.

If a transition to debug mode happens during ROM operation, any values computed from the use of device secrets may not match expected values.

Transitions to debug mode trigger a hardware clear of all device secrets, and also trigger an interrupt to FW to inform of the transition. FW is responsible for initiating another hardware clear of device secrets utilizing the clear secrets register, in case any derivations were in progress and stored after the transition was detected. FW may open the JTAG after all secrets are cleared.

Debug mode values may be set by integrators in the Caliptra configuration files. The default values are shown in the following table.

Note: When entering debug or scan mode, all crypto engines are zeroized. Before starting any crypto operation in these modes, the status registers of all crypto engines must be checked to confirm they are ready. Failing to do so may trigger a fatal error caused by concurrent crypto operations.

Clock gating

Caliptra provides a clock gating feature that turns off clocks when the microcontroller is halted. Clock gating is disabled by default, but can be globally enabled via the following register.

When enabled, halting the microcontroller turns off clocks to all of the cryptographic subsystem, the vaults (key vault, PCR vault, and data vault), mailbox SRAM, SoC interface, and peripherals subsystem. The Watchdog timer and SoC registers run on the gated RDC clock. The RV core implements its own clock gating mechanism. Halting the core automatically turns off its clock.

There are a total of 4 clocks in Caliptra: ungated clock, gated clock, gated RDC clock, and gated SoC IFC clock. The following table shows the different modules and their designated clocks.

Wake up conditions

For details on halting the core and waking up the core from the halt state, see section 5 of the RISC-V VeeR EL2 Programmer's Reference Manual.

When the RV core wakes up, all clocks are enabled. However, when the core is halted, it is possible to wake up Caliptra clocks through:

• A change in generic_input_wires

• Cptra_fatal_error assertion

• Entry to debug or scan modes

• JTAG accesses

• AXI transactions

Activity on the AXI subordinate interface only wakes up the SoC IFC clock. All other clocks remain off until any other condition is met or the core exits the halt state.

Usage

The following applies to the clock gating feature:

• The core should only be halted after all pending vault writes are done and cryptographic operations are complete.
• While the core is halted, any AXI transaction wakes up the SoC interface clock and leaves all other clocks disabled. If the core is still halted when the AXI transactions are done, the SoC interface clock is returned to a disabled state. .
• The RDC clock is similar to an ungated clock and is only disabled when a reset event occurs. This avoids metastability on flops. The RDC clock operates independently of core halt status.

Timing information

The following figure shows the timing information for clock gating.

Figure: Clock gating timing

Integrated TRNG

Caliptra implements a true random number generator (TRNG) block for local use models. Firmware is able to read a random number from the TRNG core by accessing its register block over the AHB-lite interface. This is a configuration that SoC integrators enable by defining CALIPTRA_INTERNAL_TRNG.

This TRNG block is a combination of entropy source and CSRNG implementations. For information, see the ENTROPY_SRC HWIP Technical Specification and the CSRNG HWIP Technical Specification. The core code (see entropy source and csrng) is reused from here but the interface to the module is changed to AHB-lite. This design provides an interface to an external physical random noise generator. This is also referred to as a physical true random number generator (PTRNG). The PTRNG external source is a physical true random noise source. A noise source and its relation to an entropy source are defined by SP 800-90B.

The block is instantiated based on a design parameter chosen at integration time. This is to provide options for SoC to reuse an existing TRNG to build an optimized SoC design. For the optimized scenarios, SoC needs to follow the External-TRNG REQ HW API.

The following figure shows the integrated TRNG block.

Figure: Integrated TRNG block

The following figure shows the CSRNG block.

Figure: CSRNG block

The following figure shows the entropy source block.

Figure: Entropy source block

Operation

Requests for entropy bits start with command requests over the AHB-lite interface to the csrng CMD_REQ register.

The following describes the fields of the command request header:

• Application Command: Selects one of five operations to perform. The commands supported are instantiate, reseed, generate, update, and uninstantiate.

• Command Length: Number of 32-bit words that can optionally be appended to the command. A value of zero will only transfer the command header. A value of 4'hc transfers the header plus an additional twelve 32-bit words of data.

• Command Flag0: flag0 is associated with the current command. Setting this field to True (4’h6) enables flag0 to be enabled. Note that flag0 is used for the instantiate and reseed commands only; for all other commands, the flag0 value is ignored.

• Generate Length: Only defined for the generate command, this field is the total number of cryptographic entropy blocks requested. Each unit represents 128 bits of entropy returned. A value of 8 would return a total of 1024 bits. The maximum size supported is 4096.

First an instantiate command is requested over the SW application interface to initialize an instance in the CSRNG module. Depending on the flag0 and clen fields in the command header, a request to the entropy_src module over the entropy interface is sent to seed the csrng. This can take a few milliseconds if the seed entropy is not immediately available.

Example instantiation:

acmd = 0x1 (Instantiate)

clen/flag0 = The seed behavior is described in the following table.

glen = Not used

Next a generate command is used to request generation of cryptographic entropy bits. The glen field defines how many 128 bit words are to be returned to the application interface. After the generated bits are ready, they can be read out via the GENBITS register. This register must be read out glen * 4 times for each request made.

Example generate command:

acmd = 0x3 (Generate)

clen = 0

flag0 = false (4’h9)

glen = 4 (4 *128 = 512b)

This requires 16 reads from GENBITS to read out all of the generated entropy.

Configuration

The HW application interfaces are not supported. Only the SW application interface should be used for this design.

Physical true random noise source signal descriptions

These are the top level signals defined in caliptra_top.

The following figure shows the top level signals defined in caliptra_top.

Figure: caliptra_top signals

Entropy source signal descriptions

The following table provides descriptions of the entropy source signals.

The following figure shows the entropy source signals.

Figure: Entropy source signals

CSRNG signal descriptions

The following table provides descriptions for the CSRNG signals.

The CSRNG may only be enabled if entropy_src is enabled. After it is disabled, CSRNG may only be re-enabled after entropy_src has been disabled and re-enabled.

FIPS considerations

The following sections illustrate the self-test parameter configuration. The entropy_src block provides additional tests, but Caliptra focuses primarily on the adaptive and repetition count tests, which are the ones strictly required for FIPS compliance. Additional details can be found in NIST publication SP 800-90B.

The TRNG must be re-initialized whenever self-test parameter changes are needed. As described in the previous section, the initialization steps are as follows:

1. Disable csrng and entropy_src in that order.
2. Apply new self-test configuration.
3. Enable entropy_src and csrng in that order.

Adaptive self-test window and thresholds

This section details the configuration of the entropy_src, focusing on how the test window size for the adaptive self-test is determined and how it relates to threshold calculations.

Understanding Test Window Sizes

The adaptive self-test within the entropy_src block utilizes a configurable test window. To clarify its interpretation, two terms are defined:

• ENTROPY_TEST_WINDOW: This refers to the test window size directly configured in the hardware registers of the entropy_src block.
• ACTUAL_TEST_WINDOW: This refers to the effective window size used for the adaptive self-test threshold calculations. Its value depends on how the test scores are aggregated.

The aggregation method is determined by the CONF.THRESHOLD_SCOPE setting in the entropy_src block.

Aggregate per symbol

When CONF.THRESHOLD_SCOPE is enabled:

• The adaptive test combines the inputs from all physical entropy lines into a single, cumulative score.
• The test essentially treats the combined input as a single binary stream, counting the occurrences of '1's.
• In this configuration:
  • If ENTROPY_TEST_WINDOW is set to 1024, then
  • ACTUAL_TEST_WINDOW = ENTROPY_TEST_WINDOW = 1024

Handle each physical noise source separately

When CONF.THRESHOLD_SCOPE is disabled:

• The adaptive test scores each individual physical noise input line independently.
• This allows for monitoring the health of each noise source.
• In this configuration (assuming, for example, 4 noise sources):
  • If ENTROPY_TEST_WINDOW is set to 4096 bits, then
  • ACTUAL_TEST_WINDOW = (ENTROPY_TEST_WINDOW / 4) = 1024

Configuring adaptive self-test thresholds

Once the ACTUAL_TEST_WINDOW is determined, the adaptive self-test thresholds can be configured as follows:

• ADAPTP_HI_THRESHOLDS.FIPS_THRESH = adaptp_cutoff
• ADAPTP_LO_THRESHOLDS.FIPS_THRESH = ACTUAL_TEST_WINDOW - adaptp_cutoff

Here, adaptp_cutoff represents the pre-determined cutoff value for the adaptive proportion test, as defined by NIST SP 800-90B. See the threshold calculations below as an example.

\(α = 2^{-40}\) (recommended)
\(H = 0.5\) (example, estimated entropy measured from hardware)
\(W\) = ACTUAL_TEST_WINDOW
adaptp_cutoff = \(1 + critbinom(W, 2^{-H}, 1 - α)\)

Note: The critbinom function (critical binomial distribution function) is implemented by most spreadsheet applications.

Recommended configuration

The following configuration is recommended for the adaptive and repetition count tests:

Adaptive test

1. Set CONF.THRESHOLD_SCOPE to disabled. This allows the test to monitor and score each physical noise source individually, providing more granular health information.
2. Set HEALTH_TEST_WINDOWS.FIPS_WINDOW to 4096 bits. This value serves as the ENTROPY_TEST_WINDOW. With the current 4 noise source configuration, this is equivalent to 1024 bits per noise source, where each source produces 1 bit of entropy as defined in NIST SP 800-90B.
3. Calculate thresholds. Use an ACTUAL_TEST_WINDOW of 1024 bits (derived from step 2) in the adaptive test threshold formulas provided earlier in this subsection.

Repetition count test

The methodology used for calculating the repetition count threshold in the ROM boot phase can be directly applied for this test as well. The threshold is applied on a per-noise-source basis.

External-TRNG REQ HW API

For SoCs that choose to not instantiate Caliptra’s integrated TRNG, Caliptra provides a TRNGREQ HW API.

1. Caliptra asserts TRNG_REQ wire (FW made the request for a TRNG).
2. SoC writes the TRNG architectural registers.
3. SoC writes a done bit in the TRNG architectural registers.
4. Caliptra desserts TRNG_REQ.

The reason to have a separate interface from the SoC mailbox is to ensure that this request is not intercepted by any SoC FW agents that communicate with the SoC mailbox. It is required for FIPS compliance that this TRNG HW API is always handled by a SoC HW gasket logic and not handled by SoC ROM/FW code.

SoC-SHA accelerator HW API

Caliptra provides a SHA accelerator HW API for Caliptra internal FW to use via mailbox or via DMA operations through the AXI subordinate interface. The SHA accelerator HW API is restricted on AXI for use by Caliptra via the AXI DMA assist block; this access restriction is enforced by checking logic on the AXI AxUSER signal associated with the request.

Using the HW API:

• A user of the HW API first locks the accelerator by reading the LOCK register. A read that returns the value 0 indicates that the resource was locked for exclusive use by the requesting user. A write of ‘1 clears the lock.
• The USER register captures the AXI USERID value of the requestor that locked the SHA accelerator. This is the only user that is allowed to control the SHA accelerator by performing AXI register writes. Writes by any other agent on the AXI subordinate interface are dropped.
• SHA supports Mailbox mode: SHA is computed on LENGTH (DLEN) bytes of data stored in the mailbox beginning at START_ADDRESS. This computation is performed when the EXECUTE register is set by the user. When the operation is completed and the result in the DIGEST register is valid, SHA accelerator sets the VALID bit of the STATUS register.
• Note that even though the mailbox size is fixed, due to SHA save/restore function enhancement, there is no limit on the size of the block that needs to be SHAd. SOC needs to follow FW API
• The SHA computation engine in the SHA accelerator requires big endian data, but the SHA accelerator can accommodate mailbox input data in either the little endian or big endian format. By default, input data is assumed to be little endian and is swizzled to big endian at the byte level prior to computation. For the big endian format, data is loaded into the SHA engine as-is. Users may configure the SHA accelerator to treat data as big endian by setting the ENDIAN_TOGGLE bit appropriately.
• See the register definition for the encodings.
• SHA engine also provides a ‘zeroize’ function through its CONTROL register to clear any of the SHA internal state. This can be used when the user wants to conceal previous state for debug or security reasons.

JTAG implementation

For specific debug flows, see the JTAG/TAP Debug section in Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT).

The following figure shows the JTAG implementation within the Caliptra boundary. The output of the existing DMI wrapper is used to find the non-Core (Caliptra uncore) aperture to route the JTAG commands.

Caliptra’s JTAG/TAP should be implemented as a TAP EP. JTAG is open if the debug mode is set at the time of Caliptra reset deassertion.

Note: If the debug security state switches to debug mode anytime, the security assets and keys are still flushed even though JTAG is not open.

The following table details the alias addresses for registers in soc ifc that are accessible through JTAG. Debug Locked registers are a subset of registers accessible when debug intent is set, when debug is unlocked, or the lifecycle state is DEVICE_MANUFACTURING. Debug Unlocked registers are accessible when debug is unlocked, or the lifecycle state is DEVICE_MANUFACTURING.

Figure: JTAG implementation

Cryptographic subsystem architecture

The architecture of Caliptra cryptographic subsystem includes the following components:

• Symmetric cryptographic primitives
  • De-obfuscation engine
  • SHA512/384 (based on NIST FIPS 180-4 [2])
  • SHA256 (based on NIST FIPS 180-4 [2])
  • HMAC512 (based on NIST FIPS 198-1 [5] and RFC 4868 [6])
  • SHA3 (based on NIST FIPS 202 [17])
• Public-key cryptography
  • NIST Secp384r1 Deterministic Digital Signature Algorithm (based on FIPS-186-4 [11] and RFC 6979 [7])
• Key vault
  • Key slots
  • Key slot management

The high-level architecture of Caliptra cryptographic subsystem is shown in the following figure.

Figure: Caliptra cryptographic subsystem

SHA512/SHA384

SHA512 is a function of cryptographic hash algorithm SHA-2. The hardware implementation is based on Secworks/SHA512 [1]. This implementation complies with the functionality in NIST FIPS 180-4 [2]. The implementation supports the SHA512 variants SHA-512/224, SHA-512/256, SHA384 and SHA512.

The SHA512 algorithm is described as follows:

• The message is padded by the host and broken into 1024-bit chunks
• For each chunk:
  • The message is fed to the SHA512 core
  • The core should be triggered by the host
  • The SHA512 core status is changed to ready after hash processing
• The result digest can be read after feeding all message chunks

Operation

Padding

The message should be padded before feeding to the hash core. The input message is taken, and some padding bits are appended to it to get it to the desired length. The bits that are used for padding are simply ‘0’ bits with a leading ‘1’ (100000…000). The appended length of the message (before pre-processing), in bits, is a 128-bit big-endian integer.

The total size should be equal to 128 bits short of a multiple of 1024 since the goal is to have the formatted message size as a multiple of 1024 bits (N x 1024). The following figure shows the SHA512 input formatting.

Figure: SHA512 input formatting

Hashing

The SHA512 core performs 80 iterative operations to process the hash value of the given message. The algorithm processes each block of 1024 bits from the message using the result from the previous block. For the first block, the initial vectors (IV) are used for starting the chain processing of each 1024-bit block.

FSM

The SHA512 architecture has the finite-state machine as shown in the following figure.

Figure: SHA512 FSM

Signal descriptions

The SHA512 architecture inputs and outputs are described in the following table.

Address map

The SHA512 address map is shown here: sha512_reg — clp Reference (chipsalliance.github.io)

Pseudocode

The following pseudocode demonstrates how the SHA512 interface can be implemented.

Figure: SHA512 pseudocode

SCA countermeasure

We do not propose any countermeasure to protect the hash functions. Inherently, hash functions do not work like other cryptographic engines. Hash functions target integrity without requiring a secret key. Hence, the attacker can target only messages. Also, the attacker cannot build a CPA or DPA platform on the hash function because the same message ideally gives the same side-channel behavior.

If the attacker works on the multi-message mechanism, the attacker then needs to work with single trace attacks, which are very unlikely in ASIC/FPGA implementations. Also, our hash implementation is a noisy platform. As a result, we do not propose any SCA implementation countermeasure on the hash functions.

Performance

The SHA512 core performance is reported considering two different architectures: pure hardware architecture, and hardware/software architecture. These are described next.

Pure hardware architecture

In this architecture, the SHA512 interface and controller are implemented in hardware. The performance specification of the SHA512 architecture is shown in the following table.

Hardware/software architecture

In this architecture, the SHA512 interface and controller are implemented in RISC-V core. The performance specification of the SHA512 architecture is shown in the following table.

Pure software architecture

In this architecture, the SHA512 algorithm is implemented fully in software. The implementation is derived from the OpenSSL SHA512 implementation [3]. The performance numbers for this architecture are shown in the following table.

SHA256

SHA256 is a function of the SHA-2 cryptographic hash algorithm. The hardware implementation is based on Secworks/SHA256 [1]. The implementation supports the two variants: SHA256/224 and SHA256.

The SHA256 algorithm is described as follows:

• The message is padded by the host and broken into 512-bit chunks
• For each chunk:
  • The message is fed to the sha256 core
  • The core should be triggered by the host
  • The sha256 core status is changed to ready after hash processing
• The result digest can be read after feeding all message chunks

Operation

Padding

The message should be padded before feeding to the hash core. The input message is taken, and some padding bits are appended to the message to get it to the desired length. The bits that are used for padding are simply ‘0’ bits with a leading ‘1’ (100000…000). The appended length of the message (before pre-processing), in bits, is a 64-bit big-endian integer.

The total size should be equal to 64 bits, short of a multiple of 512 because the goal is to have the formatted message size as a multiple of 512 bits (N x 512).

The following figure shows SHA256 input formatting.

Figure: SHA256 input formatting

Hashing

The SHA256 core performs 64 iterative operations to process the hash value of the given message. The algorithm processes each block of 512 bits from the message using the result from the previous block. For the first block, the initial vectors (IV) are used to start the chain processing of each 512-bit block.

FSM

The SHA256 architecture has the finite-state machine as shown in the following figure.

Figure: SHA256 FSM

Signal descriptions

The SHA256 architecture inputs and outputs are described as follows.

* For more imformation about these inputs, please refer to LMS accelerator section.

Address map

The SHA256 address map is shown here: sha256_reg — clp Reference (chipsalliance.github.io).

Pseudocode

The following pseudocode demonstrates how the SHA256 interface can be implemented.

Figure: SHA256 pseudocode

SCA countermeasure

We do not propose any countermeasure to protect the hash functions. For more information, see SCA countermeasure in the SHA512/SHA384 section.

Performance

The SHA256 core performance is reported considering two different architectures: pure hardware architecture, and hardware/software architecture. These are described next.

Pure hardware architecture

In this architecture, the SHA256 interface and controller are implemented in hardware. The performance specification of the SHA256 architecture is reported as shown in the following table.

Hardware/software architecture

In this architecture, the SHA256 interface and controller are implemented in RISC-V core. The performance specification of the SHA256 architecture is reported as shown in the following table.

SHA3

The SHA3 HWIP performs the hash functions, whose purpose is to check the integrity of the received message. It supports various SHA3 hashing functions including SHA3 Extended Output Function (XOF) known as SHAKE functions. The details of the operation are described in the SHA3 specification, FIPS 202 known as sponge construction. It has been adapted from OpenTitan and you can find documentation describing the functionality of the KMAC block it was derived from here. In the current use cases of the SHA3 HW IP, either (a) messages are not considered secret (External Mu), or (b) SCA hardening would not be meaningful (HPKE in OCP L.O.C.K.), hence there are no SCA requirements.

Features

• Support for SHA3-224, 256, 384, 512, SHAKE[128, 256] and cSHAKE[128, 256]
• Support byte-granularity on input message
• Support arbitrary output length for SHAKE, cSHAKE
• Support customization input string S, and function-name N up to 36 bytes total
• 64b x 10 depth Message FIFO
• Performance (at 100 MHz):
  • SHA3-224: 2.93 B/cycle, 2.34 Gbit/s - 1.19 B/cycle, 952 Mbit/s (DOM)
  • SHA3-512: 1.47 B/cycle, 1.18 Gbit/s - 0.59 B/cycle, 472 Mbit/s (DOM)

Design Details

Keccak Round

A Keccak round implements the Keccak_f function described in the SHA3 specification. Keccak round logic in SHA3 HWIP not only supports 1600 bit internal states but also all possible values {25, 50, 100, 200, 400, 800, 1600} based on a parameter Width. Keccak permutations in the specification allow arbitrary number of rounds. This module, however, supports Keccak_f which always runs 12 + 2*L rounds, where \[ L = log_2 {( {Width \over 25} )} \] . For instance, 200 bits of internal state run 18 rounds. SHA3 instantiates the Keccak round module with 1600 bit.

Keccak round logic has two phases inside. Theta, Rho, Pi functions are executed at the 1st phase. Chi and Iota functions run at the 2nd phase. The first phase and the second phase run in the same cycle.

To save circuit area, the Chi function uses 800 instead 1600 DOM multipliers but the multipliers are fully pipelined. The Chi and Iota functions are thus separately applied to the two halves of the state and the 2nd phase takes in total three clock cycles to complete. In the first clock cycle of the 2nd phase, the first stage of Chi is computed for the first lane halves of the state. In the second clock cycle, the new first lane halves are output and written to state register. At the same time, the first stage of Chi is computed for the second lane halves. In the third clock cycle, the new second lane halves are output and written to the state register.

Padding for Keccak

Padding logic supports SHA3/SHAKE/cSHAKE algorithms. cSHAKE needs the extra inputs for the Function-name N and the Customization string S. Other than that, SHA3, SHAKE, and cSHAKE share similar datapath inside the padding module except the last part added next to the end of the message. SHA3 adds 2'b 10, SHAKE adds 4'b 1111, cSHAKE adds 2'b00 then pad10*1() follows. All are little-endian values.