Secure boot management method, server, IoT device, and medium

Abstract

Disclosed are a secure boot management method, a server, an IoT device and a storage medium. The method implemented by a server and includes: receiving public key information from one or more Internet of Things (IoT) devices, wherein the public key information from each IoT device corresponds to a plurality of public keys stored on the IoT device; and for each of the one or more IoT devices: retrieving, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys; signing a firmware image with the one or more private keys; and sending the signed firmware image to the IoT device.

Description

SECURE BOOT MANAGEMENT METHOD, SERVER, IOT DEVICE, AND MEDIUMTECHNICAL FIELD

[0001] Embodiments described herein relate to the technical field of Internet of Things (IoT) , and in particular, to a secure boot management method, a server, an IoT device and a computer-readable medium.BACKGROUND

[0002] With the development of Internet of Things (IoT) technology, wireless IoT devices have been greatly popularized, and accordingly wireless firmware upgrades are becoming more and more important. A server management platform of IoT supports the transmission of a signed firmware image to a IoT device through Over the Air (OTA) technology, and the IoT device completes the firmware upgrade through a bootloader to perform verification operation after receiving the signed firmware image.

[0003] However, keys stored in the server management platform can lead to security risks if they are inadvertently leaked. The IoT device may be at risk if the IoT device loads insecure or malicious software or firmware during the boot process. Therefore, how to improve the security of wireless firmware upgrades becomes a problem to be solved in this field.SUMMARY

[0004] To solve at least the technical problems described above, the present disclosure provides a secure boot management method, a server, an IoT device and a storage medium, aiming to at least improve the security of the key management.

[0005] According to a first aspect of the present disclosure, a method implemented by a server is provided. The method includes: receiving public key information from one or more Internet of Things (IoT) devices, wherein the public key information from each IoT device corresponds to a plurality of public keys stored on the IoT device; and for each of the one or more IoT devices: retrieving, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys; signing a firmware image with the one or more private keys; and sending the signed firmware image to the IoT device.

[0006] In some embodiments, the public key information includes a set of key digests corresponding to all valid public keys from the plurality of public keys.

[0007] In some embodiments, the step of signing a firmware image with the one or more private keys includes signing the firmware image with a first private key that is not revoked from the one or more private keys.

[0008] In some embodiments, the plurality of public keys are sorted in a first order. In some embodiments, the method further includes, in response to an indication from the user, marking a public key and all public keys before or after the public key in the first order from the plurality of public keys as revoked.

[0009] In some embodiments, the step of signing a firmware image with the one or more private keys includes signing the firmware image with all private keys that are not revoked from the one or more private keys.

[0010] In some embodiments, the method further includes, in response to an indication from the user, marking a public key from the plurality of public keys as revoked.

[0011] In some embodiments, the server is a cloud server.

[0012] In some embodiments, the step of retrieving includes retrieving, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys from a hardware security module (HSM) accessible to the server.

[0013] In some embodiments, the firmware image is provided by a user to the server.

[0014] According to a second aspect of the present disclosure, a method implemented by an Internet of Things (IoT) device is provided. The method includes: reporting public key information to a server, wherein the public key information corresponds to a plurality of public keys stored on the IoT device; receiving a firmware image signed by the server with one or more private keys corresponding to a subset or all of the plurality of public keys; validating the signed firmware image with one or more of the plurality of public keys; and applying, in response to a successful validation, the signed firmware image on the IoT device.

[0015] In some embodiments, the public key information includes a set of key digests corresponding to all valid public keys from the plurality of public keys.

[0016] In some embodiments, the firmware image is signed by the server with a first private key that is not revoked from the one or more private keys.

[0017] In some embodiments, the plurality of public keys are sorted in a first order. In some embodiments, the method further includes, in response to the firmware image being signed with a private key, revoking all public keys in the plurality of public keys that are before or after a public key corresponding to the private key in the first order.

[0018] In some embodiments, the firmware image is signed by the server with all private keys that are not revoked from the one or more private keys.

