Diff: ROM Specification

@@ -1,26 +1,11 @@
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/cddb376171e1e39f16484b44965a68e93fcb461a/rom/dev/README.md" target="_blank">chipsalliance/caliptra-sw/rom/dev/README.md</a> @ <code>cddb376</code>
	2	+📄 Source: <a href="https://github.com/chipsalliance/caliptra-sw/blob/51ff0a89f169bbf8e06acb49b31db555e99fefb6/rom/dev/README.md" target="_blank">chipsalliance/caliptra-sw/rom/dev/README.md</a> @ <code>51ff0a8</code>
3	3	</div>
4	4
5	5
6	6	# Caliptra - ROM Specification v1.0
7	7
8		-## 1. Version History
9		-
10		-\| Date \| Version \| Description \|
11		-\| :--------- \| :------ \| :----------------------------------------------------------------------- \|
12		-\| 09/18/2022 \| 0.1 \| Document Created, Boot flow defined \|
13		-\| 12/30/2022 \| 0.1 \| Image Format Defined \|
14		-\| 12/15/2022 \| 0.3 \| Added Fuse & Register details \|
15		-\| 01/20/2023 \| 0.4 \| Added Certificate Details \|
16		-\| 02/20/2023 \| 0.5 \| Added Image Verification Details \|
17		-\| 03/01/2023 \| 0.5.1 \| Added Crypto Derivations \|
18		-\| 04/27/2023 \| 0.5.2 \| Added Runtime SVN bit clarification \|
19		-\| 08/15/2023 \| 0.9 \| Added LMS keys and signatures to image format \|
20		-\| 03/04/2024 \| 1.0 \| Final editorial fixes for specification completion \|
21		-
22		-
23		-## 2. Scope
	8	+## Scope
24	9
25	10	Caliptra is an open-source Hardware Root of Trust for Measurement (RTM). This document is the architecture specification
26	11	for Caliptra Read Only Memory Code (ROM). As an architecture specification for ROM, this document describes the
@@ -30,13 +15,15 @@
30	15	2. Describe ROM DICE Layering Architecture
31	16	3. Describe ROM functionality
32	17	4. Define ROM boot flows
	18	+
33	19	- Cold Reset Flow
34	20	- Warm Reset Flow
35	21	- Update Reset Flow
36	22	- Unknown/Spurious Reset Flow
	23	+
37	24	5. Cryptographic Derivations
38	25
39		-## 3. Glossary
	26	+## Glossary
40	27
41	28	\| Term \| Description \|
42	29	\| :------------------ \| :------------------------------------------------------------------------ \|
@@ -58,7 +45,7 @@
58	45	\| X509 \| Digital Certificate Standard \|
59	46
60	47
61		-## 4. FUSE & Architectural Registers
	48	+## Fuse and architectural registers
62	49
63	50	Following are the main FUSE & Architectural Registers used by the Caliptra ROM for DICE Derivations:
64	51
@@ -76,16 +63,16 @@
76	63	\| FUSE_RUNTIME_SVN \| 128 \| Runtime Security Version Number \|
77	64	\| FUSE_ANTI_ROLLBACK_DISABLE \| 1 \| Disable SVN checking for FMC & Runtime when bit is set \|
78	65	\| FUSE_IDEVID_CERT_ATTR \| 768 \| FUSE containing information for generating IDEVID CSR <br> Word 0: X509 Key Id Algorithm (2 bits) 1: SHA1, 2: SHA256, 2: SHA384, 3: Fuse <br> Word 1,2,3,4,5: Subject Key Id <br> Words 7,8: Unique Endpoint ID \|
79		-\| CPTRA_DBG_MANUF_SERVICE_REG \| 16 \| Manufacturing Services: <br> Bit 0: IDEVID CSR upload <br> Bit 1: Random Number Generator Unavailable <br> Bit 31: Fake ROM image verify enable \|
80		-
81		-
82		-## 5. Firmware Image Bundle
	66	+\| CPTRA_DBG_MANUF_SERVICE_REG \| 16 \| Manufacturing Services: <br> Bit 0: IDEVID CSR upload <br> Bit 1: Random Number Generator Unavailable <br> Bit 15:8: FIPS test hook code <br> Bit 30: Fake ROM enable in production lifecycle mode <br> Bit 31: Fake ROM image verify enable \|
	67	+
	68	+
	69	+## Firmware image bundle
83	70
84	71	The Caliptra Firmware image has two main components:
85	72
86		-* ### Firmware Manifest
87		-
88		-* ### Firmware Images
	73	+- ### Firmware manifest
	74	+
	75	+- ### Firmware images
89	76
90	77	The firmware manifest is a combination of preamble and a signed header. It has
91	78	public keys, signatures and table of contents which refer to the various
@@ -93,18 +80,19 @@
93	80
94	81	![Firmware Image Bundle](../images/caliptra-sw/rom/dev/doc/svg/fw-img-bundle.svg)
95	82
96		-### 5.1 Firmware Manifest
	83	+### Firmware manifest
97	84
98	85	Firmware manifest consists of preamble, header and table of contents.
99	86
100		-#### 5.1.1 Preamble
	87	+#### Preamble
101	88
102	89	It is the unsigned portion of the manifest. Preamble contains the signing public keys and signatures. ROM is responsible for parsing the preamble. ROM performs the following steps:
103		-* Loads the preamble from the mailbox.
104		-* Calculates the hash of the four Manufacturer ECC and thirty-two LMS (if LMS verification is enabled) Public Keys in the preamble and compares it against the hash in the fuse (FUSE_KEY_MANIFEST_PK_HASH). If the hashes do not match, the boot fails.
105		-* Selects the appropriate Manufacturer Public Key(s) based on fuse (FUSE_KEY_MANIFEST_PK_HASH_MASK for ECC public key, FUSE_LMS_REVOCATION for LMS public key)
106		-
107		- Note: All fields are little endian unless specified
	90	+
	91	+- Loads the preamble from the mailbox.
	92	+- Calculates the hash of the four Manufacturer ECC and thirty-two LMS (if LMS verification is enabled) Public Keys in the preamble and compares it against the hash in the fuse (FUSE_KEY_MANIFEST_PK_HASH). If the hashes do not match, the boot fails.
	93	+- Selects the appropriate Manufacturer Public Key(s) based on fuse (FUSE_KEY_MANIFEST_PK_HASH_MASK for ECC public key, FUSE_LMS_REVOCATION for LMS public key)
	94	+
	95	+Note: All fields are little endian unless specified
