[component] Why opentitan need to do a lot of functional safety sms?

[Jiahua-Gong]

Description

It's a wonderful project. I see a lot of fusa SMs to be designed in the chip.
Such as,

1. core lock step
2. end to end protection in bus,flash....
   It's a secret chip, not a automotive or space level chip. why we need to do a lot of fuctional safety SMs?

If it's a automotive or space level secret chip, why we design too less fusa SMs? I'm confused. Some sms need to be add into the chip.
Such as,

1. Logic bist to improve latent fault discover.
2. Register lock bit. After cofiguration. We need locked all of static register. I only see interrupt test.
3. peridic test, power on test......memory bist,register check,flash content check .....
4. After factory, We also need to inject errors to ensure fusa SMs always work.
5. A lot of points need to be consider.........

Opentitan do some fusa SMs，However，Some fusa point are lack.

I'm confused. Could anyone explain this?

Thanks

[cdgori]

Hello,

(I am assuming that "fusa" means functional safety, if I have interpreted that incorrectly, I apologize.)

I would say that while the countermeasures might look like typical functional safety techniques, the same strategies are also often used in security designs to thwart attackers/active adversaries.

The lock-step Ibex and end-to-end integrity techniques are part of the overall anti-fault-injection defenses of the OpenTitan design. Fault attacks are commonly used by adversaries to attempt to manipulate security components such as a root-of-trust, as they are fairly low-cost and potentially very effective.

So, some of the techniques you mentioned as functional safety needs are not required for fault injection defense and are thus not implemented. If you have a specific threat in mind where the defenses are not adequate (or can be improved), please do make suggestions!

[Jiahua-Gong]

Thank you for your patience to answer.I also went to read the paper to understand the fault attacks.

I think the opentitan project can protect against most attacks on core, tl bus, flash, and sram. (But it is not impossible to extract the chip layout and take pictures, extract the netlist, and then formally compare the netlist to find the alarm signal, and the FIB process cuts to find the corresponding metal connection, and then connects the alarm so that it will never alarm. This is actually already very, very difficult). The circuit for the safety mechanism test is missing here, so there is this vulnerability. Generally, automotive chips will do logic bist when the chip is powered on. Make sure the circuit is not damaged.

Some peripheral units cannot be protected. Such as AES encryption engine, hmac, kmac, random number generate etc...

I think this issue should be considered like functional safety. First, establish several information security goals, then decompose sub-goals, use fault tree analysis and FMEA, and use some hardware and software solutions to prevent fault injection attacks. Finally, the probability of being breached by fault injection attacks is evaluated by calculating the fault diagnosis rate.

This solution is very successful in the application of functional safety. There is also some very mature software to do these things. For example, the medini software of ANSYS.

[cdgori]

While the properties desired for functional safety and security often are well-aligned, they are ultimately different in their goals.

OpenTitan tries to follow best practices for secure hardware design. Protecting against fault injection attacks with an active adversary/attacker requires substantial investment in redundancy (either temporal or spatial), as well as a sensitivity analysis for the security assets protected by a given submodule, as you have basically suggested.

Cryptographic functions (like AES or Keccak) can often be tested functionally using known-answer tests rather than dedicated logic BIST, as the avalanche/diffusion properties required by the underlying primitives are very good at detecting modifications to the logic implementation. Detecting removal of alarm signals is more difficult, but OpenTitan uses an active/bi-directional handshake with pings to attempt to do so.

I would suggest to you that based on publications and industry presentations that the reverse engineering and modification process you described is not as difficult as you think (see for example the presentation by Chipworks as far back as CHES 2009, but there are many others), and is potentially in-scope as a threat for some applications of OpenTitan.

Thanks for your comments.