[0019] In some embodiments, the method further includes, marking one or more public keys from the plurality of public keys as revoked on the IoT device, wherein the one or more public keys correspond to private keys that are not found in the all private keys that are not revoked from the one or more private keys.

[0020] In some embodiments, the method further includes, receiving revoked public key information from the server, wherein the revoked public key information corresponding to one or more revoked public keys; marking, based on the revoked public key information, the one or more revoked public keys as revoked on the IoT device.

[0021] According to a third aspect of the present disclosure, a server is provided. The server includes one or more processors; and a memory storing instructions, when executed by the one or more processors, causing the server to perform any of the above methods implemented by the server.

[0022] According to a fourth aspect of the present disclosure, an IoT device is provided. The IoT device includes one or more processors; and a memory storing instructions, when executed by the one or more processors, causing the IoT device to perform any of the above methods implemented by the IoT device.

[0023] According to a fifth aspect of the present disclosure, a computer-readable medium is provided. The medium includes instructions, when executed by one or more processors of a computer, causing the computer to perform operations of any of the above methods implemented by the server and any of the above methods implemented by the IoT device.BRIEF DESCRIPTION OF THE DRAWINGS

[0024] In the following, the present disclosure will be further explained on the basis of embodiments with reference to the attached drawings.

[0025] FIG. 1 illustrates a flow diagram of a secure boot management method executed by a server provided according to some embodiments of the present disclosure.

[0026] FIG. 2 illustrates a flow diagram of a signing process provided according to a specific example of the present disclosure.

[0027] FIG. 3 illustrates a flow diagram of a key revocation method provided according to a specific example of the present disclosure.

[0028] FIG. 4 illustrates a flow diagram of a secure boot management method executed by an IoT device provided according to some embodiments of the present disclosure.

[0029] FIG. 5 illustrates a structure diagram of a server provided according to some embodiments of the present disclosure.

[0030] FIG. 6 illustrates a structure diagram of an IoT device provided according to some embodiments of the present disclosure.DETAILED DESCRIPTION

[0031] The disclosure will be further described in the following with reference to the specific embodiments. It should be understood that these embodiments are only used to illustrate the disclosure and not to limit the scope of the disclosure. In addition, it should be understood that those skilled in the art can make various changes or modifications to the disclosure after reading the content taught by the disclosure, and these equivalent forms also fall within the scope defined by the appended claims of the disclosure.

[0032] Before the embodiments of the present disclosure are described in further detail, the terms and terminology involved in the embodiments of the present disclosure are applicable to the following explanations.

[0033] The term “bootloader” is a small program that runs when a device powers on. The bootloader is responsible for loading the main application program into memory, validating and then running the main application program.

[0034] The term “firmware” is the main application program that has all the business logic and is loaded by the bootloader.

[0035] The term “secure boot keys” is a set of key pairs used to sign and verify the bootloader and firmware. The key pair generally includes a public key and a private key, the private key is used to sign (encrypt) the loader and firmware, and the public key is used to verify (decrypt) the bootloader and firmware encrypted by the private key to verify the legitimacy and integrity of the bootloader and firmware.

[0036] The term “digest” is a hash of a block of data, which could be the bootloader, the firmware, a signature block, a public key, etc. Generally, as compared to the data block itself, the digest is protected by a cryptographic algorithm, which can have improved security.

[0037] The term “key digest” is a hash of the public key, which can assist in uniquely identifying a key.

[0038] Most devices, especially IoT devices require a way to ensure that only valid firmware can be executed by the bootloader. For this, the IoT device uses a signed firmware image which the bootloader can then verify with the public key it has. A general good practice for enabling secure boot is to have a set of n keys, say k0, k1, kn-1 which can be used to sign bootloader and firmware. However, managing the corresponding private keys is a security concern since it should not be accessible to anyone. Moreover, once the IoT devices are in field, there is no easy way to know what keys were used for signing the firmware image. This makes OTA firmware upgrades tricky and hard to manage.

[0039] For this, some embodiments of the present disclosure provide a server based secure boot method, which at least aims to securely manage the secure boot keys at the server side, to enable updating of one or more IoT devices with secure boot.

