Caliptra Subsystem Provisioning Guide

Goal / Disclaimer

This document aims to provide Caliptra Subsystem (SS) silicon vendors/manufacturers with guidance on how to provision devices during manufacturing. Nothing in this document is a requirement for Caliptra Trademark compliance. Note, this document focuses on the technical and operational aspects of provisioning a device with Caliptra Subsystem. Details on how to secure provisioning infrastructure to meet various certification requirements are outside the scope of this document.

Assets

There are two categories of assets that must be provisioned into a product that integrates Caliptra Subsystem before the device becomes fully operational:

1. fuses
2. IDevID (UDS) certificate

Fuses

Caliptra SS contains a One-Time Programmable (OTP) fuse memory bank that must be provisioned during SoC manufacturing. The fuse bank contains several logical fields organized across a set of partitions. Additionally, Caliptra SS contains a fuse-backed lifecycle FSM (known as the lifecycle controller), whose states gate debug capabilities of a device, thus requiring specific fuse fields be programmed in specific life-cycle states. The table below describes the fuse map and the lifecycle states they should be provisioned by.

Certificates

When requested, the IDevID CSR is generated by the Caliptra Core ROM after receiving the UDS Seed from the Caliptra Subsystem fuse controller. It should be endorsed by an external CA protected via an HSM on an isolated manufacturing network¹.

There are two different IDevID certificates to be generated, based on the cryptographic keys they are constructed for:

1. ECC secp384r1
2. ML-DSA-87

The signature sizes for each are shown in the following table. These signatures should be stored in the larger SoC’s nonvolatile storage or other accessible service.

To be able to reconstruct the IDevID certificate on boot, Caliptra also requires the original certificate attributes be stored in the SoC's fuses. The size and encoding of this data is fixed for both certificate types (ECC and ML-DSA), and detailed in the Caliptra specification.

Provisioning Sequence

The Caliptra Subsystem provisioning sequence is described below. The provisioning sequence is designed to suit various requirements among downstream integrators, including:

1. providing an ATE-friendly provisioning sequence where DUT operations can be performed: a. directly over JTAG, and/or b. by loading custom MCU firmware into SRAM (via JTAG).
2. The ability to program different fuse partitions at various lifecycle stages.

In addition to the provisioning flow description, the Caliptra project aims to provide a general reference provisioning flow, and supporting tooling / firmware, upstream. These are currently under development, and tied to a caliptra-mcu-sw GitHub milestone.

Before describing the sequence, we provide some background information on two important hardware blocks that facilitate the provisioning sequence, namely:

1. lifecycle controller, and
2. fuse controller.

Background: Lifecycle Controller Architecture

Caliptra Subsystem provides a hardware backed lifecycle FSM (known as the lifecycle controller) that transitions through several lifecycle states shown in the diagram below:

States only move forward and persist across chip resets; once advanced, it cannot revert to a previous state as lifecycle states are encoded in fuses. Transitions between some states require the use of password-like tokens. All tokens are provisioned in fuses, except the "Raw Unlock Token", which is a netlist constant. The purpose of each lifecycle state is described below. Additionally below is a table that summarizes which states allow debug (i.e. JTAG and DFT) access to various Caliptra Subsystem and SoC components.

* Integration Configurable
CLTAP = Chip Level TAP

TestUnlocked[0–7] states are used for initial testing to ensure chip health. All lifecycle tokens in the SECRET_LC_TRANSITION_PARTITION fuse partition should be provisioned in TestUnlocked0 to allow further actuation of the lifecycle controller during manufacturing. After testing, the chip is locked by entering a TestLocked[0–7] state to close debug access.

Using a provisioned token, a chip can transition from any of the TestUnlock[0–7] / TestLocked[0–7] states to the Manuf(acturing) state. In this state, debug access is once again opened, and the UDS and other manufacturing-specific fuses are injected. All production debug unlock tokens for the production state must be provisioned in this state, and the partition locked.

