PPK Revocation

Each PPK has a set of revocation bits implemented with eFUSEs. Programming these fuses invalidates (revokes) that PPK permanently preventing its use. The following figure demonstrates the OTA use case with the revocation of a PPK (PPK0 in this instance).

Figure 1. Configuration Update with PPK Revocation

In the notional system, it is assumed that a revision of the design (Design_PPK0) and a golden image (GoldenDesign_PPK0) are both stored in external memory and both are signed by PSK0 (authenticated by PPK0).

Again, this is a representative system used to describe the process of updating a system when it is necessary to revoke a PPK. It is not a requirement.

The initial design, Design_PPK0, is notified when an update is desired. In many cases, the design itself is responsible for supporting the remote update. Design_PPK0 increments the MultiBoot register ( PMC_MULTI_BOOT ) and then initiates a reset. Design_PPK1 is then booted, and if successful, begins operation. Design_PPK1 should then update, if necessary, the golden image and then program the eFUSEs to revoke PPK0. In the event of a failed boot, the RCU increments the MultiBoot register and initiates a reset. As the golden image is stored at a higher address in external memory, it is ultimately loaded, and communication can be re-established (again, assuming this is an OTA case).