[0040] FIG. 1 illustrates a flow diagram of a secure boot management method executed by the server provided according to some embodiments of the present disclosure. Referring to FIG. 1, the method includes:

[0041] At step S101, the server receives public key information from one or more Internet of Things (IoT) devices, wherein the public key information from each IoT device corresponds to a plurality of public keys stored on the IoT device.

[0042] In this step, each IoT device is stored with a plurality of public keys and manages its own public key information. The server receives the public key information from each IoT device.

[0043] At step S102, for each of the one or more IoT devices, the server retrieves, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys.

[0044] In this step, the server may retrieve and use the private key (s) corresponding to the valid public key (s) from the plurality of public keys. Here, the valid public key (s) may be a subset or all of the plurality of public keys.

[0045] At step S103, a firmware image is signed with the one or more private keys.

[0046] At step S104, the signed firmware image is sent to the IoT device.

[0047] In the embodiments, whenever the IoT device with secure boot is to be updated, the server, based on the public key information, retrieves the private key (s) corresponds to the public key (s) stored on the IoT device. Subsequently, the server can auto-sign the firmware image with the private key (s) that is valid for each of the plurality of IoT devices, and then send the signed firmware image to the corresponding IoT device to proceed with the OTA firmware upgrade.

[0048] According to the embodiments, the server receives and maintains the public key information from the IoT device, rather than the private key per se corresponding to the public key, and retrieves the private key (s) corresponding to the public key (s) based on the public key information for signing the firmware image, thereby significantly improving the security of the private key management, and avoiding the security risk caused by inadvertent leakage of the key stored on the server.

[0049] In some embodiments, the firmware image is provided by a user to the server. For example, the user may indicate an unsigned firmware image to be used for the OTA firmware upgrade and specify the IoT device / groups of IoT devices to which this firmware image needs to be pushed. This helps to trigger / enable the server-based secure boot of the IoT device (s) .

[0050] In some embodiments, the public key information includes a set of key digests corresponding to all valid public keys from the plurality of public keys. As noted above, the key digest is a hash of the public key. The key digest is a shorter representation of the public key and can be used as an unique identifier of the public key.

[0051] In an example, for the server to know what keys are to be used for signing, the IoT device reports a list of all valid key digests to the server as below:

[0052] { “k0” : “<digest1>” , “k1” : “<digest2>” ..... “kn-1” : “<digestn-1>” }

[0053] Wherein, the digest1, digest2, ....., digestn-1 denotes the n key digests corresponding to n public keys respectively. Herein, it should be noted that the k0, k1, ....., kn-1 denotes the labels of the n public keys stored on the IoT device, rather than the values of the n public keys per se.

[0054] In some embodiments, the list of key digests is reported on each boot up so that the correct data about currently active keys gets reported, since firmware verification happens on each boot up, and of course during OTA, but that too triggers a reboot.

[0055] Based on this, instead of maintaining a mapping of devices and keys, the server may maintain a database and additional metadata for the keys, like the name, key digest, etc., which can help in identifying and searching the keys. In this case, the server has a database of keys, which also includes its digests. Since the IoT device has also reported their key digests, it can match the digests, so that the server can finds out the keys corresponding to the reported key digests. In other words, once receiving the public key information from the IoT device, the server is capable of retrieving the private key based on the database for that key, and signing the firmware image using that private key.

[0056] As compared to the circumstance that the server maintains the mapping of devices to keys somewhere in the server, and signs the firmware image with the key corresponding to the particular device, in the present embodiments, the IoT device first reports the correct data about the currently active key to the server, and then the server retrieves the private key from the database for that key, which ensures that the firmware image can be signed with the appropriate private key corresponding to the valid public key.

[0057] In some embodiments, the server is a cloud server.

[0058] In some embodiments, in the step S102, the server retrieves, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys from a hardware security module (HSM) accessible to the server. In an example, the HSM may be a part of the server. Alternatively, the HSM may be remote from the server and may be wired or wirelessly connected to the server.