After manufacturing, the chip enters a production state (Prod or ProdEnd). Additional fuse provisioning (e.g., field entropy, revocation bits) may occur here, but only for fuse partitions not already locked in manufacturing. Entry into debug mode in production uses signature authentication with public keys, supporting multiple debug levels (up to 8), each with different privileges.

Production End & RMA marks the end of the chip’s functional lifecycle. The chip is no longer considered part of the active fleet and is not used for regular operations. Additionally, from any lifecycle state, the chip may transition (unconditionally without token) to the Scrap state, where fuse zeroization is performed, in accordance with FIPS requirements, to securely erase all secret assets stored in fuses.

Background: Fuse Controller

As mentioned above, Caliptra Subsystem contains a One-Time Programmable (OTP) fuse memory bank that is controlled by a hardware block known as the fuse_ctrl (or fuse controller). The OTP memory bank is split into partitions, and each partition:

1. contains a digest field over the partition, and
2. can be write-locked by writing to the digest field.

The locking mechanism prevents further changes to certain partitions (e.g., UDS). Once locked, these fuses cannot be overwritten for the lifetime of the device, with the exception of zeroizable partitions which may be cleared once a device is decommissioned. While the fuse memory map may be expanded for a particular integration, see the integration guide for more details, a baseline memory map is provided upstream.

Provisioning Sequence

Below is a summary of the provisioning flow required to bring a Caliptra Subsystem device from a raw lifecycle state to a production lifecycle state. This flow assumes all devices in a raw state have all fuses in their, unprogrammed, initial state, i.e., all bits set to zeros. Additionally, while this flow may be performed at a manufacturing stage of the integrator's choosing, we describe the following operations from the perspective of a tester, as if the operations were performed entirely at a Final Test (FT) silicon manufacturing stage with the aid of an Automated Test Equipment (ATE).

1. Tester drives a lifecycle transition via JTAG: Raw → TestUnlocked0
2. Perform wafer sort testing.
3. Tester programs the following fuses (via JTAG or by loading MCU firmware loaded to SRAM):
   1. vendor test
   2. Lifecycle tokens
   3. Manuf debug unlock token
4. Perform more wafer sort testing.
5. Tester drives a lifecycle transition via JTAG: TestUnlocked* → Manuf
6. Tester programs remaining fuses:
   1. Secure Boot Key hashes / types
   2. UDS fuses via programming sequence with Caliptra Core API
7. Tester requests Caliptra Core to generate HMAC endorsed IDevID CSR and extract from DUT.
8. Tester forward CSR and HMAC to HSM for authentication and endorsement.
9. HSM validates HMAC and endorses IDevID TBS certificate.
10. [Optional] Tester program IDevID certificate into integration-specific non-volatile storage.
11. Tester drives a lifecycle transition via JTAG: Manuf → Prod[End]

Provisioning Responsibilities

Provisioning responsibilities vary depending on whether the SoC containing Caliptra Subsystem follows one of two integration scenarios (labeled 1 and 2 below). Below, we provide details on how the IDevID Certificate Signing Requests (CSRs) are authenticated and endorsed in each product integration scenario. We define two different roles to aid this discussion: "vendor/manufacturer" and "owner".

Scenario 1: Vendor and Owner are the Same Entity