108	96
109	97	\| Field \| Size (bytes) \| Description \|
110	98	\| ------- \| -------- \| ------------ \|
@@ -116,7 +104,7 @@
116	104	\| Manufacturer ECC Public Key 4 \| 96 \| ECC P-384 public key used to verify the Firmware Manifest Header Signature. <br> X-Coordinate: Public Key X-Coordinate (48 bytes) <br> Y-Coordinate: Public Key Y-Coordinate (48 bytes) \|
117	105	\| Manufacturer LMS Public Key 1 \| 48 \| LMS public key used to verify the Firmware Manifest Header Signature. <br> tree_type: LMS Algorithm Type (4 bytes) <br> otstype: LMS Ots Algorithm Type (4 bytes) <br> id: (16 bytes) <br> digest: (24 bytes) \|
118	106	\| Manufacturer LMS Public Key 2 \| 48 \| LMS public key used to verify the Firmware Manifest Header Signature. <br> tree_type: LMS Algorithm Type (4 bytes) <br> otstype: LMS Ots Algorithm Type (4 bytes) <br> id: (16 bytes) <br> digest: (24 bytes) \|
119		-\| ...<Manufacturer LMS Public Key 32> \|
	107	+\| ...<Manufacturer LMS Public Key 32> \|\|\|
120	108	\| ECC Public Key Index Hint \| 4 \| The hint to ROM to indicate which ECC public key it should first use. \|
121	109	\| LMS Public Key Index Hint \| 4 \| The hint to ROM to indicate which LMS public key it should first use. \|
122	110	\| Manufacturer ECC Signature \| 96 \| Manufacturer ECDSA P-384 signature of the Firmware Manifest header hashed using SHA2-384. <br> R-Coordinate: Random Point (48 bytes) <br> S-Coordinate: Proof (48 bytes) \|
@@ -129,7 +117,7 @@
129	117
130	118	<br>
131	119
132		-#### 5.1.2 Header
	120	+#### Header
133	121
134	122	The header contains the security version and SHA2-384 hash of the table of contents. Header is the only signed component in the image. Signing the header is enough as the table of contents contains the hashes of the individual firmware images. This technique reduces the number of signature verifications required to be performed during boot.
135	123
@@ -146,8 +134,8 @@
146	134	\| Owner Data \| 40 \| Owner Data. <br> Not Before: Owner Start Date [ASN1 Time Format] For LDEV-Id certificate. Takes preference over vendor start date (15 bytes) <br> Not After: Owner End Date [ASN1 Time Format] For LDEV-Id certificate. Takes preference over vendor end date (15 bytes) <br> Reserved: (10 bytes) \|
147	135
148	136
149		-
150		-#### 5.1.3 Table of Contents
	137	+#### Table of contents
	138	+
151	139	It contains the image information and SHA-384 hash of individual firmware images.
152	140	\| Field \| Size (bytes) \| Description \|
153	141	\| ------- \| -------- \| ------------ \|
@@ -164,15 +152,14 @@
164	152	\| Image Hash \| 48 \| SHA2-384 hash of image \|
165	153
166	154
167		-### 5.2 Image
	155	+### Image
168	156
169	157	\| Field \| Size (bytes) \| Description \|
170	158	\| ------- \| -------------- \| --------------- \|
171	159	\| Data \| N \| Image content \|
172	160
173	161
174		-
175		-## 6. Cryptographic Primitives
	162	+## Cryptographic primitives
176	163
177	164	The following sections define the various cryptographic primitives used by Caliptra ROM:
178	165
@@ -200,7 +187,7 @@
200	187
201	188	<br>
202	189
203		-## 7. Well Known Cryptographic Constants
	190	+## Well known cryptographic constants
204	191
205	192	\| Constant \| Size (bytes) \| Description \|
206	193	\| ---------- \| -------------- \| ------------- \|
@@ -208,7 +195,7 @@
208	195
209	196	<br>
210	197
211		-## 8. Cold Reset Flow
	198	+## Cold reset flow
212	199
213	200	![COLD RESET](../images/caliptra-sw/rom/dev/doc/svg/cold-reset.svg)
214	201
@@ -216,9 +203,10 @@
216	203
217	204	Note that KvSlot3 is generally used as a temporary location for derived keying material during ECC keygen.
218	205
219		-### 8.1 Initialization
	206	+### Initialization
220	207
221	208	The initialization step involves a traditional startup script for microcontroller. The initialization script performs following:
	209	+
222	210	- Resets instruction counter
223	211	- Disables interrupts
224	212	- Clears all general purpose registers
@@ -228,63 +216,68 @@
228	216	- Zeros ICCM & DCCM memories (to initialize ECC)
229	217	- Jumps to Rust entry point
230	218
231		-### 8.2 Decrypt Secrets
	219	+### Decrypt secrets
	220	+
232	221	DICE Unique Device Secret (UDS) is stored in an SOC backed fuse (or derived from PUF). The raw UDS is not directly used. UDS is deobfuscated using Deobfuscation Engine. UDS is provisioned by the Silicon Vendor.
233	222
234	223	Field Entropy is used to mitigate certain classes of supply chain attacks. Field Entropy is programmed by the owner of the device in a secure environment in the owner’s facility. Field Entropy programmed in fuses is not directly used. Field Entropy is put through the deobfuscation engine to randomize it.
235	224
236	225	Both UDS and Field Entropy are available only during cold reset of Caliptra.
237	226
238		-Pre-Conditions:
239		-* Caliptra subsystem is being cold reset
240		-* Obfuscation Key loaded in deobfuscation engine
241		-* UDS and Field Entropy loaded in Caliptra Fuse Registers
242		-* Keys Slot 0 - 31 are empty and Usage Bits are all cleared
243		-* PCR 0 - 31 are all cleared
244		-* Data Vault is all cleared
	227	+Pre-conditions:
	228	+
	229	+- Caliptra subsystem is being cold reset
	230	+- Obfuscation Key loaded in deobfuscation engine
	231	+- UDS and Field Entropy loaded in Caliptra Fuse Registers
	232	+- Keys Slot 0 - 31 are empty and Usage Bits are all cleared
	233	+- PCR 0 - 31 are all cleared
	234	+- Data Vault is all cleared
245	235
246	236	Actions:
247		-1. Decrypt UDS to Key Vault Slot 0
	237	+
	238	+1. Decrypt UDS to Key Vault Slot 0
