4.5.1.2 Revocation Table

The revocation table is a critical asset for managing the trust status of public keys used for secure boot, firmware update and other cryptographic operations. Unlike key rotation where new keys can be added as needed, a key revocation table operates with a fixed set of public keys that are provisioned during device setup. The revocation table tracks which keys are valid and which have been revoked, ensuring that compromised or untrusted keys are not used.

Security Objective: Access Control

Access control is the security objective for the revocation table. Enforcing access control ensures that only authorized code is permitted to modify the revocation table. Unauthorized changes could compromise the device’s ability to boot by invalidating valid keys or by removing revocations.

Access control for revocation tables in dsPIC33A devices is primarily achieved through the configuration of Flash protection regions. Revocations are a one-way operation, and revoked keys should not be restored. An OTP region allows for writes but not erases which allows the creation of desired one-way operations. This allows a non-blank value to write to the table to indicate that a key has been revoked but prevents that region from being erased to clear the revocation.

An OTP region, however, cannot have the permissions changed. They are locked on Reset. Because the IRT needs to be written on a revocation event, it must be writable. The revocation table should be protected from unauthorized modification, so before authorization or when complete with a modification, it needs to disable writes.

Figure 4-27. OTP Section - Revocation Table

Using an OTP section for the revocation table allows the table to be write only (disables erases) but does not provide a way to control when writes are authorized.

To control the write permissions at run-time, a second FIRMWARE type region can be used that overlaps the revocation table. This region can be used to disable write permissions on Reset and only enable write permissions when authorized. When the IRT has determined there is not a pending revocation, it can lock the revocation table until Reset to prevent modification of the region until the next Reset.

Figure 4-28. Key Revocation Table Control via Overlapping Firmware Region

By using an overlapping FIRMWARE type region, the access to the write permissions to the key revocation table can be better controlled.

For more information on Flash protection regions, including overlapping regions, see Flash Protection Regions.

Key Considerations:

Requires additional storage for backup keys
Having multiple fixed signature verification (public) keys may not provide a benefit if the signing (private) keys are not protected separately. If they are stored in the same HSM with the same access controls, a compromise of the system could compromise all the keys.
Consider using a Key Rotation of Code Signing Public Keys scheme to reduce the quantity of keys that need to be created, stored and monitored
For the revocation table, use an OTP region to create the one-way write behavior needed. Overlap with a FIRMWARE region to have additional hardware support for write access to the table.