[0059] According to the embodiments, the private keys are maintained in the hardware security module, so that they are not directly accessible to anyone without authorization. The corresponding public certificates are available to authorized users, to be programmed into the devices. Further, APIs to get firmware images signed with these keys are also governed by appropriate access and the authorization control mechanism. In other words, only authorized users / devices can access the hardware security module to retrieve the corresponding private key. As a result, the security of private key management is improved by storing the private keys in the hardware security module, so as to avoid malicious access by unauthorized users.

[0060] In some embodiments, the bootloader may be signed with all the keys since it is not upgradable, so that it can be always verifiable with one of the keys. The firmware image needs to be signed by a single valid key. Both the bootloader and the firmware will have access to the valid public keys required for verification of firmware images. When the user triggers firmware updates to groups of devices which may contain a varying set of signing keys, the server is expected to auto-sign the firmware images with the keys that are valid for that particular device.

[0061] For this, in some embodiments, in step S103, the firmware image is signed with a first private key that is not revoked from the one or more private keys.

[0062] FIG. 2 illustrates a flow diagram of a signing process provided according to a specific example of the present disclosure. Referring to FIG. 2, in an example signing process, each of the IoT devices in the OTA job / group provides a list of key digests (S201) , then for all keys pertaining to the particular IoT device, the first key that is not revoked is identified (S202) , and it is checked if the current OTA firmware image is already signed with this key (S203) . If not, proceed to generate the signed firmware image and store for future use (S204) . If yes, proceed to use the previous signed firmware image for OTA notification (S205) . Finally, the signed firmware image is delivered to the particular IoT device.

[0063] In some embodiments, in response to an indication from the user, a public key from the plurality of public keys is marked as revoked. That is, the user may indicate to the server that a particular signing key has been revoked. This will inform the server that that particular signing key should not be subsequently used for signing. In this way, the server can guarantee to auto-sign the firmware image with the private key that is valid for the particular IoT device.

[0064] The IoT device can mark a key, k, as revoked, if it receives a firmware upgrade that contains a signed firmware image with some other key kn, such that kn≠k. That is, if the IoT device receives a signed firmware image with a key kn, instead of k, then the IoT device can mark the key k as revoked. In this way, after the IoT device is in field, it is still possible to manage the mapping of the IoT devices to the keys, to ensure the reliability and accuracy of that mapping relationship.

[0065] In some embodiments, some indication may also be sent to the IoT device so that the IoT device can also mark the particular key as revoked.

[0066] In order to further manage the mapping of the IoT devices to the keys, it is further provided with two key revocation methods as below.

[0067] In a first embodiment, the plurality of public keys are sorted in a first order. In one embodiment, in response to an indication from the user, the server marks a public key and all public keys before or after the public key in the first order from the plurality of public keys as revoked.

[0068] In an example, the keys are used in an incremental order. In the case that the device firmware finds that a firmware is signed with kn where n > 0, then the device firmware will mark all keys from 0 to n-1 as revoked.

[0069] In an alternative example, the keys are used in a decremental order. In the case that the device firmware finds that a firmware is signed with kn-5 where n > 0, then the device firmware will mark all keys from n-4 to n-1 as revoked.

[0070] According to the embodiments, when a key gets leaked, all the untrusted keys are revoked, thereby ensuring that other valid keys are used for signing firmware image for secure boot.

[0071] FIG. 3 illustrates a flow diagram of a key revocation method provided according to a specific example of the present disclosure. Referring to FIG. 3, all OTA firmware upgrades are signed by k0 by default. If k0 leaks, the specific key revocation method includes:

[0072] At step S301, an OTA firmware image signed with k1 is sent.

[0073] At step S302, the current firmware verifies this firmware image with k1 before rebooting into it.

[0074] At step S303: the bootloader verifies new firmware with k1.

[0075] At step S304: a new firmware verifies the bootloader with k1.

[0076] At step S305: the old key, k0, is marked as revoked.

[0077] That is, in this example, when the IoT device finds that the firmware image is signed with k1, then the key k0 before the public key k1 is marked as revoked.

