Revision table

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:

• AMD
• Google
• Microsoft
• Nvidia

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.

Compliance with OCP Tenets

Openness

The Caliptra source for RTL and firmware are licensed using the Apache 2.0 license. See caliptra.io for links to all code repositories and companion specifications.

Efficiency

Caliptra is used during the boot sequence and upgrade cycles, so it cannot yield a measurable impact on system efficiency.

Impact

Caliptra brings consistency and transparency to a foundational area of security and confidential compute. Open source in-package RoTs have not been attempted before in the industry. It is challenging to align partners, and it is challenging to align a common core of functionality everyone agrees upon in this space. Caliptra breaches multiple traditional blockers and creates new ground for the industry and for open ecosystems.

Scale

Caliptra is a committed intercept for Google and Microsoft first party Cloud silicon. It is also a committed intercept for AMD server silicon products. This scale covers both a significant portion of the Cloud market as well as one of the two key CPU vendors in hyperscale and enterprise.

Sustainability

Caliptra is synthesized to about a quarter of a square millimeter in modern tapeout processes. It boots and generates a DICE chain in less than 200 milliseconds, executing at 400MHz. During the rest of execution, the RISC-V core is idle waiting for mailbox requests. We anticipate millions of Caliptra instances to consume mere Joules per year, which is conducive to sustainability.