248	239
249	240	`doe_decrypt_uds(KvSlot0, DOE_IV)`
250	241
251		-2. Decrypt Field Entropy to Key Vault Slot 1
252		-
253		- `doe_decrypt_uds(KvSlot1, DOE_IV)`
254		-
255		-3. Clear class secrets (Clears UDS, Field Entropy and Obfuscation Key cleared)
256		-
257		- `doe_clear_secrets()`
258		-
259		-Post-Conditions:
260		-* UDS Fuse Register and Field Entropy Fuse register cleared
261		-* Obfuscation Key cleared from Deobfuscation Engine
262		-* Vault State is as follows:
	242	+2. Decrypt Field Entropy to Key Vault Slot 1
	243	+
	244	+ `doe_decrypt_uds(KvSlot1, DOE_IV)`
	245	+
	246	+3. Clear class secrets (Clears UDS, Field Entropy and Obfuscation Key cleared)
	247	+
	248	+ `doe_clear_secrets()`
	249	+
	250	+Post-conditions:
	251	+
	252	+- UDS Fuse Register and Field Entropy Fuse register cleared
	253	+- Obfuscation Key cleared from Deobfuscation Engine
	254	+- Vault State is as follows:
263	255
264	256	\| Slot \| Key Vault \| PCR Bank \| Data Vault 48 Byte (Sticky) \| Data Vault 4 Byte (Sticky) \|
265	257	\| ------ \| ----------- \| ---------- \| ----------------------------- \| ---------------------------- \|
266		-\| 0 \| UDS (48 bytes) \|
267		-\| 1 \| Field Entropy (32 bytes) \|
268		-
269		-
270		-### 8.3 Initial Device ID DICE Layer
	258	+\| 0 \| UDS (48 bytes) \|\|\|\|
	259	+\| 1 \| Field Entropy (32 bytes) \|\|\|\|
	260	+
	261	+
	262	+### Initial Device ID DICE layer
271	263
272	264	Initial Device ID Layer is used to generate Manufacturer CDI & Private Key. This layer represents the manufacturer or silicon vendor DICE Identity. During manufacturing, ROM can be requested to create Certificate Signing Request (CSR) via JTAG.
273	265
274		-Pre-Conditions:
275		-* UDS is loaded in Key Vault Slot 0
	266	+Pre-conditions:
	267	+
	268	+- UDS is loaded in Key Vault Slot 0
276	269
277	270	Actions:
278	271
279		-1. Derive the CDI using ROM specified label and UDS in Slot 0 as data and store the resultant mac in KeySlot6
280		-
281		- `hmac384_kdf(KvSlot0, b"idevid_cdi", KvSlot6)`
282		-
283		-2. Clear the UDS in key vault
284		-
285		- `kv_clear(KvSlot0)`
286		-
287		-3. Derive ECC Key Pair using CDI in Key Vault Slot6 and store the generated private key in KeySlot7
	272	+1. Derive the CDI using ROM specified label and UDS in Slot 0 as data and store the resultant mac in KeySlot6
	273	+
	274	+ `hmac384_kdf(KvSlot0, b"idevid_cdi", KvSlot6)`
	275	+
	276	+2. Clear the UDS in key vault
	277	+
	278	+ `kv_clear(KvSlot0)`
	279	+
	280	+3. Derive ECC Key Pair using CDI in Key Vault Slot6 and store the generated private key in KeySlot7
288	281
289	282	`IDevIDSeed = hmac384_kdf(KvSlot6, b"idevid_keygen", KvSlot3)`
290	283	`IDevIdPubKey = ecc384_keygen(KvSlot3, KvSlot7)`
@@ -292,115 +285,120 @@
292	285
293	286	(Note: Steps 4-7 are performed if CSR download is requested via CPTRA_DBG_MANUF_SERVICE_REG register)
294	287
295		-4. Generate the `To Be Signed` DER Blob of the IDevId CSR
296		-
297		- `IDevIdTbs = gen_tbs(IDEVID_CSR, IDevIdPubKey)`
298		-
299		-5. Sign the IDevID `To Be Signed` DER Blob with IDevId Private Key in Key Vault Slot 7
300		-
301		- `IDevIdTbsDigest = sha384_digest(IDevIdTbs)`
302		- `IDevIdCertSig = ecc384_sign(KvSlot7, IDevIdTbsDigest)`
303		-
304		-6. Verify the signature of IDevID `To Be Signed` Blob
305		-
306		- `IDevIdTbsDigest = sha384_digest(IDevIdTbs)`
307		- `Result = ecc384_verify(IDevIdPubKey, IDevIdTbsDigest, IDevIdCertSig)`
308		-
309		-7. Upload the CSR to mailbox and wait for JTAG to read the CSR out of the mailbox.
310		-
311		-Post-Conditions:
312		-* Vault state as follows:
	288	+4. Generate the `To Be Signed` DER Blob of the IDevId CSR
	289	+
	290	+ `IDevIdTbs = gen_tbs(IDEVID_CSR, IDevIdPubKey)`
	291	+
	292	+5. Sign the IDevID `To Be Signed` DER Blob with IDevId Private Key in Key Vault Slot 7
	293	+
	294	+ `IDevIdTbsDigest = sha384_digest(IDevIdTbs)`
	295	+ `IDevIdCertSig = ecc384_sign(KvSlot7, IDevIdTbsDigest)`
	296	+
	297	+6. Verify the signature of IDevID `To Be Signed` Blob
	298	+
	299	+ `IDevIdTbsDigest = sha384_digest(IDevIdTbs)`
	300	+ `Result = ecc384_verify(IDevIdPubKey, IDevIdTbsDigest, IDevIdCertSig)`
	301	+
	302	+7. Upload the CSR to mailbox and wait for JTAG to read the CSR out of the mailbox.
	303	+
	304	+Post-conditions:
	305	+
	306	+- Vault state as follows:
313	307
314	308	\| Slot \| Key Vault \| PCR Bank \| Data Vault 48 Byte (Sticky) \| Data Vault 4 Byte (Sticky) \|
315	309	\| ------ \| ----------- \| ---------- \| ----------------------------- \| ---------------------------- \|
316		-\| 1 \| Field Entropy (32 bytes) \|
317		-\| 6 \| IDevID CDI (48 bytes) \|
318		-\| 7 \| IDevID Private Key (48 bytes) \|
319		-
320		-
321		-### 8.4 Local Device ID DICE Layer
	310	+\| 1 \| Field Entropy (32 bytes) \|\|\|\|
	311	+\| 6 \| IDevID CDI (48 bytes) \|\|\|\|
	312	+\| 7 \| IDevID Private Key (48 bytes) \|\|\|\|
	313	+
	314	+
	315	+### Local Device ID DICE layer
322	316
323	317	Local Device ID Layer derives the Owner CDI & ECC Keys. This layer represents the owner DICE Identity as it is mixed with the Field Entropy programmed by the Owner.
324	318
325		-Pre-Conditions:
326		-* Field Entropy is loaded in Key Vault Slot 1
327		-* IDevID CDI is stored in Key Vault Slot 6
328		-* IDevID Private Key is stored in Key Vault Slot 7
	319	+Pre-conditions:
	320	+
	321	+- Field Entropy is loaded in Key Vault Slot 1
	322	+- IDevID CDI is stored in Key Vault Slot 6
	323	+- IDevID Private Key is stored in Key Vault Slot 7
