[sram_ctrl, flash_ctrl, icache, otbn] Protecting scrambling keys at rest

[msfschaffner]

Scrambling keys are currently obtained from OTP and then stored locally in a register for use with the scrambling device.
However, that register is not protected against any FI injection, which may in rare cases be exploited.
Should we ECC protect these key registers and trigger an alert if there is a mismatch?

[tjaychen]

i honestly think sram_ctrl, otbn, icache by virtue of being ephemeral, it is okay for now.
otbn specifically will get software redundancy layered across.

For sram, really sensitive variables will need to be separately hardened by software, and i'm hoping if the key is attacked, it will mostly look like garbage instruction for the icache. In theory this should be difficult to reproduce across power cycles.

For flash the key is installed really early during manufacturing, so any disturbance later will actually cause code verification to fail. Any stored data will also get really wonky.

@msfschaffner could you add Bilgiday also to get his thoughts?

While i'm not saying this is bad to do, for the blocks that have passed D2S I really think we should refrain from re-opening unless we absolutely have to. The we protection I think was necessary because for ibex at least, those were unprotected otherwise. Here it is already protected, and it is just more layering.

[msfschaffner]

Your reasoning makes sense. I just wanted to bring it up so we can document this decision somewhere. I will mark this as a future enhancement for now.

[andreaskurth]

Triaged for sram_ctrl. Suggest to keep Type:FutureRelease Not relevant to currently planned releases/milestones as per the arguments above.

[GregAC]

Triaged for flash_ctrl, happy to keep Type:FutureRelease Not relevant to currently planned releases/milestones

[GregAC]

Triaged for otbn, same conclusion as above

[GregAC]

Triaged for ibex, same conclusion as above

[msfschaffner]

Do we think this is still useful to do? It seems like defense in depth and may not be warranted to spend much effort on, given that these are just ephemeral scrambling keys.

[msfschaffner]

@johannheyszl @vogelpi WDYT?

[vogelpi]

Johann and I think it would make sense to at least bring this up in the Sec WG. I am thus adding the corresponding label.

Personally, I think additional ECC can make sense when there is a long timing window between refreshing the scrambling key and actually using it. Otherwise, injected bit flips likely lead to ECC errors upon reading the memory with an invalid key as Tim pointed out above. Then the attacker needs to glitch the key upon loading which is harder because the timing needs to be right.

[vogelpi]

We've discussed this issue in the Security Working Group meeting on Sept 14.

It was agreed that for all blocks except one, there are ECC checks further down the line and chances are high that an ECC error would be triggered fairly quickly. Extending the protection in this case would be about adding an additional layer of security. Thus, it has been decided to not change these blocks.

For OTBN, the situation is a bit different as there can be a time gap between renewing the key and filling the data memory. However, the current understanding is that we will add an algorithmic layer for protection anyway. So the additional integrity of the scrambling key wouldn't be super beneficial. Even though a potential design change could be small (don't need to change the transmission, just the storage), it may have DV implications that we would prefer to avoid at this stage. People thought it wasn't worth to unfreeze the RTL of OTBN for just this but we should keep the idea around for future releases.

I am thus closing this issue and will open a new one for OTBN exclusively. Removing the hotlist label.

[vogelpi]

The new OTBN-specific issues is here: #20162