Vendor and owner are the same entity; provisioning is performed on owner controlled infrastructure. The owner may choose to deploy provisioning infrastructure at any stage in their silicon (e.g., FT or SLT stages) and/or platform (e.g. L5 or L10 stages) manufacturing process, since they own both silicon and platform manufacturing. Specifically, at silicon manufacturing (typically at FT or SLT stages) the UDS should be programmed, and the IDevID CSR (and HMAC) extracted, using Caliptra APIs. Then, the IDevID CSR may either be (depending on the Vendor/Owner's product specific requirements),

1. endorsed at the same silicon manufacturing stage (FT or SLT) after verifying the CSR HMAC, or
2. collected, along with the CSR HMAC, and stored in an owner database to be authenticated and endorsed at a later platform manufacturing stage.

Regardless of which manufacturing stage (silicon or platform) the owner chooses to deploy provisioning infrastructure at, two key infrastructure components will be required:

• an HSM to both:
  • verify the HMAC signature of each IDevID CSR, and
  • endorse each certificate.
• a Device Registry Database to either:
  • store IDevID CSRs harvested during silicon manufacturing to be endorsed later during platform manufacturing, or
  • store IDevID certificates that are endorsed during silicon manufacturing.

Scenario 2: Vendor builds a Caliptra device for a single Owner

The vendor is building a device for a single owner. In this scenario, provisioning may be either:

1. entirely performed by the vendor's infrastructure deployed at any silicon manufacturing stage (e.g., FT or SLT stages), or
2. performed by a combination of the vendor's provisioning infrastructure, deployed at a silicon manufacturing stage (e.g., FT or SLT stages), and the ODM or owner's infrastructure, deployed at a platform manufacturing stage (e.g., L5 or L10 stages)

Option 1

If option 1 is selected, the vendor will likely need to deploy the same two infrastructure components required in Scenario 1: an HSM and Device Registry Database. The vendor infrastructure is then responsible for:

1. programming the UDS using Caliptra APIs,
2. extracting the IDevID CSR (and HMAC) using Caliptra APIs
3. validating CSR HMACs/endorsing CSRs with their HSM, and
4. storing endorsed certificates in a database until they can be transferred to the intended owner.

In this option, the owner is trusting the vendor's CA keys, and therefore their provisioning infrastructure.

Option 2

If option 2 is selected, the vendor may only need to deploy a Device Registry Database, while the owner will need to deploy both an HSM and a Device Registry Database. The vendor then performs steps 1 and 2 in option 1 during silicon manufacturing, and stores the CSRs and their corresponding HMACs in a database to share with the owner. Later, during platform manufacturing, the owner validates each CSR HMAC and endorses each certificate with their HSM.

Lifecycle and Debug Unlock Token Requirements

All lifecycle and debug tokens, except the raw unlock token, are provisioned during manufacturing (in the TestUnlocked0 state), and stored by the manufacturer, or handed over to the device owner (e.g., the RMA unlock token). Below we provide guidance on how said tokens should be generated, stored, and/or transmitted to device owners.

Token Generation

All lifecycle and manufacturing debug tokens should be generated using either a NIST’s SP 800-90A or NIST’s SP 800-90C (Second Draft) compliant random bit generator (RBG), depending on the uniqueness requirements of the given token. Production debug unlock tokens should follow the guideline of FIPS 186-5 and FIPS 204 for ECDSA and ML-DSA based signature schemes, respectively.

Token Uniqueness

While product integration requirements should ultimately dictate the uniqueness of tokens across a set of chips for a given product, the following table provides a recommendation to maximize security of the provisioning process, while also facilitating ease of deployment.

Token Storage and Use

Manufacturers / Vendors should avoid storing these tokens in plaintext on disk. Instead, an HSM-backed Key Derivation Function should be used to produce the tokens on demand when possible. If tokens must be stored, as is the case with RMA and debug tokens, they should be encrypted with a key that is itself protected by an HSM.

Facility Guidelines

To meet various security certification requirements (e.g. FIPS 140-3 Level 3) provisioning Caliptra Subsystem fuses (including secret fuse values like Field Entropy and UDS) may demand a highly controlled OSAT environment. Below we categorize some of these facility requirements:

1. physical security and access controls,
2. environmental controls,
3. data logging and traceability,
4. key management practices, and
5. adherence to industry standards and certification requirements.

It is the responsibility of the product integrator to ensure the appropriate requirements are met for the specific certification level relevant to their product.

Appendix

Lifecycle State Constraints for Provisioning Fuses

The fuse partition below corresponds to the Caliptra Subsystem 2.1.1 reference fuse map.

Glossary

The following acronyms and abbreviations are used throughout this document.