[csrng] Add a lock CSR for en_csrng_sw_app_read

[vogelpi]

Description

The en_csrng_sw_app_read OTP switch right now gates access to reading the internal state of all 3 CSRNG instances (SW, EDN0, EDN1) but also reading the genbits register for the SW instance, i.e., it is essential to allow using the SW instance.

Because cryptolib needs to be able to access the SW instance the switch always needs to enabled, meaning reading the internal state seems always possible which is bad. We should decouple reading the internal state and the genbits register.

Since reading the internal state is required for certification evaluation, we should convert the setting to a CSR that can be locked at runtime.

See also lowRISC/opentitan-integrated#436.

[andreaskurth]

@moidx: This is an open because when we have to restart CSRNG, we need to decide if we have to run a KAT based on internal state.
@vogelpi: Split access between HW and SW instance?
@moidx: For Entropy Complex 2.0, we may want to split FIPS from entropy quality. But agree that separate controls would be nice.

[andreaskurth]

@moidx: Split per CSRNG instance

[andreaskurth]

By @vogelpi: Doesn't seem to be super important to me. Given the other work left, incl. OTBN, I suggest moving this to M4 or Backlog. We'll discuss on Monday with @johannheyszl and may move to Backlog then. In the state DB you can also read the number of reseeds, which is useful debug / performance information.

[johannheyszl]

@vogelpi and I discussed this:

• We think it should remain on the list, however, there are other things more critical. Also the security implication is 'only' secondary because it requires compromised SW.

• Therefore setting as P3 in M4.

• Since reading the internal state is useful for KATs for certification, adding a lockable CSR per instance sounds appropriate. Details of when to lock remain unclear (after restart of entropy complex, to repeat KAT, will lock be removed on clear?

• We would suggest to only gate access to key and v using this setting but leave access to counter open.

[vogelpi]

I've discussed this again today with @johannheyszl and we both believe we need to implement that for security reasons. The change isn't huge and I have a clear idea of how to do that. I am thus now raising priority.

[vogelpi]

A PR to implement this as follows can be found here: #23539

What the PR adds:

• Expose the reseed counter of each instance unconditionally of OTP fuses and CSRNG configuration.
• Add a regren bit per instance that allows locking read access to the internal state (i.e. K and V) per instance. If firmware locks read access, the lock persists until the next CSRNG disablement. This is sufficient to do KAT after enabling and allows to lock internal state access moving forward.

[vogelpi]

Alternatively, the lock could easily be made to persist until the next reset. We may also want to consider splitting the OTP fuse for internal state access and the genbits read. Without the latter, the SW context cannot be used at all. My suggestion would be to simply not factor the OTP fuse into the genbits read access. I.e., the SW context would always be usable when the SW_APP_ENABLE field in https://opentitan.org/book/hw/ip/csrng/doc/registers.html#ctrl is set. What do you think @johannheyszl @moidx ?

[vogelpi]

We've discussed in the triage meeting that it would be better to allow locking the read enable setting until the next reset e.g. in ROM_EXT. I've now modified the linked PR accordingly.

[vogelpi]

The OTP setting is left untouched though. The understanding is that for KATs, the internal read access is always required and that this is needed always.