Implement hash chain support in Caliptra ROM

[bluegate010]

This supports Stable Identity. Requirements:

• Stable across FMC/RT FW updates.
• Non-stable across epoch updates.
• Allows SVN-specific keys to be derived.
• Allows firmware that cold-booted with SVN X to wield the key bound to SVN X or below.

[bluegate010]

We'll implement SVN-specific keys using a hash chain. However, to make this FIPS compliant, each link in the chain will need to be a KDF. Hopefully a future version of SP 800-133 will allow cryptographic keys to be chained together via hashes.

We will have to anchor the hash chain to the min-SVN-since-cold-boot value, instead of simply the current SVN. The reason being:

• If we want to support update-resets from an older SVN to a newer SVN, we will need to re-start the hash chain from a secret that is available upon update reset.
• The only secret that fits this bill in ROM is the FMC CDI.
• The FMC CDI is not guaranteed to be stable across cold-boots; if the FMC updates, anything derived from the FMC CDI will be lost. This will not satisfy the stability requirement.
• Therefore, when ROM is generating the hash chain, it will fork off from the LDevID CDI, which does remain stable across FMC updates.
• However, the LDevID is not available to ROM upon an update reset. Therefore, ROM will not be able to shorten the hash chain.
• What ROM can do though, is lengthen the hash chain, such that its length corresponds with min-SVN-since-cold-boot. With this PR the ROM will be tracking this value.

In short: if we update-reset from an older SVN to a newer SVN, the hash chain will remain where it is. If we update-reset from a newer SVN to an older SVN, ROM will crank the hash chain until it corresponds with the older SVN, before it allows that older firmware to boot.

This is because the only secret available across update-resets from which we could restart the hash chain is mingled with the FMC hash, and therefore is not suitable for anchoring Stable Identity.