[0078] However, in the above first key revocation method, it may have to unnecessarily revoke a lot of keys. For example, if kn-1 itself gets leaked, then it may have to revoke all keys, which is not practical. Further, since there cannot be infinite signing keys, some limitation is bound to be present.

[0079] In a second embodiment, in step S103, the firmware image is signed with all private keys that are not revoked from the one or more private keys. In one embodiment, in response to an indication from the user, a public key from the plurality of public keys is marked as revoked.

[0080] For example, the firmware is always signed with all keys, k0, k1, ....., kn-1. If any key, say k1 is to be revoked, the firmware will be signed with all keys except k1. Since the verification with k1 will fail, the key, k1, will be marked as revoked.

[0081] In the second key revocation method, it can revoke only one key at a time, instead of revoking multiple keys, which may effectively improves the utilization of keys. For example, as compared to the first key revocation method, when the key kn-1 itself gets leaked, it is not necessary to revoke all keys, but may just sign with all keys except kn-1. Therefore, it is sufficient for the IoT device to retain a limited number of keys, which helps to reduce the storage space for keys.

[0082] In conclusion, after the IoT device is in field, in the case that a key is leaked, the leaked key can be revoked, which ensures that the mapping of the IoT devices to the keys can be reliable and accurate. Further, the server can be ensured to auto-sign the firmware using the valid key for the IoT devices, thereby improving the security of OTA firmware upgrades.

[0083] FIG. 4 illustrates a flow diagram of a secure boot management method executed by an IoT device provided according to some embodiments of the present disclosure. Referring to FIG. 4, the method includes:

[0084] At step S401, the IoT device reports public key information to a server, wherein the public key information corresponds to a plurality of public keys stored on the IoT device.

[0085] At step S402, the IoT device receives a firmware image signed by the server with one or more private keys corresponding to a subset or all of the plurality of public keys.

[0086] At step S403, the IoT device validates the signed firmware image with one or more of the plurality of public keys.

[0087] At step S404, the IoT device applies, in response to a successful validation, the signed firmware image on the IoT device.

[0088] In this way, whenever the IoT device with secure boot is to be updated, the IoT device reports the public key information to the server, so that the server can retrieve, based on the public key information, the private key (s) corresponds to the public key (s) stored on the IoT device. Subsequently, the IoT device receives the firmware image signed by the server with the valid private key to proceed with the OTA firmware upgrade. Thereby, the security of the private key management can be significantly improved, and the security risk caused by inadvertent leakage of the key stored on the server can be avoided. In some embodiments, the IoT device may only send the public key information to the server once in its lifetime. It is noted that the IoT device, once programmed in the factory, will continue to have the same public key information within it. Thus, it might not be necessary for the IoT device to send its public key information on every OTA request. Once the IoT device sends its public key information to the server, the server can make a note of the public key information, and use that for subsequent OTA invocations. This helps to save some network data transfer and save data traffic accordingly.

[0089] In some embodiments, the public key information includes a set of key digests corresponding to all valid public keys from the plurality of public keys. The key digest can assist in uniquely identifying the key. In this way, once the IoT device reports the set of key digests to the server, the server can know what keys are to be used for signing, by retrieving the private key (s) based on the set of key digests. In an example, the server may have a database of keys, which also includes the key digests. Then, the server may retrieve the private key (s) from the database, since the key digest can be used to uniquely identify the key. Moreover, the firmware upgrade is enabled after the IoT device reports the public key information to the server and after the server retrieves the private key based on the public key information, so that the security of private key management can be improved.

[0090] In some embodiments, the firmware image is signed by the server with a first private key that is not revoked from the one or more private keys. In this way, when the user triggers firmware updates to groups of devices which may contain a varying set of signing keys, the server can auto-sign the firmware images with the keys that are valid for that particular device.

[0091] In some embodiments, the plurality of public keys are sorted in a first order. The first order may be an incremental order or a decremental order. In some embodiments, the IoT device revokes all public keys in the plurality of public keys that are before or after a public key corresponding to the private key in the first order, in response to the firmware image being signed with a private key. In an example, the plurality of public keys are sorted in an incremental order. If it is found that the firmware image is signed with kn, then all the keys from 0 to n-1 may be marked as revoked.

