Diff: ROM Specification

@@ -1,9 +1,9 @@
1	1	<div style="font-size: 0.85em; color: #656d76; margin-bottom: 1em; padding: 0.5em; background: #f6f8fa; border-radius: 4px;">
2		-📄 Source: <a href="https://github.com/chipsalliance/caliptra-sw/blob/8b2a7652fe8369be080e540f7c3e565e1e34231b/rom/dev/README.md" target="_blank">chipsalliance/caliptra-sw/rom/dev/README.md</a> @ <code>8b2a765</code>
	2	+📄 Source: <a href="https://github.com/chipsalliance/caliptra-sw/blob/3dee8a3821b35a3ad98fbf84d104b85fa8198350/rom/dev/README.md" target="_blank">chipsalliance/caliptra-sw/rom/dev/README.md</a> @ <code>3dee8a3</code>
3	3	</div>
4	4
5	5
6		-# Caliptra - ROM Specification v2.0.2
	6	+# Caliptra - ROM Specification v2.1
7	7
8	8	Spec Version: 1.0
9	9
@@ -59,23 +59,28 @@
59	59	### Fuse Registers
60	60	\| Register \| Width (bits) \| Description \|
61	61	\| :------------------------------ \| :------------ \| :----------------------------------------------------- \|
62		-\| FUSE_UDS_SEED \| 512 \| Obfuscated UDS \|
63		-\| FUSE_FIELD_ENTROPY \| 256 \| Obfuscated Field Entropy \|
64		-\| FUSE_VENDOR_PK_HASH \| 384 \| Hash of the ECC and LMS or MLDSA Manufacturer Public Key Descriptors \|
	62	+\| FUSE_UDS_SEED \| 512 \| Obfuscated UDS. Stored as `[u32; 16]` — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
	63	+\| FUSE_FIELD_ENTROPY \| 256 \| Obfuscated Field Entropy. Stored as `[u32; 8]` — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
	64	+\| FUSE_VENDOR_PK_HASH \| 384 \| Hash of the ECC and LMS or MLDSA Manufacturer Public Key Descriptors. Stored as `[u32; 12]` — see [Public key hash byte ordering](#public-key-hash-byte-ordering-dword-reversal). \|
65	65	\| FUSE_ECC_REVOCATION \| 4 \| Manufacturer ECC Public Key Revocation Mask \|
66	66	\| FUSE_LMS_REVOCATION \| 32 \| Manufacturer LMS Public Key Revocation Mask \|
67	67	\| FUSE_MLDSA_REVOCATION \| 4 \| Manufacturer MLDSA Public Key Revocation Mask \|
68		-\| FUSE_FIRMWARE_SVN \| 128 \| Firmware Security Version Number \|
	68	+\| FUSE_FIRMWARE_SVN \| 128 \| Firmware Security Version Number. 128-bit bitmap — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
69	69	\| FUSE_ANTI_ROLLBACK_DISABLE \| 1 \| Disable SVN checking for firmware when bit is set \|
70		-\| FUSE_IDEVID_CERT_ATTR \| 768 \| FUSE containing information for generating IDEVID CSR <br> Word 0:bits[0-2]: ECDSA X509 Key Id Algorithm (3 bits) 0: SHA1, 1: SHA256, 2: SHA384, 3: SHA512, 4: Fuse <br> Word 0:bits[3-5]: MLDSA X509 Key Id Algorithm (3 bits) 0: SHA1, 1: SHA256, 2: SHA384, 3: SHA512, 4: Fuse <br> Word 1,2,3,4,5: ECDSA Subject Key Id <br> Word 6,7,8,9,10: MLDSA Subject Key Id <br> Words 11: UEID type as defined in [IETF RATS specification](https://www.ietf.org/archive/id/draft-ietf-rats-eat-21.html#section-4.2.1.1) <br> Words 12,13,14,15: Manufacturer Serial Number \|
71		-\| FUSE_MANUF_DEBUG_UNLOCK_TOKEN \| 512 \| SHA-512 digest of secret value for manufacturing debug unlock authorization \|
	70	+\| FUSE_IDEVID_CERT_ATTR \| 768 \| FUSE containing information for generating IDEVID CSR <br> Word 0:bits[0-2]: ECDSA X509 Key Id Algorithm (3 bits) 0: SHA1, 1: SHA256, 2: SHA384, 3: SHA512, 4: Fuse <br> Word 0:bits[3-5]: MLDSA X509 Key Id Algorithm (3 bits) 0: SHA1, 1: SHA256, 2: SHA384, 3: SHA512, 4: Fuse <br> Word 1,2,3,4,5: ECDSA Subject Key Id <br> Word 6,7,8,9,10: MLDSA Subject Key Id <br> Words 11: UEID type as defined in the [IETF EAT specification](https://www.rfc-editor.org/rfc/rfc9711.html#section-4.2.1.1) <br> Words 12,13,14,15: Manufacturer Serial Number \|
	71	+\| FUSE_MANUF_DEBUG_UNLOCK_TOKEN \| 512 \| SHA-512 digest of secret value for manufacturing debug unlock authorization. Stored as `[u32; 16]` — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
72	72	\| FUSE_PQC_KEY_TYPE \| 2 \| One-hot encoded selection of PQC key type for firmware validation. <br> Bit 0: MLDSA <br> Bit 1: LMS \|
	73	+\| FUSE_HEK_SEED \| 256 \| OCP HEK Seed. Stored as `[u32; 8]` — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
	74	+\| FUSE_SOC_MANIFEST_SVN \| 128 \| SoC Manifest Security Version Number. 128-bit bitmap — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
	75	+\| FUSE_SOC_MANIFEST_MAX_SVN \| 8 \| Maximum SoC Manifest Security Version Number \|
	76	+\| FUSE_SOC_STEPPING_ID \| 16 \| SoC Stepping Identifier \|
	77	+\| FUSE_IDEVID_MANUF_HSM_ID \| 128 \| Manufacturer HSM Identifier. Stored as `[u32; 4]` — see [Fuse value byte ordering](#fuse-value-byte-ordering). \|
73	78
74	79
75	80	### Architectural Registers
76	81	\| Register \| Width (bits) \| Description \|
77	82	\| :------------------------------ \| :------------ \| :----------------------------------------------------- \|
78		-\| CPTRA_OWNER_PK_HASH \| 384 \| Owner ECC and LMS or MLDSA Public Key Hash \|
	83	+\| CPTRA_OWNER_PK_HASH \| 384 \| Owner ECC and LMS or MLDSA Public Key Hash. Stored as `[u32; 12]` — see [Public key hash byte ordering](#public-key-hash-byte-ordering-dword-reversal). \|
79	84
80	85
81	86	### Entropy Source Configuration Registers
@@ -159,7 +164,7 @@
159	164	\| Key Descriptor Version \| 2 \| Version of the Key Descriptor. The value must be 0x1 for Caliptra 2.x \|
160	165	\| Reserved \| 1 \| Reserved \|
161	166	\| Key Hash Count \| 1 \| Number of valid public key hashes \|
162		-\| Public Key Hash(es) \| 48 * n \| List of valid and invalid (if any) SHA2-384 public key hashes. ECDSA: n = 4 \|
	167	+\| Public Key Hash(es) \| 48 * n \| List of valid and invalid (if any) SHA2-384 public key hashes. ECDSA: n = 4. Each hash is stored in reversed-dword format (see [Public key hash byte ordering](#public-key-hash-byte-ordering-dword-reversal)). \|
163	168
164	169
165	170	#### PQC Manufacturer Public Key Descriptor
@@ -169,7 +174,7 @@
169	174	\| Key Descriptor Version \| 2 \| Version of the Key Descriptor. The value must be 0x1 for Caliptra 2.x \|
170	175	\| Key Type \| 1 \| Type of the key in the descriptor <br> 0x1 - MLDSA <br> 0x3 - LMS \|
171	176	\| Key Hash Count \| 1 \| Number of valid public key hashes \|
172		-\| Public Key Hash(es) \| 48 * n \| List of valid and invalid (if any) SHA2-384 public key hashes. LMS: n = 32, MLDSA: n = 4 \|
	177	+\| Public Key Hash(es) \| 48 * n \| List of valid and invalid (if any) SHA2-384 public key hashes. n = 32 for both LMS and MLDSA (the struct always allocates 32 slots; for MLDSA only the first 4 are populated and the rest are zero). Each hash is stored in reversed-dword format (see [Public key hash byte ordering](#public-key-hash-byte-ordering-dword-reversal)). \|
173	178
174	179
175	180	#### Header
@@ -380,10 +385,10 @@
380	385	\| Unlock Level \| 1 \| Debug unlock Level (Number 1-8). \|
381	386	\| Reserved \| 3 \| Reserved field. \|
382	387	\| Challenge \| 48 \| Random number sent in `AUTH_DEBUG_UNLOCK_CHALLENGE` mailbox command payload. \|
383		-\| ECC Public Key \| 96 \| ECC P-384 public key used to verify the Message Signature <br> X-Coordinate: Public Key X-Coordinate (48 bytes, big endian) <br> Y-Coordinate: Public Key Y-Coordinate (48 bytes, big endian) \|
384		-\| MLDSA Public Key \| 2592 \| MLDSA-87 public key used to verify the Message Signature. \|
385		-\| ECC Signature \| 96 \| ECC P-384 signature of the Message hashed using SHA2-384. <br> R-Coordinate: Random Point (48 bytes) <br> S-Coordinate: Proof (48 bytes). \|
386		-\| MLDSA Signature \| 4628 \| MLDSA signature of the Message hashed using SHA2-512. (4627 bytes + 1 Reserved byte). \|
	388	+\| ECC Public Key \| 96 \| ECC P-384 public key used to verify the Message Signature <br> X-Coordinate: Public Key X-Coordinate (48 bytes) <br> Y-Coordinate: Public Key Y-Coordinate (48 bytes). See [Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields). \|
	389	+\| MLDSA Public Key \| 2592 \| MLDSA-87 public key used to verify the Message Signature. See [Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields). \|
	390	+\| ECC Signature \| 96 \| ECC P-384 signature of the Message hashed using SHA2-384. <br> R-Coordinate: Random Point (48 bytes) <br> S-Coordinate: Proof (48 bytes). See [Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields). \|
	391	+\| MLDSA Signature \| 4628 \| MLDSA-87 signature of the Message hashed using SHA2-512 (4627 bytes + 1 Reserved byte). See [Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields). \|
387	392
388	393
389	394	7. On receiving this payload, ROM performs the following validations:
@@ -392,7 +397,7 @@
392	397	- Calculates the address of the public key hash fuse as follows: <br>
393	398	*SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET register value + ( (Debug Unlock Level - 1) SHA2-384 hash size (48 bytes) )**
394	399	- Retrieves the SHA2-384 hash (48 bytes) from the calculated address using DMA assist.
395		- - Computes the SHA2-384 hash of the message formed by concatenating the ECC and MLDSA public keys in the payload.
	400	+ - Computes the SHA2-384 hash of the message formed by concatenating the ECC and MLDSA public keys in the payload. See [Production debug unlock public key hashes: byte ordering](#production-debug-unlock-public-key-hashes-byte-ordering) for the exact byte order and fuse programming details.
396	401	- Compares the retrieved and computed hashes. It the comparison fails, the ROM blocks the debug unlock request by setting the registers outlined in step 3.
397	402	- Upon hash comparison failure, the ROM exits the payload validation flow and completes the mailbox command.
398	403
@@ -589,6 +594,105 @@
589	594	\| 🔒IDevID MLDSA Pub Key \|
590	595
591	596
	597	+#### UEID (Unique Endpoint Identifier)
	598	+
	599	+The UEID is a 17-byte identifier that is embedded (as an X.509 extension) in the
	600	+IDevID CSR, the LDevID certificate, and the FMC Alias certificate. Its value is
	601	+derived entirely from fuses.
	602	+
	603	+##### Source fuses
	604	+
	605	+The UEID is assembled from 5 consecutive 32-bit words of the
	606	+`FUSE_IDEVID_CERT_ATTR` fuse bank (see the [Fuse Registers](#fuse-registers)
	607	+table):
	608	+
	609	+\| Fuse word \| `IdevidCertAttr` variant \| Usage in UEID \|
	610	+\| ----------- \| ------------------------------- \| ----------------------------------------- \|
	611	+\| 11 \| `UeidType` \| UEID type byte (see RFC 9711 §4.2.1.1) \|
	612	+\| 12 \| `ManufacturerSerialNumber1` \| First 4 bytes of the endpoint serial \|
	613	+\| 13 \| `ManufacturerSerialNumber2` \| Next 4 bytes of the endpoint serial \|
	614	+\| 14 \| `ManufacturerSerialNumber3` \| Next 4 bytes of the endpoint serial \|
	615	+\| 15 \| `ManufacturerSerialNumber4` \| Last 4 bytes of the endpoint serial \|
	616	+
	617	+
	618	+Only the low byte of word 11 is used; the high 3 bytes of that word are
	619	+discarded. Each of the four serial-number words is written to the UEID buffer
	620	+in little-endian order (the natural byte order of the u32 register).
	621	+
	622	+##### Byte layout
	623	+
	624	+```
	625	+ byte 0 byte 1 ─ byte 4 byte 5 ─ byte 8 byte 9 ─ byte 12 byte 13 ─ byte 16
	626	+ ┌──────────┐ ┌────────────────┐ ┌────────────────┐ ┌─────────────────┐ ┌─────────────────┐
	627	+ │ UeidType │ │ MfgSerialNum1 │ │ MfgSerialNum2 │ │ MfgSerialNum3 │ │ MfgSerialNum4 │
	628	+ │ (byte 0) │ │ (LE u32) │ │ (LE u32) │ │ (LE u32) │ │ (LE u32) │
	629	+ └──────────┘ └────────────────┘ └────────────────┘ └─────────────────┘ └─────────────────┘
	630	+```
	631	+
	632	+This assembly is implemented in `caliptra_drivers::FuseBank::ueid` in
	633	+`drivers/src/fuse_bank.rs`, returning a `[u8; 17]`.
	634	+
	635	+##### Placement in the certificate / CSR
	636	+
	637	+The 17-byte UEID is placed in the TCG DICE "Ueid" X.509 extension (OID
	638	+`2.23.133.5.4.4`, not marked critical). The extension's `extnValue`
	639	+`OCTET STRING` contains a DER-encoded `SEQUENCE { ueid OCTET STRING }`, as
	640	+defined by the TCG DICE specification. The DER bytes written into the TBS
	641	+template are:
	642	+
	643	+\| DER bytes \| Meaning \|
	644	+\| --------------------------- \| --------------------------------------------------------- \|
	645	+\| `30 1F` \| `SEQUENCE`, length 31 — the `Extension` \|
	646	+\| `06 06 67 81 05 05 04 04` \| `OID 2.23.133.5.4.4` (`tcg-dice-Ueid`) \|
	647	+\| `04 15` \| `OCTET STRING`, length 21 — the `extnValue` wrapper \|
	648	+\| `30 13` \| inner `SEQUENCE`, length 19 — the `TcgUeid` structure \|
	649	+\| `04 11` \| inner `OCTET STRING`, length 17 — the UEID value \|
	650	+\| `XX XX … XX` (17 B) \| the 17 UEID bytes assembled above \|
	651	+
	652	+
	653	+The template slot for the 17 UEID bytes sits at a fixed offset in the TBS
	654	+template (e.g. `UEID_OFFSET = 312` for `InitDevIdCsrTbsEcc384`); the ROM copies
	655	+the UEID returned by `FuseBank::ueid` directly into that slot with no further
	656	+transformation. See `x509/gen/src/x509.rs::make_tcg_ueid_ext` for the generator
	657	+and `x509/build/*` for the resulting pre-baked templates.
	658	+
	659	+##### End-to-end example
	660	+
	661	+Given the following example fuse values (as programmed by the integration test
	662	+`cert_test_with_ueid` in `rom/dev/tests/rom_integration_tests/test_image_validation.rs`):
	663	+
	664	+\| Fuse word \| Field \| Value \|
	665	+\| ----------- \| -------------------------------- \| --------------- \|
	666	+\| 11 \| `UeidType` \| `0x0000_0001` \|
	667	+\| 12 \| `ManufacturerSerialNumber1` \| `0x0403_0201` \|
	668	+\| 13 \| `ManufacturerSerialNumber2` \| `0x0807_0605` \|
	669	+\| 14 \| `ManufacturerSerialNumber3` \| `0x0C0B_0A09` \|
	670	+\| 15 \| `ManufacturerSerialNumber4` \| `0x100F_0E0D` \|
	671	+
	672	+
	673	+Step-by-step:
	674	+
	675	+1. `FuseBank::ueid` reads the five fuse words and takes the low byte of word 11:
	676	+ `ueid_type = 0x01`.
	677	+2. Each serial-number word is converted to little-endian bytes:
	678	+ - `0x04030201 → 01 02 03 04`
	679	+ - `0x08070605 → 05 06 07 08`
	680	+ - `0x0C0B0A09 → 09 0A 0B 0C`
	681	+ - `0x100F0E0D → 0D 0E 0F 10`
	682	+3. The 17-byte UEID is:
	683	+ `01 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10`
	684	+ (byte 0 is the type; bytes 1–16 are the endpoint serial).
	685	+4. The UEID is wrapped in the DER framing shown above and emitted verbatim in
	686	+ the IDevID CSR, LDevID certificate, and FMC Alias certificate. The resulting
	687	+ bytes on the wire for the Ueid extension are:
	688	+ `30 1F 06 06 67 81 05 05 04 04 04 15 30 13 04 11 01 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10`.
	689	+
	690	+The `cert_test_with_ueid` test programs exactly these fuses, boots the ROM,
	691	+retrieves the IDevID ECC CSR, LDevID cert, and FMC Alias cert from the UART
	692	+log, and asserts that the hex-encoded bytes
	693	+`010102030405060708090A0B0C0D0E0F10` appear in all three — confirming both the
	694	+fuse-to-UEID assembly and the DER placement described here.
	695	+
592	696	### Local Device ID DICE layer
593	697
594	698	Local Device ID Layer derives the Owner CDI, ECC and MLDSA Keys. This layer represents the owner DICE Identity as it is mixed with the Field Entropy programmed by the Owner.
@@ -707,24 +811,63 @@
707	811
708	812	#### Handling commands from mailbox
709	813
710		-ROM supports the following set of commands before handling the FW_DOWNLOAD command in PASSIVE mode (described in section 9.6) or RI_DOWNLOAD_FIRMWARE command in SUBSYSTEM mode. Once the FW_DOWNLOAD or RI_DOWNLOAD_FIRMWARE is issued, ROM stops processing any additional mailbox commands.
711		-
712		-1. STASH_MEASUREMENT: Up to eight measurements can be sent to the ROM for recording. Sending more than eight measurements will result in an FW_PROC_MAILBOX_STASH_MEASUREMENT_MAX_LIMIT fatal error. Format of a measurement is documented at [Stash Measurement command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#stash_measurement).
713		-2. VERSION: Get version info about the module. [Version command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#version).
714		-3. SELF_TEST_START: This command is used to invoke the FIPS Known-Answer-Tests (aka KAT) on demand. [Self Test Start command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#self_test_start).
715		-4. SELF_TEST_GET_RESULTS: This command is used to check if a SELF_TEST command is in progress. [Self Test Get Results command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#self_test_get_results).
716		-5. SHUTDOWN: This command is used clear the hardware crypto blocks including the keyvault. [Shutdown command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#shutdown).
717		-6. CAPABILITIES: This command is used to query the ROM capabilities. Capabilities is a 128-bit value with individual bits indicating a specific capability. Currently, the only capability supported is ROM_BASE (bit 0). [Capabilities command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#capabilities).
718		-7. GET_IDEVID_CSR: This command is used to fetch the IDevID CSR from ROM. [Fetch IDevIDCSR command](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#get_idevid_csr).
719		-8. CM_DERIVE_STABLE_KEY: This command is used to derive a stable key for Device Ownership Transfer or other flows. Note that in Caliptra 2.0 in subsystem mode, derived stable keys, their derivatives, and commands using them will be marked with a FIPS status of invalid since the UDS and FE cannot be completely zeroized. See [CM_DERIVE_STABLE_KEY](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#cm_derive_stable_key).
720		-9. CM_HMAC: This command uses derived stable keys for Device Ownership Transfer or other flows. [CM_HMAC](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#cm_hmac)
721		-10. ECDSA384_SIGNATURE_VERIFY: This command verifies ECDSA384 signatures for Device Ownership Transfer or other flows. [ECDSA384_SIGNATURE_VERIFY](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#ecdsa384_signature_verify)
722		-11. MLDSA87_SIGNATURE_VERIFY: This command verifies MLDSA87 signatures for Device Ownership Transfer or other flows. [MLDSA87_SIGNATURE_VERIFY](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#mldsa87_signature_verify)
723		-12. CM_RANDOM_GENERATE: This command returns random numbers from Caliptra's RNG for Device Ownership Transfer or other flows. [CM_RANDOM_GENERATE](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime/README.md#cm_random_generate)
	814	+ROM supports the following set of commands before handling the FW_DOWNLOAD command in PASSIVE mode (described in section 9.6) or RI_DOWNLOAD_FIRMWARE/RI_DOWNLOAD_ENCRYPTED_FIRMWARE command in SUBSYSTEM mode. Once the FW_DOWNLOAD, RI_DOWNLOAD_FIRMWARE, or RI_DOWNLOAD_ENCRYPTED_FIRMWARE is issued, ROM stops processing any additional mailbox commands.
	815	+
	816	+1. STASH_MEASUREMENT: Up to eight measurements can be sent to the ROM for recording. Sending more than eight measurements will result in an FW_PROC_MAILBOX_STASH_MEASUREMENT_MAX_LIMIT fatal error. Format of a measurement is documented at [Stash Measurement command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#stash_measurement).
	817	+2. VERSION: Get version info about the module. [Version command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#version).
	818	+3. SELF_TEST_START: This command is used to invoke the FIPS Known-Answer-Tests (aka KAT) on demand. [Self Test Start command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#self_test_start).
	819	+4. SELF_TEST_GET_RESULTS: This command is used to check if a SELF_TEST command is in progress. [Self Test Get Results command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#self_test_get_results).
	820	+5. SHUTDOWN: This command is used clear the hardware crypto blocks including the keyvault. [Shutdown command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#shutdown).
	821	+6. CAPABILITIES: This command is used to query the ROM capabilities. Capabilities is a 128-bit value with individual bits indicating a specific capability. Capabilities are documented in the [Capabilities command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#capabilities).
	822	+7. GET_IDEVID_CSR: This command is used to fetch the IDevID CSR from ROM. [Fetch IDevIDCSR command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#get_idevid_csr).
	823	+8. CM_DERIVE_STABLE_KEY: This command is used to derive a stable key for Device Ownership Transfer or other flows. [CM_DERIVE_STABLE_KEY](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#cm_derive_stable_key)
	824	+9. CM_HMAC: This command uses derived stable keys for Device Ownership Transfer or other flows. [CM_HMAC](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#cm_hmac)
	825	+10. ECDSA384_SIGNATURE_VERIFY: This command verifies ECDSA384 signatures for Device Ownership Transfer or other flows. [ECDSA384_SIGNATURE_VERIFY](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#ecdsa384_signature_verify)
	826	+11. MLDSA87_SIGNATURE_VERIFY: This command verifies MLDSA87 signatures for Device Ownership Transfer or other flows. [MLDSA87_SIGNATURE_VERIFY](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#mldsa87_signature_verify)
	827	+12. CM_RANDOM_GENERATE: This command returns random numbers from Caliptra's RNG for Device Ownership Transfer or other flows. [CM_RANDOM_GENERATE](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#cm_random_generate)
724	828	13. CM_SHA: This ROM-only command (ROM 2.0.1+ only) computes a SHA-384 or SHA-512 hash of input data in a single operation. This is useful for MCU ROM to verify signatures and hashes against Vendor PK hash without needing its own hash implementation. Unlike the runtime CM_SHA_INIT/CM_SHA_UPDATE/CM_SHA_FINAL commands, this is a one-shot operation that does not support streaming or contexts. See [CM_SHA](#cm_sha) below for details.
725		-14. GET_LDEV_ECC384_CERT: This command fetches an LDevID ECC384 certificate signed by the ECC384 IDevID private key. [GET_LDEV_ECC384_CERT](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime#get_ldev_ecc384_cert)
726		-15. GET_LDEV_MLDSA87_CERT: This command fetches an LDevID MLDSA87 certificate signed by the MLDSA87 IDevID private key. [GET_LDEV_MLDSA87_CERT](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime#get_ldev_mldsa87_cert)
727		-16. INSTALL_OWNER_PK_HASH: This command saves the owner public key hash to persistent data. [INSTALL_OWNER_PK_HASH](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/runtime#install_owner_pk_hash)
	829	+14. GET_LDEV_ECC384_CERT: This command fetches an LDevID ECC384 certificate signed by the ECC384 IDevID private key. [GET_LDEV_ECC384_CERT](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime#get_ldev_ecc384_cert)
	830	+15. GET_LDEV_MLDSA87_CERT: This command fetches an LDevID MLDSA87 certificate signed by the MLDSA87 IDevID private key. [GET_LDEV_MLDSA87_CERT](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime#get_ldev_mldsa87_cert)
	831	+16. INSTALL_OWNER_PK_HASH: This command saves the owner public key hash to persistent data. [INSTALL_OWNER_PK_HASH](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime#install_owner_pk_hash)
	832	+17. OCP_LOCK_REPORT_HEK_METADATA: This command allows the MCU to report HEK seed state and metadata to the ROM, which determines if the HEK is available. See the [OCP LOCK specification](https://github.com/chipsalliance/Caliptra/blob/main/doc/ocp_lock/releases/OCP_LOCK_Specification_v1.0_RC2.pdf) for details.
	833	+18. ZEROIZE_UDS_FE
	834	+
	835	+Zeroizes (sets to 0xFFFFFFFF) the UDS (Unique Device Secret) and/or FE (Field Entropy) partitions in the OTP fuse controller. This command is typically used during device decommissioning or ownership transfer flows.
	836	+
	837	+The command accepts a flags field where each bit controls a specific partition. Multiple partitions can be zeroized in a single command by setting multiple flag bits.
	838	+
	839	+The zeroization process follows these steps for each partition:
	840	+1. Clears the zeroization marker first to mask potential ECC errors during power failures
	841	+2. Zeroizes the seed data
	842	+3. Clears the partition digest
	843	+
	844	+All operations are verified to return 0xFFFFFFFF before proceeding.
	845	+
	846	+Command Code: `0x5A45_5546` ("ZEUF")
	847	+
	848	+Table: `ZEROIZE_UDS_FE` input arguments
	849	+
	850	+\| Name \| Type \| Description
	851	+\| -------- \| -------- \| ---------------
	852	+\| chksum \| u32 \| Checksum over other input arguments, computed by the caller. Little endian.
	853	+\| flags \| u32 \| Partition flags. See ZEROIZE_UDS_FE_FLAGS below.
	854	+
	855	+Table: `ZEROIZE_UDS_FE_FLAGS` input flags
	856	+
	857	+\| Name \| Value \| Description
	858	+\| ------------------ \| --------- \| ---------------
	859	+\| ZEROIZE_UDS_FLAG \| 1 << 0 \| Zeroize UDS partition
	860	+\| ZEROIZE_FE0_FLAG \| 1 << 1 \| Zeroize FE partition 0
	861	+\| ZEROIZE_FE1_FLAG \| 1 << 2 \| Zeroize FE partition 1
	862	+\| ZEROIZE_FE2_FLAG \| 1 << 3 \| Zeroize FE partition 2
	863	+\| ZEROIZE_FE3_FLAG \| 1 << 4 \| Zeroize FE partition 3
	864	+
	865	+Table: `ZEROIZE_UDS_FE` output arguments
	866	+
	867	+\| Name \| Type \| Description
	868	+\| -------- \| -------- \| ---------------
	869	+\| chksum \| u32 \| Checksum over other output arguments, computed by Caliptra. Little endian.
	870	+\| dpe_result \| u32 \| Result code, 0 on success.
728	871
729	872	#### CM_SHA
730	873
@@ -740,7 +883,7 @@
740	883	\| -------------- \| ------------- \| ---------------
741	884	\| chksum \| u32 \| Checksum over other input arguments, computed by the caller. Little endian.
742	885	\| hash_algorithm \| u32 \| Hash algorithm: 1 = SHA-384, 2 = SHA-512. Value 0 is reserved and will return an error.
743		-\| input_size \| u32 \| Size of input data in bytes. Maximum 262,132 bytes (256 KB minus 12-byte header overhead).
	886	+\| input_size \| u32 \| Size of input data in bytes. Maximum 262,132 bytes (256 KB minus 12-byte header overhead) in passive mode, and 16,372 bytes in subsystem mode for 2.1 (16 KB minus overhead).
744	887	\| input \| u8[input_size]\| Input data to hash. Variable size up to the mailbox capacity.
745	888
746	889	Table: `CM_SHA` output arguments
@@ -769,7 +912,11 @@
769	912
770	913	Following is the sequence of steps that are performed to download the firmware image into the mailbox in SUBSYSTEM mode.
771	914
772		-1. On receiving the RI_DOWNLOAD_FIRMWARE mailbox command, set the RI PROT_CAP2 register version to 1.1 and the `Agent Capability` field bits:
	915	+ROM supports two commands for firmware download in SUBSYSTEM mode:
	916	+- RI_DOWNLOAD_FIRMWARE (Command Code: `0x5249_4644` / "RIFD"): Standard firmware download. After downloading and validating the firmware, the runtime will activate the MCU firmware immediately.
	917	+- RI_DOWNLOAD_ENCRYPTED_FIRMWARE (Command Code: `0x5249_4645` / "RIFE"): Encrypted firmware download. Sets the boot mode to `EncryptedFirmware`, which signals to the runtime that the MCU firmware is encrypted and should not be activated until it has been decrypted using the `CM_AES_GCM_DECRYPT_DMA` command.
	918	+
	919	+1. On receiving the RI_DOWNLOAD_FIRMWARE or RI_DOWNLOAD_ENCRYPTED_FIRMWARE mailbox command, set the RI PROT_CAP2 register version to 1.1 and the `Agent Capability` field bits:
773	920	- `Device ID`
774	921	- `Device Status`
775	922	- `Push C-image support`
@@ -1023,7 +1170,7 @@
1023	1170	- ICCM
1024	1171
1025	1172	### Launch FMC
1026		-The ROM initializes and populates the Firmware Handoff Table (FHT) to relay essential parameters to the FMC. The format of the FHT is documented [here](https://github.com/chipsalliance/caliptra-sw/blob/main-2.x/fmc/README.md#firmware-handoff-table). Upon successful population, the ROM transfers execution control to the FMC.
	1173	+The ROM initializes and populates the Firmware Handoff Table (FHT) to relay essential parameters to the FMC. The format of the FHT is documented [here](https://github.com/chipsalliance/caliptra-sw/blob/main/fmc/README.md#firmware-handoff-table). Upon successful population, the ROM transfers execution control to the FMC.
1027	1174
1028	1175	## Warm reset flow
1029	1176	ROM does not perform any DICE derivations or firmware validation during warm reset.
@@ -1136,11 +1283,12 @@
1136	1283	### Preamble validation: Manufacturing key validation
1137	1284
1138	1285	- fuse_ecc_revocation serves as the bitmask for revoking ECC keys.
1139		- - If bit-n is set, the nth key is disabled. All other higher bits that are zeros indicate the keys are still enabled.
	1286	+ - If bit-n is set, the nth key is disabled. All other bits that are zeros indicate the keys are still enabled.
1140	1287	- If all the bits are zeros, all ECC keys remain enabled.
1141	1288	- Ensure that the Active Key Index in the preamble is not disabled by the fuse_ecc_revocation fuse.
1142	1289	- If the key is disabled, the validation process fails.
1143		-- Repeat the above procedure for LMS or MLDSA keys using the fuse_lms_revocation or fuse_mldsa_revocation fuses, respectively, for key revocation.
	1290	+ - Note: The last key index is never revoked, regardless of the fuse value.
	1291	+- Repeat the above procedure for LMS or MLDSA keys using the fuse_lms_revocation or fuse_mldsa_revocation fuses, respectively, for key revocation. The last key index for PQC keys is also never revoked.
1144	1292
1145	1293	### Preamble validation: Validate the Owner key
1146	1294
@@ -1149,6 +1297,755 @@
1149	1297	- The validation process for owner public keys involves generating a SHA2-384 hash from the owner public keys within the preamble and comparing it to the hash stored in the fuse_owner_pk_hash register.
1150	1298	- If the computed hash matches the value in fuse_owner_pk_hash, the owner public keys are deemed valid.
1151	1299	- If there is a hash mismatch, the image validation process fails.
	1300	+
	1301	+### Public key hash byte ordering (dword reversal)
	1302	+
	1303	+Important: Hashes and ECC key coordinates stored in the firmware manifest and fuse registers use
	1304	+a reversed-dword format rather than the standard byte order defined by the SHA specification.
	1305	+
	1306	+In standard byte order, a SHA2-384 hash is a sequence of 48 bytes exactly as output by tools like
	1307	+OpenSSL or Python's `hashlib`. In reversed-dword format, the same 48 bytes are grouped into 12
	1308	+four-byte words (dwords) and the bytes within each dword are reversed.
	1309	+
	1310	+For example, if the standard SHA2-384 hash begins with `b1 7c a8 77 66 66 57 cc d1 00 e6 92 ...`:
	1311	+
	1312	+\| Standard byte order \| → \| Reversed-dword format \|
	1313	+\| ---------------------- \| --- \| ----------------------- \|
	1314	+\| `b1 7c a8 77` \|\| `77 a8 7c b1` \|
	1315	+\| `66 66 57 cc` \|\| `cc 57 66 66` \|
	1316	+\| `d1 00 e6 92` \|\| `92 e6 00 d1` \|
	1317	+\| ... \|\| ... \|
	1318	+
	1319	+
	1320	+This reversed-dword format applies to:
	1321	+- Individual public key hashes in the ECC and PQC key descriptors within the preamble
	1322	+- FUSE_VENDOR_PK_HASH and CPTRA_OWNER_PK_HASH fuse/register values (which are `[u32; 12]` arrays)
	1323	+- ECC public key coordinates (X and Y), which are stored as `[u32; 12]` arrays in the preamble
	1324	+
	1325	+Note: LMS public key fields (`tree_type`, `otstype`, `id`, `digest`) follow the LMS specification
	1326	+encoding and are not subject to dword reversal. MLDSA public keys are stored as raw byte arrays
	1327	+and are also not subject to dword reversal.
	1328	+
	1329	+For a detailed description of byte ordering conventions for all mailbox cryptographic fields
	1330	+(including ECC, ML-DSA, and SHA digest fields with OpenSSL examples), see the
	1331	+[Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields)
	1332	+section in the Runtime README.
	1333	+
	1334	+### Computing public key hashes: step-by-step example
	1335	+
	1336	+The following example walks through the computation of the vendor PK descriptor hash
	1337	+using the test public keys from `image/fake-keys/src/lib.rs` with PQC key type LMS (type 3).
	1338	+
	1339	+#### Step 1: Hash each vendor ECC public key
	1340	+
	1341	+Each ECC-384 public key has X and Y coordinates, each stored as `[u32; 12]`. To hash a key,
	1342	+serialize the struct to 96 bytes by writing each `u32` word in reversed-dword format, then
	1343	+compute SHA2-384 of those 96 bytes.
	1344	+
	1345	+ECC Key 0:
	1346	+```
	1347	+X (standard byte order): c69fe67f 97ea3e42 21a7a603 6c2e070d 1657327b c3f1e7c1
	1348	+ 8dccb9e4 ffda5c3f 4db0a1c0 567e0973 17bf4484 39696a07
	1349	+Y (standard byte order): c126b913 5fc82572 8f1cd403 19109430 994fe3e8 74a8b026
	1350	+ be14794d 27789964 7735fde8 328afd84 cd4d4aa8 72d40b42
	1351	+
	1352	+X (reversed-dword): 7fe69fc6 423eea97 03a6a721 0d072e6c 7b325716 c1e7f1c3
	1353	+ e4b9cc8d 3f5cdaff c0a1b04d 73097e56 8444bf17 076a6939
	1354	+Y (reversed-dword): 13b926c1 7225c85f 03d41c8f 30941019 e8e34f99 26b0a874
	1355	+ 4d7914be 64997827 e8fd3577 84fd8a32 a84a4dcd 420bd472
	1356	+
	1357	+Input to SHA384 = X_reversed \|\| Y_reversed (96 bytes)
	1358	+SHA384 (standard): 84facd34 227de869 1fbb7d33 49306e0f 250a3659 53a6cc6b
	1359	+ 629d4616 32f73cfd 768152bb 8a03a255 5a1b1f1f c3923faa
	1360	+SHA384 (reversed-dword): 34cdfa84 69e87d22 337dbb1f 0f6e3049 59360a25 6bcca653
	1361	+ 16469d62 fd3cf732 bb528176 55a2038a 1f1f1b5a aa3f92c3
	1362	+```
	1363	+
	1364	+ECC Key 1:
	1365	+```
	1366	+X (standard): a6309750 f0a05ddb 956a7f86 2812ec4f ec454e95 3b53dbfb
	1367	+ 9eb54140 15ea7507 084af93c b7fa33fe 51811ad5 e754232e
	1368	+Y (standard): ef5a5987 7a0ce0be 2621d2a9 8bf3c5df af7b3d6d 97f24183
	1369	+ a4a42038 58c39b86 272ef548 e572b937 1ecf1994 1b8d4ea7
	1370	+
	1371	+SHA384 (standard): fe89195f 7fab8ebb 2818d935 837493c2 378525ef 686ed220
	1372	+ 09b9a399 f23f1f42 2f5ae1f3 ba1c3083 1a68a456 9c01fc96
	1373	+SHA384 (reversed-dword): 5f1989fe bb8eab7f 35d91828 c2937483 ef258537 20d26e68
	1374	+ 99a3b909 421f3ff2 f3e15a2f 83301cba 56a4681a 96fc019c
	1375	+```
	1376	+
	1377	+ECC Key 2:
	1378	+```
	1379	+X (standard): a0d25693 c4251e48 185615b0 a6c27f6d e62c39f5 a9a32f75
	1380	+ 9553226a 4d1926c1 7928910f b7adc1b6 89996733 10134881
	1381	+Y (standard): bbdf72d7 07c08100 d54fcdad b1567bb0 0522762b 76b8dc4a
	1382	+ 846c175a 3fbd0501 9bdc8118 4be5f33c bb21b41d 93a8c523
	1383	+
	1384	+SHA384 (standard): f397ba45 b5801ddf b732078d ffdf792f b584a73f b055acaf
	1385	+ ef39f31d 5b88c7d5 2753a45a 0c76b098 90d8e335 7be87f26
	1386	+SHA384 (reversed-dword): 45ba97f3 df1d80b5 8d0732b7 2f79dfff 3fa784b5 afac55b0
	1387	+ 1df339ef d5c7885b 5aa45327 98b0760c 35e3d890 267fe87b
	1388	+```
	1389	+
	1390	+ECC Key 3:
	1391	+```
	1392	+X (standard): 002a82b6 8e03e9a0 fd3b4c14 ca2cb3e8 14350a71 0e43956d
	1393	+ 21694fb4 f34485e8 f0e33583 f7ea142d 50e16f8b 0225bb95
	1394	+Y (standard): 5802641c 7c45a4a2 408e03a6 a4100a92 50fcc468 d238cd0d
	1395	+ 449cc3e5 1abc25e7 0b05c426 843dcd6f 944ef6ff fa53ec5b
	1396	+
	1397	+SHA384 (standard): 8ba8acb6 b98da9dc 8ffce0bc eba86454 4acbbd6e 3f31466e
	1398	+ 5d532565 0bfc9e3b c8afb2b5 c33e20f5 06992143 83f33bc1
	1399	+SHA384 (reversed-dword): b6aca88b dca98db9 bce0fc8f 5464a8eb 6ebdcb4a 6e46313f
	1400	+ 6525535d 3b9efc0b b5b2afc8 f5203ec3 43219906 c13bf383
	1401	+```
	1402	+
	1403	+#### Step 2: Hash each vendor LMS public key
	1404	+
	1405	+Each LMS public key is a 48-byte struct: `tree_type` (u32), `otstype` (u32), `id` (16 bytes),
	1406	+`digest` (24 bytes). The binary serialization is hashed directly.
	1407	+
	1408	+LMS Key 0:
	1409	+```
	1410	+tree_type=0x0000000c, otstype=0x00000007
	1411	+id: 4908a17b cadb1829 1e289058 d5a8e3e8
	1412	+digest: 64ad3eb8 be6864f1 7ccda38b de35edaa 6c0da527 645407c6
	1413	+
	1414	+Serialized (48 bytes): 0000000c 00000007 4908a17b cadb1829 1e289058 d5a8e3e8
	1415	+ 64ad3eb8 be6864f1 7ccda38b de35edaa 6c0da527 645407c6
	1416	+SHA384 (standard): fc2c1b6f 56f732d1 fd876f3f ef757cbb a2b1c64b cc148298
	1417	+ d7508262 4bdf27cb 23d6b5b6 7169c46f 50b7fc19 92068fec
	1418	+SHA384 (reversed-dword): 6f1b2cfc d132f756 3f6f87fd bb7c75ef 4bc6b1a2 988214cc
	1419	+ 628250d7 cb27df4b b6b5d623 6fc46971 19fcb750 ec8f0692
	1420	+```
	1421	+
	1422	+LMS Key 1:
	1423	+```
	1424	+tree_type=0x0000000c, otstype=0x00000007
	1425	+id: 7cb5369d 64e4281d 046e977c 70d4d0a3
	1426	+digest: 8ea4701d adf7d700 0564b7d6 1d1c9587 9dd6475c 9c3aae0b
	1427	+
	1428	+SHA384 (standard): 7b5811fd 8d2b0cf8 9851f12d d2a7c239 f4f3abc5 d928dcc0
	1429	+ 3b4b891d abbdc67f c7b88436 432e1544 a408bc9c bb503f6b
	1430	+SHA384 (reversed-dword): fd11587b f80c2b8d 2df15198 39c2a7d2 c5abf3f4 c0dc28d9
	1431	+ 1d894b3b 7fc6bdab 3684b8c7 44152e43 9cbc08a4 6b3f50bb
	1432	+```
	1433	+
	1434	+LMS Key 2:
	1435	+```
	1436	+tree_type=0x0000000c, otstype=0x00000007
	1437	+id: 2bbb4b72 c5b41e05 d2fabe76 f41704bd
	1438	+digest: dcb53f96 24d4c7b3 c9ae4d4c 0e41e08e 3b159396 0fe6a277
	1439	+
	1440	+SHA384 (standard): 7e08a494 6933d35a 42c0d7b0 0236b10b db14c100 3f82f6a9
	1441	+ 7d401cb8 e420a7fa 5aab12b3 c4e96bec 49aec770 225a8f88
	1442	+SHA384 (reversed-dword): 94a4087e 5ad33369 b0d7c042 0bb13602 00c114db a9f6823f
	1443	+ b81c407d faa720e4 b312ab5a ec6be9c4 70c7ae49 888f5a22
	1444	+```
	1445	+
	1446	+LMS Key 3:
	1447	+```
	1448	+tree_type=0x0000000c, otstype=0x00000007
	1449	+id: 42cba2e5 575b5235 7ea7aead ef54074c
	1450	+digest: 5aa60e27 69251599 3ae8e21f 27ccdded 8ffcd3d2 8efbdec2
	1451	+
	1452	+SHA384 (standard): d3734fbc ee2893a3 b1b6519b 6ec78fb8 d7425327 cde1f7aa
	1453	+ 23012c64 c635219f d4ab1c4d 1b023252 00042884 2e463dbb
	1454	+SHA384 (reversed-dword): bc4f73d3 a39328ee 9b51b6b1 b88fc76e 275342d7 aaf7e1cd
	1455	+ 642c0123 9f2135c6 4d1cabd4 5232021b 84280400 bb3d462e
	1456	+```
	1457	+
	1458	+#### Step 3: Build the ECC key descriptor (196 bytes)
	1459	+
	1460	+Concatenate the 4-byte header with the 4 key hashes (each in reversed-dword format):
	1461	+
	1462	+```
	1463	+Header (4 bytes): 01 00 00 04 (version=1, reserved=0, key_hash_count=4)
	1464	+ECC key 0 hash (48 bytes, reversed-dword): 34cdfa84 69e87d22 ... aa3f92c3
	1465	+ECC key 1 hash (48 bytes, reversed-dword): 5f1989fe bb8eab7f ... 96fc019c
	1466	+ECC key 2 hash (48 bytes, reversed-dword): 45ba97f3 df1d80b5 ... 267fe87b
	1467	+ECC key 3 hash (48 bytes, reversed-dword): b6aca88b dca98db9 ... c13bf383
	1468	+
	1469	+Total: 4 + (4 × 48) = 196 bytes
	1470	+```
	1471	+
	1472	+#### Step 4: Build the PQC (LMS) key descriptor (1540 bytes)
	1473	+
	1474	+```
	1475	+Header (4 bytes): 01 00 03 20 (version=1, key_type=3=LMS, key_hash_count=32)
	1476	+LMS key 0 hash (48 bytes, reversed-dword): 6f1b2cfc d132f756 ... ec8f0692
	1477	+LMS key 1 hash (48 bytes, reversed-dword): fd11587b f80c2b8d ... 6b3f50bb
	1478	+LMS key 2 hash (48 bytes, reversed-dword): 94a4087e 5ad33369 ... 888f5a22
	1479	+LMS key 3 hash (48 bytes, reversed-dword): bc4f73d3 a39328ee ... bb3d462e
	1480	+ ... (keys 0-3 repeated 8 times to fill all 32 slots)
	1481	+
	1482	+Total: 4 + (32 × 48) = 1540 bytes
	1483	+```
	1484	+
	1485	+#### Step 5: Compute the vendor PK descriptor hash
	1486	+
	1487	+```
	1488	+Input = ECC descriptor (196 bytes) \|\| PQC descriptor (1540 bytes) = 1736 bytes
	1489	+
	1490	+SHA384 (standard byte order):
	1491	+ b17ca877 666657cc d100e692 6c7206b6 0c995cb6 8992c6c9
	1492	+ baefce72 8af05441 dee1ff41 5adfc187 e1e4edb4 d3b2d909
	1493	+
	1494	+As [u32; 12] fuse register value:
	1495	+ [0xb17ca877, 0x666657cc, 0xd100e692, 0x6c7206b6,
	1496	+ 0x0c995cb6, 0x8992c6c9, 0xbaefce72, 0x8af05441,
	1497	+ 0xdee1ff41, 0x5adfc187, 0xe1e4edb4, 0xd3b2d909]
	1498	+```
	1499	+
	1500	+### Computing public key hashes: MLDSA step-by-step example
	1501	+
	1502	+The following example walks through the same computation as the LMS example above, but
	1503	+using PQC key type MLDSA (type 1) with the test keys from `image/fake-keys/src/lib.rs`.
	1504	+
	1505	+#### MLDSA Step 1: Hash each vendor ECC public key
	1506	+
	1507	+The ECC keys and their hashes are identical to the LMS example — see
	1508	+[Step 1 above](#step-1-hash-each-vendor-ecc-public-key). The ECC key descriptor is
	1509	+independent of the PQC key type.
	1510	+
	1511	+#### MLDSA Step 2: Hash each vendor MLDSA public key
	1512	+
	1513	+Each MLDSA-87 public key is a 2592-byte array (`[u32; 648]`). When serialized via
	1514	+`as_bytes()`, each `u32` word is written in little-endian byte order — for example, the
	1515	+Rust value `0x3bf1c072` becomes bytes `72 c0 f1 3b` in memory. Unlike LMS keys, MLDSA
	1516	+keys are not subject to any additional encoding — these raw bytes are hashed directly
	1517	+with SHA2-384.
	1518	+
	1519	+MLDSA Key 0:
	1520	+```
	1521	+Size: 2592 bytes (648 u32 words)
	1522	+First 24 bytes: 72c0f13b 7d937e22 69b6988d 6daadc3a e78acd11 940cfc0d ...
	1523	+
	1524	+SHA384 (standard): f1097978 0adae470 dcd4eeb8 5749a2e4 2e70c055 ebac46e4
	1525	+ 07c2c404 b46473d8 189117ed 8c83dde4 9f941e6a 1b6c6d4c
	1526	+SHA384 (reversed-dword): 787909f1 70e4da0a b8eed4dc e4a24957 55c0702e e446aceb
	1527	+ 04c4c207 d87364b4 ed179118 e4dd838c 6a1e949f 4c6d6c1b
	1528	+```
	1529	+
	1530	+MLDSA Key 1:
	1531	+```
	1532	+Size: 2592 bytes (648 u32 words)
	1533	+First 24 bytes: f432346c 096d0ec9 04f8d925 1512236b e3fd1ccb bda9ed3a ...
	1534	+
	1535	+SHA384 (standard): a57b6f71 ffab9844 de49e9f7 ad61476b 7446e140 517d07b1
	1536	+ 81447acb a6d7166f 7b89f199 b6e36174 2d0ab01c 540d26de
	1537	+SHA384 (reversed-dword): 716f7ba5 4498abff f7e949de 6b4761ad 40e14674 b1077d51
	1538	+ cb7a4481 6f16d7a6 99f1897b 7461e3b6 1cb00a2d de260d54
	1539	+```
	1540	+
	1541	+MLDSA Key 2:
	1542	+```
	1543	+Size: 2592 bytes (648 u32 words)
	1544	+First 24 bytes: 2bc91a00 7d3e5a4f e6b3f2ec cb1aaa0d 278d9786 44b25fed ...
	1545	+
	1546	+SHA384 (standard): 7f2f3c55 e8dd2481 bbee17c1 5d5773a8 01a9c0a6 84b30e47
	1547	+ 0ae67ecd 1ec3e7ac 19273c71 feb6bb99 10d26dd0 4ace4298
	1548	+SHA384 (reversed-dword): 553c2f7f 8124dde8 c117eebb a873575d a6c0a901 470eb384
	1549	+ cd7ee60a ace7c31e 713c2719 99bbb6fe d06dd210 9842ce4a
	1550	+```
	1551	+
	1552	+MLDSA Key 3:
	1553	+```
	1554	+Size: 2592 bytes (648 u32 words)
	1555	+First 24 bytes: 378dcb02 a6db3481 d51e9913 14da1567 a211290e f4c3d02f ...
	1556	+
	1557	+SHA384 (standard): 79fbeb0a 6ebc354b ccf48dd1 5b6c9142 a62af0c5 198c0de1
	1558	+ 365fbcb0 b2463ee5 103ccae3 4504ab83 04b37886 5c9a28ae
	1559	+SHA384 (reversed-dword): 0aebfb79 4b35bc6e d18df4cc 42916c5b c5f02aa6 e10d8c19
	1560	+ b0bc5f36 e53e46b2 e3ca3c10 83ab0445 8678b304 ae289a5c
	1561	+```
	1562	+
	1563	+#### MLDSA Step 3: Build the ECC key descriptor (196 bytes)
	1564	+
	1565	+Same as the LMS example — the ECC descriptor is independent of PQC key type. See
	1566	+[Step 3 above](#step-3-build-the-ecc-key-descriptor-196-bytes).
	1567	+
	1568	+#### MLDSA Step 4: Build the PQC (MLDSA) key descriptor (1540 bytes)
	1569	+
	1570	+The PQC key descriptor struct always has 32 hash slots (`VENDOR_PQC_MAX_KEY_COUNT`).
	1571	+For MLDSA, only 4 keys are populated; the remaining 28 slots are zero-filled.
	1572	+
	1573	+```
	1574	+Header (4 bytes): 01 00 01 04 (version=1, key_type=1=MLDSA, key_hash_count=4)
	1575	+MLDSA key 0 hash (48 bytes, reversed-dword): 787909f1 70e4da0a ... 4c6d6c1b
	1576	+MLDSA key 1 hash (48 bytes, reversed-dword): 716f7ba5 4498abff ... de260d54
	1577	+MLDSA key 2 hash (48 bytes, reversed-dword): 553c2f7f 8124dde8 ... 9842ce4a
	1578	+MLDSA key 3 hash (48 bytes, reversed-dword): 0aebfb79 4b35bc6e ... ae289a5c
	1579	+ ... (keys 4-31 are zero-filled)
	1580	+
	1581	+Total: 4 + (32 × 48) = 1540 bytes
	1582	+```
	1583	+
	1584	+#### MLDSA Step 5: Compute the vendor PK descriptor hash
	1585	+
	1586	+```
	1587	+Input = ECC descriptor (196 bytes) \|\| PQC descriptor (1540 bytes) = 1736 bytes
	1588	+
	1589	+SHA384 (standard byte order):
	1590	+ 30399676 a17e3e97 3677b3ff 862f4bf2 d1932d88 4778453c
	1591	+ 376fe00d c93fb8aa 0770f3eb f3411a08 53e9c57e ce8a2980
	1592	+
	1593	+As [u32; 12] fuse register value:
	1594	+ [0x30399676, 0xa17e3e97, 0x3677b3ff, 0x862f4bf2,
	1595	+ 0xd1932d88, 0x4778453c, 0x376fe00d, 0xc93fb8aa,
	1596	+ 0x0770f3eb, 0xf3411a08, 0x53e9c57e, 0xce8a2980]
	1597	+```
	1598	+
	1599	+#### Owner PK hash
	1600	+
	1601	+The owner PK hash is SHA2-384 over the serialized `ImageOwnerPubKeys` struct, which contains:
	1602	+- `ecc_pub_key`: `{ x: [u32; 12], y: [u32; 12] }` — 96 bytes (in reversed-dword format)
	1603	+- `pqc_pub_key`: raw byte array of 2592 bytes (for LMS, only the first 48 bytes are meaningful;
	1604	+ the rest are zero-padded)
	1605	+
	1606	+Total: 2688 bytes. The SHA2-384 of these bytes is the owner PK hash.
	1607	+
	1608	+#### Summary of expected hash values using test keys
	1609	+
	1610	+Using the test keys from `image/fake-keys/src/lib.rs`:
	1611	+
	1612	+\| Hash \| PQC Type \| Standard byte order (hex) \|
	1613	+\| ------ \| ---------- \| --------------------------- \|
	1614	+\| Vendor PK descriptor hash \| LMS (type 3) \| `b17ca877666657ccd100e6926c7206b60c995cb68992c6c9baefce728af05441dee1ff415adfc187e1e4edb4d3b2d909` \|
	1615	+\| Vendor PK descriptor hash \| MLDSA (type 1) \| `30399676a17e3e973677b3ff862f4bf2d1932d884778453c376fe00dc93fb8aa0770f3ebf3411a0853e9c57ece8a2980` \|
	1616	+\| Owner PK hash \| LMS (type 3) \| `1b179390e4e6c44422ed553e256c7d675cd93190cb49d88d485aa4ef3906cd492ab3ee3d3ba5f2c990ad13390fed4de5` \|
	1617	+\| Owner PK hash \| MLDSA (type 1) \| `48afdb073c5e0d4ee46490468ef81f2cf57249b6e76a28f5fca4de696a7d3e2ed3efc4e6774318543e95307a54988bd7` \|
	1618	+
	1619	+
	1620	+To convert any of these standard byte order hashes to the `[u32; 12]` fuse register format, group
	1621	+the hex string into 8-character (4-byte) chunks and interpret each as a 32-bit word:
	1622	+- `b17ca877666657cc...` → `[0xb17ca877, 0x666657cc, 0xd100e692, ...]`
	1623	+
	1624	+#### Python script to compute vendor and owner PK hashes
	1625	+
	1626	+The following Python script computes the vendor PK descriptor hash and owner PK hash from
	1627	+ECC PEM files and LMS or MLDSA binary key files:
	1628	+
	1629	+```python
	1630	+#!/usr/bin/env python3
	1631	+"""
	1632	+Compute the Caliptra vendor PK descriptor hash and owner PK hash
	1633	+from ECC (.pem) and LMS/MLDSA (.bin) public key files.
	1634	+
	1635	+Usage:
	1636	+ python3 compute_pk_hashes.py --pqc-key-type <1\|3> \\
	1637	+ --vendor-ecc-pub-keys key0.pem key1.pem key2.pem key3.pem \\
	1638	+ --vendor-pqc-pub-keys pqc0.bin pqc1.bin ... \\
	1639	+ --owner-ecc-pub-key owner.pem \\
	1640	+ --owner-pqc-pub-key owner_pqc.bin
	1641	+
	1642	+PQC key type: 1 = MLDSA, 3 = LMS
	1643	+
	1644	+ECC public keys are PEM files (P-384).
	1645	+LMS public keys are 48-byte binary files (tree_type, otstype, id, digest).
	1646	+MLDSA public keys are 2592-byte binary files.
	1647	+"""
	1648	+import argparse
	1649	+import hashlib
	1650	+import struct
	1651	+import sys
	1652	+
	1653	+from cryptography.hazmat.primitives.serialization import load_pem_public_key
	1654	+
	1655	+# Sizes
	1656	+ECC_PUB_KEY_BYTES = 96 # 2 x 48-byte coordinates
	1657	+PQC_PUB_KEY_SLOT_BYTES = 2592 # MLDSA key size; LMS keys are 48 bytes, zero-padded
	1658	+LMS_PUB_KEY_BYTES = 48
	1659	+MLDSA_PUB_KEY_BYTES = 2592
	1660	+HASH_BYTES = 48 # SHA2-384
	1661	+
	1662	+VENDOR_ECC_MAX_KEYS = 4
	1663	+VENDOR_LMS_MAX_KEYS = 32
	1664	+VENDOR_MLDSA_MAX_KEYS = 32 # struct always allocates 32 slots; only first 4 are populated
	1665	+KEY_DESCRIPTOR_VERSION = 1
	1666	+
	1667	+
	1668	+def ecc_pub_key_to_reversed_dwords(pem_path: str) -> bytes:
	1669	+ """Read an ECC P-384 PEM public key and return 96 bytes in reversed-dword format."""
	1670	+ with open(pem_path, 'rb') as f:
	1671	+ pub_key = load_pem_public_key(f.read())
	1672	+ nums = pub_key.public_numbers()
	1673	+ x_bytes = nums.x.to_bytes(48, 'big')
	1674	+ y_bytes = nums.y.to_bytes(48, 'big')
	1675	+ return to_reversed_dwords(x_bytes) + to_reversed_dwords(y_bytes)
	1676	+
	1677	+
	1678	+def to_reversed_dwords(standard_bytes: bytes) -> bytes:
	1679	+ """Convert bytes from standard byte order to reversed-dword format.
	1680	+
	1681	+ Groups the input into 4-byte dwords and reverses the bytes within each dword.
	1682	+ """
	1683	+ assert len(standard_bytes) % 4 == 0
	1684	+ result = bytearray()
	1685	+ for i in range(0, len(standard_bytes), 4):
	1686	+ result.extend(standard_bytes[i:i+4][::-1])
	1687	+ return bytes(result)
	1688	+
	1689	+
	1690	+def sha384_reversed_dwords(data: bytes) -> bytes:
	1691	+ """Compute SHA2-384 and return the hash in reversed-dword format."""
	1692	+ h = hashlib.sha384(data).digest()
	1693	+ return to_reversed_dwords(h)
	1694	+
	1695	+
	1696	+def build_ecc_key_descriptor(ecc_pem_paths: list) -> bytes:
	1697	+ """Build the ECC key descriptor: header + key hashes."""
	1698	+ n = len(ecc_pem_paths)
	1699	+ header = struct.pack('<HBB', KEY_DESCRIPTOR_VERSION, 0, n)
	1700	+ hashes = b''
	1701	+ for path in ecc_pem_paths:
	1702	+ key_bytes = ecc_pub_key_to_reversed_dwords(path)
	1703	+ hashes += sha384_reversed_dwords(key_bytes)
	1704	+ # Pad to VENDOR_ECC_MAX_KEYS slots
	1705	+ hashes += b'\x00' * (HASH_BYTES * (VENDOR_ECC_MAX_KEYS - n))
	1706	+ return header + hashes
	1707	+
	1708	+
	1709	+def build_pqc_key_descriptor(pqc_bin_paths: list, pqc_key_type: int) -> bytes:
	1710	+ """Build the PQC key descriptor: header + key hashes."""
	1711	+ n = len(pqc_bin_paths)
	1712	+ max_keys = VENDOR_LMS_MAX_KEYS if pqc_key_type == 3 else VENDOR_MLDSA_MAX_KEYS
	1713	+ header = struct.pack('<HBB', KEY_DESCRIPTOR_VERSION, pqc_key_type, n)
	1714	+ hashes = b''
	1715	+ for path in pqc_bin_paths:
	1716	+ with open(path, 'rb') as f:
	1717	+ key_bytes = f.read()
	1718	+ hashes += sha384_reversed_dwords(key_bytes)
	1719	+ # Pad to max slots
	1720	+ hashes += b'\x00' * (HASH_BYTES * (max_keys - n))
	1721	+ return header + hashes
	1722	+
	1723	+
	1724	+def build_owner_pub_keys(ecc_pem_path: str, pqc_bin_path: str) -> bytes:
	1725	+ """Build the serialized ImageOwnerPubKeys struct."""
	1726	+ ecc_bytes = ecc_pub_key_to_reversed_dwords(ecc_pem_path)
	1727	+ with open(pqc_bin_path, 'rb') as f:
	1728	+ pqc_bytes = f.read()
	1729	+ # Pad PQC key to full slot size
	1730	+ pqc_padded = pqc_bytes + b'\x00' * (PQC_PUB_KEY_SLOT_BYTES - len(pqc_bytes))
	1731	+ return ecc_bytes + pqc_padded
	1732	+
	1733	+
	1734	+def hash_to_fuse_words(standard_hash: bytes) -> list:
	1735	+ """Convert a standard byte order hash to [u32; 12] fuse word format."""
	1736	+ return [int.from_bytes(standard_hash[i:i+4], 'big') for i in range(0, 48, 4)]
	1737	+
	1738	+
	1739	+def main():
	1740	+ parser = argparse.ArgumentParser(
	1741	+ description='Compute Caliptra vendor PK descriptor hash and owner PK hash')
	1742	+ parser.add_argument('--pqc-key-type', type=int, required=True, choices=[1, 3],
	1743	+ help='PQC key type: 1=MLDSA, 3=LMS')
	1744	+ parser.add_argument('--vendor-ecc-pub-keys', nargs='+', required=True,
	1745	+ help='Vendor ECC P-384 public key PEM files')
	1746	+ parser.add_argument('--vendor-pqc-pub-keys', nargs='+', required=True,
	1747	+ help='Vendor PQC (LMS .bin or MLDSA .bin) public key files')
	1748	+ parser.add_argument('--owner-ecc-pub-key',
	1749	+ help='Owner ECC P-384 public key PEM file')
	1750	+ parser.add_argument('--owner-pqc-pub-key',
	1751	+ help='Owner PQC (LMS .bin or MLDSA .bin) public key file')
	1752	+ args = parser.parse_args()
	1753	+
	1754	+ pqc_name = {1: 'MLDSA', 3: 'LMS'}[args.pqc_key_type]
	1755	+
	1756	+ # Build descriptors
	1757	+ ecc_desc = build_ecc_key_descriptor(args.vendor_ecc_pub_keys)
	1758	+ pqc_desc = build_pqc_key_descriptor(args.vendor_pqc_pub_keys, args.pqc_key_type)
	1759	+ vendor_pub_key_info = ecc_desc + pqc_desc
	1760	+
	1761	+ # Vendor PK descriptor hash (standard byte order)
	1762	+ vendor_hash = hashlib.sha384(vendor_pub_key_info).digest()
	1763	+ vendor_hex = vendor_hash.hex()
	1764	+ vendor_words = hash_to_fuse_words(vendor_hash)
	1765	+
	1766	+ print(f"PQC key type: {args.pqc_key_type} ({pqc_name})")
	1767	+ print()
	1768	+ print(f"Vendor PK descriptor hash (standard byte order):")
	1769	+ print(f" {vendor_hex}")
	1770	+ print(f"Vendor PK descriptor hash (fuse [u32; 12]):")
	1771	+ print(f" {['0x{:08x}'.format(w) for w in vendor_words]}")
	1772	+
	1773	+ if args.owner_ecc_pub_key and args.owner_pqc_pub_key:
	1774	+ owner_bytes = build_owner_pub_keys(args.owner_ecc_pub_key, args.owner_pqc_pub_key)
	1775	+ owner_hash = hashlib.sha384(owner_bytes).digest()
	1776	+ owner_hex = owner_hash.hex()
	1777	+ owner_words = hash_to_fuse_words(owner_hash)
	1778	+
	1779	+ print()
	1780	+ print(f"Owner PK hash (standard byte order):")
	1781	+ print(f" {owner_hex}")
	1782	+ print(f"Owner PK hash (fuse [u32; 12]):")
	1783	+ print(f" {['0x{:08x}'.format(w) for w in owner_words]}")
	1784	+
	1785	+
	1786	+if __name__ == '__main__':
	1787	+ main()
	1788	+```
	1789	+
	1790	+### Fuse value byte ordering
	1791	+
	1792	+This section documents the byte ordering convention for every multi-word fuse
	1793	+register. It uses the same style as the
	1794	+[Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields)
	1795	+section in the Runtime README: examples show the relationship between standard
	1796	+tool output (e.g. OpenSSL, Python `hashlib`) and the `u32` word values written
	1797	+to fuse registers.
	1798	+
	1799	+> When adding a new multi-word fuse, add an entry to the appropriate
	1800	+> category below so that SoC integrators have a single reference for all fuse
	1801	+> byte ordering.
	1802	+
	1803	+#### SHA digest fuses (big-endian words / reversed-dword)
	1804	+
	1805	+The following fuse registers store SHA digest values as `[u32; N]` arrays using
	1806	+the same reversed-dword format described in
	1807	+[Public key hash byte ordering](#public-key-hash-byte-ordering-dword-reversal).
	1808	+Each 4-byte group from the standard hash output (as produced by `openssl dgst`
	1809	+or Python's `hashlib`) is byte-reversed when stored as a `u32` word.
	1810	+
	1811	+\| Fuse Register \| Array Type \| Hash Algorithm \|
	1812	+\| --- \| --- \| --- \|
	1813	+\| FUSE_VENDOR_PK_HASH \| `[u32; 12]` \| SHA2-384 of vendor public key descriptors \|
	1814	+\| FUSE_MANUF_DEBUG_UNLOCK_TOKEN \| `[u32; 16]` \| SHA-512 of the manufacturing debug unlock token \|
	1815	+
	1816	+
	1817	+Example — suppose `openssl dgst -sha512` produces a digest starting with:
	1818	+
	1819	+```
	1820	+openssl output: 86 9B A8 D5 AD 0F CF 82 02 E5 60 80 ...
	1821	+ ~~~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~
	1822	+Fuse register[0]: 0x869BA8D5 [1]: 0xAD0FCF82 [2]: 0x02E56080 ...
	1823	+```
	1824	+
	1825	+Each 4-byte group from the OpenSSL output maps directly to one fuse register
	1826	+word as a big-endian `u32` — the first byte of the group is the most-significant
	1827	+byte of the word.
	1828	+
	1829	+On the little-endian RISC-V bus the bytes within each register word appear
	1830	+reversed at byte addresses:
	1831	+
	1832	+```
	1833	+Fuse byte address: 0 1 2 3 4 5 6 7 8 9 A B ...
	1834	+Byte value: D5 A8 9B 86 82 CF 0F AD 80 60 E5 02 ...
	1835	+ ── register[0] ── ─── register[1] ── ── register[2] ──
	1836	+```
	1837	+
	1838	+##### Manufacturing debug unlock token: step-by-step
	1839	+
	1840	+1. Choose a 32-byte random secret (the raw token). This is what the SoC sends
	1841	+ over the mailbox to unlock debug.
	1842	+
	1843	+2. Compute SHA-512 of the raw token:
	1844	+ ```
	1845	+ $ printf '\xd8\x92\x2c\x55\x79\x2b\x73\x7f\x29\x13\xf3\xe5\xcb\xe6\x54\x75' \
	1846	+ '\x62\x52\x01\x6e\xae\xe9\x63\xa1\xdd\x4e\x75\x3a\xf7\x87\xf0\x96' \
	1847	+ \| openssl dgst -sha512 -binary \| xxd -p -c 64
	1848	+ 869ba8d5ad0fcf8202e560803281da659812ffa2fc28c2d5154cb645ee0c38ec
	1849	+ 4fd9dd8bb0be7deb193f625381383a91ab40bd920fcd9425919e63723c0bf7a8
	1850	+ ```
	1851	+
	1852	+3. Split into 4-byte groups and interpret each as a big-endian `u32` to get the
	1853	+ fuse word values:
	1854	+ ```
	1855	+ Fuse [u32; 16] = {
	1856	+ 0x869BA8D5, 0xAD0FCF82, 0x02E56080, 0x3281DA65,
	1857	+ 0x9812FFA2, 0xFC28C2D5, 0x154CB645, 0xEE0C38EC,
	1858	+ 0x4FD9DD8B, 0xB0BE7DEB, 0x193F6253, 0x81383A91,
	1859	+ 0xAB40BD92, 0x0FCD9425, 0x919E6372, 0x3C0BF7A8,
	1860	+ }
	1861	+ ```
	1862	+
	1863	+4. MCU or SoC manager writes these 16 words into the `FUSE_MANUF_DEBUG_UNLOCK_TOKEN` registers from fuses.
	1864	+
	1865	+#### Architectural register: CPTRA_OWNER_PK_HASH (big-endian words)
	1866	+
	1867	+CPTRA_OWNER_PK_HASH (`[u32; 12]`) uses the same reversed-dword format as
	1868	+FUSE_VENDOR_PK_HASH. See
	1869	+[Public key hash byte ordering](#public-key-hash-byte-ordering-dword-reversal)
	1870	+for details and worked examples.
	1871	+
	1872	+##### Production debug unlock public key hashes: byte ordering
	1873	+
	1874	+The production debug unlock flow uses SHA2-384 hashes of the concatenated
	1875	+ECC and MLDSA public keys to authenticate debug unlock tokens. These hashes
	1876	+are stored in the MCI register bank at addresses computed from
	1877	+`SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET`.
	1878	+
	1879	+Hash input construction:
	1880	+
	1881	+The hash is SHA2-384 over the raw mailbox wire bytes of the concatenated
	1882	+ECC and MLDSA public keys from the `AUTH_DEBUG_UNLOCK_TOKEN` payload.
	1883	+The mailbox wire format for each key type is:
	1884	+
	1885	+- ECC public key (96 bytes): Each 4-byte group of the X and Y
	1886	+ coordinates is dword-reversed from the standard OpenSSL output.
	1887	+
	1888	+ ```
	1889	+ openssl ec output: AB CD EF 01 23 45 67 89 ... (X, 48 bytes)
	1890	+ 11 22 33 44 55 66 77 88 ... (Y, 48 bytes)
	1891	+
	1892	+ Hash input (= mailbox wire bytes):
	1893	+ 01 EF CD AB 89 67 45 23 ... (X, dword-reversed)
	1894	+ 44 33 22 11 88 77 66 55 ... (Y, dword-reversed)
	1895	+ ```
	1896	+
	1897	+- MLDSA public key (2592 bytes): The native MLDSA key bytes are
	1898	+ used as-is — no conversion.
	1899	+
	1900	+ ```
	1901	+ MLDSA keygen output: 72 C0 F1 3B 7D 93 7E 22 ...
	1902	+
	1903	+ Hash input (= mailbox wire bytes):
	1904	+ 72 C0 F1 3B 7D 93 7E 22 ... (identical)
	1905	+ ```
	1906	+
	1907	+To compute the same hash offline for fuse provisioning, reconstruct the
	1908	+mailbox wire bytes: dword-reverse the ECC coordinates, keep MLDSA native,
	1909	+concatenate, and hash:
	1910	+
	1911	+```
	1912	+ECC dword-reversed: 01 EF CD AB 89 67 45 23 ... (96 bytes)
	1913	+MLDSA native: 72 C0 F1 3B 7D 93 7E 22 ... (2592 bytes)
	1914	+
	1915	+hash_input = ECC_dword_reversed \|\| MLDSA_native_bytes (2688 bytes)
	1916	+
	1917	+$ openssl dgst -sha384 -binary combined.bin \| xxd -p -c 48
	1918	+→ 3f7a2b91c4e8d0f5...
	1919	+```
	1920	+
	1921	+Provisioning: OpenSSL example
	1922	+
	1923	+To prepare `combined_keys.bin`, dword-reverse the ECC raw coordinates
	1924	+and concatenate with the native MLDSA key bytes. Then compute the hash:
	1925	+
	1926	+```
	1927	+$ openssl dgst -sha384 -binary combined_keys.bin \| xxd -p -c 48
	1928	+3f7a2b91c4e8d0f5a1b2c3d4e5f60718293a4b5c6d7e8f90a0b1c2d3e4f5061728394a5b6c
	1929	+```
	1930	+
	1931	+Map the digest output to fuse register words — each 4-byte group becomes
	1932	+one `u32` fuse word (same convention as all other SHA digest fuses):
	1933	+
	1934	+```
	1935	+openssl output: 3f 7a 2b 91 c4 e8 d0 f5 a1 b2 c3 d4 ...
	1936	+ ~~~~~~~~~~~ ~~~~~~~~~~~ ~~~~~~~~~~~
	1937	+Fuse word[0]: 0x3F7A2B91 [1]: 0xC4E8D0F5 [2]: 0xA1B2C3D4 ...
	1938	+```
	1939	+
	1940	+Write these 12 words to the MCI register bank at offset:
	1941	+
	1942	+```
	1943	+SS_PROD_DEBUG_UNLOCK_AUTH_PK_HASH_REG_BANK_OFFSET + ((level - 1) * 48)
	1944	+```
	1945	+
	1946	+Mailbox payload: preparing fields from OpenSSL output
	1947	+
	1948	+The `AUTH_DEBUG_UNLOCK_TOKEN` mailbox command fields use the byte order
	1949	+conventions described in
	1950	+[Byte order of cryptographic fields](../../runtime/README.md#byte-order-of-cryptographic-fields).
	1951	+The table below summarizes how to convert OpenSSL tool output into the
	1952	+mailbox payload bytes for each field:
	1953	+
	1954	+- ECC P-384 public key (big-endian words): Extract the raw X and Y
	1955	+ coordinates (48 bytes each) from the PEM key, then dword-reverse
	1956	+ each 4-byte group before writing to the mailbox.
	1957	+
	1958	+ ```
	1959	+ # Extract raw X\|\|Y from PEM (96 bytes, big-endian):
	1960	+ $ openssl ec -pubin -in key.pem -outform DER 2>/dev/null \
	1961	+ \| tail -c 96 \| xxd -p -c 48
	1962	+
	1963	+ OpenSSL raw bytes: AB CD EF 01 23 45 67 89 ... (X, 48 bytes)
	1964	+ 11 22 33 44 55 66 77 88 ... (Y, 48 bytes)
	1965	+
	1966	+ Mailbox bytes: 01 EF CD AB 89 67 45 23 ... (X, dword-reversed)
	1967	+ 44 33 22 11 88 77 66 55 ... (Y, dword-reversed)
	1968	+ ```
	1969	+
	1970	+- MLDSA-87 public key (little-endian words): Copy the raw key bytes
	1971	+ produced by an MLDSA implementation (e.g. OpenSSL 3.5+, `fips204` crate)
	1972	+ directly into the mailbox — no conversion needed.
	1973	+
	1974	+ ```
	1975	+ MLDSA key bytes: 72 C0 F1 3B 7D 93 7E 22 ... (2592 bytes)
	1976	+ Mailbox bytes: 72 C0 F1 3B 7D 93 7E 22 ... (identical)
	1977	+ ```
	1978	+
	1979	+- ECC P-384 signature (big-endian words): Same treatment as the public
	1980	+ key — dword-reverse each 4-byte group of the R and S coordinates.
	1981	+
	1982	+- MLDSA-87 signature (little-endian words): Copy raw signature bytes
	1983	+ directly — no conversion needed. The trailing byte (byte 4628) is
	1984	+ reserved and should be zero.
	1985	+
	1986	+Note: The hash used for fuse provisioning is computed over the exact
	1987	+same bytes that appear on the mailbox wire. There is no additional
	1988	+transformation — the SHA accelerator's internal endianness handling is
	1989	+transparent and produces `SHA384(wire_bytes)`. Therefore the provisioning
	1990	+hash and the runtime verification hash are both computed over
	1991	+`ECC_dword_reversed \|\| MLDSA_native`.
	1992	+
	1993	+#### SVN fuses (little-endian 128-bit bitmap)
	1994	+
	1995	+FUSE_FIRMWARE_SVN and FUSE_SOC_MANIFEST_SVN are 128-bit one-hot encoded bitmaps stored
	1996	+as `[u32; 4]`. These are not cryptographic values — the security version
	1997	+number equals the bit position of the highest set bit.
	1998	+
	1999	+The four words form a little-endian 128-bit integer: word\[0\] contains bits
	2000	+0–31, word\[1\] contains bits 32–63, and so on.
	2001	+
	2002	+Example — to program SVN 7, set bits 0 through 6:
	2003	+
	2004	+```
	2005	+FUSE_FIRMWARE_SVN[0] = 0x0000007F (bits 0-6 set)
	2006	+FUSE_FIRMWARE_SVN[1] = 0x00000000
	2007	+FUSE_FIRMWARE_SVN[2] = 0x00000000
	2008	+FUSE_FIRMWARE_SVN[3] = 0x00000000
	2009	+```
	2010	+
	2011	+Example — SVN 40 means bits 0 through 39 are set:
	2012	+
	2013	+```
	2014	+FUSE_FIRMWARE_SVN[0] = 0xFFFFFFFF (bits 0-31 set)
	2015	+FUSE_FIRMWARE_SVN[1] = 0x000000FF (bits 32-39 set)
	2016	+FUSE_FIRMWARE_SVN[2] = 0x00000000
	2017	+FUSE_FIRMWARE_SVN[3] = 0x00000000
	2018	+```
	2019	+
	2020	+#### Obfuscated seed fuses (big-endian words)
	2021	+
	2022	+FUSE_UDS_SEED (`[u32; 16]`), FUSE_FIELD_ENTROPY (`[u32; 8]`), and
	2023	+FUSE_HEK_SEED (`[u32; 8]`) are obfuscated secret values. They use the same
	2024	+big-endian word ordering as SHA digest fuses — each `u32` word maps to 4
	2025	+bytes in big-endian order.
	2026	+
	2027	+These values are consumed through an AES de-obfuscation step and are typically
	2028	+programmed by the manufacturing toolchain. If replicating values for test or
	2029	+simulation, use the same big-endian word convention when converting between byte
	2030	+arrays and `[u32; N]` arrays.
	2031	+
	2032	+#### Scalar and per-word fuses (no byte-ordering concern)
	2033	+
	2034	+The following fuse registers are single words or per-word indexed values with no
	2035	+multi-word byte ordering:
	2036	+
	2037	+\| Register \| Width \| Notes \|
	2038	+\| --- \| --- \| --- \|
	2039	+\| FUSE_ECC_REVOCATION \| 4 bits \| Bitmask \|
	2040	+\| FUSE_LMS_REVOCATION \| 32 bits \| Bitmask \|
	2041	+\| FUSE_MLDSA_REVOCATION \| 4 bits \| Bitmask \|
	2042	+\| FUSE_ANTI_ROLLBACK_DISABLE \| 1 bit \| Boolean \|
	2043	+\| FUSE_PQC_KEY_TYPE \| 2 bits \| One-hot encoded \|
	2044	+\| FUSE_SOC_STEPPING_ID \| 16 bits \| Scalar \|
	2045	+\| FUSE_SOC_MANIFEST_MAX_SVN \| 8 bits \| Scalar \|
	2046	+\| FUSE_IDEVID_CERT_ATTR \| 24 × u32 \| Per-word indexed; each word accessed individually \|
	2047	+\| FUSE_IDEVID_MANUF_HSM_ID \| 4 × u32 \| Opaque identifier, used as-is \|
	2048	+
1152	2049
1153	2050	## Preamble validation steps
1154	2051

Changes to ROM Specification