329	324
330	325	Actions:
331	326
332		-1. Derive the CDI using IDevID CDI in Key Vault Slot6 as HMAC Key and Field Entropy stored in Key Vault Slot1 as data. The resultant mac is stored back in Slot 6
	327	+1. Derive the CDI using IDevID CDI in Key Vault Slot6 as HMAC Key and Field Entropy stored in Key Vault Slot1 as data. The resultant mac is stored back in Slot 6
333	328
334	329	`hmac384_mac(KvSlot6, b"ldevid_cdi", KvSlot6)`
335		- `hmac384_mac(KvSlot6, KvSlot1, KvSlot6)`
	330	+ `hmac384_mac(KvSlot6, KvSlot1, KvSlot6)`
336	331
337	332	(Note: this uses a pair of HMACs to incorporate the diversification label, rather than a single KDF invocation, due to hardware limitations when passing KV data to the HMAC hardware as a message.)
338	333
339		-2. Clear the Field Entropy in Key Vault Slot 1
340		-
341		- `kv_clear(KvSlot1)`
342		-
343		-3. Derive ECC Key Pair using CDI in Key Vault Slot6 and store the generated private key in KeySlot5.
	334	+2. Clear the Field Entropy in Key Vault Slot 1
	335	+
	336	+ `kv_clear(KvSlot1)`
	337	+
	338	+3. Derive ECC Key Pair using CDI in Key Vault Slot6 and store the generated private key in KeySlot5.
344	339
345	340	`LDevIDSeed = hmac384_kdf(KvSlot6, b"ldevid_keygen", KvSlot3)`
346	341	`LDevIdPubKey = ecc384_keygen(KvSlot3, KvSlot5)`
347	342	`kv_clear(KvSlot3)`
348	343
349		-4. Store and lock (for write) the LDevID Public Key in Data Vault (48 bytes) Slot 2 & Slot 3
	344	+4. Store and lock (for write) the LDevID Public Key in Data Vault (48 bytes) Slot 2 and Slot 3
350	345
351	346	`dv48_store(LDevIdPubKey.X, Dv48Slot2)`
352	347	`dv48_lock_wr(Dv48Slot2)`
353	348	`dv48_store(LDevIdPubKey.Y, Dv48Slot3)`
354	349	`dv48_lock_wr(Dv48Slot3)`
355	350
356		-5. Generate the `To Be Signed` DER Blob of the LDevId Certificate
357		-
358		- `LDevIdTbs = gen_cert_tbs(LDEVID_CERT, IDevIdPubKey, LDevIdPubKey)`
359		-
360		-6. Sign the LDevID `To Be Signed` DER Blob with IDevId Private Key in Key Vault Slot 7
361		-
362		- `LDevIdTbsDigest = sha384_digest(LDevIdTbs)`
363		- `LDevIdCertSig = ecc384_sign(KvSlot7, LDevIdTbsDigest)`
364		-
365		-7. Clear the IDevId Private Key in Key Vault Slot 7
366		-
367		- `kv_clear(KvSlot7)`
368		-
369		-8. Verify the signature of LDevID `To Be Signed` Blob
370		-
371		- `LDevIdTbsDigest = sha384_digest(LDevIdTbs)`
372		- `Result = ecc384_verify(LDevIdPubKey, LDevIdTbsDigest, LDevIdCertSig)`
373		-
374		-9. Store and lock (for write) the LDevID Certificate Signature in the sticky Data Vault (48 bytes) Slot 0 & Slot 1
375		-
376		- `dv48_store(LDevIdCertSig.R, Dv48Slot0)`
	351	+5. Generate the `To Be Signed` DER Blob of the LDevId Certificate
	352	+
	353	+ `LDevIdTbs = gen_cert_tbs(LDEVID_CERT, IDevIdPubKey, LDevIdPubKey)`
	354	+
	355	+6. Sign the LDevID `To Be Signed` DER Blob with IDevId Private Key in Key Vault Slot 7
	356	+
	357	+ `LDevIdTbsDigest = sha384_digest(LDevIdTbs)`
	358	+ `LDevIdCertSig = ecc384_sign(KvSlot7, LDevIdTbsDigest)`
	359	+
	360	+7. Clear the IDevId Private Key in Key Vault Slot 7
	361	+
	362	+ `kv_clear(KvSlot7)`
	363	+
	364	+8. Verify the signature of LDevID `To Be Signed` Blob
	365	+
	366	+ `LDevIdTbsDigest = sha384_digest(LDevIdTbs)`
	367	+ `Result = ecc384_verify(LDevIdPubKey, LDevIdTbsDigest, LDevIdCertSig)`
	368	+
	369	+9. Store and lock (for write) the LDevID Certificate Signature in the sticky Data Vault (48 bytes) Slot 0 & Slot 1
	370	+
	371	+ `dv48_store(LDevIdCertSig.R, Dv48Slot0)`
377	372	`dv48_lock_wr(Dv48Slot0)`
378	373	`dv48_store(LDevIdCertSig.S, Dv48Slot1)`
379	374	`dv48_lock_wr(Dv48Slot1)`
380	375
381		-Post-Conditions:
382		-* Vault state as follows:
	376	+Post-conditions:
	377	+
	378	+- Vault state as follows:
383	379
384	380	\| Slot \| Key Vault \| PCR Bank \| Data Vault 48 Byte (Sticky) \| Data Vault 4 Byte (Sticky) \|
385	381	\| ------ \| ----------- \| ---------- \| ----------------------------- \| ---------------------------- \|
386		-\| 0 \|\|\| 🔒LDevID Cert Signature R \|
387		-\| 1 \|\|\| 🔒LDevID Cert Signature S \|
388		-\| 2 \|\|\| 🔒LDevID Pub Key X \|
389		-\| 3 \|\|\| 🔒LDevID Pub Key Y \|
390		-\| 5 \| LDevID Private Key (48 bytes) \|
391		-\| 6 \| LDevID CDI (48 bytes) \|
392		-
393		-
394		-### 8.5 Handling commands from Mailbox
	382	+\| 0 \|\|\| 🔒LDevID Cert Signature R \|\|
	383	+\| 1 \|\|\| 🔒LDevID Cert Signature S \|\|
	384	+\| 2 \|\|\| 🔒LDevID Pub Key X \|\|
	385	+\| 3 \|\|\| 🔒LDevID Pub Key Y \|\|
	386	+\| 5 \| LDevID Private Key (48 bytes) \|\|\|\|
	387	+\| 6 \| LDevID CDI (48 bytes) \|\|\|\|
	388	+
	389	+
	390	+### Handling commands from mailbox
	391	+
