4.5 Key Revocation of Code Signing Public Keys

Network capable solutions can use key revocation via Certificate Revocation Lists (CRLs). These are lists of certificates that are revoked from usage and are provided by a trusted Certificate Authority (CA). Networked revocation lists and their usage are not covered in this section.

For devices without network access, key revocation can be achieved by using a list of pre-generated keys in the key store stored in protected memory. When a key is compromised or needs to be replaced, it is revoked from the table, but the system can use other keys in the key store that are still valid. In this model, the number of available keys is limited to those provisioned in advance. Having a fixed number of revocable keys introduces new considerations.

This example shows a system with multiple code signature verification keys with a revocation table. In this example, the key store is immutable, but the key revocation table can be written only by the boot code/IRT. With multiple possible keys, the firmware image would likely include the key used to sign the image or an indicator of which key was used so the boot code knows which key to use for the verification of the valid keys. This indicator could be an index in the list, a digest of the public key or any other type of identifier.

If the key store is immutable, it may not require authentication of the key store during boot. This would result in faster boot times than an updatable key store.

As the number of keys stored in the key store increases, it may also present storage considerations, especially when there are multiple unique code sections to authenticate or when the keys used are large, such as the case for Post-Quantum (PQC) public keys. For example, an MLA-DSA-87 public key is 2592 bytes compared to an ECDSA p521 public key at 133 bytes uncompressed. When there are multiple sections to authenticate and multiple keys needed per section, this results in a considerable impact on the key store size.

To mitigate this increased memory usage, the key store can be modified to store the hash of the public key rather than the public key itself.

In Figure 4-26, if the code verification keys are large, such as ML-DSA-87 public keys, storing multiple keys is costly. Instead, the key store stores the digest of the valid public keys. With this change, the firmware image needs to include the full public key. The boot code hashes the public key in the firmware image and verifies the resulting digest against the valid digests in the key store. If the digest matches the digest of a valid key in the key store for the target region, then the authentication process can continue.

For more details on key management guidance, refer to NIST SP 800-57 Part 1 – Recommendation for Key Management: Part 1 – General.