[keymgr, security] Assume adversarial SW model regarding keymgr analysis

@ballifatih is already working on this.

Since Mar 27, 2023.

### Description

This is a security opinion on threat modeling regarding keymgr, which spun off from an offline discussion with @gdessouky and @bilgiday and is closely related to #17508. I wanted to have a separate issue to discuss this, so that I can easily refer to this from other dependent issues.

TL;DR: I think when we are analyzing security issues involving `keymgr`, we should assume that all layers of SW are controlled by an attacker (including ROM and ROMExt).

`keymgr` is responsible for keeping device-unique secrets secure. These secrets include those that are received from other IPs (OTP root key, flash diversification keys etc.) as well as those generated internally through KMAC calls (internal state, attestation seeds, sealing encryption keys, OTBN seeds etc.) My interpretation is the raison d'être for `keymgr` is that the secrecy of these sensitive key material is guaranteed by HWIP itself without relying on any assumption from SW side. Even if SW is compromised, `keymgr` should deliver on the promise that these secrets will not be compromised. Maybe these keys were used to encrypt sensitive user data locally and we would like to keep it secure even if the platform is compromised.

This might seem to contradict with the fact that HWIPs + ROM + ROMExt are all owned by a SiliconCreator, so from that point of view, why would SiliconCreator be considered as an attacker? The security OpenTitan can deliver if SiliconCreator is adversarial is limited and out of our scope, and SiliconCreator could come up with many other ways to reach its malicious goal without having to touch any layer of SW.

Here, I can imagine few things possibly going wrong even if SiliconCreator does everything right:

1. There might be some bugs in ROM, ROMExt or upper layer of SW that might allow attacker to partially or fully control Ibex. For instance, maybe attacker has a way of weakening randomness used by `keymgr`'s internal LFSR and combine with SCA #15088.
2. Even if there are no bugs in ROM, ROMExt, the drivers already need to tackle lots of issues of their own. If HW does not prevent particular potential weakness, patching it through drivers requires a tedious analysis and even then we might miss few attack scenarios.
3. In the worst case scenario, if secure boot is compromised (e.g. SiliconOwner root key stolen, and that key is not revoked yet), I think this is not a reason for `keymgr` to not deliver on its promise of protecting its keys.

In short, the main point is that the security of `keymgr` should not rely on so many assumptions outside HWIP itself.

Let me know if this threat modeling sounds too far-fetched before I dive deeper into analyzing `keymgr` and `kmac` interaction in this model. Of course this is orthogonal to M2.5 bucketing, and many potential issues arising from that point of view could be tagged as FutureRelease.

cc: @johannheyszl @moidx @vogelpi @jadephilipoom