395	392	ROM supports the following set of commands before handling the FW_DOWNLOAD command (described in section 9.6). Once the FW_DOWNLOAD is issued, ROM stops processing any additional mailbox commands.
396		-1. STASH_MEASUREMENT: Up to eight measurements can be sent to the ROM for recording. Format of a measurement is documented at https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#stash_measurement
397		-2. VERSION: Get version info about the module. https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#version
398		-3. SELF_TEST_START: This command is used to invoke the FIPS Known-Answer-Tests (aka KAT) on demand. https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#self_test_start
399		-4. SELF_TEST_GET_RESULTS: This command is used to check if a SELF_TEST command is in progress. https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#self_test_get_results
400		-5. SHUTDOWN: This command is used clear the hardware crypto blocks including the keyvault. https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#shutdown
401		-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). https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#capabilities
402		-
403		-### 8.6 Downloading images from Mailbox
	393	+
	394	+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).
	395	+2. VERSION: Get version info about the module. [Version command](https://github.com/chipsalliance/caliptra-sw/blob/main/runtime/README.md#version).
	396	+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).
	397	+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).
	398	+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).
	399	+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/runtime/README.md#capabilities).
	400	+
	401	+### Downloading images from mailbox
404	402
405	403	The following is the sequence of the steps that are required to download the parts of firmware image from mailbox.
406	404
@@ -410,34 +408,35 @@
410	408	- Read the data length register and validate the value in it.
411	409	- Read N dwords from the mailbox DATAOUT register. Execute the command.
412	410	- Once the entire data is processed, clear the execute bit.
413		- - This should be the last step. Clearing this bit transfers the control back to the originator of the command.
	411	+ - This should be the last step. Clearing this bit transfers the control back to the originator of the command.