[0092] According to the embodiments, when a key gets leaked, all the untrusted keys are revoked, thereby ensuring that other valid keys are used for signing firmware for secure boot.

[0093] In some embodiments, the firmware image is signed by the server with all private keys that are not revoked from the one or more private keys. In an example, if the key k1 is to be revoked, the firmware image is signed with all keys except k1.

[0094] In some embodiments, the IoT device may further mark one or more public keys from the plurality of public keys as revoked on the IoT device, wherein the one or more public keys correspond to private keys that are not found in the all private keys that are not revoked from the one or more private keys. In an example, the firmware image is always signed with all keys, k0, k1, kn-1, and if the key k1 is not found in the signing keys for the firmware image, then the IoT device may mark the public key corresponding to the key k1 as revoked on the IoT device. In other words, the IoT device may only mark the key k1 as revoked after receiving the firmware upgrade that contains a signed firmware without using the key k1.

[0095] In some embodiments, the IoT device may receive revoked public key information from the server, wherein the revoked public key information corresponding to one or more revoked public keys, and mark, based on the revoked public key information, the one or more revoked public keys as revoked on the IoT device. In an example, the user may indicate to the server that a particular signing key has been revoked, so that the server can update the revoked public key information.

[0096] In conclusion, after the IoT device is in field, in the case that a key is leaked, the leaked key can be revoked, so that the server can be ensured to auto-sign the firmware using the valid key for the IoT devices, thereby improving the security of OTA firmware upgrades. Moreover, the IoT device can update the public key information stored thereon by receiving revoked public key information from the server, to better manage the mapping of the devices to keys.

[0097] It shall be understood that, the method executed by the IoT device herein is corresponding to the above method executed by the server to complete the OTA firmware upgrades, and the method executed by the IoT device may be implemented in conjunction with the above method executed by the server. The relevant technical details mentioned in the method executed by the server are still valid in the present method executed by the IoT device, and in order to reduce repetition, they are not repeated here. Accordingly, the relevant technical details mentioned in the present method executed by the IoT device may also be applied in the above method executed by the server.

[0098] FIG. 5 illustrates a structure diagram of a server provided according to some embodiments of the present disclosure. Referring to FIG. 5, in some embodiments, the server includes one or more processors and a memory storing instructions, when executed by the one or more processors, causing the server to perform any of the above methods performed by the server.

[0099] FIG. 6 illustrates a structure diagram of an IoT device provided according to some embodiments of the present disclosure. Referring to FIG. 6, in some embodiments, the IoT device includes one or more processors and a memory storing instructions, when executed by the one or more processors, causing the IoT device to perform any of the above methods performed by the IoT device.

[0100] In some embodiments, a computer-readable medium is further provided. The computer-readable medium includes instructions, when executed by one or more processors of a computer, causing the computer to perform operations of any of the above methods performed by the server and any of the above methods performed by the IoT device.

[0101] Those skilled in the art may understand that realizing all or part of the processes in the methods of the above embodiments is possible by means of a computer program to instruct the relevant hardware to accomplish the same, and the computer program may be stored in a non-transitory computer-readable storage medium, which, when executed, may cause to perform operations of the embodiments of the methods described above. Among other things, any reference to a memory, database, or other medium used in the embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memories may include a read-only memory (ROM) , a magnetic tape, a floppy disk, a flash memory, an optical memory, a high-density embedded non-volatile memory, a resistive memory (ReRAM) , a magneto resistive random access memory (MRAM) , a ferroelectric random access memory (FRAM) , a phase change memory (PCM) , a graphene memory, and the like. The volatile memory may include a random access memory (RAM) or an external cache memory, and the like. As an illustration and not as a limitation, the RAM may be in various forms, such as a static random access memory (SRAM) or a dynamic random access memory (DRAM) , and the like. The databases involved in the embodiments may include at least one of a relational database and a non-relational database. The non-relational database may include a blockchain-based distributed database and the like, which is not limited thereto. The processor involved in the embodiments may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logician, a data processing logician based on quantum computing, and the like, which is not limited thereto.