Base specification

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 OCP Security WG: Ownership Transfer 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 Platform Firmware Resiliency Guidelines, 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. (See Section for links.)

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 Attestation of System Components v1.0 Requirements and Recommendations, devices must have a cryptographic identity for the endorsement of attestation quotes. The RTM implementation follows TCG DICE (for information, see TCG DICE Layering Architecture Version 1.0 Revision 0.19, TCG DICE Attestation Architecture Version 1.00 Revision 0.23, and Hardware Requirements for a Device Identifier Composition Engine Version 1.0 Revision 0.91. 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: Tools accessible to attacker {#tools-accessible-to-attacker}

Table: Type of access to level of access {#type-level-of-access}

Table: Definition of expertise (JIL) {#definition-of-expertise}

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: Attack types {#attack-types}

Table: Logical attacks {#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.

{#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: Assets {#assets}

High level architecture

The following figure shows the basic high-level blocks of 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 runtime cryptographic mailbox commands documentation for more 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.

{#passive-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.

{#dice-key-gen}

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 Attestation of System Components v1.0 Requirements and Recommendations).

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 four 8-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 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

{#subsystem-uds-manufacturing-flow}

There are two ways of generating a UDS seed:

1. Use the internal TRNG to directly generate a 512-bit random number.
2. Use an entity external to Caliptra such as an HSM or SoC-specific methodology to produce the 512-bit random number for the UDS seed that is pushed into the fuse controller (same as Caliptra 1.0).

UDS Manufacturing

To use the internal TRNG to generate the UDS seed during manufacturing in subsystem mode:

1. When SoC life cycle is in MANUFACTURING MODE, set the manufacturing service register bit SS_DBG_MANUF_SERVICE_REG_REQ[2] through JTAG to request the UDS seed programming flow.
2. Caliptra ROM will sample this bit on power up; when this bit is set, Caliptra ROM rechecks that the life cycle state is manufacturing mode and reads the iTRNG for a 512-bit value.
3. Caliptra ROM writes the 512-bit value to the address available through registers named SS_UDS_SEED_BASE_ADDR_L and SS_UDS_SEED_BASE_ADDR_H (which are strapped by SoC at integration time) by using Caliptra's DMA.
4. Caliptra ROM sets the corresponding status bit in SS_DBG_MANUF_SERVICE_REG_RSP 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 (e.g., fuse macro voltage elevation flows).

Provisioning IDevID during manufacturing

{#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 TCG DICE Attestation Architecture Version 1.00 Revision 0.23 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. 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: IDevID certificate fields {#idevid-cert-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: LDevID certificate fields {#ldevid-cert-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: Alias~FMC~ certificate fields {#alias-fmc-cert-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: Alias~RT~ certificate fields {#alias-rt-cert-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

{#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: Security states {#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 unsecured 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 Platform Firmware Resiliency Guidelines). 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: NIST SP 800-193 requirements {#nist-sp-800-193-requirements}

Secure boot flow

Caliptra shall follow and implement the secure boot guidelines as described in Open Compute Project Secure Boot Specification.

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: PCR bank usage {#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) 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^2^ 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. Side-Channel Attacks: Ten Years After Its Publication and the Impacts on Cryptographic Module Security Testing 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 Attestation of System Components v1.0 Requirements and Recommendations 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: KAT failure mitigations {#kat-failure-mitigations}

Table: POST/CAST usage {#post-cast-usage}

As shown in Table, 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 Open Compute Project Secure Boot Specification.

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), a header (Table), and a Table of Contents (TOC) (Table). The image layout is shown in Figure.

{#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.

Fields in Tables [-Table], [-Table], [-Table], [-Table], and [-Table] that are 4-byte dwords are little endian unless described otherwise. Hashes must be stored with each 32-bit dword having swapped endianness from the SHA2 standard byte order. Signatures are stored in the byte order indicated in the standard.

Table: Firmware manifest preamble {#fw-manifest-preamble}

Table: ECC Manufacturer Public Key Descriptor {#ecc-pub-key-descriptor}

Table: PQC Manufacturer Public Key Descriptor {#pqc-pub-key-descriptor}

Table: Firmware manifest header {#fw-manifest-header}

Table: Table of contents {#toc}

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 2.1 provides cryptographic servies to support ML-KEM (in addition to ECDH) key exchanges.

Key rotation

Firmware signing key rotation shall follow the requirements described in Open Compute Project Secure Boot Specification.

Hardware

Please refer to Caliptra HW specification

Passive Caliptra FW Load flow

{#passive-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

{#hardare-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 256 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.

{#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).

{#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 to hash the required data and present it back to Calitpra FW.

JTAG/TAP debug

{#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: JTAG accessible registers {#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 Attestation of System Components v1.0 Requirements and Recommendations.

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: Caliptra Fuse Map {#caliptra-fuse-map}

Error reporting and handling

This section describes Caliptra error reporting and handling.

Table: Hardware and firmware error types {#hw-fw-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.

{#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.

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)
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.

{#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

OCP Recovery Document

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. Initialization step: Caliptra ROM initializes PROT_CAP, DEVICE_ID, DEVICE_STATUS, RECOVERY_STATUS, HW_STATUS, INDIRECT_FIFO_STATUS (remove these two reg from ROM initialization) default values. Note: Any I3C initialization is done b/w MCU ROM, I3C target HW and I3C initiator. This is not part of this document.
2. MCU Specific SoC init of I3C & streaming boot interface.
   1. MCU ROM can set HW_STATUS register per recovery spec, at any time based on SOC specific conditions.
   2. MCU ROM will program DEVICE_ID register value based on associated fuse values.
   3. 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 & max transfer size.
3. Caliptra ROM will update PROT_CAP register, bit 11 to set to ‘1 “Flashless boot (From RESET)”. Caliptra ROM will set other register bits based on other recovery capabilities. PROT_CAP will also indicate support for FIFO CMS for I3C device by updating byte 10-11, bit 12 with 0x1 “FIFO CMS Support”.
4. To start streaming boot, Caliptra ROM will write DEVICE_STATUS register to “RECOVERY_MODE” by writing byte 0, with data 0x3. Caliptra ROM will write DEVICE_STATUS register’s byte 2-3 to set the FSB parameter (0x12).
5. I3C streaming boot HW will set byte 1 based on the DEVICE_STATUS register based on the rules defined for this register. This register status will assist BMC operation.
6. Caliptra ROM will write via DMA assist to RECOVERY_STATUS register with data of (byte 0, 0x1) and sets the streaming boot image index to 0x0
7. BMC or a similar platform component will update INDIRECT_FIFO_CTRL with Component Memory Space (CMS) byte 0 with 0x0, Reset field byte 1 with 0x1 and Image size byte 2 to 5 field to size of the image.
8. BMC or a similar platform component writes to INDIRECT_FIFO_DATA register. 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.
9. The I3C device will keep head and tail pointers along with FIFO status up to date into INDIRECT_FIFO_STATUS register. I3C streaming boot interface HW wait for an update to INDIRECT_DATA_REG with 1-256B data from BMC.
10. If there is a write to INDIRECT_DATA_FIFO, I3C device will indicate data availability via side channel implemented as wire “payload_available” ( for more details read here) to Caliptra. Caliptra HW will latch this wire into the register for Caliptra firmware to read.
11. Caliptra ROM arms DMA interface to read INDIRECT_FIFO_CTRL for the image size and programs DMA engine back to read the image data from INDIRECT_FIFO_DATA.
12. Steps 9 through 11 repeat until all the images are pushed over I3C and it matches the image size initialized into the INDIRECT_FIFO_CTRL register.
13. After the above steps, Caliptra ROM Firmware will wait for BMC to activate image indicated to Caliptra via side channel.
14. If the Image is activated, update RECOVERY STATUS to “Booting recovery image” by writing byte0, with data 0x2. If the image is authenticated, then the Caliptra RT FW will update the image index in RECOVERY_STATUS register (0x1 in byte 0, bits 7:4) and then set then update the byte 0, bit 3:0 to “Awaiting for recovery image” (0x1)
15. BMC or a similar platform component will send the next image as requested in the image index, and Caliptra RT FW and I3C HW go through the same flow as above.

BMC or a similar platform component requirements for recovery support

1. It 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 bye by writing 1).
2. It must send 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 must read FIFO empty status from INDIRECT_FIFO_STATUS register.
3. After last write for the image, it must activate the image after reading INDIRECT_FIFO_STATUS register, FIFO empty status.

Lifecycle Controller & SoC Debug Architecture

Please refer to Caliptra subsystem hardware specification.

Terminology

The following acronyms and abbreviations are used throughout this document.

Acknowledgements

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)
• Howard Tran (Google)
• James Zhang (NVIDIA)
• Jeff Andersen (Google)
• John Traver (AMD)
• Jordan Hand (Google)
• Kor Nielsen (Google)
• Louis Ferraro (AMD)
• Marius Schilder (Google)
• Matt Cockrell (Google)
• Michael Norris (Microsoft)
• Nathan Nadarajah (AMD)
• 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)

Caliptra Hardware Specification

Revision 2.0.3

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

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 initial power-on arc of the Mailbox Boot FSM.

Figure 1: Mailbox 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.

BOOT_DONE enables Caliptra reset de-assertion 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_fw_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. The boot flow is modified as shown in the following figure.

Figure 2: Mailbox Boot FSM state diagram for FW update reset

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.

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 3: 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 10: 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 11: Integrated TRNG block

The following figure shows the CSRNG block.

Figure 12: CSRNG block

The following figure shows the entropy source block.

Figure 13: 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 14: 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 15: 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.

Figure 16: 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])
• 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 17: 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 18: 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 19: 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 20: 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 21: 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 22: 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 23: 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.

HMAC512/HMAC384

Hash-based message authentication code (HMAC) is a cryptographic authentication technique that uses a hash function and a secret key. HMAC involves a cryptographic hash function and a secret cryptographic key. This implementation supports the HMAC512 variants HMAC-SHA-512-256 and HMAC-SHA-384-192 as specified in NIST FIPS 198-1 [5]. The implementation is compatible with the HMAC-SHA-512-256 and HMAC-SHA-384-192 authentication and integrity functions defined in RFC 4868 [6].

Caliptra HMAC implementation uses SHA512 as the hash function, accepts a 512-bit key, and generates a 512-bit tag.

The implementation also supports PRF-HMAC-SHA-512. The PRF-HMAC-SHA-512 algorithm is identical to HMAC-SHA-512-256, except that variable-length keys are permitted, and the truncation step is not performed.

The HMAC algorithm is described as follows:

• The key is fed to the HMAC core to be padded
• The message is broken into 1024-bit chunks by the host
• For each chunk:
  • The message is fed to the HMAC core
  • The HMAC core should be triggered by the host
  • The HMAC 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 HMAC core. Internally, the i_padded key is concatenated with the message. 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 total size should be equal to 128 bits, short of a multiple of 1024 because the goal is to have the formatted message size as a multiple of 1024 bits (N x 1024).

Figure 24: HMAC input formatting

The following figures show examples of input formatting for different message lengths.

Figure 25: Message length of 1023 bits

When the message is 1023 bits long, padding is given in the next block along with message size.

Figure 26: 1 bit padding

When the message size is 895 bits, a padding of ‘1’ is also considered valid, followed by the message size.

Figure 27: Multi block message

Messages with a length greater than 1024 bits are broken down into N 1024-bit blocks. The last block contains padding and the size of the message.

Hashing

The HMAC512 core performs the sha2-512 function to process the hash value of the given message. The algorithm processes each block of the 1024 bits from the message, using the result from the previous block. This data flow is shown in the following figure.

Figure 28: HMAC-SHA-512-256 data flow

The HMAC384 core performs the sha2-384 function to process the hash value of the given message. The algorithm processes each block of the 1024 bits from the message, using the result from the previous block. This data flow is shown in the following figure.

Figure 29: HMAC-SHA-384-192 data flow

FSM

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

Figure 30: HMAC FSM

CSR Mode

When the CSR Mode register is set, the HMAC512 core uses the value latched from the cptra_csr_hmac_key interface pins in place of the API key register. These pins are latched internally after powergood assertion during DEVICE_MANUFACTURING lifecycle state. During debug mode operation this value is overridden with all 1's, and during any other lifecycle state it has a value of zero.

Signal descriptions

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

Address map

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

Pseudocode

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

Figure 31: HMAC pseudocode

SCA countermeasure

In an attack model, an attacker can form hypotheses about the secret key value and compute the corresponding output values by using the Hamming Distance model as an appropriate leakage model. An attacker who has knowledge of the implementation for open-source architecture has an advantage. The attacker can capture the power consumption traces to verify their hypotheses, by partitioning the acquisitions or using Pearson’s correlation coefficient.

To protect the HMAC algorithm from side-channel attacks, a masking countermeasure is applied. This means that random values are added to the intermediate variables during the algorithm’s execution, so that the side-channel signals do not reveal any information about them.

The embedded countermeasures are based on "Differential Power Analysis of HMAC Based on SHA-2, and Countermeasures" by McEvoy et. al. To provide the required random values for masking intermediate values, a lightweight 74-bit LFSR is implemented. Based on “Spin Me Right Round Rotational Symmetry for FPGA-specific AES” by Wegener et. al., LFSR is sufficient for masking statistical randomness.

Each round of SHA512 execution needs 6,432 random bits, while one HMAC operation needs at least 4 rounds of SHA512 operations. However, the proposed architecture requires only 384-bit LFSR seed and provides first-order DPA attack protection at the cost of 10% latency overhead with negligible hardware resource overhead.

Performance

The HMAC 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 HMAC interface and controller are implemented in hardware. The performance specification of the HMAC architecture is reported as shown in the following table.

Hardware/software architecture

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

HMAC_DRBG

Hash-based message authentication code (HMAC) deterministic random bit generator (DRBG) is a cryptographic random bit generator that uses a HMAC function. HMAC_DRBG involves a cryptographic HMAC function and a seed. This architecture is designed as specified in section 10.1.2. of NIST SP 800-90A [12]. For ECC signing operation, the implementation is compatible with section 3.1. of RFC 6979 [7].

Caliptra HMAC_DRBG implementation uses HMAC384 as the HMAC function, accepts a 384-bit seed, and generates a 384-bit random value.

The HMAC algorithm is described as follows:

• The seed is fed to HMAC_DRBG core by the host
• For each 384-bit random value
  • The core should be triggered by the host
  • The HMAC_DRBG core status is changed to ready after HMAC processing
  • The result digest can be read

Operation

HMAC_DRBG uses a loop of HMAC(K, V) to generate the random bits. In this algorithm, two constant values of K_init and V_init are used as follows:

        1. 	Set V_init = 0x01 0x01 0x01 ... 0x01  (V has 384-bit)
        2. 	Set K_init = 0x00 0x00 0x00 ... 0x00  (K has 384-bit)
        3. 	K_tmp = HMAC(K_init, V_init || 0x00 || entropy || nonce)
        4. 	V_tmp = HMAC(K_tmp,  V_init)
        5. 	K_new = HMAC(K_tmp,  V_tmp  || 0x01 || entropy || nonce)
        6. 	V_new = HMAC(K_new,  V_tmp)
        7. 	Set T = []
        8. 	T = T || HMAC(K_new, V_new)
        9. 	Return T if T is within the [1,q-1] range, otherwise:
        10.	K_new = HMAC(K_new,  V_new || 0x00)
        11.	V_new = HMAC(K_new,  V_new)
        12.	Jump to 8

For ECC KeyGen operation, HMAC_DRBG is used to generate privkey as follows:

Privkey = HMAC_DRBG(seed, nonce)

For ECC SIGNING operation, HMAC_DRBG is used to generate k as follows:

K = HMAC_DRBG(privkey, hashed_msg)

Signal descriptions

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

Address map

The HMAC_DRBG is embedded into ECC architecture, since there is no address map to access it from FW.

SCA countermeasure

For information, see SCA countermeasure in the HMAC384 section.

ECC

The ECC unit includes the ECDSA (Elliptic Curve Digital Signature Algorithm) engine and the ECDH (Elliptic Curve Diffie-Hellman Key-Exchange) engine, offering a variant of the cryptographically secure Digital Signature Algorithm (DSA) and Diffie-Hellman Key-Exchange (DH), which uses elliptic curve (ECC). A digital signature is an authentication method in which a public key pair and a digital certificate are used as a signature to verify the identity of a recipient or sender of information.

The hardware implementation supports deterministic ECDSA, 384 Bits (Prime Field), also known as NIST-Secp384r1, described in RFC6979.

The hardware implementation also supports ECDH, 384 Bits (Prime Field), also known as NIST-Secp384r1, described in SP800-56A.

Secp384r1 parameters are shown in the following figure.

Figure 32: Secp384r1 parameters

Operation

The ECDSA consists of three operations, shown in the following figure.

Figure 33: ECDSA operations

The ECDH also consists of the sharedkey generation.

KeyGen

In the deterministic key generation, the paired key of (privKey, pubKey) is generated by KeyGen(seed, nonce), taking a deterministic seed and nonce. The KeyGen algorithm is as follows:

• Compute privKey = HMAC_DRBG(seed, nonce) to generate a random integer in the interval [1, n-1] where n is the group order of Secp384 curve.
• Generate pubKey(x,y) as a point on ECC calculated by pubKey=privKey × G, while G is the generator point over the curve.

Signing

In the signing algorithm, a signature (r, s) is generated by Sign(privKey, h), taking a privKey and hash of message m, h = hash(m), using a cryptographic hash function, SHA512. The signing algorithm includes:

• Generate a random number k in the range [1..n-1], while k = HMAC_DRBG(privKey, h)
• Calculate the random point R = k × G
• Take r = Rx mod n, where Rx is x coordinate of R=(Rx, Ry)
• Calculate the signature proof: s = k^-1 × (h + r × privKey) mod n
• Return the signature (r, s), each in the range [1..n-1]

Verifying

The signature (r, s) can be verified by Verify(pubKey ,h ,r, s) considering the public key pubKey and hash of message m, h=hash(m) using the same cryptographic hash function SHA512. The output is r’ value of verifying a signature. The ECDSA verify algorithm includes:

• Calculate s1 = s⁻¹ mod n
• Compute R' = (h × s1) × G + (r × s1) × pubKey
• Take r’ = R'x mod n, while R'x is x coordinate of R’=(R'x, R'y)
• Verify the signature by comparing whether r' == r

ECDH sharedkey

In ECDH sharedkey generation, the shared key is generated by ECDH_sharedkey(privKey_A, pubKey_B), taking an own prikey and other party pubkey. The ECDH sharedkey algorithm is as follows:

• Compute P = sharedkey(privkey_A, pubkey_b) where P(x,y) is a point on ECC.
• Output sharedkey = Px, where Px is x coordinate of P.

Architecture

The ECC top-level architecture is shown in the following figure.

Figure 34: ECC architecture

Signal descriptions

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

Address map

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

Pseudocode

The following pseudocode blocks demonstrate example implementations for KeyGen, Signing, Verifying, and ECDH sharedkey.

KeyGen

Figure 35: KeyGen pseudocode

Signing

Figure 36: Signing pseudocode

Verifying

Figure 37: Verifying pseudocode

ECDH sharedkey

Figure 38: ECDH sharedkey pseudocode

SCA countermeasure

The described ECC has four main routines: KeyGen, Signing, Verifying, and ECDH sharedkey. Since the Verifying routine requires operation with public values rather than a secret value, our side-channel analysis does not cover this routine. Our evaluation covers the KeyGen, Signing, and ECDH sharedkey routines where the secret values are processed.

KeyGen consists of HMAC DRBG and scalar multiplication, while Signing first requires a message hashing and then follows the same operations as KeyGen (HMAC DRBG and scalar multiplication). The last step of Signing is generating “S” as the proof of signature. Since HMAC DRBG and hash operations are evaluated separately in our document, this evaluation covers scalar multiplication and modular arithmetic operations.

Scalar multiplication

To perform the scalar multiplication, the Montgomery ladder is implemented, which is inherently resistant to timing and single power analysis (SPA) attacks.

Implementation of complete unified addition formula for the scalar multiplication avoids information leakage and enhances architecture from security and mathematical perspectives.

To protect the architecture against horizontal power/electromagnetic (EM) and differential power analysis (DPA) attacks, several countermeasures are embedded in the design [9]. Since these countermeasures require random inputs, HMAC-DRBG is fed by IV to generate these random values.

Since HMAC-DRBG generates random value in a deterministic way, firmware MUST feed different IV to ECC engine for EACH keygen, signing, and ECDH sharedkey operation.

Base point randomization

This countermeasure is achieved using the randomized base point in projective coordinates. Hence, the base point G=(Gx, Gy) in affine coordinates is transformed and randomized to projective coordinates as (X, Y, Z) using a random value as follows:

This approach does not have the performance or area overhead because the architecture is variable-base-point implemented.

Scalar blinding

This countermeasure is achieved by randomizing the scalar as follows:

Based on [10], half of the bit size of is required to prevent advanced DPA attacks. Therefore, has 192 bits, and the blinded scalar has 576 bits. Hence, this countermeasure extends the Montgomery ladder iterations due to extended scalar.

This approach is achieved at the cost of 50% more latency on scalar multiplication and adding one lightweight block, including one 32*32 multiplier and an accumulator.

Note: the length of rand is configurable to have a trade-off between the required protection and performance.

Making countermeasures embedded into HMAC_DRBG

In the first step of the KeyGen operation, the privkey is generated using HMAC_DRBG by feeding the following two inputs: seed and nonce. To avoid SCA information leakage during this operation, we embed masking countermeasures into the HMAC_DRBG architecture.

Each round of SHA512 execution needs 6,432 random bits, and one HMAC operation needs at least 4 rounds of SHA512 operations. Furthermore, each HMAC_DRBG round needs at least 5 rounds of HMAC operations. However, the proposed architecture uses a lightweight LFSR and provides first-order DPA attack protection with negligible latency and hardware resource overhead.

ECDSA signing nonce leakage

Generating “S” as the proof of signature at the steps of the signing operation leaks where the hashed message is signed with private key and ephemeral key as follows:

Since the given message is known or the signature part r is known, the attacker can perform a known-plaintext attack. The attacker can sign multiple messages with the same key, or the attacker can observe part of the signature that is generated with multiple messages but the same key.

The evaluation shows that the CPA attack can be performed with a small number of traces, respectively. Thus, an arithmetic masked design for these operations is implemented.

Masking signature

This countermeasure is achieved by randomizing the privkey as follows:

Although computation of “S” seems the most vulnerable point in our scheme, the operation does not have a big contribution to overall latency. Hence, masking these operations has low overhead on the cost of the design.

Random number generator for SCA countermeasure

The ECC countermeasure requires several random vectors to randomize the intermediate values, as described in the preceding section. HMAC_DRBG is used to take one random vector of 384-bit (i.e., ECC_IV register) and to generate the required random vectors for different countermeasures.

The state machine of HMAC_DRBG utilization is shown in the following figure, including three main states:

1. SCA random generator: Running HMAC_DRBG with IV and an internal counter to generate the required random vectors.
2. KEYGEN PRIVKEY: Running HMAC_DRBG with seed and nonce to generate the privkey in KEYGEN operation.
3. SIGNING NONCE: Running HMAC_DRBG based on RFC6979 in SIGNING operation with privkey and hashed_msg.

Figure 39: HMAC_DRBG utilization

In SCA random generator state:

• This state (in KeyGen operation mode) generates 3 384-bit random vectors for the following: LFSR, base point randomization, and scalar blinding randomization.
• This state (in signing operation) generates 4 384-bit random vectors for the following: LFSR, base point randomization, scalar blinding, and masking signature randomization.
• HMAC_DRBG is initialized with IV and an internal counter. This 64-bit counter enables after reset and zeroization and contains different values depending on when ECC is called.
• HMAC_DRBG is enabled by the INIT command. To generate all required vectors, HMAC-DRBG is continued by the NEXT command that increments the built-in counter inside the HMAC-DRBG unit.
• To initialize the required seed for LFSR, LFSR_INIT_SEED is set as a constant by RTL after reset and zeroization. However, this value is updated before enabling HMAC_DRBG as follows:
  • In the first execution of HMAC_DRBG after reset and zeroization, hmac_lfsr_seed is equal to LFSR_INIT_SEED XORed by internal 64-bit counter.
  • In the next executions of HMAC_DRBG, hmac_lfsr_seed is equal to HMAC_DRBG output of the first execution XORed by internal 64-bit counter.

The data flow of the HMAC_DRBG operation in keygen operation mode is shown in the following figure.

Figure 40: HMAC_DRBG data flow

TVLA results

Test vector leakage assessment (TVLA) provides a robust test using a 𝑡-test. This test evaluates the differences between sets of acquisitions to determine if one set of measurement can be distinguished from the other. This technique can detect different types of leakages, providing a clear indication of leakage or lack thereof.

In practice, observing a t-value greater than a specific threshold (mainly 4.5) indicates the presence of leakage. However, in ECC, due to its latency, around 5 million samples are required to be captured. This latency leads to many false positives and the TVLA threshold can be considered a higher value than 4.5. Based on the following figure from “Side-Channel Analysis and Countermeasure Design for Implementation of Curve448 on Cortex-M4” by Bisheh-Niasar et. al., the threshold can be considered equal to 7 in our case.

Figure 41: TVLA threshold as a function of the number of samples per trace

KeyGen TVLA

The TVLA results for performing seed/nonce-dependent leakage detection using 200,000 traces is shown in the following figure. Based on this figure, there is no leakage in ECC keygen by changing the seed/nonce after 200,000 operations.

Figure 42: seed/nonce-dependent leakage detection using TVLA for ECC keygen after 200,000 traces

Signing TVLA

The TVLA results for performing privkey-dependent leakage detection using 20,000 traces is shown in the following figure. Based on this figure, there is no leakage in ECC signing by changing the privkey after 20,000 operations.

Figure 43: privkey-dependent leakage detection using TVLA for ECC signing after 20,000 traces

The TVLA results for performing message-dependent leakage detection using 64,000 traces is shown in the following figure. Based on this figure, there is no leakage in ECC signing by changing the message after 64,000 operations.

Figure 44: Message-dependent leakage detection using TVLA for ECC signing after 64,000 traces

The point with t-value equal to -40 is mapped to the Montgomery conversion of the message that is a publicly known value (no secret is there). By ignoring those corresponding samples, there are some sparse samples with a t-value greater than 7, as shown in the following table.

Performance

The ECC core performance is reported in the next section.

Pure hardware architecture

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

LMS Accelerator

LMS cryptography is a type of hash-based digital signature scheme that was standardized by NIST in 2020. It is based on the Leighton-Micali Signature (LMS) system, which uses a Merkle tree structure to combine many one-time signature (OTS) keys into a single public key. LMS cryptography is resistant to quantum attacks and can achieve a high level of security without relying on large integer mathematics.

Caliptra supports only LMS verification using a software/hardware co-design approach. Hence, the LMS accelerator reuses the SHA256 engine to speedup the Winternitz chain by removing software-hardware interface overhead. The LMS-OTS verification algorithm is shown in follwoing figure:

Figure 45: LMS-OTS Verification algorithm

The high-level architecture of LMS is shown in the following figure.

Figure 46: LMS high-level architecture

LMS parameters

LMS parameters are shown in the following table:

• SHA256 is used for n=32 and SHA256/192 is used for n=24.
• SHAKE256 is not supported in this architecture.
• Value of p is determined based on w. If w=1, p is equal to 265, and so on.

Winternitz Chain Accelerator

The Winternitz hash chain can be accelerated in hardware to enhance the performance of the design. For that, a configurable architecture is proposed that can reuse SHA256 engine. The LMS accelerator architecture is shown in the following figure, while H is SHA256 engine.

Figure 47: Winternitz chain architecture

Signal descriptions

The LMS accelerator integrated into SHA256 architecture inputs and outputs are described as follows.

Address map

The address map for LMS accelerator integrated into SHA256 is shown here: sha256_reg — clp Reference (chipsalliance.github.io).

Adams Bridge - Dilithium (ML-DSA)

Please refer to the Adams-bridge specification

Address map

Address map of ML-DSA accelerator is shown here: ML-DSA_reg — clp Reference (chipsalliance.github.io)

AES

The AES unit is a cryptographic accelerator that processes requests from the processor to encrypt or decrypt 16-byte data blocks. It supports AES-128/192/256 in various modes, including Electronic Codebook (ECB), Cipher Block Chaining (CBC), Cipher Feedback (CFB) with a fixed segment size of 128 bits (CFB-128), Output Feedback (OFB), Counter (CTR), and Galois/Counter Mode (GCM).

The AES unit is reused from here, (see aes with a shim to translate from AHB-lite to the tl-ul interface.

Additional registers have been added to support key vault integration. Keys from the key vault can be loaded into the AES unit to be used for encryption or decryption.

Operation

For more information, see the AES Programmer's Guide.

Signal descriptions

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

Address map

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

SCA countermeasures

The AES unit employs separate SCA countermeasures for the AES cipher core used for the encryption/decryption part and for the GHASH module used for computing the integrity tag in GCM.

AES cipher core

A detailed specification of the SCA countermeasure employed in the AES cipher core is shown here: AES cipher core SCA countermeasure. The most critical building block of the SCA countermeasure, i.e., the masked AES S-Box, successfully passes formal masking verification at the netlist level using Alma: Execution-aware Masking Verification. The flow required for repeating the formal masking verification using Alma together with a Howto can be found here. The entire AES cipher core including the masked S-Boxes and as well as the PRNG generating the randomness for remasking successfully passes masking evaluation at the netlist level using PROLEAD - A Probing-Based Leakage Detection Tool for Hardware and Software. The flow required for repeating the masking evaluation using PROLEAD together with a Howto can be found here.

GHASH module

A detailed specification of the SCA countermeasure employed in the GHASH module is shown here: GHASH module SCA countermeasure.

To optimize and verify this masking countermeasure, two different types of experiments have been performed for which the results are given below.

1. Formal masking verification using Alma: Execution-aware Masking Verification. These experiments led to a series of small design optimizations which have been integrated into Caliptra. The resulting design successfully passes formal masking verification at the netlist level.
2. Test-vector leakage assessment (TVLA) applied to power SCA traces captured on a ChipWhisperer-based FPGA setup. These experiments confirm the formal masking verification results: No 1st-order SCA can be observed during the GHASH operation. The leakage observed at the boundary of and outside the GHASH operation can be attributed to the evaluation methodology and the handling of unmasked and uncritical data, as well as to FPGA-specific leakage effects known from literature. We are confident that the optimized SCA hardening concept effectively deters SCA attacks.

Formal masking verification using Alma

Alma is an open source, formal masking verification tool developed at TU Graz which enables formal verification of masking SCA countermeasures at the netlist level. The main advantages of this approach compared to analyzing FPGA power traces are as follows:

• The turn-around time is much faster as it does not involve FPGA bitstream generation and capturing power traces (both can take several hours).
• Netlist-based analysis tools typically enable pinpointing sources of SCA leakage and easily allow analyzing sub parts of the masked design individually. As a result, individual issues can be fixed up faster.
• The analyzed netlist is closer to the targeted ASIC implementation. During FPGA synthesis, the netlist is mapped to the logic elements such as look-up tables (LUTs) available on the selected FPGA which are fundamentally different from more simple ASIC gates.

However, formal netlist analysis tools may not be perfect and they also have limitations in terms of what can be analyzed. For example, the maximum supported netlist size depends on the complexity and number of the non-linear elements. Also, random number generators and in particular pseudo-random number generators typically need to be excluded from the analysis and random number inputs need to be assumed as ideal by tools. Thus, they don’t replace FPGA-based analysis. We use them to increase our confidence in our SCA countermeasures and to close countermeasure verification faster by reducing the number of FPGA evaluation runs.

Prerequisites

The Alma-based formal masking verification flow together with a Howto (including installation instructions) as well an open source Yosys synthesis flow are available open soure. The tool can both run on generic Yosys netlists or on proprietary and technology-specific netlists. For the latter, a slightly modified verification flow with an additional translation step is required. To verify the GHASH SCA countermeasure, the generic flow was used with the following tool versions:

• Alma (specific commit)
• Yosys 0.36 (git sha1 8f07a0d84)
• sv2v v0.0.11-28-g81d8225
• Verilator 4.214 2021-10-17 rev v4.214

Yosys Netlist Synthesis

Setup the open source Yosys synthesis flow by copying the syn_setup.example.sh file and renaming it to syn_setup.sh. Change the LR_SYNTH_TOP_MODULE variable to aes_ghash_wrap and the LR_SYNTH_CELL_LIBRARY_PATH to the NangateOpenCellLibrary_typical.lib file in the folder where you installed the nangate45 library.

Then, start the synthesis by executing

./syn_yosys.sh

This should produce output similar to what is shown below:

8. Printing statistics.

=== aes_ghash_wrap ===

   Number of wires:             24543
   Number of wire bits:         29339
   Number of public wires:      567
   Number of public wire bits:  5363
   Number of memories:          0
   Number of memory bits:       0
   Number of processes:         0
   Number of cells:             26214
    AND2_X1                     1585
    AND3_X1                     4
    AND4_X1                     32
    AOI211_X1                   58
    AOI21_X1                    293
    AOI221_X1                   215
    AOI22_X1                    364
    DFFR_X1                     1468
    DFFS_X1                     5
    INV_X1                      584
    MUX2_X1                     1252
    NAND2_X1                    1870
    NAND3_X1                    128
    NAND4_X1                    37
    NOR2_X1                     7551
    NOR3_X1                     445
    NOR4_X1                     28
    OAI211_X1                   98
    OAI21_X1                    827
    OAI221_X1                   3
    OAI22_X1                    183
    OR2_X1                      28
    OR3_X1                      67
    OR4_X1                      2
    XNOR2_X1                    7122
    XOR2_X1                     1965

   Chip area for module '\aes_ghash_wrap': 37534.728000

====== End Yosys Stat Report ======

Warnings: 20 unique messages, 102 total

End of script. Logfile hash: 16c4d13569, CPU: user 25.11s system 0.12s, MEM: 176.29 MB peak
Yosys 0.36 (git sha1 8f07a0d84, gcc 11.4.0-1ubuntu1~22.04 -fPIC -Os)
Time spent: 66% 2x abc (47 sec), 9% 40x opt_expr (6 sec), ...
Area in kGE =  47.04

Note that the reported area is quite a bit bigger compared to the number reported in the GHASH SCA countermeasure specification The reasons are twofold:

1. The aes_ghash_wrap module synthesized is a wrapper module around the GHASH module in focus of this analysis. The goal of the wrapper is to separately feed in secrets (the hash subkey H and the encrypted initial counter block S) as well as randomness in a tool aware manner. As such, the wrapper includes some additional muxing resources and a counter to ease interpretation of results.
2. To speed up the formal analysis, the pipelined Galois-field multipliers have been instantiated with a latency of 4 instead of 32 clock cycles as on FPGA. While the latency or more precisely the processing parallelism does have an impact on the SNR, it does not have an impact on the formal netlist analysis which is performed in a so-to-say noise free environment.

Formal Netlist Analysis

After synthesizing the netlist, the following steps should be taken to perform the analysis:

1. Make sure to source the build_consts.sh script

   source util/build_consts.sh
   

   in order to set up some shell variables.

2. Enter the directory where you have downloaded Alma and load the virtual Python environment

   source dev/bin/activate
   

3. Launch the Alma tool to parse, trace (simulate) and formally verify the netlist. For simplicity, a single script is provided to launch all the required steps with a single command. Simply run

   ${REPO_TOP}/hw/ip/aes/pre_sca/alma/verify_aes_ghash.sh
   

   This should produce output similar to the one below:

   Verifying aes_ghash_wrap using Alma
   Starting yosys synthesis...
   | CircuitGraph | Total: 29882 | Linear: 9091 | Non-linear: 12741 | Registers: 1473 | Mux: 3538 |
   parse.py successful (47.99s)
   1: Running verilator on given netlist
   2: Compiling verilated netlist library
   3: Compiling provided verilator testbench
   4: Simulating circuit and generating VCD
   | CircuitGraph | Total: 29882 | Linear: 9091 | Non-linear: 12741 | Registers: 1473 | Mux: 3538 |
   tmp/tmp.vcd:24765: [WARNING] Entry for name alert_fatal_i already exists in namemap (alert_fatal_i -> Ce")
   tmp/tmp.vcd:24766: [WARNING] Entry for name alert_o already exists in namemap (alert_o -> De")
   tmp/tmp.vcd:24767: [WARNING] Entry for name clear_i already exists in namemap (clear_i -> Ee")
   tmp/tmp.vcd:24768: [WARNING] Entry for name clk_i already exists in namemap (clk_i -> Fe")
   tmp/tmp.vcd:24770: [WARNING] Entry for name cyc_ctr_o already exists in namemap (cyc_ctr_o -> Ge")
   tmp/tmp.vcd:24771: [WARNING] Entry for name data_in_prev_i already exists in namemap (data_in_prev_i -> He")
   tmp/tmp.vcd:24772: [WARNING] Entry for name data_out_i already exists in namemap (data_out_i -> Le")
   tmp/tmp.vcd:24773: [WARNING] Entry for name first_block_o already exists in namemap (first_block_o -> Pe")
   tmp/tmp.vcd:24774: [WARNING] Entry for name gcm_phase_i already exists in namemap (gcm_phase_i -> Qe")
   tmp/tmp.vcd:24775: [WARNING] Entry for name ghash_state_done_o already exists in namemap (ghash_state_done_o -> Re")
   tmp/tmp.vcd:24776: [WARNING] Entry for name hash_subkey_i already exists in namemap (hash_subkey_i -> Ve")
   tmp/tmp.vcd:24777: [WARNING] Entry for name in_ready_o already exists in namemap (in_ready_o -> ^e")
   tmp/tmp.vcd:24778: [WARNING] Entry for name in_valid_i already exists in namemap (in_valid_i -> _e")
   tmp/tmp.vcd:24779: [WARNING] Entry for name load_hash_subkey_i already exists in namemap (load_hash_subkey_i -> `e")
   tmp/tmp.vcd:24780: [WARNING] Entry for name num_valid_bytes_i already exists in namemap (num_valid_bytes_i -> ae")
   tmp/tmp.vcd:24781: [WARNING] Entry for name op_i already exists in namemap (op_i -> be")
   tmp/tmp.vcd:24782: [WARNING] Entry for name out_ready_i already exists in namemap (out_ready_i -> ce")
   tmp/tmp.vcd:24783: [WARNING] Entry for name out_valid_o already exists in namemap (out_valid_o -> de")
   tmp/tmp.vcd:24784: [WARNING] Entry for name prd_i already exists in namemap (prd_i -> ee")
   tmp/tmp.vcd:24785: [WARNING] Entry for name rst_ni already exists in namemap (rst_ni -> me")
   tmp/tmp.vcd:24786: [WARNING] Entry for name s_i already exists in namemap (s_i -> ne")
   0
   0
   Building formula for cycle 0: vars 0 clauses 0
   Checking cycle 0:
   Building formula for cycle 1: vars 1024 clauses 1536
   Checking cycle 1:
   Building formula for cycle 2: vars 3968 clauses 6528
   Checking cycle 2:
   Building formula for cycle 3: vars 6298 clauses 11026
   Checking cycle 3:
   Building formula for cycle 4: vars 14888 clauses 34886
   Checking cycle 4:
   Building formula for cycle 5: vars 20924 clauses 52734
   Checking cycle 5:
   Building formula for cycle 6: vars 53986 clauses 143674
   Checking cycle 6:
   Building formula for cycle 7: vars 57570 clauses 150970
   Checking cycle 7:
   Building formula for cycle 8: vars 80484 clauses 169282
   Checking cycle 8:
   Building formula for cycle 9: vars 213770 clauses 504198
   Checking cycle 9:
   Building formula for cycle 10: vars 594390 clauses 1617276
   Checking cycle 10:
   Building formula for cycle 11: vars 1024018 clauses 2881744
   Checking cycle 11:
   Building formula for cycle 12: vars 1704424 clauses 4910342
   Checking cycle 12:
   Building formula for cycle 13: vars 1713897 clauses 4915466
   Checking cycle 13:
   Building formula for cycle 14: vars 1834911 clauses 5233038
   Checking cycle 14:
   Building formula for cycle 15: vars 2258841 clauses 6492446
   Checking cycle 15:
   Building formula for cycle 16: vars 2734646 clauses 7907830
   Checking cycle 16:
   Building formula for cycle 17: vars 5868600 clauses 18374416
   Checking cycle 17:
   Building formula for cycle 18: vars 5922747 clauses 18524578
   Checking cycle 18:
   Building formula for cycle 19: vars 6100898 clauses 19061808
   Checking cycle 19:
   Building formula for cycle 20: vars 6427297 clauses 20074334
   Checking cycle 20:
   Building formula for cycle 21: vars 6949506 clauses 21693947
   Checking cycle 21:
   Building formula for cycle 22: vars 6949506 clauses 21693947
   Checking cycle 22:
   Building formula for cycle 23: vars 6949506 clauses 21693947
   Checking cycle 23:
   Building formula for cycle 24: vars 7057992 clauses 21994175
   Checking cycle 24:
   Building formula for cycle 25: vars 7407412 clauses 23047989
   Checking cycle 25:
   Building formula for cycle 26: vars 7797810 clauses 24221073
   Checking cycle 26:
   Building formula for cycle 27: vars 10939700 clauses 34732235
   Checking cycle 27:
   Building formula for cycle 28: vars 11268148 clauses 35780811
   Checking cycle 28:
   Building formula for cycle 29: vars 11268148 clauses 35780811
   Checking cycle 29:
   Building formula for cycle 30: vars 11268148 clauses 35780811
   Checking cycle 30:
   Building formula for cycle 31: vars 11376634 clauses 36081039
   Checking cycle 31:
   Building formula for cycle 32: vars 11726054 clauses 37134853
   Checking cycle 32:
   Building formula for cycle 33: vars 12116452 clauses 38307937
   Checking cycle 33:
   Building formula for cycle 34: vars 15258342 clauses 48819099
   Checking cycle 34:
   Building formula for cycle 35: vars 15586534 clauses 49867675
   Checking cycle 35:
   Building formula for cycle 36: vars 15619430 clauses 49965979
   Checking cycle 36:
   Finished in 3948.52
   The execution is secure
   

Notes:

• This analysis exercises the full data path of the GHASH block and comprises the following operations (controlled by a small Verilator testbench):

  • Initial clearing of all internal registers.
  • Loading the hash subkey H.
  • Loading the encrypted initial counter block S including the subsequent generation of repeatedly used correction terms.
  • Processing a first AAD/ciphertext block including the generation of a correction term that is used for the first block only.
  • Processing a second AAD/ciphertext block.
  • Producing the final authentication tag.

• The following main changes have been implemented as a result of the formal netlist analysis using Alma (refer to the countermeasure spec for details):

  • The result of the final addition of Share 1 of S and the unmasked GHASH state is no longer stored into the GHASH state register but directly forwarded to the output, and the state input to this addition is blanked. The input multiplexer (ghash_in_mux) loses one input.
  • The two 3-input multiplexers selecting the operands for the addition with the GHASH state (add_in_mux) are replaced by one-hot multiplexers with registered control signals.
  • The Operand B inputs of both GF multipliers are now blanked. The 3-input multiplexer selecting Operand B of the second GF multiplier is replaced by a one-hot multiplexer with registered control signal. In addition, the last input slice of Operand B for this multiplier is registered. This allows the switching the multiplexer during the last clock cycle of the multiplication to avoid some undesirable transient leakage occurring upon saving the result of the multiplication into the GHASH state register (and this new value propagating through the multiplexer into the multiplier again).
  • The GF multipliers are configured to output zero instead of Operand A (the hash subkey) while busy.
  • The state input for the addition required for the generation of the correction term for Share 0 is blanked.
  • Between adding the correction terms to the GHASH state for the last time and between unmasking the GHASH state, a bubble cycle is added to allow signals to fully settle thereby avoiding undesirable transient effects unmasking the uncorrected state shares.

• The overall area impact of these changes is low (+0.16 kGE in Yosys + nangate45).

• The final design successfully passes the formal masking verification. For details regarding tool parameters, check the analysis script.

ChipWhisperer-based FPGA evaluation and TVLA

To underpin the results of the formal verification flow, the hardening of the GHASH module has been analyzed on the ChipWhisperer CW310 FPGA board. For this analysis, power traces with the ChipWhisperer Husky scope were captured during GCM operations. Afterwards a Test Vector Leakage Assessment (TVLA) with the ot-sca toolset has been performed. The setup is illustrated in Figure 1.

:--: Figure 1: Target CW310 FPGA board (left) and the CW Husky scope (right).

Setup

:--: Figure 2: Measurement setup. The main components are the target board, the scope, and the SCA framework.

Figure 2 gives a detailed overview of the measurement setup that has been utilized to capture the power traces. The SCA evaluation framework ot-sca is the central component of the measurement setup. It is responsible for communicating with the penetration testing framework that runs on the target FPGA board and with the scope. Initially, ot-sca configures the scope (sample rate, number of samples) and the pentest framework (which input, how many encryptions, where to trigger).

Based on the configuration, the pentest framework generates the cipher input, starts the encryption, and sends back the computed tag to ot-sca. The trigger is automatically set and unset by the AES hardware block to achieve an accurate & constant trigger window. In parallel, the scope waits for the trigger, captures the power consumption, and transfers the traces to the SCA evaluation framework. The ot-sca framework stores the trace as well as the cipher configuration in a database.

:--: Figure 3: Power trace with AES encryption rounds visible (left). Aligned traces when zooming in (right).

Figure 3 depicts power traces captured during AES-GCM encryptions with the setup above. As shown in the figure, the traces are nicely aligned, allowing to perform a sound evaluation.

Methodology

To detect whether the hardened GHASH implementation effectively mitigates SCA attacks, the Test Vector Leakage Assessment (TVLA) approach discussed by Rambus in a whitepaper is adapted for the GCM mode of AES. In TVLA, Welch’s t-test is used to determine whether it is possible to statistically distinguish two power trace sets from each other. This test returns a value t for each sample, where a value of |t| > 4.5 means that, with a high probability, a data dependent leakage was detected. However, note that this test cannot provide any information whether the leakage is actually exploitable.

:-- Figure 4: TVLA plot showing leakage at around sample 1000. When increasing the number of traces (from 1000 to 10000), the leakage becomes more present. Note that the traces shown in this plot are taken from an arbitrary cryptographic hardware block and not AES.

Figure 4 shows a TVLA plot that will be used throughout this document. The red lines mark the ± t-test border.

Dataset Generation for FvsR IV & Key

In TVLA, two different trace data sets need to be recorded. As described in the whitepaper, we generate these two trace data sets by using a fixed and a random AES-GCM cipher input set, i.e., the fixed and the random set.

As shown in the table above, for our experiment we use a static cipher input for the fixed set. For the random set, we use a PRNG to randomly generate the secrets, i.e., key and IV, for each encryption. The dataset is generated directly on the device in the pentest framework. For each trace, ot-sca stores information to which dataset the trace belongs to.

With TVLA, the idea is to check whether we are able to distinguish power traces from the fixed and the random set.

Dataset Generation for FvsR PTX & AAD

For the second experiment, we use a static IV and key and calculate a FvsR PTX and AAD set:

Results – FvsR IV & Key

In the following, we discuss the analysis results for each GCM phase. We start with the results for the FvsR IV & Key datasets.

:--: Figure 5: AES-GCM block diagram. Red lines mark the trigger windows for each analysis step.

As shown in Figure 5, we focus on analyzing (i) the generation of the hash subkey H, (ii) the encryption of the initial counter block S, (iii) the processing of the AAD blocks, (iv) the plaintext blocks, and (v) the tag generation. Each measurement is conducted with (a) masks off and (b) masks on to analyze the effectiveness of the masking countermeasure.

i) SCA Evaluation of Generating the Hash Subkey H

:--:

| Figure 6a: Masking Off - 100k traces - Figure 6b: Masking On - 1M traces |

Interpretation

The AES encryption is clearly visible in the form of 12 distinct peaks in the power traces shown Figures 6a and 6b. The 12 peaks correspond to first the loading of the key and the all-zero block into the AES cipher core, followed by the initial round and the 10 full AES rounds (AES-128). They spread over approximately 470 samples which corresponds to the 56 target clock cycles a full AES-128 encryption takes.

If the masking is turned off (Figure 6a), first and second-order leakage is clearly visible throughout the operation. If the masking is on (Figure 6b), there is first-order leakage 1) at the beginning as well as 2) at the end of the operation.

1. The leakage at the beginning of the operation is due to incrementing the IV/CTR value (inc32 function in GCM spec) which spreads across the first two AES rounds. This produces first-order leakage as the inc32 function implementation isn’t masked. It doesn’t need to be masked as the IV is not secret, just the encrypted initial counter block S (i.e., the encrypted IV) is secret in the context of GCM.
2. The leakage at the end of the operation happens when the masked output of the AES cipher core, i.e., the masked hash subkey H, gets loaded in shares into the GHASH block. When studying the RTL, one can see that there is nothing in the path between the AES cipher core and the hash subkey registers inside the GHASH block that could combine the shares and cause this leakage. The leakage is most likely due to how the FPGA implementation tool maps the flip flops of the hash subkey register shares to the available FPGA logic slices: if flip flops of the different shares get mapped to the same logic slice, the carry-chain and other muxing logic present in the logic slice can combine the various inputs thereby causing SCA leakage despite these logic outputs not being used. We’ve observed similar effects in the past and there is research giving more insight into this and other FPGA-specific issues.

To summarize, the observed first-order leakage if masking is on (Figure 6b) is not of concern for ASIC implementations.

ii) SCA Evaluation of Encrypting the Initial Counter Block

:--:

| Figure 7a: Masking Off - 100k traces - Figure 7b: Masking On - 1M traces |

Interpretation

Again, the AES encryption is clearly visible in the form of 12 peaks in the power traces shown Figures 7a and 7b. This AES encryption corresponds to the generation of the encrypted initial counter block S. The AES encryption is followed by another operation visible in the power trace: the computation of repeatedly used correction terms using the Galois-field multipliers inside GHASH. This operation takes 33 target clock cycles (approximately 275 samples).

If the masking is turned off (Figure 7a), first and second-order leakage is clearly visible throughout both operations while being more pronounced during the GHASH operation. This is because the GHASH block is smaller and thus produces less noise. If the masking is on (Figure 7b), there is first-order leakage 1) at the beginning as well as 2) between the two operations.

1. As before, the leakage at the beginning of the operation is due to incrementing the IV/CTR value (inc32 function in GCM spec) which spreads across the first two AES rounds. This produces first-order leakage as the inc32 function implementation isn’t masked. It doesn’t need to be masked as the IV is not secret, just the encrypted initial counter block S (i.e., the encrypted IV) is secret in the context of GCM.
2. As before, the leakage at the end of the operation happens when the masked output of the AES cipher core, i.e., the encrypted initial counter block gets loaded in shares into the GHASH block. When studying the RTL, one can see that there is nothing in the path between the AES cipher core and the GHASH state registers inside the GHASH block that could combine the shares and cause this leakage. As before, the leakage is most likely due to how the FPGA implementation tool maps the multiplexers in front of the GHASH state registers to the available FPGA logic slices: Since the multiplexers for both shares use the same control signals, the multiplexing logic can be combined even into the same look-up tables (LUTs) thereby causing SCA leakage. We’ve observed similar effects in the past and there is research giving more insight into this and other FPGA-specific issues.

To summarize, the observed first-order leakage if masking is on (FIgure 7b) is not of concern for ASIC implementations.

iii) SCA Evaluation of Processing the AAD Blocks

Processing AAD Block 0

:--:

| Figure 8a: Masking Off - 50k traces - Figure 8b: Masking On - 10M traces |

Interpretation

For AAD blocks, the AES cipher core is not involved. However, during the computation of the first AAD block, the GHASH block needs to compute an additional correction term which is used for the very first block only. If the masking is turned off (Figure 8a), first- and second-order leakage is clearly visible but only for the first activity block. The second activity block involves computing the additional correction terms which requires Share 1 of the encrypted initial counter block to be multiplied by Share 1 of the hash subkey. But since the masking is off, both these values are zero for both the fixed and the random set and hence there is no SCA leakage. If the masking is turned on (Figure 8b), no SCA leakage is observable which is desirable.

Processing AAD Block 1

:--:

| Figure 9a: Masking Off - 50k traces - Figure 9b: Masking On - 10M traces |

Interpretation

For the second AAD block (and any subsequent AAD blocks) there is only one activity block corresponding to the Galois-field multiplication. If masking is turned off (Figure 9a), there is both first- and second-order leakage observable. If the masking is turned on (Figure 9b), no SCA leakage is observable which is desirable.

iv) SCA Evaluation of Processing the PTX Blocks

Processing PTX Block 0

:--:

| Figure 10a: Masking Off - 50k traces - Figure 10b: Masking On - 1M traces |

Interpretation

Like in ii) SCA Evaluation of Encrypting the Initial Counter Block there is first-order leakage 1) at the beginning and 2) between the two operations if the masking is turned on (Figure 10b).

1. As before, the leakage at the beginning of the operation is due to incrementing the IV/CTR value (inc32 function in GCM spec) which spreads across the first two AES rounds. This produces first-order leakage as the inc32 function implementation isn’t masked. It doesn’t need to be masked as the IV is not secret, just the encrypted initial counter block S (i.e., the encrypted IV) is secret in the context of GCM.
2. The leakage between the two operations is due to the unmasking of the AES cipher core output, the addition of input data to produce the ciphertext, and writing this value to the GHASH block and the output data registers. It’s not related to the hash subkey H or the initial counter block S (i.e. the two secrets involved in the GHASH part of GCM). But since the AAD and the plaintext have been chosen to be the same for all traces in the fixed and the random sets, the traces of the fixed set only produce all the same ciphertext and thus are expected to exhibit a static power signature for this step, whereas the ciphertext of the random set is randomized through the random key and IV. However, since the ciphertext is not secret in the context of GCM, this leakage is of no concern.

To summarize, the observed first-order leakage if masking is on (FIgure 10b) is not of concern.

Processing PTX Block 1

:--:

| Figure 11a: Masking Off - 50k traces - Figure 11b: Masking On - 1M traces |

Interpretation

As before (PTX Block 0), there is some first-order leakage observable when the masking is turned on. For the same reasons as before, this leakage is not of concern.

v) SCA Evaluation of the Tag Generation

:--:

| Figure 12a: Masking Off - 50k traces - Figure 12b: Masking On - 1M traces |

Interpretation

The generation of the final authentication tag consists of two operations.

1. The 128-bit block containing the AAD and ciphertext lengths is hashed and the correction terms are added. The GHASH state is unmasked (still masked with the encrypted initial counter block S) and Share 1 of S is added to write the final authentication tag to the data output registers readable by software.
2. In parallel to writing the final authentication tag to the data output registers, the internal state is all cleared to random values and an additional multiplication is triggered to clear the internal state of the Galois-field multipliers and the correction term registers.

If masking is turned off (Figure 12a), there is both first- and second-order leakage observable during the first activity block (tag generation) but not during the clearing operation. If the masking is turned on (Figure 12b), some SCA leakage is observable between the two operations, i.e., when the final authentication tag is written to the output data registers. This leakage is expected as both the fixed and the random data sets use a static AAD and plaintext. This means, the tag for the fixed data set is fixed whereas the tags for the random set get randomized through the ciphertext (random due to the random key and IV).

To summarize, the observed first-order leakage if masking is on (FIgure 12b) is not of concern.

Results – FvsR PTX & AAD

In the following, we discuss the analysis results for each FvsR PTX & AAD datasets. These experiments were specifically done to investigate leakage peaks identified for the FvsR Key & IV datasets that are attributed to how the FPGA implementation tool maps flip flops and multiplexer shares to the available FPGA logic slices.

i) SCA Evaluation of Generating the Hash Subkey H

:--:

| Figure 13a: Masking Off - 50k traces - Figure 13b: Masking On - 1M traces |

Interpretation

There is no SCA leakage visible in both cases without masking (Figure 13a) and with masking turned on (Figure 13b). This is expected as the hash subkey generation doesn’t involve the plaintext and the AAD but only the key and IV. Both the fixed and random set use the same static key and IV.

This experiment was specifically done to check whether the leakage identified in Figure 6b and attributed to how the FPGA implementation tool maps the flip flops of the hash subkey register shares to the available FPGA logic slices. As expected, the leakage peak is now gone.

ii) SCA Evaluation of Encrypting the Initial Counter Block

:--:

| Figure 14a: Masking Off - 50k traces - Figure 14b: Masking On - 1M traces |

Interpretation

There is no SCA leakage visible in both cases without masking (Figure 14a) and with masking turned on (Figure 14b). This is expected as the encryption of the initial counter block and the subsequent computation of repeatedly used correction terms doesn’t involve the plaintext and the AAD but only the key and IV. Both the fixed and random set use the same static key and IV.

This experiment was specifically done to check whether the leakage identified in Figure 7b and attributed to how the FPGA implementation tool maps the multiplexers in front of the GHASH state registers to the available FPGA logic slices. As expected, the leakage peak is now gone.

iv) SCA Evaluation of Processing the PTX Block 0

:--:

| Figure 15a: Masking Off - 100k traces - Figure 15b: Masking On - 1M traces |

Interpretation

With the masking turned off (Figure 15a), there is first-order leakage 1) at the beginning of the operation and 2) throughout the entire GHASH operation.

1. The leakage at the beginning of the operation is due to the input data (the plaintext) being written to an internal buffer register. The AES cipher is operated in counter mode, meaning it doesn’t encrypt the input data but the counter value (incremented IV). Because the IV is fixed for both the fixed and the random data set, no leakage is observed during the AES encryption even if the masking is off. At the end of the AES encryption, the output of the AES cipher core is added to the content of the buffer register to produce the ciphertext which is then forwarded to the GHASH block and to the data output registers.
2. The GHASH operation then processes this ciphertext. The observed leakage when the masking is off is expected.

With the masking turned on (Figure 15b), the first-order leakage at the beginning of the operation remains visible. The reason for this is that the internal register buffering the previous input data is not masked. This is of no concern as the leakage is not related to key or IV.

Another first-order leakage peak is visible between the AES encryption and the GHASH operation. This leakage is due to the unmasked AES cipher core output being added to the input data (coming from the internal buffer register) and the result being stored to the output data register. As key and IV are static and identical for both the fixed and the random data set, the cipher core output is the same for both sets. Any difference in the power signature between the two sets is due to the different plaintext / ciphertext. Again, this is to be expected and of no concern as the ciphertext is not secret in the context of GCM.

Reproducing the FPGA Experiments

Prerequisites

(i) Setting up the CW310 and CW Husky

Please follow the guide here to prepare the CW310 and CW Husky for the SCA measurements.

(ii) Generating the FPGA Bitstream

Follow the guide here to install Xilinx Vivado. Please note that a valid license is needed to generate bitstreams for the CW310 FPGA board.

Then, build the bitstream from the aes-gcm-sca-bitstream branch. This branch includes the AES-GCM and applies several optimizations (disabling certain features to reduce the area utilization) to improve the SCA measurements.

git clone https://github.com/vogelpi/opentitan.git
cd opentitan
git checkout aes-gcm-sca-bitstream
./bazelisk.sh build //hw/bitstream/vivado:fpga_cw310_test_rom
cp bazel-bin/hw/bitstream/vivado/build.fpga_cw310/synth-vivado/lowrisc_systems_chip_earlgrey_cw310_0.1.bit .

The resulting bitstream is lowrisc_systems_chip_earlgrey_cw310_0.1.bit.

(iii) Compiling the Penetration Testing Binary

The penetration testing binary that is running on the target is the framework that receives commands from the side-channel evaluation framework and triggers the AES-GCM operations.

git clone <https://github.com/vogelpi/opentitan.git>
cd opentitan
git checkout aes-gcm-review
./bazelisk.sh build //sw/device/tests/penetrationtests/firmware:firmware_fpga_cw310_test_rom
cp bazel-bin/sw/device/tests/penetrationtests/firmware/firmware_fpga_cw310_test_rom_fpga_cw310_test_rom.bin sca_ujson_fpga_cw310.bin

The resulting penetration testing binary is sca_ujson_fpga_cw310.bin.

(iv) Setting up the Side-Channel Evaluation Framework

Clone the ot-sca repository and switch to the dedicated AES-GCM branch:

git clone <https://github.com/lowRISC/ot-sca.git>
cd ot-sca
git checkout ot-sca-aes-gcm

Then, follow this guideline to prepare your machine for the measurements.

Afterwards, copy the bitstream to ot-sca/objs/lowrisc_systems_chip_earlgrey_cw310_0.1.bit and the binary to ot-sca/objs/sca_ujson_fpga_cw310.bin.

Finally, determine the port the CW310 opened on your machine (e.g., /dev/ttyACM2) and set it accordingly in the port field of the ot-sca/capture/configs/aes_gcm_sca_cw310.yaml configuration file.

Capturing Traces

After fulfilling the prerequisites, traces can be captured using ot-sca. To configure the measurement, adapt the script located in ot-sca/capture/configs/aes_gcm_sca_cw310.yaml. The following parameters can be changed:

husky:
  # Number of encryptions performed in one batch.
  num_segments: 35
  # Number of cycles that are captured by the CW Husky.
  num_cycles: 320
capture:
  # Number of traces to capture.
  num_traces: 100000
  # Number of traces to keep in memory before flushing to the disk.
  trace_threshold: 50000
test:
  # Values used for the fixed set.
  iv_fixed: [0xDE, 0xAD, 0xBE, 0xEF, 0xCA, 0xFE, 0xBA, 0xAD, 0xF0, 0xCA,
             0xCC, 0x1A, 0x00, 0x00, 0x00, 0x00]
  key_fixed: [0x81, 0x1E, 0x37, 0x31, 0xB0, 0x12, 0x0A, 0x78, 0x42, 0x78,
              0x1E, 0x22, 0xB2, 0x5C, 0xDD, 0xF9]
  # Static values that are used by the fixed and the random set.
  ptx_blocks: 2
  ptx_static: [[0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA,
                0xAA, 0xAA, 0xAA, 0xAA, 0xAA, 0xAA], [0xBB, 0xBB, 0xBB,
                0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB, 0xBB,
                0xBB, 0xBB, 0xBB]]
  ptx_last_block_len_bytes: 16
  aad_blocks: 2
  aad_static: [[0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC,
                 0xCC, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC], [0xDD, 0xDD, 0xDD,
                 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD, 0xDD,
                 0xDD, 0xDD, 0xDD, 0xDD]]
  aad_last_block_len_bytes: 16
  # Trigger configuration (select only one).
  # [Hash sub key, Init. block, AAD block, PTX block, TAG block]
  triggers: [False, False, False, False, True]
  # Which AAD or PTX block.  0 = first block.
  trigger_block: 0
  # 32-bit seed for masking on device. To switch off the masking, use 0
  # as an LFSR seed.
  lfsr_seed: 0x00000000
  #lfsr_seed: 0xdeadbeef

After tweaking the configuration, the traces can be captured by executing:

cd capture
./capture_aes_gcm.py -c configs/aes_gcm_sca_cw310.yaml -p aes_gcm_sca

Where the -c parameter is the config and -p the database where the traces are stored.

Performing the TVLA

After capturing the traces, the TVLA can be performed by switching into the ot-sca/analysis folder, copying the ot-sca/analysis/configs/tvla_cfg_kmac.yaml file to ot-sca/analysis/configs/tvla_cfg_aes_gcm.yaml, and modifying the configuration file:

project_file: ../capture/projects/aes_gcm_sca
trace_file: null
trace_start: null
trace_end: null
leakage_file: null
save_to_disk: null
save_to_disk_ttest: null
round_select: null
byte_select: null
input_histogram_file: null
output_histogram_file: null
number_of_steps: 1
ttest_step_file: null
plot_figures: true
test_type: "GENERAL_KEY"
mode: aes
filter_traces: true
trace_threshold: 50000
trace_db: ot_trace_library

By calling

./tvla.py --cfg-file tvla_cfg_aes_gcm.yaml run-tvla

the TVLA plot is generated.

PCR vault

• Platform Configuration Register (PCR) vault is a register file that stores measurements to be used by the microcontroller.
• PCR entries are read-only registers of 512 bits each.
• Control bits allow for entries to be cleared by FW, which sets their values back to 0.
• A lock bit can be set by FW to prevent the entry from being cleared. The lock bit is sticky and only resets on a powergood cycle.

PCR vault functional block

PCR entries are hash extended using a hash extension function. The hash extension function takes the data currently in the PCR entry specified, concatenates data provided by the FW, and performs a SHA384 function on that data, storing the result back into the same PCR entry.

PCR hash extend function

FW provides the PCR entry to use as source and destination of the hash extend. HW copies the PCR into the start of the SHA block and locks those dwords from FW access. FW then provides the new data, and runs the SHA function as usual. After initialization, the locked dwords are unlocked.

FW must set a last cycle flag before running the last iteration of the SHA engine. This could be the first “init” cycle, or the Nth “next” cycle. This flag allows HW to copy the final resulting hash output back to the source PCR.

PCR signing

• PCR signing uses the key in key slot index 7 for PCR signing
• HW implements a HW function called GEN_PCR_HASH
  • HW reads all the PCRs from all the PCR slots and hash extends them along with the NONCE that Caliptra FW provides
  • PCR Hash = Hash(PCR[0], …, PCR[31], Nonce)
• HW also implements a HW function called SIGN_PCR. This function takes the PCR digest that was generated by the previous routine and signs it using the key in key slot 7, following the same ECC sign flow defined in the ECC section.
  • The resulting PCR DIGEST is used only once for signing by the HW. If a new PCR signing is required, GEN_PCR_HASH needs to be redone.

Key vault

Key Vault (KV) is a register file that stores the keys to be used by the microcontroller, but this register file is not observed by the microcontroller. Each cryptographic function has a control register and functional block designed to read from and write to the KV. 

Key vault functional block

Keys and measurements are stored in 512b register files. These have no read or write path from the microcontroller. The entries are read through a passive read mux driven by each cryptographic block. Locked entries return zeroes. 

Entries in the KV must be cleared via control register, or by de-assertion of pwrgood.  

Each entry has a control register that is writable by the microcontroller. 

The destination valid field is programmed by FW in the cryptographic block generating the key, and it is passed here at generation time. This field cannot be modified after the key is generated and stored in the KV. 

Key vault cryptographic functional block 

A generic block is instantiated in each cryptographic block to enable access to KV. 

Each input to a cryptographic engine can have a key vault read block associated with it. The KV read block takes in a key vault read control register that drives an FSM to copy an entry from the key vault into the appropriate input register of the cryptographic engine.

Each output generated by a cryptographic engine can have its result copied to a slot in the key vault. The KV write block takes in a key vault write control register. This register drives an FSM to copy the result from the cryptographic engine into the appropriate key vault entry. It also programs a control field for that entry to indicate where that entry can be used.

After programming the key vault read control, FW needs to query the associated key vault read status to confirm that the requested key was copied successfully. After valid is set and the error field reports success, the key is ready to be used.

Similarly, after programming the key vault write control and initiating the cryptographic function that generates the key to be written, FW needs to query the associated key vault write status to confirm that the requested key was generated and written successfully.

When a key is read from the key vault, the API register is locked and any result generated from the cryptographic block is not readable by firmware. The digest can only be sent to the key vault by appropriately programming the key vault write controls. After the cryptographic block completes its operation, the lock is cleared and the key is cleared from the API registers.

If multiple iterations of the cryptographic function are required, the key vault read and write controls must be programmed for each iteration. This ensures that the lock is set and the digest is not readable.

The following tables describe read, write, and status values for key vault blocks.

De-obfuscation engine

To protect software intellectual property from different attacks and, particularly, for thwarting an array of supply chain threats, code obfuscation is employed. Hence, the de-obfuscation engine is implemented to decrypt the code.

Advanced Encryption Standard (AES) is used as a de-obfuscation function to encrypt and decrypt data [4]. The hardware implementation is based on Secworks/aes [1]. The implementation supports the two variants: 128- and 256-bit keys with a block/chunk size of 128 bits.

The AES algorithm is described as follows:

• The key is fed to an AES core to compute and initialize the round key
• The message is broken into 128-bit chunks by the host
• For each chunk:
  • The message is fed to the AES core
  • The AES core and its working mode (enc/dec) are triggered by the host
  • The AES core status is changed to ready after encryption or decryption processing
• The result digest can be read before processing the next message chunks

Key vault de-obfuscation block operation

A de-obfuscation engine (DOE) is used in conjunction with AES cryptography to de-obfuscate the UDS and field entropy.  

1. The obfuscation key is driven to the AES key. The data to be decrypted (either obfuscated UDS or obfuscated field entropy) is fed into the AES data. 
2. An FSM manually drives the AES engine and writes the decrypted data back to the key vault. 
3. FW programs the DOE with the requested function (UDS or field entropy de-obfuscation), and the destination for the result. 
4. After de-obfuscation is complete, FW can clear out the UDS and field entropy values from any flops until cptra_pwrgood de-assertion.  

The following tables describe DOE register and control fields.

Key vault de-obfuscation flow 

1. ROM loads IV into DOE. ROM writes to the DOE control register the destination for the de-obfuscated result and sets the appropriate bit to run UDS and/or the field entropy flow. 
2. DOE state machine takes over and loads the Caliptra obfuscation key into the key register. 
3. Next, either the obfuscated UDS or field entropy are loaded into the block register 4 DWORDS at a time. 
4. Results are written to the KV entry specified in the DEST field of the DOE control register. 
5. State machine resets the appropriate RUN bit when the de-obfuscated key is written to KV. FW can poll this register to know when the flow is complete.
6. The clear obf secrets command flushes the obfuscation key, the obfuscated UDS, and the field entropy from the internal flops. This should be done by ROM after both de-obfuscation flows are complete.

Data vault

Data vault is a set of generic scratch pad registers with specific lock functionality and clearable on cold and warm resets.

• 48B scratchpad registers that are lockable but cleared on cold reset (10 registers)
• 48B scratchpad registers that are lockable but cleared on warm reset (10 registers)
• 4B scratchpad registers that are lockable but cleared on cold reset (8 registers)
• 4B scratchpad registers that are lockable but cleared on warm reset (10 registers)
• 4B scratchpad registers that are cleared on warm reset (8 registers)

Cryptographic blocks fatal and non-fatal errors

The following table describes cryptographic errors.

Terminology

The following terminology is used in this document.

References

1. J. Strömbergson, "Secworks," [Online]. Available at https://github.com/secworks.
2. NIST, Federal Information Processing Standards Publication (FIPS PUB) 180-4 Secure Hash Standard (SHS).
3. OpenSSL [Online]. Available at https://www.openssl.org/docs/man3.0/man3/SHA512.html.
4. N. W. Group, RFC 3394, Advanced Encryption Standard (AES) Key Wrap Algorithm, 2002.
5. NIST, Federal Information Processing Standards Publication (FIPS) 198-1, The Keyed-Hash Message Authentication Code, 2008.
6. N. W. Group, RFC 4868, Using HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 with IPsec, 2007.
7. RFC 6979, Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA), 2013.
8. TCG, Hardware Requirements for a Device Identifier Composition Engine, 2018.
9. Coron, J.-S.: Resistance against differential power analysis for elliptic curve cryptosystems. In: Ko¸c, C¸ .K., Paar, C. (eds.) CHES 1999. LNCS, vol. 1717, pp. 292–302.
10. Schindler, W., Wiemers, A.: Efficient side-channel attacks on scalar blinding on elliptic curves with special structure. In: NISTWorkshop on ECC Standards (2015).
11. National Institute of Standards and Technology, "Digital Signature Standard (DSS)", Federal Information Processing Standards Publication (FIPS PUB) 186-4, July 2013.
12. NIST SP 800-90A, Rev 1: "Recommendation for Random Number Generation Using Deterministic Random Bit Generators", 2012. |
13. CHIPS Alliance, “RISC-V VeeR EL2 Programmer’s Reference Manual” [Online] Available at https://github.com/chipsalliance/Cores-VeeR-EL2/blob/main/docs/RISC-V_VeeR_EL2_PRM.pdf.
14. “The RISC-V Instruction Set Manual, Volume I: User-Level ISA, Document Version 20191213”, Editors Andrew Waterman and Krste Asanovi ́c, RISC-V Foundation, December 2019. Available at https://riscv.org/technical/specifications/.
15. “The RISC-V Instruction Set Manual, Volume II: Privileged Architecture, Document Version 20211203”, Editors Andrew Waterman, Krste Asanovi ́c, and John Hauser, RISC-V International, December 2021. Available at https://riscv.org/technical/specifications/.
16. NIST SP 800-56A, Rev 3: "Recommendation for Pair-Wise Key-Establishment Schemes Using Discrete Logarithm Cryptography", 2018, |

^[1] Caliptra.** **Spanish for “root cap” and describes the deepest part of the root

Caliptra Integration Specification

Version 2.0.3

Scope

This document describes the Caliptra hardware implementation requirements, details, and release notes. This document is intended for a high-level overview of the IP used in Caliptra.

This document is not intended for any micro-architectural design specifications. Detailed information on each of the IP components are shared in individual documents, where applicable.

Overview

This document contains high level information on the Caliptra hardware design. The details include open-source IP information, configuration settings for open-source IP (if applicable), and IP written specifically for Caliptra.

For more information, see Caliptra: A Datacenter System on a Chip (SoC) Root of Trust (RoT).

References and related specifications

The blocks described in this document are either obtained from open-source GitHub repositories, developed from scratch, or modification of open-source implementations. Links to relevant documentation and GitHub sources are shared in the following table.

Table 1: Related specifications

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).

SoC interface definition

The following figure shows the SoC interface definition.

Figure 1: SoC Interface Block Diagram

Integration parameters

The following table describes integration parameters.

Table 2: Integration parameters

Table 3: Integration Defines

Interface

The following tables describe the interface signals.

Table 4: Clocks and resets

Table 5: AXI Subordinate Interface

Table 6: Mailbox notifications

Table 7: Caliptra SRAM interface

Table 8: Adams-Bridge SRAM Interface

Adams-Bridge SRAM interface is used to connect the necessary SRAM instances for Adams-Bridge. There are 8 SRAMs, 2 of which have 2 banks. Each SRAM has a parameterized data width and depth used to calculate the addr width.

All memories are modeled as 1 read 1 write port RAMs with a flopped read data. See abr_1r1w_ram.sv and abr_1r1w_be_ram.sv for examples. Strobe width describes the number of bits enabled by each strobe. All strobed memories are byte enabled in the design. See ABR Memory requirement for more details.

The full set of wires is encapsulated in the mldsa_mem_if construct mldsa_memory_export at the Caliptra boundary.

The table below details the interface required for each SRAM. Driver direction is from the perspective of Caliptra.

Table 9: JTAG interface

Table 10: RISC-V Trace interface

Table 11: Subsystem Straps and Control

Table 12: Security and miscellaneous

Architectural registers and fuses

Control registers and fuses are documented on GitHub.

• External Registers: caliptra_top_reg — caliptra_top_reg Reference (chipsalliance.github.io)
• Internal Registers - clp — clp Reference (chipsalliance.github.io)

Fuses

Fuses may only be written during the BOOT_FUSE state of the Boot FSM and require a cptra_pwrgood to be recycled to be written again.

After all fuses are written, the fuse done register at the end of the fuse address space must be set to 1 to lock the fuse writes and to proceed with the boot flow.

Although fuse values (and the fuse done register) persist across a warm reset, SoC is still required to perform a write to the fuse done register while in the BOOT_FUSE state in order to complete the bringup from reset. See Boot FSM for further details.

Note: Starting in Caliptra 2.0 subsystem strap and other configuration registers have been added to the fuse region. Subsystem straps are expected to be programmed during the same time as fuses per Caliptra spec. The following SS registers in the fuse region are not straps, are intended for internal use in Caliptra, and cannot be written by any SoC agents; therefore, categorizing them under the FUSE range has no effect:

• SS_DBG_MANUF_SERVICE_REG_RSP
• SS_SOC_DBG_UNLOCK_LEVEL
• SS_GENERIC_FW_EXEC_CTRL

The remaining register SS_DBG_MANUF_SERVICE_REG_REQ is initialized by the same SoC agent as fuses and is the only agent that can make subsystem debug service requests.

Interface rules

The following figure shows the reset rules and timing for cold boot flows.

Figure 2: Reset rules and timing diagram

Deassertion of cptra_pwrgood indicates a power cycle that results in returning Caliptra to its default state. All resettable flops are reset.

Deassertion of cptra_rst_b indicates a warm reset cycle that resets all but the “sticky” registers (fuses, error logging, etc.).

Assertion of BootFSM_BrkPoint stops the boot flow from releasing Caliptra from reset after fuse download. Writing a 1 to the GO field of the CPTRA_BOOTFSM_GO register allows the boot flow to proceed.

AXI

Arbitration

Caliptra has two interfaces attached to the AXI bus: a subordinate, incapable of initiating transfers, and a manager interface. The AXI manager is only enabled in Caliptra Subsystem mode, and must be tied to 0 in all other use-cases. The AXI subordinate is used by SoC agents to interact with the Caliptra external registers. If SoCs have multiple AXI agents or other proprietary-fabric protocols that require any special fabric arbitration, that arbitration is done at SoC level.

AXI User

AXI address user request signals (ARUSER and AWUSER, collectively "AxUSER") are used to uniquely identify AXI agents that have issued the request to Caliptra. Refer to Mailbox AXI User Attribute Register and SoC Integration Requirements for additional details.

Unsupported features

The Caliptra AXI subordinate has the following usage restrictions:

• Single outstanding transaction is serviced at a time (read or write). Operation is half-duplex due to the underlying register access interface.
  • AXI read and write requests may be accepted simultaneously by the AXI subordinate, but internal arbitration will service them one at a time.
• Responses are in order
• Burst data interleaving is not supported
• SoC agents shall not initiate AXI burst transfers to the SoC interface, except as write bursts to the mbox_datain register or read bursts from the mbox_dataout register. Such bursts shall be of the AXI "FIXED" burst type.
• Accesses to these registers shall not be "narrow". This means that AxSIZE must be set to 0x2 and WSTRB must be set to 0xF.
  • mbox_datain
  • mbox_dataout
  • CPTRA_TRNG_DATA
• Violations of the AXI specification by AXI managers will result in undefined behavior. Examples include:
  • AxSIZE values larger than interface width (greater than 0x2).
  • AxLEN larger than legal value (256 maximum burst size, 16 for FIXED bursts, and total burst length must be 4096 Bytes or less).
  • Number of data beats on W channel does not match burst length indicated on AWLEN.
  • RRESP or BRESP has an undefined value.
  • WLAST is driven incorrectly, driven on multiple beats, or never driven.
• Exclusive accesses are not supported. I.e. AxLOCK must be tied to 0.
• The following signals are unused/unconnected:
  • AxCACHE
  • AxPROT
  • AxREGION
  • AxQOS

Undefined address accesses

All accesses that are outside of the defined address space of Caliptra are responded to by Caliptra’s SoC interface:

• All reads to undefined addresses get completions with zero data.
• All writes to undefined addresses are dropped.
• All other undefined opcodes are silently dropped.
• Access to mailbox memory region with invalid AXI_USER are dropped.
• Access to a fuse with invalid AXI_USER are dropped.
• Access to the trng with invalid AXI_USER are dropped.
• SLVERR is asserted for any of the above conditions.

All accesses must be 32-bit aligned. Misaligned writes are dropped and reads return 0x0.

DMA Assist Engine

Caliptra contains a DMA assist engine and AXI manager interface that is used in Subsystem mode to initiate AXI transactions to the SoC AXI interconnect. When Caliptra is integrated in passive mode the DMA assist block is not available for use; all AXI manager interfaces must be tied to 0 and must not be connected to the SoC interconnect. For details on the DMA block in Subsystem mode operation, refer to the Caliptra Subsystem Hardware Specification.

Undefined mailbox usages

A trusted/valid requester that locks the mailbox and never releases the lock will cause the mailbox to be locked indefinitely.

Caliptra firmware internally has the capability to force release the mailbox based on various timers but there is no architectural requirement to use this capability.

Straps

Straps are signal inputs to Caliptra that are sampled once on reset exit, and the latched value persists throughout the remaining uptime of the system. Straps are sampled on either cptra_pwrgood signal assertion (cold reset exit) or cptra_noncore_rst_b deassertion (warm reset exit) – refer to interface table for list of straps. In 2.0, Caliptra adds support for numerous Subsystem-level straps. These straps are initialized on warm reset deassertion to the value from the external port, but may also be rewritten by the SoC firmware at any time prior to CPTRA_FUSE_WR_DONE being set. These must be programmed by SoC FW at the same time as Caliptra Fuses per Caliptra Spec. Once written and locked, the values of these straps persist until a cold reset.

Obfuscation key

SoC drives the key at the tape-in time of the SoC using an Engineering Change Order (ECO) and must be protected from common knowledge. For a given SoC construction, this can be driven using a PUF too.

The key must follow the security rules defined in the Caliptra architectural specification.

SoC must ensure that there are no SCAN cells on the flops that latch this key internally to Caliptra.

CSR HMAC key

SoC drives the key at the tape-in time of the SoC using an Engineering Change Order (ECO) and must be protected from common knowledge.

The key must follow the security rules defined in the Caliptra architectural specification.

SoC must ensure that there are no SCAN cells on the flops that latch this key internally to Caliptra.

Late binding interface signals

The interface signals generic_input_wires, generic_output_wires, and strap_ss_strap_generic_N are placeholders on the SoC interface reserved for late binding features. This may include any feature that is required for correct operation of the design in the final integrated SoC and that may not be accommodated through existing interface signaling (such as the mailbox).

While these late binding interface pins are generic in nature until assigned a function, integrators must not define non-standard use cases for these pins. Defining standard use cases ensures that the security posture of Caliptra in the final implementation is not degraded relative to the consortium design intent. Bits in generic_input_wires and strap_ss_strap_generic_N that don't have a function defined in Caliptra must be tied to a 0-value. These undefined input bits shall not be connected to any flip flops (which would allow run-time transitions on the value).

Each wire connects to a register in the SoC Interface register bank through which communication to the internal microprocessor may be facilitated. Each of the generic wire signals is 64 bits in size. The size of the generic strap is indicated in Table 11.

Activity on any bit of the generic_input_wires triggers a notification interrupt to the microcontroller indicating a bit toggle.

The following table describes the allocation of functionality on generic_input_wires. All bits not listed in this table must be tied to 0.

Table 13: generic_input_wires function binding

The following table describes the allocation of functionality to strap_ss_strap_generic_N. All straps not listed in this table must be tied to 0.

Table 14: strap_ss_strap_generic_N function binding

SoC interface operation

The Caliptra mailbox is the primary communication method between Caliptra and the SoC that Caliptra is integrated into.

The Caliptra mailbox uses an AXI interface to communicate with the SoC. The SoC can write to and read from various memory mapped register locations over the AXI interface in order to pass information to Caliptra.

Caliptra in turn also uses the mailbox to pass information back to the SoC. The interface does not author any transaction on the AXI interface. The interface only signals to the SoC that data is available in the mailbox and it is the responsibility of the SoC to read that data from the mailbox.

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 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 deasserting the internal reset. The following figure shows the boot FSM state.

Figure 3: Mailbox Boot FSM state diagram

The boot FSM first waits for the SoC to assert cptra_pwrgood and deassert cptra_rst_b. The SoC first provides a stable clock to Caliptra. After a minimum of 10 clock cycles have elapsed on the stable clock, the SoC asserts cptra_pwrgood. The SoC waits for a minimum of 10 clocks after asserting cptra_pwrgood before deasserting 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.

BOOT_DONE enables Caliptra reset deassertion through a two flip-flop synchronizer.

SoC access mechanism

The SoC communicates with the mailbox through an AXI Interface. The SoC acts as the requester with the Caliptra mailbox as the receiver.

The AXI_USER bits are used by the SoC to identify which device is accessing the mailbox.

Mailbox

The Caliptra mailbox is a 256 KiB buffer used for exchanging data between the SoC and the Caliptra microcontroller.

When a mailbox is populated by the SoC, initiation of the operation by writing the execute bit triggers an interrupt to the microcontroller. This interrupt 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, an output wire to the SoC indicates that a command is available in the mailbox. The SoC is responsible for reading from and responding to the command.

Mailboxes are generic data-passing structures with a specific protocol that defines legal operations. This protocol for writing to and reading from the mailbox is enforced in hardware as described in the Caliptra mailbox errors section. How the command and data are interpreted by the microcontroller and SoC are not enforced in this specification.

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 will be 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. Status can return:
   1. CMD_BUSY - 2’b00 – Indicates the requested command is still in progress
   2. DATA_READY - 2’b01 – Indicates the return data is in the mailbox for requested command
   3. CMD_COMPLETE- 2’b10 – Indicates the successful completion of the requested command
   4. CMD_FAILURE- 2’b11 – Indicates the requested command failed
7. Requester reads the response if DATA_READY was the status.
8. Requester resets the EXECUTE register to release the lock.

Notes on behavior:

Once LOCK is granted, the mailbox is locked until that device has concluded its operation. Caliptra has access to an internal mechanism to terminate a lock early or release the lock if the device does not proceed to use it or to recover from deadlock scenarios. The following figure shows the sender protocol flow.

Figure 4: Sender protocol flow chart

Receiver Protocol

Upon receiving indication that mailbox has been 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.

Caliptra will not initiate any mailbox commands that require a response from the SoC. Caliptra initiated mailbox commands are “broadcast” and available to any user on the SoC. SoC will not be able to write the DLEN or DATAIN register while processing a Caliptra initiated mailbox command.

Receiving data from the mailbox:

1. On mailbox_data_avail assertion, the receiver reads the COMMAND register.
2. Receiver reads the DLEN register.
3. Receiver reads the CMD register.
4. Receiver reads the MBOX DATAOUT register.
   • Continue reading MBOX DATAOUT register until DLEN bytes are read.
5. If a response is required, the receiver can populate the mailbox with the response by updating the DLEN register and writing to DATAIN with the response. (NOTE: The new DLEN value will not take effect until control is returned to the sender via write to the status register).
6. Set the mailbox status register appropriately to hand control back to the sender.
7. The sender will reset the EXECUTE register.
   • This releases the LOCK on the mailbox.

The following figure shows the receiver protocol flow.

Figure 5: Receiver protocol flowchart

TAP mailbox mode

When Caliptra sets the tap_mode register, the mailbox will transition from RDY_FOR_DATA to EXECUTE_TAP instead of EXECUTE_SOC. This will pass control of the mailbox to the TAP. TAP will follow the Receiving data from the mailbox protocol detailed above.

When TAP acquires the mailbox lock, the mailbox will transition from RDY_FOR_DATA_to EXECUTE_UC. This transition results in the assertion of the internal interrupt signal uc_mailbox_data_avail to UC. This will pass control of the mailbox to the UC. UC will follow the Receiving data from the mailbox protocol detailed above.

Mailbox arbitration

From a mailbox protocol perspective, as long as CPTRA_VALID_AXI_USER registers carry valid requesters, mailbox lock can be obtained by any of those valid requesters but only one of them at any given time. While the mailbox flow is happening, all other requesters will not get a grant.

A request for lock that is denied due to firmware having the lock results in an interrupt to the firmware. Firmware can optionally use this interrupt to release the lock.

There is no fair arbitration scheme between SoC and microcontroller. It is first come, first served. When the mailbox is locked for microcontroller use and SoC has unsuccessfully requested the mailbox (due to mailbox actively being used), the mailbox generates an interrupt to the microcontroller as a notification.

Further, there is no arbitration between various AXI_USER attributes. AXI_USER attributes exist for security and filtering reasons only.

MAILBOX AXI USER attribute register

It is strongly recommended that these AXI_USER registers are either set at integration time through integration parameters or be programmed by the SoC ROM before any mutable firmware or ROM patches are applied.

SoC SHALL not use value 0xFFFFFFFF as a valid AXI user value for any of the below settings. This is reserved for Caliptra-internal usage.

Programmable registers

Caliptra provides 5 programmable registers that SoC can set at boot time to limit access to the mailbox peripheral. The default AXI_USER set by the integration parameter CPTRA_DEF_MBOX_VALID_AXI_USER is valid at all times. CPTRA_MBOX_VALID_AXI_USER registers become valid once the corresponding lock bit CPTRA_MBOX_AXI_USER_LOCK is set.

Table 15: AXI_USER register definition

Parameter override

Another option for limiting access to the mailbox peripheral are the integration time parameters that override the programmable AXI_USER registers. At integration time, the CPTRA_SET_MBOX_AXI_USER_INTEG parameters can be set to 1 which enables the corresponding CPTRA_MBOX_VALID_AXI_USER parameters to override the programmable register.

Table 16: AXI_USER Parameter definition

Caliptra mailbox protocol

After the SoC side has written the EXECUTE register, the mailbox sends an interrupt to the microcontroller.

The microcontroller reads the COMMAND and DLEN registers, as well as the data populated in the mailbox.

The microcontroller can signal back to SoC through functional registers, and populate COMMAND, DLEN, and MAILBOX as well.

Caliptra mailbox errors

Mailbox is responsible for only accepting writes from the device that requested and locked the mailbox.

If the SoC violates this protocol, the mailbox flags a protocol violation and enters an error state. Two protocol violations are detected:

1. Access without lock: Writes to any mailbox register by SoC or reads from the dataout register, without having first acquired the lock, are a violation.
   1. If any agent currently has the lock, accesses by agents other than the one holding the lock are ignored.
   2. If no agent currently has the lock, the violation results in a flagged error.
2. Out of order access: SoC must follow the rules for the sender and receiver protocol that define access ordering and progression for a mailbox command.
   1. If, after acquiring the lock, an SoC agent performs any register write (or read from the dataout register) outside of the prescribed ordering, this is a flagged violation.
   2. Such access by any SoC agent that does not have the lock is ignored.

After a mailbox protocol violation is flagged, it is reported to the system in several ways:

• The mailbox FSM enters the ERROR state in response to an out of order access violation, and the new FSM state is readable via the mailbox status register. The LOCK value is preserved on entry to the ERROR state. The access without lock violation does not result in a state change. After entering the ERROR state, the mailbox may only be restored to the IDLE state by:

  • System reset
  • Write to the force unlock register by firmware inside Caliptra (via internal bus)

  Either of these mechanisms will also clear the mailbox LOCK.

• Mailbox protocol violations are reported as fields in the HW ERROR non-fatal register. These events also cause assertion of the cptra_error_non_fatal interrupt signal to SoC. Upon detection, SoC may acknowledge the error by clearing the error field in this register via bus write.

• Mailbox protocol violations generate an internal interrupt to the Caliptra microcontroller. Caliptra firmware is aware of the protocol violation.

The following table describes AXI transactions that cause the Mailbox FSM to enter the ERROR state, given that the register “mbox_user” contains the value of the AXI USER that was used to originally acquire the mailbox lock.

Table 17: Mailbox protocol error trigger conditions

* mbox_user value is not used when Caliptra has lock and is sending a Caliptra to SoC mailbox operation.

SoC SHA acceleration block

Overview

The SHA acceleration block is in the SoC interface. The SoC can access the accelerator’s hardware API and stream data to be hashed over the AXI interface.

SHA acceleration block uses a similar protocol to the mailbox, but has its own dedicated registers. Caliptra is the only permitted user of SHA acceleration, either in streaming mode (via AXI) or in mailbox mode. Use of the SHA acceleration block over AXI is only available in Caliptra Subsystem, and is only available to Caliptra, which will access it via the AXI DMA block. The SHA accelerator checks the AXI AxUSER signal to block any access that originates from an agent other than Caliptra's AXI DMA.

SHA_LOCK register is set on read. A read of 0 indicates the SHA was unlocked and will now be locked for the requesting user.

SHA_MODE register sets the mode of operation for the SHA.

See the Hardware specification for additional details.

• 2’b00 - SHA384 streaming mode
• 2’b01 - SHA512 streaming mode
• 2’b10 - SHA384 mailbox mode (Caliptra only, invalid for SoC requests)
• 2’b11 - SHA512 mailbox mode (Caliptra only, invalid for SoC requests)

SoC Sender Protocol

Sending data to the SHA accelerator:

1. Requester queries the accelerator by reading the SHA_LOCK control register.
   • If SHA_LOCK returns 0, SHA_LOCK is granted and is set to 1.
   • If SHA_LOCK returns 1, it is locked for another device.
2. Requester writes the SHA_MODE register to the appropriate mode of operation.
3. Requester writes the data length in bytes to the SHA_DLEN register.
4. Requester writes data packets to the SHA_DATAIN register until SHA_DLEN bytes are written.
5. Requester writes the SHA_EXECUTE register, this indicates that it is done streaming data.
6. Requesters can poll the SHA_STATUS register for the VALID field to be asserted.
7. Once VALID is asserted, the completed hash can be read from the SHA_DIGEST register.
8. Requester must write 1 to the LOCK register to release the lock.

TRNG REQ HW API

For SoCs that choose to not instantiate Caliptra’s internal TRNG, we provide a TRNQ REQ HW API.

While the use of this API is convenient for early enablement, the current Caliptra hardware is unable to provide the same security guarantees with an external TRNG. In particular, it is highly advisable to instantiate an internal TRNG if ROM glitch protection is important.

1. Caliptra asserts TRNG_REQ wire (this may be because Caliptra’s internal hardware or firmware made the request for a TRNG).
2. SoC writes the TRNG architectural registers.
3. SoC write a done bit in the TRNG architectural registers.
4. Caliptra deasserts TRNG_REQ.

Having an interface that is separate from the SoC mailbox ensures that this request is not intercepted by any SoC firmware agents (which communicate with SoC mailbox). It is a requirement for FIPS compliance that this TRNG HW API is always handled by SoC hardware gasket logic (and not some SoC ROM or firmware code).

TRNG DATA register is tied to TRNG VALID AXI USER. SoC can program the TRNG VALID AXI USER and lock the register using TRNG_AXI_USER_LOCK[LOCK]. This ensures that TRNG DATA register is read-writeable by only the AXI USER programmed into the TRNG_VALID_AXI_USER register. If the CPTRA_TNRG_AXI_USER_LOCK.LOCK is set to ‘0, then any agent can write to the TRNG DATA register. If the lock is set, only an agent with a specific TRNG_VALID_AXI_USER can write.

The ROM and firmware currently time out on the TRNG interface after 250,000 attempts to read a DONE bit. This bit is set in the architectural registers, as referenced in 3 in the preceding list.

Internal TRNG

TRNG self-test ROM configuration

The internal TRNG is configured by the ROM to extract entropy used to initialize Control Flow Integrity (CFI) countermeasures. Since the ROM does not use entropy for any cryptographic operations, the TRNG self-tests are not configured for FIPS compliance, but rather to ensure that the quality of the entropy output is sufficient for ROM operation.

The default self-test parameters are provided to the ROM via the CPTRA_iTRNG_ENTROPY_CONFIG0 and CPTRA_iTRNG_ENTROPY_CONFIG1 registers.

The ROM configures self tests with the following parameters.

Adaptive test

The adaptive self-test thresholds are configured as follows if the high and low thresholds provided in the CPTRA_iTRNG_ENTROPY_CONFIG0 are non-zero.

entropy_src.ADAPTP_HI_THRESHOLDS.FIPS_THRESH = CPTRA_iTRNG_ENTROPY_CONFIG0.HIGH_THRESHOLD
entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH = CPTRA_iTRNG_ENTROPY_CONFIG0.HIGH_THRESHOLD

Otherwise, the ROM will use 75% and 25% of the FIPS window size for the default high and low thresholds.

W = 2048 (bits)
entropy_src.ADAPTP_HI_THRESHOLDS.FIPS_THRESH = \(3 * (W / 4)\) = 1536
entropy_src.ADAPTP_LO_THRESHOLDS.FIPS_THRESH = \(W / 4\) = 512

It is strongly recommended to avoid using the default values.

Repetition count test

Caliptra supports two implementations of the repetition count test, one that counts repetitions per physical noise source (REPCNT); and, another that counts repetitions at the symbol level (REPCNTS). The ROM configures the REPCNT version.

The self-test is configured as follows if the CPTRA_iTRNG_ENTROPY_CONFIG1 register is not zero.

entropy_src.REPCNT_THRESHOLDS.FIPS_THRESH = CPTRA_iTRNG_ENTROPY_CONFIG1.REPETITION_COUNT

Otherwise, the ROM will use a default value configuration:

entropy_src.REPCNT_THRESHOLDS.FIPS_THRESH = 41

It is strongly recommended to avoid using the default values.

Recommended TRNG self-test thresholds

The thresholds should be tuned to match the entropy estimate of the noise source (H), which is calculated by applying a NIST-approved entropy estimate calculation against raw entropy extracted from the target silicon.

Important: It is important to note that the TRNG will discard samples that do not pass any of the health tests. Since there is a compression function requiring 2048 bits of good entropy to produce a 384 bit seed, the ROM may stall if the self-test thresholds are too aggressive or if the values are misconfigured. To avoid boot stall issues, it is strongly recommended to characterize the noise source on target silicon and select reliable test parameters. The ROM only needs to provide sufficient entropy for countermeasures, so FIPS-level checks can be performed later, in a less boot-timing-sensitive stage.

The following sections illustrate the self-test parameter configuration. The entropy_src block provides additional tests, but Caliptra's ROM focuses primarily on the adaptive and repetition count (REPCNT) tests. All other tests are left with their reset value configuration, which is equivalent to running the test with the most permissive settings.

Test parameters

The variable names are as defined in NIST SP 800-90B.

\(α = 2^{-40}\) (recommended)
\(H = 0.5\) (example, implementation specific)
\(W = 2048\) (constant in ROM/hw)

Adaptive proportion test

The test is configured with to sum all the bits per symbol, due to entropy_src.CONF.THRESHOLD_SCOPE being enabled. The test essentially treats the combined input as a single binary stream, counting the occurrences of '1's.

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

CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold = \(1 + critbinom(W, 2^{-H}, 1 - α)\)
CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold = \(1 + critbinom(2048, 2^{-H}, 1 - 2^{-40})\)
CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold = 1591

CPTRA_iTRNG_ENTROPY_CONFIG0.low_threshold = W - CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold
CPTRA_iTRNG_ENTROPY_CONFIG0.low_threshold = 2048 - CPTRA_iTRNG_ENTROPY_CONFIG0.high_threshold
CPTRA_iTRNG_ENTROPY_CONFIG0.low_threshold = 457

Repetition count threshold

The repetition count test as configured in the ROM makes no FIPS compliance claims due to the fact that counts are aggregated for each individual bit. This results in a less restrictive threshold as the test will wait for 4x more repetitions before failing. From an entropy quality perspective, this is deemed acceptable for the current Caliptra release.

\[ \begin{aligned} & RcThresh = \frac{-log_2(α)}{H} + 1 \ & RcThresh = \frac{40}{H} + 1 \ & RcThresh = 81 \end{aligned} \]

CPTRA_iTRNG_ENTROPY_CONFIG1.repetition_count = RcThresh = 81

FIPS Compliance

Caliptra 1.x and 2.0 do not make any FIPS conformance claims on the self-tests configured by the ROM and executed by the internal TRNG. This is due to the test configuration. See previous sections for more details.

SRAM implementation

Overview

SRAMs are instantiated at the SoC level. Caliptra provides the interface to export SRAMs from internal components.

SRAM repair logic (for example, BIST) and its associated fuses, which are proprietary to companies and their methodologies, is implemented external to the Caliptra boundary.

SRAMs must NOT go through BIST or repair flows across a “warm reset”. SoC shall perform SRAM repair during a powergood cycling event ("cold reset") and only prior to deasserting cptra_rst_b. During powergood cycling events, SoC shall also initialize all entries in the SRAM to a 0 value, prior to deasserting caliptra_rst_b.

Mailbox SRAM is implemented with ECC protection. Data width for the mailbox is 32-bits, with 7 parity bits for a Hamming-based SECDED (single-bit error correction and double-bit error detection).

RISC-V internal memory export

To support synthesis flexibility and ease memory integration to various fabrication processes, all SRAM blocks inside the RISC-V core are exported to an external location in the testbench. A single unified interface connects these memory blocks to their parent logic within the RISC-V core. Any memory implementation may be used to provide SRAM functionality in the external location in the testbench, provided the implementation adheres to the interface requirements connected to control logic inside the processor. Memories behind the interface are expected to be implemented as multiple banks of SRAM, from which the RISC-V processor selects the target using an enable vector. The I-Cache has multiple ways, each containing multiple banks of memory, but I-Cache is disabled in Caliptra and this may be removed for synthesis.

The following memories are exported:

• Instruction Closely-Coupled Memory (ICCM)
• Data Closely Coupled Memory (DCCM)

Table 7 indicates the signals contained in the memory interface. Direction is relative to the exported memory wrapper that is instantiated outside of the Caliptra subsystem (that is, from the testbench perspective).

SRAM timing behavior

• [Writes] Input wren signal is asserted simultaneously with input data and address. Input data is stored at the input address 1 clock cycle later.
• [Reads] Input clock enable signal is asserted simultaneously with input address. Output data is available 1 clock cycle later from a flip-flop register stage.
• [Writes] Input wren signal is asserted simultaneously with input data and address. Data is stored at the input address 1 clock cycle later.

The following figure shows the SRAM interface timing.

Figure 6: SRAM interface timing

SRAM parameterization

Parameterization for ICCM/DCCM memories is derived from the configuration of the VeeR RISC-V core that has been selected for Caliptra integration. Parameters defined in the VeeR core determine signal dimensions at the Caliptra top-level interface and drive requirements for SRAM layout. For details about interface parameterization, see the Interface section. Complete configuration parameters of the RISC-V Core may be found in common_defines.sv. The following table explains some parameters that are used to derive interface signal widths for exported RISC-V SRAM signals.

Table 18: SRAM parameterization

Example SRAM machine check reliability integration

This section describes an example implementation of integrator machine check reliability.

This example is applicable to scenarios where an integrator may need control of or visibility into SRAM errors for purposes of reliability or functional safety. In such cases, integrators may introduce additional layers of error injection, detection, and correction logic surrounding SRAMs. The addition of such logic is transparent to the correct function of Caliptra, and removes integrator dependency on Caliptra for error logging or injection.

Note that the example assumes that data and ECC codes are in non-deterministic bit-position in the exposed SRAM interface bus. Accordingly, redundant correction coding is shown in the integrator level logic (i.e., integrator_ecc(calitpra_data, caliptra_ecc)). If the Caliptra data and ECC are deterministically separable at the Caliptra interface, the integrator would have discretion to store the ECC codes directly and calculate integrator ECC codes for the data alone.

Figure 7: Example machine check reliability implementation

Error detection and logging

1. Caliptra IP shall interface to ECC protected memories.
2. Caliptra IP calculates and applies its own ECC code, which produces a total of 39-bit data written to external or INTEGRATOR instantiated SRAMs.
3. Each 39-bit bank memory internally calculates 8-bit ECC on a write and stores 47 bits of data with ECC into SRAM.
4. On read access syndrome is calculated based on 39-bit data.
5. If parity error is detected and syndrome is valid, then the error is deemed single-bit and correctable.
6. If no parity error is detected but syndrome == 0 or the syndrome is invalid, the error is deemed uncorrectable.
7. On both single and double errors, the read data is modified before being returned to Caliptra.
8. Since single-bit errors shall be corrected through INTEGRATOR instantiated logic, Caliptra never sees single-bit errors from SRAM.
9. Double-bit or uncorrectable errors would cause unpredictable data to be returned to Caliptra. Since this condition shall be detected and reported to MCRIP, there is no expectation that Caliptra will operate correctly after a double error.
10. On detection, single errors are reported as transparent to MCRIP, double errors are reported as fatal.
11. Along with error severity, MCRIP logs physical location of the error.
12. After MCRIP logs an error, it has a choice to send out in-band notification to an external agent.
13. MCRIP logs can be queried by SoC software.

Error injection

1. MCRIP supports two error injection modes: intrusive and non-intrusive.
2. Intrusive error injection:
   1. Can force a single or double error to be injected, which would result in incorrect data to be returned on read access.
   2. The intrusive error injection mode is disabled in Production fused parts via Security State signal.
3. Non-intrusive error injection:
   1. Allows external software to write into MCRIP error log registers.
   2. The non-intrusive error injection does not interfere with the operation of memories.
   3. The non-intrusive error injection is functional in Production fused parts.

Caliptra error handling flow

1. Any implementation of error and recovery flows must adhere to the error handling requirements specified in Caliptra.md
2. SoC level reporting and handling of fatal & non-fatal errors is product-specific architecture, outside the scope of Caliptra core definition. For example, a CPU and a PCIe device may handle fatal and non-fatal errors differently.

SoC integration requirements

The following table describes SoC integration requirements.

For additional information, see Caliptra assets and threats.

Table 19: SoC integration requirements