-
+
-
-
-
-
-
-## What does the ROM check do?
-
-One of the possible physical attacks on a system like OpenTitan is to subvert the ROM.
-The regular structure of a ROM is useful because it makes metal fixes easy, but (for the same reasons) it makes the ROM quite an easy target for an attacker.
-See \[SKO-05\][^SKO-05], section 2.1.1, for a description of ROMs and attacks on them.
-
-[^SKO-05]: **SKO-05**: Skorobogatov, [*Semi-Invasive Attacks - A New Approach to Hardware Security Analysis*](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.html), University of Cambridge Computer Laboratory Technical Report 630, 2005
-
-Since the code in ROM is the first thing to execute, an attacker that modifies it undetected can completely subvert the chain of trust.
-As such, OpenTitan needs some form of ROM integrity checking and the ROM checker is the module in charge of providing it.
-
-After bringing the ROM controller module out of reset, the power manager must wait until `pwrgr_data_o.done` is asserted before starting the host processor.
-The ROM controller also passes the `pwrmgr_data_o.good` signal.
-The power manager can use this to decide whether to boot (taking into account life cycle state).
-This provides an extra safety check, but the real security comes from key manager integration described below.
-
-The simple KMAC interface assumes that KMAC is pre-configured to run the cSHAKE algorithm with a prefix specific to the ROM checker.
-The ROM checker will not assert `kmac_data_o.valid` after finishing the one and only digest computation.
-The KMAC module may choose to add a check for this, to detect reset glitches affecting the `rom_ctrl` block.
-
-The integration with the key manager is based on forwarding the digest data in `kmac_data_i` as `keymgr_data_o.data`.
-This 256-bit digest will be incorporated into the [`CreatorRootKey`](../../../doc/security/specs/identities_and_root_keys/README.md#creator-root-key).
-The key manager should only allow one transaction (of 256 bits / 32 bits = 8 beats) after reset to pass this information across.
-On future messages, it should raise an alert, defeating an attacker that tries to trigger extra transactions before or after the real one.
-
-`CreatorRootKey` forms the first key in the chain described in Identities and Root Keys.
-An attacker who modifies the ROM will perturb `CreatorRootKey` (to avoid doing so would require a preimage attack on the ROM checksum calculation or the `KM_DERIVE` function).
-The result is that, while the chip will function, it will have the "wrong" root key and the chain of trust used for attestation will be broken.
-
-## Fault-injection hardening
-
-The core integrity check, flowing from the ROM data to `CreatorRootKey`, should be infeasible to subvert.
-However, `rom_ctrl` also controls bus access to ROM data and interacts with other blocks.
-To avoid attacks propagating into the rest of the system, we take the following extra hardening steps:
-
-- All internal FSMs are sparsely encoded, with a minimum Hamming distance of 3.
-- The "good" signal passed to the power manager is multi-bit encoded (using `mubi4_t`).
-- The switching signals for the mux are multi-bit encoded (using `mubi4_t`).
-- We check to ensure the mux doesn't switch back to the checker after giving access to the bus.
-- The main FSM has internal consistency checking to ensure that other blocks don't signal completion when the FSM is in a state that doesn't expect them to be running.
-
-## Hardware Interfaces
-
-* [Interface Tables](data/rom_ctrl.hjson#interfaces)
-
-### Parameters
-
-Parameter | Default (Max) | Top Earlgrey | Description
-----------------------------|-----------------------|--------------|---------------
-`RndCnstRomKey` | (see RTL) | (see RTL) | Compile-time random default constant for scrambling key (used in `prim_prince` block).
-`RndCnstRomNonce` | (see RTL) | (see RTL) | Compile-time random default constant for scrambling nonce (used in `prim_prince` block and the two S&P blocks).
-
-### Signals
-
-The table below lists other ROM controller inter-module signals.
-
-| Signal | -Type | -Destination | -Description | -
|---|---|---|---|
pwrmgr_data_o |
- rom_ctrl_pkg::pwrmgr_data_t |
- pwrmgr | -
-
- A structure with two fields.
- The first,
- The second, |
-
keymgr_data_o |
- rom_ctrl_pkg::keymgr_data_t |
- keymgr | -
- A 256-bit digest, together with a valid signal.
- Once the ROM check is complete, valid will become true and will then remain true until reset.
- The digest in data is only valid when valid is true and is be constant until reset.
- |
-
kmac_data_o |
- kmac_pkg::app_req_t | -kmac | -
- Outgoing data to KMAC.
- Data is sent in 64-bit words in the data field.
- When a word of data is available, the valid field is true.
- When this is the last word of data, the last field is also true.
- Since we never send partial words, the strb field is always zero.
- |
-
kmac_data_i |
- kmac_pkg::app_rsp_t | -kmac | -
- Incoming data from KMAC interface.
- This contains a ready signal for passing ROM data and a done signal that shows a digest has been computed.
- When done is true, the digest is exposed in two shares (digest_share0 and digest_share1).
- The error field is ignored.
- |
-
+
+
+
+
+
+## What does the ROM check do?
+
+One of the possible physical attacks on a system like OpenTitan is to subvert the ROM.
+The regular structure of a ROM is useful because it makes metal fixes easy, but (for the same reasons) it makes the ROM quite an easy target for an attacker.
+See \[SKO-05\][^SKO-05], section 2.1.1, for a description of ROMs and attacks on them.
+
+[^SKO-05]: **SKO-05**: Skorobogatov, [*Semi-Invasive Attacks - A New Approach to Hardware Security Analysis*](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-630.html), University of Cambridge Computer Laboratory Technical Report 630, 2005
+
+Since the code in ROM is the first thing to execute, an attacker that modifies it undetected can completely subvert the chain of trust.
+As such, OpenTitan needs some form of ROM integrity checking and the ROM checker is the module in charge of providing it.
+
+After bringing the ROM controller module out of reset, the power manager must wait until `pwrgr_data_o.done` is asserted before starting the host processor.
+The ROM controller also passes the `pwrmgr_data_o.good` signal.
+The power manager can use this to decide whether to boot (taking into account life cycle state).
+This provides an extra safety check, but the real security comes from key manager integration described below.
+
+The simple KMAC interface assumes that KMAC is pre-configured to run the cSHAKE algorithm with a prefix specific to the ROM checker.
+The ROM checker will not assert `kmac_data_o.valid` after finishing the one and only digest computation.
+The KMAC module may choose to add a check for this, to detect reset glitches affecting the `rom_ctrl` block.
+
+The integration with the key manager is based on forwarding the digest data in `kmac_data_i` as `keymgr_data_o.data`.
+This 256-bit digest will be incorporated into the [`CreatorRootKey`](../../../../doc/security/specs/identities_and_root_keys/README.md#creator-root-key).
+The key manager should only allow one transaction (of 256 bits / 32 bits = 8 beats) after reset to pass this information across.
+On future messages, it should raise an alert, defeating an attacker that tries to trigger extra transactions before or after the real one.
+
+`CreatorRootKey` forms the first key in the chain described in Identities and Root Keys.
+An attacker who modifies the ROM will perturb `CreatorRootKey` (to avoid doing so would require a preimage attack on the ROM checksum calculation or the `KM_DERIVE` function).
+The result is that, while the chip will function, it will have the "wrong" root key and the chain of trust used for attestation will be broken.
+
+## Fault-injection hardening
+
+The core integrity check, flowing from the ROM data to `CreatorRootKey`, should be infeasible to subvert.
+However, `rom_ctrl` also controls bus access to ROM data and interacts with other blocks.
+To avoid attacks propagating into the rest of the system, we take the following extra hardening steps:
+
+- All internal FSMs are sparsely encoded, with a minimum Hamming distance of 3.
+- The "good" signal passed to the power manager is multi-bit encoded (using `mubi4_t`).
+- The switching signals for the mux are multi-bit encoded (using `mubi4_t`).
+- We check to ensure the mux doesn't switch back to the checker after giving access to the bus.
+- The main FSM has internal consistency checking to ensure that other blocks don't signal completion when the FSM is in a state that doesn't expect them to be running.
+
+## Hardware Interfaces
+
+* [Interface Tables](../data/rom_ctrl.hjson#interfaces)
+
+### Parameters
+
+Parameter | Default (Max) | Top Earlgrey | Description
+----------------------------|-----------------------|--------------|---------------
+`RndCnstRomKey` | (see RTL) | (see RTL) | Compile-time random default constant for scrambling key (used in `prim_prince` block).
+`RndCnstRomNonce` | (see RTL) | (see RTL) | Compile-time random default constant for scrambling nonce (used in `prim_prince` block and the two S&P blocks).
+
+### Signals
+
+The table below lists other ROM controller inter-module signals.
+
+| Signal | +Type | +Destination | +Description | +
|---|---|---|---|
pwrmgr_data_o |
+ rom_ctrl_pkg::pwrmgr_data_t |
+ pwrmgr | +
+
+ A structure with two fields.
+ The first,
+ The second, |
+
keymgr_data_o |
+ rom_ctrl_pkg::keymgr_data_t |
+ keymgr | +
+ A 256-bit digest, together with a valid signal.
+ Once the ROM check is complete, valid will become true and will then remain true until reset.
+ The digest in data is only valid when valid is true and is be constant until reset.
+ |
+
kmac_data_o |
+ kmac_pkg::app_req_t | +kmac | +
+ Outgoing data to KMAC.
+ Data is sent in 64-bit words in the data field.
+ When a word of data is available, the valid field is true.
+ When this is the last word of data, the last field is also true.
+ Since we never send partial words, the strb field is always zero.
+ |
+
kmac_data_i |
+ kmac_pkg::app_rsp_t | +kmac | +
+ Incoming data from KMAC interface.
+ This contains a ready signal for passing ROM data and a done signal that shows a digest has been computed.
+ When done is true, the digest is exposed in two shares (digest_share0 and digest_share1).
+ The error field is ignored.
+ |
+
| -Reset Tree - | -Description - | -
rst_por_n
- |
- POR reset tree.
-
- |
-
rst_lc_n
- |
- Life Cycle reset tree.
-
-
|
-
rst_sys_n
- |
- Debug reset tree.
-
-
|
-
rst_{module}_n
- |
- Module specific reset.
-
-
- |
-
| +Reset Tree + | +Description + | +
rst_por_n
+ |
+ POR reset tree.
+
+ |
+
rst_lc_n
+ |
+ Life Cycle reset tree.
+
+
|
+
rst_sys_n
+ |
+ Debug reset tree.
+
+
|
+
rst_{module}_n
+ |
+ Module specific reset.
+
+
+ |
+
| Milestone Signal | FSM Triggers | -
|---|---|
| byte_starting | Entering WaitLead |
| Entering InternalClkLow and bit_cntr == 0 | |
| bit_shifting | Entering InternalClkLow and bit_cntr != 0 |
| byte_ending | Exiting InternalClkHigh and bit_cntr == 0 |
| Milestone Signal | FSM Triggers | +
|---|---|
| byte_starting | Entering WaitLead |
| Entering InternalClkLow and bit_cntr == 0 | |
| bit_shifting | Entering InternalClkLow and bit_cntr != 0 |
| byte_ending | Exiting InternalClkHigh and bit_cntr == 0 |