160 could be configured to designate the first identified key in the scanning operation as the currently active key.

Returning to the depicted embodiment, the security management component 160 could perform the scanning operation and determine that the public key 220₁in the memory location 1 210₁is the currently active key on the device. That is, the security management component 160 could begin scanning at the memory location n 210_nand could determine that the first key having a corresponding status 230 of ACTIVE is the key 220₁in memory location 1 210₁. The security management component 160 could then use the public key 220₁during secure during boot operations to validate a signature of the first firmware package on the device.

Responsive to the installation of a second firmware package on the first device, the security management component 160 could associate a second public key in a second secure memory key location on the first device with an active status. For example, the security management component 160 could determine that the memory location 2 210₂is immediately adjacent (here, subsequent) to the first secure memory key location 210₁. In the depicted embodiment, the security management component 160 could then write a corresponding public key to the corresponding public key location 220₂within the public key storage table 170. Additionally, the security management component 160 could update the status value 230₂to reflect an active status and could lock the status value 230₂to prevent further modifications.

These modifications are illustrated in FIG. 2B, where the security management component 160 has written the value of “)<~SGVCd3pBD[zl_H-Cank@HuJP.%/hi<cb” to the public key field 260₂, and has written the status ACTIVE to the status field 270₂and locked the status field to prevent further modifications. For example, the firmware management component 122 of the device management system 110 could have transmitted the public key value of “)<~SGVCd3pBD[zl_H-Cank@HuJP.%/hi<cb” to the device 150, along with the second firmware package.

During a boot-up operation on the device using the second firmware package, the security management component 160 could scan the updated secured memory key store 250 to determine which public key to use to validate the second firmware package. For example, the security management component 160 could begin the scanning operation by starting at a predefined secure memory key location (e.g., the final memory location n) and scanning backwards (i.e., towards the first memory location 210₁) until a status of active is identified. In the depicted example, the security management component 160 determines that the key 260₂is the currently active key. That is, even though both keys 2601 and 260₂have a corresponding status 2701 and 270₂of ACTIVE, the security management component 160 encounters the key 260₂first in the exemplary scanning operation and would designate the first-identified key as the currently active key.

The security management component 160 could then validate the second firmware package on the first device using the identified public key 260₂. In the event the validation operation for the second firmware package is successful, the security management component 160 could allow the boot operation of the device to continue. For example, the security management component 160 could generate a hash of the second firmware package using a hashing algorithm and the public key 260₂, and could compare the generated hash value with a hash digest value received with the second firmware package (e.g., from the security management component 120 on the device management system 110). If the hash values match, the security management component 160 could determine that the validation operation was successful. On the other hand, in the event the security management component 160 determines the validation operation was not successful, the security management component 160 could prevent the boot operation from completing and could provide a notification, informing the user that the boot operation was unsuccessful due to a signature mismatch for the second firmware package.

FIG. 3 is a flow chart illustrating a method for deprecating a compromised key pair used in a secure boot operation for a device, according to embodiments described herein. As shown, the method 300 begins at block 310, where the security management component 120 determines that a first key pair has been compromised 310. The security management component 120 generates a second key pair (block 315) and the security management component 120 signs a first instance of device firmware received from the firmware management component 122 using both the first key pair and the second key pair (block 320). The security management component 120 then transmits the signed device firmware 325 and any associated signature values (e.g., one or more hash digest values produced during the signing process) to the device 150.

Upon receiving the signed device firmware, the security management component 160 deletes a key pair signature corresponding to the compromised first key pair (block 330). Additionally, the security management component 160 writes the second public key from the second key pair into the secure memory at location k+1, where k is the location of the first public key from the first key pair (block 335). In other words, the security management component 160 writes the second public key to the immediately subsequent memory location relative to the location of the previously active key (the first public key, in the depicted example). The security management component 160 locks the secure memory location k+1 once the second public key is written to the secure memory location k+1, thereby preventing future modifications to the second public key within the secure memory (block 340).

Once the secure memory has been updated with the second public key, the security management component 160 reboots the device and verifies that the secure boot operation is able to successfully validate the firmware using a signature based on the second public key (block 345), and the method 300 ends. Advantageously, the method 300 allows a new key to be created after the compromise of the first key pair, which ensures that any attacker that may have compromised the first key pair did not have access to the new key pair (as it was created subsequent to the compromise of the first key pair).

In some embodiments, the security management component 160 could be configured to use a public key storage table 170 that contains multiple read-only public keys. For example, a manufacturer of the device 150 could generate such a public key storage table 170 while the manufacturer is still in control of the device 150 (e.g., at the physical location where the device 150 was manufactured). FIG. 4A is a block diagram illustrating a secured memory key store, according to one embodiment described herein. As shown, the secured memory key store