[entropy_src, OTBN] Consider renaming or removing the FIPS signal

[johannheyszl]

Description

The entropy complex can be operated in a FIPS-compatible manner (SP 800-90B) using the provided HW elements (e.g. health tests in entropy_src) or through a FW override / bypass mode. This is helpful for flexibility regarding (additional) health testing and bit width of raw data samples.

There is a FIPS compliance HW bit for entropy which is deasserted in case of FW bypass and single bit mode (asserted otherwise).

It might make sense to remove said FIPS bit and instead manage the FIPS state of the entropy complex in SW. Alternatively, the conditions for assertion should at least be reviewed.

Note that FIPS-compatible random numbers are needed for selected purposes.

In OTBN, there is an automatically asserted error upon using random numbers with a deasserted FIPS signal. This is inconvenient in case of FW FIPS mode. Depending on changes to the entropy_src this needs to be revisited.

Issue created after discussion b/w: @moidx @johannheyszl VadimS @vogelpi @zi-v @h-filali

[johannheyszl]

cc @msfschaffner @andreaskurth

[vogelpi]

Thanks for creating the issue @johannheyszl . Aborting program execution inside OTBN upon receiving a seed with de-asserted FIPS bit is certainly bad. For now, I've also added the OTBN tag for visilibility. Instead of changing the behavior of OTBN we could change two different things:

• ensure that single-bit mode is FIPS compliant (see other issue)
• allow software to manually set the FIPS bit when injecting entropy in FW override: extract & insert mode. E.g. a new MuBi4 field could be added into the Firmware Override Control Register.

I wouldn't rename the signal: this sounds like a lot of work for very little gain.

[vogelpi]

I've further discussed this today with @h-filali. We see 3 different ways in which the noise source / entropy_src could get validated / certified for FIPS:

• 4-bit hardware pipeline
• 1-bit hardware pipeline
• software pipeline (4 or 1-bit)

Which one is chosen eventually can probably not be decided 100% before tapeout. Thus, it would be better if software can fully set the FIPS signal. Because software will know whether it has now configured the mode which has been validated or not.

Related to that, the meaning of this signal is not that the entropy is FIPS compliant but rather: if the noise source / entropy_src got validated / certified, they were run in this very mode for generating the current entropy.

[johannheyszl]

I agree. SW set seems very reasonable to me. We must make sure that health test failures are escalated fast enough and there is no chance that a SW-set FIPS bit is overriding non-FIPS data

[vogelpi]

Good point. IIRC, all internal FIFOs are emptied upon disabling / enabling the entropy source and I would assume we probably set the desired configuration + FIPS bit and then enable the module.