414	412	- On failure, a non-zero status code will be reported in the `CPTRA_FW_ERROR_NON_FATAL` register
415	413
416	414	![DATA FROM MBOX FLOW](../images/caliptra-sw/rom/dev/doc/svg/data-from-mbox.svg)
417	415
418		-### 8.7 Image Validation
419		-
420		-Refer to Firmware Image Validation Process
421		-
422		-### 8.8 Alias FMC DICE Layer & PCR extension
	416	+### Image validation
	417	+
	418	+See Firmware [Image Validation Process](#firmware-image-validation-process).
	419	+
	420	+### Alias FMC DICE layer & PCR extension
423	421
424	422	Alias FMC Layer includes the measurement of the FMC and other security states. This layer is used to assert a composite identity which includes the security state, FMC measurement along with the previous layer identities.
425	423
426		-Pre-Conditions:
427		-* LDevID CDI is stored in Key Vault Slot 6
428		-* LDevID Private Key is stored in Key Vault Slot 5
429		-* Firmware Image Bundle is successfully loaded and verified from the Mailbox
430		-* ROM has following information from Firmware Image Bundle
431		-* FMC_DIGEST - Digest of the FMC
432		-* FMC_SVN - SVN for FMC
433		-* MANUFACTURER_PK - Manufacturer Public Key(s) used to verify the firmware image bundle
434		-* MANUFACTURER_PK_INDEX - Index of the MANUFACTURER_PK in the firmware image bundle
	424	+Pre-conditions:
	425	+
	426	+- LDevID CDI is stored in Key Vault Slot 6
	427	+- LDevID Private Key is stored in Key Vault Slot 5
	428	+- Firmware Image Bundle is successfully loaded and verified from the Mailbox
	429	+- ROM has following information from Firmware Image Bundle
	430	+- FMC_DIGEST - Digest of the FMC
	431	+- FMC_SVN - SVN for FMC
	432	+- MANUFACTURER_PK - Manufacturer Public Key(s) used to verify the firmware image bundle
	433	+- MANUFACTURER_PK_INDEX - Index of the MANUFACTURER_PK in the firmware image bundle
435	434
436	435	Actions:
437	436
438		-1. PCR0 is the Current PCR. PCR 1 is the Journey PCR. PCR0 is cleared by ROM upon each cold and update resets, before it is extended with FMC measurements. PCR0 and PCR1 are locked for clear by the ROM on every reset. Subsequent layers may continue to extend PCR0 as runtime updates are performed.
439		-
440		- ```
	437	+1. PCR0 is the Current PCR. PCR 1 is the Journey PCR. PCR0 is cleared by ROM upon each cold and update resets, before it is extended with FMC measurements. PCR0 and PCR1 are locked for clear by the ROM on every reset. Subsequent layers may continue to extend PCR0 as runtime updates are performed.
	438	+
	439	+ ```text
441	440	pcr_clear(Pcr0)
442	441	pcr_extend(Pcr0 && Pcr1, [
443	442	CPTRA_SECURITY_STATE.LIFECYCLE_STATE,
@@ -456,43 +455,43 @@
456	455	pcr_lock_clear(Pcr0 && Pcr1)
457	456	```
458	457
459		-2. CDI for Alias is derived from PCR0. For the Alias FMC CDI Derivation, LDevID CDI in Key Vault Slot6 is used as HMAC Key and contents of PCR0 are used as data. The resultant mac is stored back in Slot 6
460		-
461		- `Pcr0Measurement = pcr_read(Pcr0)`
	458	+2. CDI for Alias is derived from PCR0. For the Alias FMC CDI Derivation, LDevID CDI in Key Vault Slot6 is used as HMAC Key and contents of PCR0 are used as data. The resultant mac is stored back in Slot 6.
	459	+
	460	+ `Pcr0Measurement = pcr_read(Pcr0)`
462	461	`hmac384_kdf(KvSlot6, b"fmc_alias_cdi", Pcr0Measurement, KvSlot6)`
463	462
464		-3. Derive Alias FMC ECC Key Pair using CDI in Key Vault Slot6 and store the generated private key in KeySlot7.
	463	+3. Derive Alias FMC ECC Key Pair using CDI in Key Vault Slot6 and store the generated private key in KeySlot7.
465	464
466	465	`AliasFmcSeed = hmac384_kdf(KvSlot6, b"fmc_alias_keygen", KvSlot3)`
467	466	`AliasFmcPubKey = ecc384_keygen(KvSlot3, KvSlot7)`
468	467	`kv_clear(KvSlot3)`
469	468
470		-4. Store and lock (for write) the FMC Public Key in Data Vault (48 bytes) Slot 6 & Slot 7
	469	+4. Store and lock (for write) the FMC Public Key in Data Vault (48 bytes) Slot 6 & Slot 7
471	470
472	471	`dv48_store(FmcPubKey.X, Dv48Slot6)`
473	472	`dv48_lock_wr(Dv48Slot6)`
474	473	`dv48_store(FmcPubKey.Y, Dv48Slot7)`
475	474	`dv48_lock_wr(Dv48Slot7)`
476	475
477		-5. Generate the `To Be Signed` DER Blob of the Alias FMC Certificate
478		-
479		- `AliasFmcTbs = gen_cert_tbs(ALIAS_FMC_CERT, LDevIdPubKey, AliasFmcPubKey)`
480		-
481		-6. Sign the Alias FMC `To Be Signed` DER Blob with LDevId Private Key in Key Vault Slot 5
482		-
483		- `AliasFmcTbsDigest = sha384_digest(AliasFmcTbs)`
484		- `AliasFmcTbsCertSig = ecc384_sign(KvSlot5, AliasFmcTbsDigest)`
485		-
486		-7. Clear the LDevId Private Key in Key Vault Slot 5
487		-
488		- `kv_clear(KvSlot5)`
489		-
490		-8. Verify the signature of Alias FMC `To Be Signed` Blob
491		-
492		- `AliasFmcTbsDigest = sha384_digest(AliasFmcTbs)`
493		- `Result = ecc384_verify(AliasFmcPubKey, AliasFmcDigest , AliasFmcTbsCertSig)`
494		-
495		-9. Store and lock (for write) the LDevID Certificate Signature in the sticky Data Vault (48 bytes) Slot 4 & Slot 5
	476	+5. Generate the `To Be Signed` DER Blob of the Alias FMC Certificate
	477	+
	478	+ `AliasFmcTbs = gen_cert_tbs(ALIAS_FMC_CERT, LDevIdPubKey, AliasFmcPubKey)`
	479	+
	480	+6. Sign the Alias FMC `To Be Signed` DER Blob with LDevId Private Key in Key Vault Slot 5
	481	+
	482	+ `AliasFmcTbsDigest = sha384_digest(AliasFmcTbs)`
	483	+ `AliasFmcTbsCertSig = ecc384_sign(KvSlot5, AliasFmcTbsDigest)`
	484	+
	485	+7. Clear the LDevId Private Key in Key Vault Slot 5
	486	+
	487	+ `kv_clear(KvSlot5)`
	488	+
	489	+8. Verify the signature of Alias FMC `To Be Signed` Blob
	490	+
	491	+ `AliasFmcTbsDigest = sha384_digest(AliasFmcTbs)`
	492	+ `Result = ecc384_verify(AliasFmcPubKey, AliasFmcDigest , AliasFmcTbsCertSig)`
	493	+
	494	+9. Store and lock (for write) the LDevID Certificate Signature in the sticky Data Vault (48 bytes) Slot 4 and Slot 5
496	495
497	496	`dv48_store(FmcTbsCertSig.R, Dv48Slot4)`
498	497	`dv48_lock_wr(Dv48Slot4)`
@@ -500,9 +499,9 @@
500	499	`dv48_store(FmcTbsCertSig.S, Dv48Slot5)`
501	500	`dv48_lock_wr(Dv48Slot5)`
502	501
503		-10. Lock critical state needed for warm and update reset in Data Vault
504		-
505		- `dv48_store(FMC_DIGEST, Dv48Slot8)`
	502	+10. Lock critical state needed for warm and update reset in Data Vault
	503	+
	504	+ `dv48_store(FMC_DIGEST, Dv48Slot8)`
506	505	`dv48_lock_wr(Dv48Slot8)`
507	506
508	507	`dv4_store(FMC_SVN, Dv4Slot0)`
@@ -522,9 +521,9 @@
522	521	`dv4_lock_wr(Dv4Slot1)`
523	522	Note: A value of 0x140 is stored on a successful cold boot.
524	523
525		-
526		-Post-Conditions:
527		-* Vault state as follows:
	524	+Post-conditions:
	525	+
	526	+- Vault state as follows:
528	527
529	528	\| Slot \| Key Vault \| Data Vault 48 Byte (Sticky) \| Data Vault 4 Byte (Sticky) \|
530	529	\| ------ \| ---------------------------------- \| ------------------------------- \| ---------------------------- \|
@@ -533,27 +532,27 @@
533	532	\| 2 \|\| 🔒LDevID Pub Key X \| 🔒FMC Entry Point \|
534	533	\| 3 \|\| 🔒LDevID Pub Key Y \| 🔒Manufacturer ECC Public Key Index \|
535	534	\| 4 \|\| 🔒Alias FMC Cert Signature R \| 🔒Manufacturer LMS Public Key Index \|
536		-\| 5 \|\| 🔒Alias FMC Cert Signature S \|
537		-\| 6 \| Alias FMC CDI (48 bytes) \| 🔒Alias FMC Pub Key X \|
538		-\| 7 \| Alias FMC Private Key (48 bytes) \| 🔒Alias FMC Pub Key Y \|
539		-\| 8 \|\| 🔒FMC Digest \|
540		-\| 9 \|\| 🔒Owner PK Hash \|
541		-
542		-
543		-## 9. Warm Reset Flow
	535	+\| 5 \|\| 🔒Alias FMC Cert Signature S \|\|
	536	+\| 6 \| Alias FMC CDI (48 bytes) \| 🔒Alias FMC Pub Key X \|\|
	537	+\| 7 \| Alias FMC Private Key (48 bytes) \| 🔒Alias FMC Pub Key Y \|\|
	538	+\| 8 \|\| 🔒FMC Digest \|\|
	539	+\| 9 \|\| 🔒Owner PK Hash \|\|
	540	+
	541	+
	542	+## Warm reset flow
544	543
545	544	![WARM RESET](../images/caliptra-sw/rom/dev/doc/svg/warm-reset.svg)
546	545
547		-## 10. Update Reset Flow
	546	+## Update reset flow
548	547
549	548	![UPDATE RESET](../images/caliptra-sw/rom/dev/doc/svg/update-reset.svg)
550	549	<br> *(Note: Please note that Image validation for the update reset flow has some differences as compared to the cold boot flow. Please refer to the Image Validation Section for further details.)
551	550
552		-## 11. Unknown/Spurious Reset Flow
	551	+## Unknown/spurious reset flow
553	552
554	553	![UNKNOWN RESET](../images/caliptra-sw/rom/dev/doc/svg/unknown-reset.svg)
555	554
556		-## 12. Firmware Image Validation Process
	555	+## Firmware image validation process
557	556
558	557	The basic flow for validating the firmware involves the following:
559	558
@@ -569,37 +568,37 @@
569	568	- This marks the TOC data as valid. The next step is to use the TOC Hash to validate image sections.
570	569	- Download the FMC Image portion of the Image.
571	570	- Validate the FMC Image against the hash in the TOC entry for the FMC.
572		- - If this is a cold reset, the FMC version number should be stored in a register.
	571	+ - If this is a cold reset, the FMC version number should be stored in a register.
573	572	- Download the RT Image part of the firmware Image.
574	573	- Validate the RT Image against the hash in the TOC entry for the RT.
575	574	- If all the above validations are complete, the entire image is validated.
576	575	- Let the SOC know that the firmware download command is complete.
577	576	- On failure, a non-zero status code will be reported in the `CPTRA_FW_ERROR_FATAL` register
578	577
579		-
580		-### 12.1 Overall Validation Flow
	578	+### Overall validation flow
	579	+
581	580	![Overall Validation Flow](../images/caliptra-sw/rom/dev/doc/svg/overall-validation-flow.svg)
582	581
583		-
584		-#### Pre-Conditions
	582	+#### Pre-conditions
585	583
586	584	The following are the pre-conditions that should be satisfied:
	585	+
587	586	- Caliptra has transitioned through the BOOTFSM and all the fuses that are required for the validation are already populated by SOC.
588	587	- The FUSES programmed by the soc are
589		- - fuse_key_manifest_pk_hash : This fuse contains the hash of the manufacturer keys present in preamble.
590		- - fuse_key_manifest_pk_hash_mask : This is the bitmask of the ECC keys which are revoked.
591		- - fuse_lms_revocation : This is the bitmask of the LMS keys which are revoked.
592		- - fuse_owner_pk_hash : The hash of the owner public key(s) in preamble.
593		- - fuse_lms_verify: This fuse indicates if verification with LMS key is enabled.
594		- - fuse_key_manifest_svn : Used in FMC validation to make sure that the version number is good.
595		- - fuse_runtime_svn : Used in RT validation to make sure that the runtime image's version number is good.
	588	+ - fuse_key_manifest_pk_hash : This fuse contains the hash of the manufacturer keys present in preamble.
	589	+ - fuse_key_manifest_pk_hash_mask : This is the bitmask of the ECC keys which are revoked.
	590	+ - fuse_lms_revocation : This is the bitmask of the LMS keys which are revoked.
	591	+ - fuse_owner_pk_hash : The hash of the owner public key(s) in preamble.
	592	+ - fuse_lms_verify: This fuse indicates if verification with LMS key is enabled.
	593	+ - fuse_key_manifest_svn : Used in FMC validation to make sure that the version number is good.
	594	+ - fuse_runtime_svn : Used in RT validation to make sure that the runtime image's version number is good.
596	595	- The SOC has written the data to the mailbox.
597	596	- The SOC has written the data length in the DLEN mailbox register.
598	597	- The SOC has put the FW_DOWNLOAD command in the command register.
599	598	- The SOC has set the execute bit in the mailbox execute register.
600	599	<br> ( NOTE: At this time the interrupts are not enabled. Writing a execute bit will not generate an interrupt. The validation and update flow will need to be invoked externally.)
601	600
602		-## 12.2 Preamble Validation: Validate The Manufacturing Keys
	601	+## Preamble validation: Validate the manufacturing keys
603	602
604	603	- Load the preamble bytes from the mailbox.
605	604	- There are four ECC and thirty-two LMS manufacturing keys in the preamble.
@@ -608,20 +607,20 @@
608	607	- If the hash does not match, fail the image validation.
609	608	- If the hash matches, all the ECC and LMS keys are validated.
610	609
611		-### 12.2.1 Preamble Validation: Manufacturing Key Selection
	610	+### Preamble validation: Manufacturing key selection
612	611
613	612	- Since there are four ECC key slots in the preamble, we will need to select one key out of four.
614	613	- fuse_key_manifest_pk_hash_mask is the mask which revokes an ECC key.
615		- - If bit-0 is set, that key is disabled. All other higher bits which are zeros, are still enabled.
616		- - If all the bits are zeros, all the keys are enabled.
617		- - If bit-0 and bit-1 are set, all higher slot bits (2 and 3) are enabled.
	614	+ - If bit-0 is set, that key is disabled. All other higher bits which are zeros, are still enabled.
	615	+ - If all the bits are zeros, all the keys are enabled.
	616	+ - If bit-0 and bit-1 are set, all higher slot bits (2 and 3) are enabled.
618	617	- Select the key using the Public Key Index Hint field in the preamble. This key should not be disabled using the fuse_key_manifest_pk_hash_mask fuse.
619		- - If the key is disabled, fail the validation.
620		- - If the key is enabled, select the key.
	618	+ - If the key is disabled, fail the validation.
	619	+ - If the key is enabled, select the key.
621	620	- Repeat the above procedure for LMS keys using the fuse_lms_revocation for key revocation.
622	621	- At this time, we have validated all the four ECC and thirty-two LMS keys and selected the ECC and LMS key that will be used for validation of the header against the manufacturer header signature field.
623	622
624		-### 12.2.2 Preamble Validation: Validate The Owner Key
	623	+### Preamble validation: Validate the owner key
625	624
626	625	- There is one slot each for the owner ECC and LMS keys in the image preamble.
627	626	- fuse_owner_pk_hash contains the hash of the owner public keys.
@@ -629,23 +628,25 @@
629	628	- If the hash matches, the owner public keys are valid.
630	629	- If the hash match fails, fail the image validation.
631	630
632		-## Preamble Validation Steps
	631	+## Preamble validation steps
	632	+
633	633	![Preamble Validation Flow](../images/caliptra-sw/rom/dev/doc/svg/preamble-validation.svg)
634	634
635		-## 12.3 Header Validation
	635	+## Header validation
636	636
637	637	- Load the header portion of the firmware image from the mailbox.
638	638	- Header is the only signed component. There are two signatures generated for the header.
639	639	- First signature is generated using one of the manufacturing keys.
640	640	- Second signature is generated using the owner public key.
641		-- To validate the header, hash and verify the ECC manufacturer signature in the preamble is for the hash.
	641	+- To validate the header, hash and then verify that the ECC manufacturer signature in the preamble is for the hash.
642	642	- If the manufacturer signature matches, proceed with the owner signature validation. If the signature does not match, fail the validation. Repeat the same procedure with LMS manufacturer key if LMS verification is enabled.
643	643	- The hash is already generated. Verify the signature for the above hash using the ECC owner public key. Repeat the same procedure with LMS owner key if LMS verification is enabled.
644	644
645		-## Header Validation Steps
	645	+## Header validation steps
	646	+
646	647	![Header Validation Flow](../images/caliptra-sw/rom/dev/doc/svg/header-validation.svg)
647	648
648		-## 12.4 Table Of Contents Validation
	649	+## Table of contents validation
649	650
650	651	- At this point all the previous steps of validation are complete.
651	652	- The Preamble and the header are validated.
@@ -659,10 +660,11 @@
659	660
660	661	<br>
661	662
662		-## Table Of Contents Validation Steps
	663	+## Table of contents validation steps
	664	+
663	665	![Toc Validation Flow](../images/caliptra-sw/rom/dev/doc/svg/toc-validation.svg)
664	666
665		-## 12.5 Validating Image Sections
	667	+## Validating image sections
666	668
667	669	- Once the TOC is validated, the image section associated with each TOC needs validation.
668	670	- The hash for each image section is stored in the TOC data.
@@ -675,62 +677,66 @@
675	677	- Compare the hash with the hash in the RT TOC.
676	678	- If the hash matches, the RT image section is validated. If the hash does not match, reject the image.
677	679
678		-## Image Section Validation Steps
	680	+## Image section validation steps
	681	+
679	682	![Image Section Validation Flow](../images/caliptra-sw/rom/dev/doc/svg/image-section-validation.svg)
680	683
681		-## 12.6 Differences In Operating Mode Of The Validation Code
	684	+## Differences in operating mode of the validation code
682	685
683	686	- The validation code operates in three modes.
684		- - Cold Boot Mode
685		- - Warm Boot Mode
686		- - Update Reset Mode
	687	+ - Cold Boot Mode
	688	+ - Warm Boot Mode
	689	+ - Update Reset Mode
687	690	- Cold Boot Mode
688		- - Validation of the entire image is done using the steps described above.
689		- - Save the hash of the FMC portion of the image in a separate register.
690		- - Copy the FMC and RT image's text and data section in the appropriate ICCM and DCCM memory regions.
691		- - The data vault is saved with the following values:-
692		- - LDevId Dice Signature.
693		- - LDevId Dice Public Key.
694		- - Fmc Dice Signature.
695		- - Fmc Public Key.
696		- - Digest of the FMC part of the image.
697		- - Digest of the ECC and LMS owner public keys portion of preamble.
698		- - FMC SVN.
699		- - ROM Cold Boot Status.
700		- - Fmc Entry Point.
701		- - ECC Vendor public key index.
702		- - LMS Vendor public key index.
	691	+ - Validation of the entire image is done using the steps described above.
	692	+ - Save the hash of the FMC portion of the image in a separate register.
	693	+ - Copy the FMC and RT image's text and data section in the appropriate ICCM and DCCM memory regions.
	694	+ - The data vault is saved with the following values:-
	695	+ - LDevId Dice Signature.
	696	+ - LDevId Dice Public Key.
	697	+ - Fmc Dice Signature.
	698	+ - Fmc Public Key.
	699	+ - Digest of the FMC part of the image.
	700	+ - Digest of the ECC and LMS owner public keys portion of preamble.
	701	+ - FMC SVN.
	702	+ - ROM Cold Boot Status.
	703	+ - Fmc Entry Point.
	704	+ - ECC Vendor public key index.
	705	+ - LMS Vendor public key index.
703	706	- Warm Boot Mode
704		- - In this mode there is no validation or load required for any parts of the image.
705		- - All the contents of ICCM and DCCM are preserved.
	707	+ - In this mode there is no validation or load required for any parts of the image.
	708	+ - All the contents of ICCM and DCCM are preserved.
706	709	- Update Reset Mode
707		- - The image is exactly the same as the initial image which was verified on the cold boot, except that the RT part of the image is changed.
708		- - We need to validate the entire image exactly as described in the cold boot flow. In addition to that, also validate the image to make sure that no other part (except the RT image section) is altered.
709		- - The validation flow will look like the following:
710		- - Validate the preamble exactly like in cold boot flow.
711		- - Validate the vendor public key indices from the values in data vault (value saved during cold boot). Fail the validation if there is a mismatch. This is done to make sure that the key being used is the same key that was used during cold boot.
712		- - Validate the owner public key digest against the owner public key digest in data vault (value saved during cold boot). This ensures that the owner keys have not changed since last cold boot.
713		- - Validate the header exactly like in cold boot.
714		- - Validate the toc exactly like in cold boot.
715		- - We still need to make sure that the digest of the FMC which was stored in the data vault register at cold boot
716		- still matches the FMC image section.
717		- - If validation fails during ROM boot, the new RT image will not be copied from
718		- the mailbox. ROM will boot the existing FMC/Runtime images. Validation
719		- errors will be reported via the CPTRA_FW_ERROR_NON_FATAL register.
720		-
721		-## 13. Fake ROM
	710	+ - The image is exactly the same as the initial image which was verified on the cold boot, except that the RT part of the image is changed.
	711	+ - We need to validate the entire image exactly as described in the cold boot flow. In addition to that, also validate the image to make sure that no other part (except the RT image section) is altered.
	712	+ - The validation flow will look like the following:
	713	+ - Validate the preamble exactly like in cold boot flow.
	714	+ - Validate the vendor public key indices from the values in data vault (value saved during cold boot). Fail the validation if there is a mismatch. This is done to make sure that the key being used is the same key that was used during cold boot.
	715	+ - Validate the owner public key digest against the owner public key digest in data vault (value saved during cold boot). This ensures that the owner keys have not changed since last cold boot.
	716	+ - Validate the header exactly like in cold boot.
	717	+ - Validate the toc exactly like in cold boot.
	718	+ - We still need to make sure that the digest of the FMC which was stored in the data vault register at cold boot
	719	+ still matches the FMC image section.
	720	+ - If validation fails during ROM boot, the new RT image will not be copied from
	721	+ the mailbox. ROM will boot the existing FMC/Runtime images. Validation
	722	+ errors will be reported via the CPTRA_FW_ERROR_NON_FATAL register.
	723	+
	724	+## Fake ROM
722	725
723	726	Fake ROM is a variation of the ROM intended to be used in the verification/enabling stages of development. The purpose is to greatly reduce the boot time for pre-Si environments by eliminating certain steps from the boot flow. Outside of these omissions, the behavior is intended to be the same as normal ROM.
724	727
725		-Fake ROM is not available in production mode as it is not secure and breaks/bypasses the core use-cases of Caliptra as a RoT.
	728	+Fake ROM is only available in production mode if the enable bit is set in the CPTRA_DBG_MANUF_SERVICE_REG (see section above).
726	729
727	730	Differences from normal ROM:
	731	+
728	732	Fake ROM reduces boot time by doing the following:
	733	+
729	734	1. Skipping the DICE cert derivation and instead providing a static, "canned" cert chain for LDEV and FMC Alias
730	735	2. Skipping the known answer tests (KATs)
731	736	3. Skipping verification of the FW image received - This can optionally still be performed, see CPTRA_DBG_MANUF_SERVICE_REG
732	737
733	738	How to use:
	739	+
734	740	- Fake ROM is provided in the release along with the normal collateral.
735	741	- The image builder exposes the argument "fake" that can be used to generate the fake versions
736	742

Changes to ROM Specification