[0102] While various embodiments of various aspects of the disclosure have been described for the purpose of the disclosure, it shall not be understood that the teaching of the disclosure is limited to these embodiments. The features disclosed in a specific embodiment are therefore not limited to that embodiment, but can be combined with the features disclosed in different embodiments. For example, one or more features and / or operations of the method according to the present disclosure described in one embodiment can also be applied individually, in combination or as a whole in another embodiment. It can be understood by those skilled in the art that more optional embodiments and variations are possible, and that various changes and modifications can be made to the system described above, without departing from the scope defined by the claims of the present disclosure.

Claims

1.A method implemented by a server, comprising:receiving public key information from one or more Internet of Things (IoT) devices, wherein the public key information from each IoT device corresponds to a plurality of public keys stored on the IoT device; andfor each of the one or more IoT devices:retrieving, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys;signing a firmware image with the one or more private keys; andsending the signed firmware image to the IoT device.2.The method according to claim 1, wherein the public key information comprises a set of key digests corresponding to all valid public keys from the plurality of public keys.3.The method according to claim 1, wherein the step of signing a firmware image with the one or more private keys comprises signing the firmware image with a first private key that is not revoked from the one or more private keys.4.The method according to claim 3, wherein the plurality of public keys are sorted in a first order.5.The method according to claim 4, the method further comprising:in response to an indication from the user, marking a public key and all public keys before or after the public key in the first order from the plurality of public keys as revoked.6.The method according to claim 1, wherein the step of signing a firmware image with the one or more private keys comprises signing the firmware image with all private keys that are not revoked from the one or more private keys.7.The method according to claim 1, further comprising:in response to an indication from the user, marking a public key from the plurality of public keys as revoked.8.The method according to claim 1, wherein the server is a cloud server.9.The method according to claim 1, wherein the step of retrieving comprises retrieving, based on the public key information, one or more private keys corresponding to a subset or all of the plurality of public keys from a hardware security module (HSM) accessible to the server.10.The method according to claim 1, wherein the firmware image is provided by a user to the server.11.A method implemented by an Internet of Things (IoT) device, comprising:reporting public key information to a server, wherein the public key information corresponds to a plurality of public keys stored on the IoT device;receiving a firmware image signed by the server with one or more private keys corresponding to a subset or all of the plurality of public keys;validating the signed firmware image with one or more of the plurality of public keys; andapplying, in response to a successful validation, the signed firmware image on the IoT device.12.The method according to claim 11, wherein the public key information comprises a set of key digests corresponding to all valid public keys from the plurality of public keys.13.The method according to claim 11, wherein the firmware image is signed by the server with a first private key that is not revoked from the one or more private keys.14.The method according to claim 13, wherein the plurality of public keys are sorted in a first order.15.The method according to claim 14, the method further comprising:in response to the firmware image being signed with a private key, revoking all public keys in the plurality of public keys that are before or after a public key corresponding to the private key in the first order.16.The method according to claim 11, wherein the firmware image is signed by the server with all private keys that are not revoked from the one or more private keys.17.The method according to claim 16, the method further comprising:marking one or more public keys from the plurality of public keys as revoked on the IoT device, wherein the one or more public keys correspond to private keys that are not found in the all private keys that are not revoked from the one or more private keys.18.The method according to claim 11, further comprising:receiving revoked public key information from the server, wherein the revoked public key information corresponding to one or more revoked public keys;marking, based on the revoked public key information, the one or more revoked public keys as revoked on the IoT device.19.A server, comprising:one or more processors; anda memory storing instructions, when executed by the one or more processors, causing the server to perform the method according to any one of claims 1-10.20.An Internet of Things (IoT) device, comprising:one or more processors;a memory storing instructions, when executed by the one or more processors, causing the IoT device to perform the method according to any one of claims 11-18.21.A computer-readable medium, comprising instructions, when executed by one or more processors of a computer, causing the computer to perform operations of the method according to any of claims 1-18.

Images