Hardware security module firmware updates

Abstract

The present disclosure relates to a non-transitory machine-readable medium having machine-readable instructions including a firmware generator (114), the machine-readable instructions for the firmware generator (114) being executable by a processor core (112) to perform operations including signing a firmware image (116) of a hardware security module (HSM) (106) with a private key (120) of a public-private key pair to provide a first signature, and enhancing the firmware image (116) with a header (132) comprising the first signature to provide an enhanced firmware image (126). The operations further include encrypting the enhanced firmware image (126) with a symmetric key (122) to provide an encrypted enhanced firmware image (130). Further, the operations include signing the encrypted enhanced firmware image (130) with a private key (120) to provide a second signature, and enhancing the encrypted enhanced firmware image (126) with the second signature to provide a firmware package (108) for the HSM (106).

Description

Technical Field

[0001] The present disclosure relates to hardware security modules (HSMs), and in particular, the present description relates to systems and methods for updating firmware in an HSM. Background Art

[0002] A Hardware Security Module (HSM) is a physical device that provides additional security for sensitive data. An HSM is a hardware cryptographic accelerator module that includes its own core (CPU), cryptographic accelerator, and memory. An HSM is used to provide cryptographic keys for functions such as encryption, decryption, and authentication for use by applications, identities, and databases. An HSM can be embedded in other hardware, including smart cards, appliances, and other external devices. Protecting keys in a cryptographic system helps maintain a secure system. An HSM protects cryptographic keys and handles the encryption and decryption process. An HSM can also create and verify digital signatures.

[0003] Firmware is software embedded in hardware. Firmware consists of programs written by software developers to make hardware devices function properly. Firmware updates are similar to software updates. Device manufacturers create newer and better firmware. Updates add or rewrite existing software on a device to support improved efficiency. Firmware updates may also adjust the performance of the firmware or device drivers, potentially enhancing the performance of the processor or other device hardware. HSM firmware updates enable the repair of security vulnerabilities that might otherwise compromise the security of the device or the system in which the device is used. Summary of the invention

[0004] The first example involves a non-transitory machine-readable medium having machine-readable instructions including a firmware generator, the machine-readable instructions for the firmware generator being executable by a processor core to perform one or more operations. The one or more operations include signing a firmware image of a hardware security module (HSM) with a private key of a public-private key pair to provide a first signature, and enhancing the firmware image with a header including the first signature to provide an enhanced firmware image. The one or more operations further include encrypting the enhanced firmware image with a symmetric key to provide an encrypted enhanced firmware image. In addition, the one or more operations include signing the encrypted enhanced firmware image with a private key to provide a second signature; and enhancing the encrypted enhanced firmware image with a second signature to provide a firmware package for the HSM.

[0005] A second example relates to a non-transitory machine-readable medium having machine-readable instructions, the machine-readable instructions including a firmware verifier, the machine-readable instructions for the firmware verifier being executable by a processor core to perform one or more operations. The one or more operations include receiving a firmware package for a hardware security module (HSM), and requesting the HSM to verify a first signature of the firmware package, wherein the HSM uses a public key of a public key-private key pair to verify the integrity of the firmware package. The one or more operations further include extracting an encrypted enhanced firmware image from the firmware package in response to an indication from the HSM that the first signature is verified, and requesting the HSM to decrypt the encrypted enhanced firmware image, wherein the HSM uses a symmetric key to provide a decrypted enhanced firmware image in response to the decryption request. In addition, the one or more operations include transmitting the decrypted enhanced firmware image to the HSM, wherein the decrypted enhanced firmware image includes a second signature that can be verified using a public key.

[0006] A third example relates to a system comprising a hardware security module (HSM) storing updateable firmware; and a non-volatile memory having machine-readable instructions. The system further comprises a processor core that accesses the non-volatile memory and executes machine-readable instructions, the machine-readable instructions comprising a firmware verifier that can be executed by the processor core to perform one or more operations. The one or more operations include receiving a firmware package for the HSM, and requesting the HSM to verify a first signature of the firmware package, wherein the HSM uses a public key of a public-private key pair to verify the integrity of the firmware package, and extracting an encrypted enhanced firmware image from the firmware package in response to an indication from the HSM that the first signature is verified. The one or more operations further include requesting the HSM to decrypt the encrypted enhanced firmware image, wherein the HSM uses a symmetric key to provide a decrypted enhanced firmware image in response to the decryption request; and transmitting the decrypted enhanced firmware image to the HSM. The HSM includes a firmware updater that can be executed by the HSM to perform operations, and the operations for the firmware updater include writing the decrypted enhanced firmware image to the HSM firmware area of ​​the HSM, and using a public key to verify the second signature in the decrypted enhanced firmware image to verify the integrity of the firmware image in the decrypted enhanced firmware image. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 An example computing system is illustrated.

[0008] Figure 2A and Figure 2B Illustrated is a flow diagram for a computing system illustrating a process for updating firmware associated with a hardware security module (HSM).

[0009] Figure 3 A block diagram describing a procedure for forming a signed firmware package is depicted.

[0010] Figure 4 Diagram illustrating the transfer procedure for various keys to the HSM asset repository.

[0011] Figure 5 Illustrated is an example of receiving a signed firmware package at a computing platform.

[0012] Figure 6 Illustrate an example of verifying firmware versions and signatures at a computing platform.

[0013] Figure 7 An example diagram of decrypting an encrypted enhanced firmware image at a computing platform is depicted.

[0014] Figure 8 An example diagram of verifying a first signature at a computing platform is depicted.

[0015] Fig.9A An example diagram of a procedure for transferring a decrypted enhanced firmware image stored in volatile memory to an HSM is depicted.

[0016] Fig. 9B Depicted is an example diagram of a procedure for transferring a decrypted enhanced firmware image directly to an HSM without storing the decrypted enhanced firmware image in volatile memory.

[0017] Fig.10 Depicted is an example diagram of a procedure for deleting a decrypted enhanced firmware image from volatile memory / RAM associated with a computing platform.

[0018] Fig.11 A flow chart illustrating an example method for generating a firmware package to be used to update firmware associated with a hardware security module (HSM).

[0019] Fig.12 A flow chart illustrating an example method for verifying a firmware image to be used to update firmware associated with a hardware security module (HSM). DETAILED DESCRIPTION

[0020] The present specification relates to updating firmware for a hardware security module (HSM). The update of the firmware of the HSM can be used to adjust the performance of the HSM. The HSM described herein has an HSM read-only memory (ROM) and an HSM firmware area. The HSM firmware area stores firmware that can be updated. In some examples, the HSM firmware area is read / write protected and can only be accessed by the HSM ROM and the corresponding system ROM. In some examples, after the HSM is delivered / provided to the site (or client), the firmware of the HSM needs to be updated. When it comes to the firmware update of the HSM (which plays an important role in the security of the system), before updating the firmware of the HSM, the confidentiality and integrity of the HSM firmware update (e.g., the updated version of the firmware) need to be verified. In addition, rollback protection needs to be supported (e.g., to prevent the execution of an incorrect firmware version).

[0021] In view of the above, a system and method for updating the firmware of an HSM is described herein, which verifies the confidentiality and integrity of the HSM firmware update before updating the firmware of the HSM. In addition, the system and method described herein support rollback protection. The proposed system for updating the firmware of the HSM includes a secure computing platform (e.g., at the supplier end), which generates a firmware package, which includes a signed and encrypted firmware image (e.g., an updated version of the firmware), which will be used to update the firmware of the HSM (e.g., the existing firmware). In particular, in order to ensure the confidentiality of the firmware image, the firmware image is encrypted using a symmetric key (e.g., the symmetric key of the supplier). In addition, in order to ensure the integrity of the firmware image, the firmware image is signed twice with a private key in a public-private key pair (e.g., the private key of the supplier), once before the firmware image is encrypted, and once after the firmware image is encrypted. In some examples, the firmware image is further signed by an additional private key, for example, a customer private key associated with another public-private key pair. After the firmware package is generated, the firmware package is distributed on site (e.g., distributed to the client) for updating the firmware of the HSM at the client.

[0022] The system further includes a computing platform at a receiving end (e.g., a client) that receives a firmware package and downloads the firmware. After downloading the firmware package, a system read-only memory (ROM) associated with the computing platform and the HSM ROM is configured to authenticate the firmware package / image and decrypt the firmware image before using the firmware image to update the firmware of the HSM. The system ROM and the HSM ROM are configured to decrypt the firmware image using a symmetric key that is used to encrypt the firmware image at the supplier end. In addition, in order to authenticate the integrity of the firmware image, the system ROM and the HSM ROM are configured to verify the signature of the firmware package / image using the public key of the corresponding public key-private key pair before decrypting the firmware image. In addition, the HSM ROM is configured to verify the signature of the firmware image after decrypting the firmware image.

[0023] In addition, the system ROM and the HSM ROM are further configured to verify the version of the firmware image before performing the HSM firmware update. In some examples, only an authorized root of trust (e.g., a system ROM) is allowed to perform the HSM firmware update. In particular, the bus ID is added to the command / request to initiate the transfer of the firmware image to the HSM, and the HSM accepts the command / request only when the bus identifier (ID) matches the read-only memory (ROM) ID of the system ROM. By verifying the signature before and after decryption, the system supports strong security features. In addition, by utilizing the system ROM and the HSM ROM, the system is able to update the firmware of the HSM without the need for pre-programmed software in the device. In addition, the system supports rollback protection. In addition, the firmware image is signed before and after encryption, allowing the firmware image to be decrypted before moving / copying the firmware image to the HSM, thereby eliminating the need to retain additional memory in the HSM to store the encrypted firmware image.

[0024] Figure 1 An example computing system 100 is illustrated. The computing system 100 includes a secure computing platform 102 and a computing platform 104 including a hardware security module (HSM) 106. The secure computing platform 102 is configured to provide / generate a firmware package 108 for updating firmware associated with the HSM 106 of the computing platform 104. The secure computing platform 102 includes a memory 110 and a processor core 112. The memory 110 is implemented as a non-transitory machine-readable medium, such as a hard drive, a flash memory, a solid-state drive, a random access memory (RAM), or a combination thereof. The memory 110 is configured to store a firmware image 116 for generating the firmware package 108. In addition, the memory 110 is configured to store one or more keys to be used to generate the firmware package 108. In particular, the memory 110 is configured to store a public key 118 and a private key 120 associated with a public key-private key pair and an Advanced Encryption Standard (AES) key 122. In some examples, the AES key 122 is a symmetric key.

[0025] The memory 110 further includes a firmware generator 114, which includes machine-readable instructions that, when executed by the processor core 112, cause the firmware generator 114 to perform one or more operations to generate the firmware package 108. The firmware generator 114 includes a signer 124, which is configured to sign the firmware image 116 with a private key 120 of a public key-private key pair to provide a first signature. The signer 124 is further configured to include a header 132 (e.g., Figure 1 The firmware image 116 is enhanced by using the firmware package 108 in the example embodiment of the present invention to provide an enhanced firmware image 126. Figure 1The firmware image 116 and the header 132 shown in the firmware package 108 in the example together form an enhanced firmware image 126. In some examples, the header 132 includes information related to image metadata, which includes one or more of a signature of the firmware image 116 (e.g., a first signature), a public key 118, a header type / version, an image type of the firmware image 116, an image size of the firmware image 116, a rollback version (e.g., a version of the firmware image 116), etc. The firmware generator 114 further includes an encryptor 128, which is configured to encrypt the enhanced firmware image 127 with the symmetric key 122 (or the AES key 122) to provide an encrypted enhanced firmware image 130 (also referred to as Figure 1 108 in the firmware package 108). The machine-readable instructions for the firmware generator 114 are interpreted herein as including machine-readable commands for the signer 124 and the encryptor 128.

[0026] In addition, signer 124 is configured to sign encrypted enhanced firmware image 130 with private key 120 to provide a second signature. In addition, signer 124 is configured to enhance encrypted enhanced firmware image 130 with the second signature to provide firmware package 108. In some examples, the second signature is included in header 134 (e.g., Figure 1 ), the header is enhanced to the encrypted enhanced firmware image 130. In some examples, the header 134 includes information related to image metadata, which includes one or more of a signature of the firmware image 116 (e.g., a second signature), a public key 118, a header type / version, an image type of the firmware image 116, an image size of the firmware image 116, a rollback version (e.g., a version of the firmware image 116), etc. Although not shown here, in some examples, the firmware generator 114 can be further configured to sign the firmware package 108 with another private key (e.g., a customer private key) of another public key-private key pair (e.g., a customer public key-private key pair) to provide a third signature. In such cases, the firmware generator 114 is further configured to enhance the firmware package 108 with the third signature to provide a signed firmware package (not shown here). In addition, in such cases, the memory 110 can be configured to store another private key and a public key associated with another public key-private key pair (e.g., a customer public key-private key pair). In some examples, firmware package 108 may be signed outside of secure computing platform 102 (eg, on a third-party computing platform) with another private key (eg, a customer private key).

[0027] In response to generating the firmware package 108, the firmware package 108 is provided to the computing platform 104 for updating the firmware associated with the HSM 106. The computing platform 104 includes a processor core 136, a memory 138 (e.g., a non-transitory memory or a non-transitory machine-readable medium), and an HSM 106. The HSM 106 includes an HSM ROM 148 and an HSM firmware area 150. The firmware associated with the HSM 106 (e.g., updateable firmware) is stored in the HSM firmware area 150. The memory 138 includes a non-volatile memory 149 and a volatile memory 151 (e.g., a random access memory (RAM)). The non-volatile memory 149 includes a system ROM, a flash memory, a hard drive, etc. The memory 138 further includes a firmware verifier 140, which includes machine-readable instructions executable by the processor core 136 to perform one or more operations to update the firmware associated with the HSM 106. In some examples, the firmware verifier 140 is included in the system ROM of the memory 138.

[0028] In some examples, the public key 118 and the symmetric key 122 are stored in a factory configuration (FCFG) area associated with the memory 138, which is pre-programmed by the vendor root of trust (RoT). The FCFG area is a special non-volatile memory area dedicated to factory configuration. The FCFG area is only accessible by the system ROM of the memory 138. The firmware verifier 140 is further configured to copy the public key 118 and the symmetric key 122 from the FCFG area to the HSM asset repository 144 stored in the secure memory of the HSM 106. The public key 118 and the symmetric key 122 are copied to the HSM asset repository 144 to enable the HSM 106 to access the public key 118 and the symmetric key 122. The HSM asset repository 144 is only accessible by the system ROM and the HSM ROM 148. No other application can read the keys (e.g., public key 118 and symmetric key 122) stored in the HSM asset repository 144 (or FCFG area), and therefore, the keys stored in the HSM asset repository 144 are securely protected. In an example where the firmware generator 114 is configured to sign the firmware package 108 with another private key (e.g., a customer private key) of another public key-private key pair, the HSM 106 is further configured to store the associated public key (e.g., the customer public key). In some examples, the associated public key of the other public key-private key pair is stored in the system configuration (SCFG) area of ​​the memory 138 (which is pre-programmed by the customer). The firmware verifier 140 is further configured to copy the other private key from the SCFG area to the HSM asset repository 144.

[0029] In response to receiving the firmware package 108 at the computing platform 104, the firmware verifier 140 is configured to verify and dispose of the firmware package 108. Verifying and disposing the firmware package 108 includes downloading the firmware package 108 to a memory 138 associated with the computing platform 104. In some examples, the firmware package 108 may be downloaded to a flash memory (e.g., non-volatile memory) associated with the memory 138. Alternatively, in other examples, the firmware package 108 may be downloaded to a volatile memory 151 (e.g., RAM). In response to downloading the firmware package 108 to the volatile / non-volatile memory, an HSM flag of the firmware verifier 140 is set, which provides an indication to the system ROM associated with the memory 138 that an HSM firmware update is available. In addition, a pointer of the firmware verifier 140 is set, which provides an indication to the system ROM about the location to download the firmware package 108. Subsequently, the computing platform 104 is reset.

[0030] The system ROM (particularly the firmware verifier 140) is then configured to detect the firmware package 108 based on checking the HSM flag and pointer. If the firmware package 108 is in flash memory (e.g., non-volatile memory), in some examples, the system ROM is configured to copy the firmware package to volatile memory 151 (e.g., RAM). Alternatively, in other examples, the firmware package 108 is not copied to the volatile memory 151 and is stored in the flash memory itself. Subsequently, the firmware verifier 140 is configured to request the HSM 106 to verify the second signature of the firmware package 108. The HSM 106 includes a firmware updater 146, which includes machine-readable instructions that, when executed by the HSM 106 (or a processor core associated therewith), will perform one or more operations for updating the firmware associated with the HSM 106. In particular, the HSM updater 146 is configured to receive a request to verify the second signature. Upon receiving the request to verify the second signature, the firmware updater 146 is configured to verify the second signature of the firmware package 108 by using the public key 118 stored in the HSM asset repository 144. By verifying the second signature, the firmware updater 146 verifies the integrity and authenticity of the firmware package 108. Once the second signature is verified, the firmware updater 146 is configured to provide a verification indication to the firmware verifier 140 (particularly the system ROM) indicating whether the verification of the second signature passed or failed.

[0031] In an example where the firmware generator 114 is configured to sign the firmware package 108 with another private key (e.g., a customer private key) of another public-private key pair (as explained above), the firmware verifier 140 (particularly the system ROM) can be configured to request the HSM 106 to verify the third signature of the firmware package 108 before requesting the HSM 106 to verify the second signature. In such an example, the firmware updater 146 is configured to verify the third signature by using another public key (e.g., the customer public key) stored in the HSM asset repository 144 in response to receiving the request to verify the third signature. In addition, the firmware updater 146 is configured to provide a verification indication to the firmware verifier 140 (particularly the system ROM) indicating whether the verification of the third signature passed or failed.

[0032] In some cases, the firmware verifier 140 is configured to request verification of the second signature only if the third signature is verified by the firmware updater 146 (in particular, the verification of the third signature has passed). By verifying the third signature, the firmware updater 146 verifies the integrity of the firmware package 108. If the firmware package 108 signed with another private key is in flash memory (e.g., non-volatile memory), in some examples, the system ROM (in particular, the firmware verifier 140) can be configured to copy the firmware package 108 with the third signature to the volatile memory 151 (e.g., RAM) before requesting verification of the third signature. Alternatively, in other examples, the firmware package 108 with the third signature is not copied to the volatile memory 151 before requesting verification of the third signature, and is saved in the flash memory itself. The request to verify the second signature and the third signature from the firmware verifier 140 (in particular, the system ROM) can include details of the location of the firmware package 108 within the firmware verifier 140 to enable the firmware updater 146 to verify the second signature and the third signature.

[0033] In response to receiving an indication that verification of the second signature has passed, the firmware verifier 140 is configured to extract the encrypted enhanced firmware image 130 from the firmware package 108. The encrypted enhanced firmware image 130 may be stored in a flash memory (e.g., non-volatile memory) or a volatile memory 151 of the firmware verifier 140. In response to extracting the encrypted enhanced firmware image 130, the firmware verifier 140 is configured to request the HSM 106 to decrypt the encrypted enhanced firmware image 130. The firmware updater 146 is configured to receive a request to decrypt the encrypted enhanced firmware image 130. In response to receiving the request to decrypt the encrypted enhanced firmware image 130, the firmware updater 146 is configured to decrypt the encrypted enhanced firmware image 130 using a symmetric key (e.g., an AES key) 122 stored in the HSM asset repository 144 to provide a decrypted enhanced firmware image 152. In some examples, the decrypted enhanced firmware image 152 is the same as the enhanced firmware image 126. In some examples, decrypted enhanced firmware image 152 is stored in volatile memory 151 of firmware verifier 140. In some examples, if encrypted enhanced firmware image 130 is stored in flash memory (e.g., non-volatile memory) of firmware verifier 140, firmware verifier 140 (particularly system ROM) is optionally configured to copy encrypted enhanced firmware image 130 to volatile memory 151 before requesting decryption of encrypted enhanced firmware image 130.

[0034] In response to the decrypted enhanced firmware image 152 stored in the volatile memory 151, the firmware verifier 140 (particularly the system ROM) is configured to transmit the decrypted enhanced firmware image 152 to the HSM 106, and in particular to the HSM firmware area 150. Alternatively, in other examples, the firmware verifier 140 (particularly the system ROM) is configured to transmit the decrypted enhanced firmware image 152 as a decrypted block of data to the HSM firmware area 150 of the HSM 106 without storing the complete decrypted enhanced firmware image 152 in the volatile memory 151. In such examples, blocks of the decrypted enhanced firmware image 152 may be stored in the volatile memory 151. Furthermore, in some examples, in response to the firmware updater 146 decrypting the encrypted enhanced firmware image 130 to form the decrypted enhanced firmware image 152, the firmware verifier 140 is configured to transmit the decrypted enhanced firmware image 152 to the HSM firmware area 150 without storing the entire decrypted enhanced firmware image 152 or blocks of the decrypted enhanced firmware image 152 in the volatile memory 151. In examples where the decrypted enhanced firmware image 152 is stored in the volatile memory 151, the firmware verifier 140 is optionally configured to request the HSM 106 to verify a first signature of the decrypted enhanced firmware image 152 before transmitting the decrypted enhanced firmware image 152 to the HSM 106. In response to receiving the request to verify the first signature, the HSM 106, and in particular the firmware updater 146, is configured to verify the first signature of the decrypted enhanced firmware image 152 using a public key stored in the HSM asset repository 144. Once the first signature of the decrypted enhanced firmware image 152 is verified, the firmware updater 146 is further configured to provide a verification indication to the firmware verifier 140 indicating whether the verification of the first signature passed or failed.

[0035] In such examples, the firmware verifier 140 (particularly the system ROM) is configured to, in response to receiving a verification indication indicating that verification of the first signature has passed, transfer the decrypted enhanced firmware image 152 to the HSM firmware area 150. In some examples, in response to transferring the decrypted enhanced firmware image 152 to the HSM firmware area 150, the firmware verifier 140 is further configured to write the decrypted enhanced firmware image 152 to a flash memory associated with the HSM firmware area 250. In examples where the HSM firmware area 150 already has firmware stored in the HSM 106 (particularly in the HSM firmware area 150), the firmware verifier 140 is configured to overwrite / replace the firmware previously stored in the HSM firmware area 150 (e.g., in a flash memory associated therewith) with the decrypted enhanced firmware image 152. Alternatively, in other examples, in response to transferring the decrypted enhanced firmware image 152 to the HSM firmware area 15, the firmware updater 146 is configured to write the decrypted enhanced firmware image 152 to a flash memory associated with the HSM firmware area 50. In examples where the HSM firmware area already has firmware stored in the HSM 106 (particularly in the HSM firmware area 150), the firmware updater 146 is configured to overwrite / replace the firmware previously stored in the HSM firmware area 150 (e.g., in flash memory associated therewith) with the decrypted enhanced firmware image 152.

[0036] In response to writing the complete decrypted enhanced firmware image 152 to the flash memory associated with the HSM firmware area 150, the firmware updater 146 is configured to verify the first signature in the decrypted enhanced firmware image 152 using the public key stored in the HSM asset repository 144 to verify the integrity and authenticity of the firmware image 116 of the decrypted enhanced firmware image 152.

[0037] In some examples, firmware updater 146 is configured to confirm that a bus identifier (ID) of the transmission matches a read-only memory (ROM) firmware ID of HSM 106, and the transmission of firmware image 116 and the verification of the first signature are responsive to the confirmation. In some examples, the bus ID is embedded in a system bus associated with computing platform 104, and firmware updater 146 is configured to verify the bus ID embedded in the system bus. Alternatively, in other examples, firmware verifier 140 can be configured to add a bus identifier (ID) to the command that initiates the transmission, wherein the bus ID matches the read-only memory (ROM) firmware ID in HSM 106.

[0038] In some examples, the firmware verifier 140 is configured to verify / read the firmware version stored in the HSM 106 (particularly in the HSM firmware area 150) before transmitting the decrypted enhanced firmware image 152 to the HSM 106 (particularly in the HSM firmware area 150) to provide HSM firmware rollback protection. In addition, the firmware verifier 140 is configured to transmit the decrypted enhanced firmware image 152 to the HSM 106 (particularly to the HSM firmware area 150) in response to determining that the version of the firmware image 116 in the decrypted enhanced firmware image 152 is later than or equal to the version of the firmware stored in the HSM 106 (particularly in the HSM firmware area 150). In addition, in some examples, the firmware verifier 140 (particularly the system ROM) is configured to verify / read the firmware version stored in the HSM 106 (particularly in the HSM firmware area 150) before requesting verification of the second signature / third signature of the firmware package 108. In such examples, the firmware verifier 140 is configured to request verification of the second signature / third signature in response to determining that the version of the firmware image 116 in the decrypted enhanced firmware image 152 is later than or equal to the version of the firmware stored in the HSM 106 (particularly in the HSM firmware area 150).

[0039] In response to the verification of the first signature being passed, the firmware updater 146 is configured to provide an indication of the completion of the HSM firmware update to the firmware verifier 140. The HSM firmware update is completed only after the decrypted enhanced firmware image 152 is written to the HSM firmware area 150 and after the firmware updater 146 has verified the first signature. After receiving the indication of the completion of the HSM firmware update, the firmware verifier 140 is configured to delete / erase the decrypted enhanced firmware image 152 from the volatile memory 151 (for example, in the case where the complete decrypted enhanced firmware image or a block of the decrypted enhanced firmware image 152 is stored in the volatile memory 151). In addition, the firmware verifier 140 is configured to issue / provide a boot command to the firmware updater 146 (particularly to the HSM ROM 148) to boot the HSM 106. Subsequently, the firmware verifier 140 waits until the firmware image 116 is accepted by the HSM 106 (confirmed by checking the read status register associated with the HSM 106). Once the firmware image 116 is accepted by the HSM 106, the firmware verifier 140 is configured to update a monotonic counter associated with the HSM 106 to indicate the version / revision number of the firmware image 116. Once the monotonic counter is updated, the firmware verifier 140 is configured to clear the HSM flag associated with the memory 138 and exit the process for updating the firmware.

[0040] In some examples, by utilizing the system ROM (e.g., firmware verifier 140) and HSM ROM 148 to update the firmware of HSM 106, computing system 100 is able to update the firmware of HSM 106 without the need for pre-programmed software. In addition, by storing the decrypted enhanced firmware image 152 in volatile memory of computing platform 104 (or by preventing the decrypted enhanced firmware image 152 from being stored in non-volatile memory), computing system 100 facilitates secure updates of HSM firmware. In particular, in one case, if a power failure occurs during a firmware update of HSM 106, the decrypted enhanced firmware image 152 is automatically deleted from the volatile memory, thereby preventing the decrypted enhanced firmware image 152 (e.g., unencrypted data) from being compromised. Furthermore, by signing the firmware image 116 at the firmware generator 114 before and after encryption, the computing system 100 allows the firmware image 116 to be decrypted at the firmware verifier 140 of the computing platform 104 (e.g., to form a decrypted enhanced firmware image 152) before the firmware image 116 is moved / copied to the HSM 106. Copying the decrypted version of the firmware image 116 to the HSM 106 enables the elimination of the need to retain additional memory in the HSM 106 to store the encrypted version of the firmware image 116. Furthermore, in some examples, by verifying the version of the firmware image 116 before updating the HSM firmware, the computing system 100 supports rollback protection. Furthermore, by verifying the bus ID, the computing system 100 allows only an authorized root of trust (e.g., system ROM) to update the HSM firmware.

[0041] Figure 2A and Figure 2B Flowchart 200 for a computing system is illustrated, which illustrates a process for updating firmware associated with a hardware security module (HSM). Flowchart 200 depicts a computing system including a secure computing platform 202, a third-party computing platform 203, and a computing platform 204. Secure computing platform 202 includes a firmware generator 214. Additionally, computing platform 204 includes a firmware verifier 240 and HSM 206. In some examples, third-party computing platform 203 can be part of secure computing platform 202. In this example, the computing system is similar to Figure 1 The computing system 100 in FIG. 1 is used herein, and thus, the features / functionality of the computing system 100 are applicable herein.

[0042] At 260, the firmware generator 214 is configured to use a first private key (e.g., Figure 1 The private key 120 in the firmware image (eg, Figure 1The firmware generator 214 is configured to sign the firmware image 116 in the firmware image 116 to provide a first signature. The first private key is associated with the first public key to form a first public key private key pair. At 262, the firmware generator 214 is configured to send a header ( Figure 1 header 132 in the header 132) to enhance the firmware image to provide an enhanced firmware image (e.g., Figure 1 At 264, the firmware generator 214 is configured to use the AES key of the SCP (e.g., Figure 1 The enhanced firmware image is encrypted using the AES / symmetric key 122 in the embodiment of the present invention to provide an encrypted enhanced firmware image (e.g., Figure 1 At 266, the firmware generator 214 is further configured to sign the encrypted enhanced firmware image with the first private key of the SCP to provide a second signature.

[0043] At 268, the firmware generator 214 is configured to generate a header (eg, Figure 1 header 132 in the encrypted enhanced firmware image to provide a firmware package 208 (e.g., Figure 1 At 270, the third party computing platform 203 or the firmware generator 214 is configured to sign the firmware package 208 with a private key (eg, a second private key) of the third party to provide a third signature.

[0044] The second private key is associated with the second public key (or the public key of the third party) to form a second public key private key pair. At 272, the third party computing platform 203 (or the firmware generator 214) is configured to enhance the firmware package 208 with the third signature to provide a signed firmware package. In some examples, signing the firmware package 208 with the private key of the third party at 270 and enhancing the firmware package 208 with the third signature at 272 are omitted.

[0045] In some examples, the first public key, the AES key, and the second public key are stored in an HSM asset repository associated with the HSM 206. At 274, the firmware verifier 240 is configured to receive a signed firmware package from the firmware generator 214 / third-party computing platform 203. At 276, the firmware verifier 240 is configured to request a firmware version from the HSM 206 (particularly, request a version of the firmware stored in the HSM 206). At 278, the HSM 206 is configured to provide the firmware version to the firmware verifier 240. In particular, the HSM 206 is configured to provide the firmware verifier 240 with a version / version number of the firmware stored in the HSM 206. Although not mentioned herein, it should be understood that Figure 2A and Figure 2BThe operations performed by HSM 206 are performed by the HSMROM associated with HSM 206 (e.g., Figure 1 HSM ROM 148 in the Figure 1 At 280, in response to receiving the firmware version from HSM 206, firmware verifier 240 is configured to verify whether the signed firmware package has a later version or the same version. In particular, firmware verifier 240 is configured to verify whether the version or version number of the firmware image associated with the signed firmware package has a later version / version number or the same version / version number as the version / version number received from HSM 206.

[0046] In some examples, if it is determined at 280 that the signed firmware package has no later version or the same version as the version / version number received from the HSM 206, the firmware verifier 240 may no longer proceed with the procedure for updating the firmware of the HSM 206, thereby providing rollback protection. However, if it is determined at 280 that the signed firmware package has a later version or the same version as the version / version number received from the HSM 206, the firmware verifier 240 proceeds to 282. At 282, the firmware verifier 240 is configured to request the HSM 206 to verify the third signature of the signed firmware package. At 284, in response to receiving the request to verify the third signature, the HSM 206 is configured to verify the third signature using a public key of a third party (e.g., a second public key of a second public key-private key pair). In addition, at 286, the HSM 206 is configured to provide a signature verification response to the firmware verifier 240. The signature verification response may indicate whether the verification of the third signature is passed or failed.

[0047] In the example where the signature verification response received at 286 indicates that verification of the third signature has failed, the firmware verifier 240 may no longer proceed with the procedure of updating the firmware of the HSM 206. Alternatively, if the signature verification response received at 286 indicates that verification of the third signature has passed, the firmware verifier 240 proceeds to 288. At 288, the firmware verifier 240 is configured to request verification of the second signature associated with the firmware package from the HSM 206.

[0048] At 290, in response to receiving the request to verify the second signature, HSM 206 is configured to verify the second signature using the first public key of the first public-private key pair. In addition, at 292, HSM 206 is configured to provide a signature verification response to firmware verifier 240. The signature verification response at 292 may indicate whether the verification of the second signature passed or failed. If the signature verification response received at 292 indicates that the verification of the second signature failed, then firmware verifier 240 may no longer proceed with the procedure of updating the firmware of HSM 206. Alternatively, if the signature verification response received at 292 indicates that the verification of the second signature has passed, then firmware verifier 240 proceeds to Figure 2B 294 of 3. Figure 2B At 294 , the firmware verifier 240 is configured to extract the encrypted enhanced firmware image from the firmware package. The encrypted enhanced firmware image may be stored in flash memory or RAM associated with the computing platform 204 .

[0049] In response to extracting the encrypted enhanced firmware image, at 296, the firmware verifier 240 is configured to request the HSM 206 to decrypt the encrypted enhanced firmware package. At 298, the HSM 206 (particularly the HSM firmware updater in the HSM ROM) is configured to decrypt the encrypted enhanced firmware image using a symmetric key (e.g., an AES key) to provide a decrypted enhanced firmware image. At 300, the firmware verifier 240 is configured to store the complete / full decrypted enhanced firmware image or a block of the decrypted enhanced firmware image in a volatile memory (e.g., Figure 1204). Although not shown here, in response to the HSM 206 providing the decrypted enhanced firmware image, the firmware verifier 240 can be configured to provide a command to the HSM 206 (particularly the HSM ROM associated therewith) to initiate the transfer of the decrypted enhanced firmware image to the HSM 206. At 302, in response to receiving the command to initiate the transfer, the HSM 206 is configured to confirm that the bus identifier (ID) of the transfer matches the read-only memory (ROM) firmware ID of the HSM 206. In some examples, the bus ID matching the ROM firmware ID provides an indication to the HSM 206 that the command to initiate the transfer was received from the system ROM associated with the computing platform 204. In some examples, the bus ID is embedded in a system bus associated with the computing platform 204, and the HSM 206 is configured to verify the bus ID embedded in the system bus. Alternatively, in other examples, the firmware verifier 240 may be configured to add a bus identifier (ID) to the command initiating the transfer, where the bus ID matches a read-only memory (ROM) firmware ID in the HSM 206. In response to the HSM 106 confirming that the transmitted bus ID matches the ROM firmware ID of the HSM 206, at 304, the firmware verifier 240 is configured to transfer / copy the decrypted enhanced firmware image (e.g., in its entirety or block by block) to the HSM 206.

[0050] In some examples, before transmitting the decrypted enhanced firmware image to the HSM 206 at 304, although not shown here, the firmware verifier 240 can be configured to request the HSM 206 to verify the first signature of the decrypted enhanced firmware image. In response to receiving the request to verify the first signature, the HSM 206 can be configured to verify the first signature using the first public key of the first public key-private key pair. In response to verifying the first signature, the HSM 206 can be configured to provide a signature verification response to the firmware verifier 240. The signature verification response can indicate whether the verification of the first signature passed or failed. In some examples, the firmware verifier 240 can be configured to transmit the decrypted enhanced firmware image to the HSM 206 only when the signature verification response indicates that the verification of the first signature has passed.

[0051] Additionally, in some examples, before transmitting the decrypted enhanced firmware image to the HSM 206 at 304, although not shown here, the firmware verifier 240 can be configured to request a firmware version from the HSM 206 (particularly, request a version of the firmware stored in the HSM 206). In response, the HSM 206 can be configured to provide the firmware version to the firmware verifier 240. In some examples, the firmware verifier 240 can be configured to transmit the decrypted enhanced firmware image to the HSM 206 only if the version of the firmware image associated with the decrypted enhanced firmware image is later than or equal to the version of the firmware stored in the HSM 106.

[0052] In response to transmitting the decrypted enhanced firmware image to the HSM 206, at 306, the HSM 206 (e.g., a firmware updater associated therewith) is configured to write the decrypted enhanced firmware image (e.g., in its entirety or block by block) to an HSM firmware area (e.g., Figure 1 Alternatively, in some examples, although not shown here, at 306, firmware verifier 240 may be configured to write the decrypted enhanced firmware image (e.g., in its entirety or block by block) to a memory location (e.g., flash memory) in an HSM firmware area (e.g., HSM firmware area 150) associated with HSM 206. Figure 1 206). In some examples, the decrypted enhanced firmware image overwrites / replaces the firmware already stored in the HSM firmware area of ​​the HSM 206. At 308, in response to writing the decrypted enhanced firmware image, the HSM 206 is configured to verify the first signature of the decrypted enhanced firmware image using the first public key of the first public key-private key pair. The first public key of the first public key-private key pair may be stored in an HSM asset repository of the HSM 206.

[0053] In response to passing the verification of the first signature, at 310, HSM 206 is configured to provide a firmware update completion indication (or a write completion indication) to firmware verifier 240. At 312, in response to receiving the firmware update completion indication (or a write completion indication), firmware verifier 240 is configured to delete / erase the complete or residual decrypted enhanced firmware image from the volatile memory / RAM associated with computing platform 204.

[0054] Figures 3 to 10 Illustrate the various steps when updating the HSM firmware. In some examples, Figures 3 to 10 The various steps depicted in can correspond to Figure 2A and Figure 2B One or more steps shown in flowchart 200 in FIG. Figures 3 to 10 depicts the sequential relationship relative to each other, and Figures 3 to 10 The same numbering is used to depict the same structures. Figure 1 All features of the computing system 100 in Figures 3 to 10 . Figure 3 A block diagram 400 is depicted for illustrating the procedure for forming a signed firmware package. Figure 3 As can be seen in FIG. 4 , the firmware image 416 is signed using private key 1 420 (e.g., the first private key of the first public-private key pair) to provide signature 1 (e.g., the first signature). Subsequently, the firmware image 416 is enhanced with a header 432 including signature 1 (e.g., the first signature) to provide an enhanced firmware image 426.

[0055] The enhanced firmware image 426 is encrypted using an AES key 422 (e.g., a symmetric key) to form an encrypted enhanced firmware image 430. The encrypted enhanced firmware image 430 is signed using a private key 1 420 (e.g., a first private key) to provide a signature 2 (e.g., a second signature). The encrypted enhanced firmware image 430 is enhanced with a header 434 including the signature 2 (e.g., the second signature) to provide a firmware package 408. The firmware package 408 is signed using a private key 2 454 (e.g., a second private key of a second public key private key pair) to provide a signature 3 (e.g., a third signature). The firmware package 408 is enhanced with the signature 3 (i.e., the third signature) in the header 434 to provide a signed firmware package 456. The public key 1 (e.g., the first public key of the first public key private key pair), the AES key, and the public key 2 (e.g., the second public key of the second public key private key pair) are stored in the HSM asset repository 444.

[0056] Figure 4 Diagram showing the transfer of various keys to an HSM (e.g. Figure 1 In particular, the public key 1 and the AES key are transmitted by the firmware verifier (e.g., Figure 1 The firmware verifier 140 in FIG. 140 is copied from the FCFG area 458 to the HSM asset repository 444. Similarly, the public key 2 is copied from the SCFG area 460 to the HSM asset repository 444 by the firmware verifier.

[0057] Figure 5 An example diagram 600 of receiving a signed firmware package 456 at a computing platform 404 is depicted. Figure 5 As can be seen in FIG. 4 , the signed firmware package 456 is received at the firmware verifier 440. Receiving the signed firmware package 456 at the firmware verifier 440 includes downloading the signed firmware package 456 to a memory associated with the computing platform (e.g., Figure 1The memory includes a system ROM 462 and a FLASH (flash) / RAM memory 464 including flash and RAM. The firmware verifier 440 is configured to download the signed firmware package 456 to the flash or RAM associated with the FLASH / RAM memory 464.

[0058] Figure 6 An example diagram 700 of verifying firmware versions and signatures at a computing platform 404 is depicted. Figure 6 As can be seen in FIG. 5 , the system ROM 462 (particularly the firmware verifier 440) provides a request 504 to read the monotonic counter to the HSM ROM 448 (particularly the firmware updater 446). The HSM ROM 448 is a HSM (e.g., Figure 2A and Figure 2B The HSM 206 is a part of the HSM 206 in the HSM. The HSM further includes an HSM firmware area 450 and an HSM asset repository 444. Reading the monotonic counter provides the version (e.g., version number) of the firmware that has been stored in the HSM firmware area 450. In response to receiving the request 504 to read the monotonic counter, the HSM ROM 448 (particularly the firmware updater 446) is configured to provide a response 508 to the system ROM 462 (particularly the firmware verifier 440). The response 508 includes the version or version number of the firmware that has been stored in the HSM firmware area 450. If no firmware is stored in the HSM firmware area 450, the response 508 may not return a version number (or the version number is 0).

[0059] In response to receiving the response 508, the system ROM 462 (particularly the firmware verifier 440) is configured to compare the version number included in the response 508 with the version / version number of the firmware image 416 in the signed firmware package 456, and verify whether the version / version number of the firmware image 416 in the signed firmware package 456 is later than or equal to the version / version number included in the response 508. The version / version number of the firmware image 416 in the signed firmware package 456 may be included in the header 432 associated with the signed firmware package 456. The system ROM 462 (particularly the firmware verifier 440) is further configured to provide a verify signature 3 request 512 to the HSM ROM 448 (particularly the firmware updater 446) to verify the signature 3 included in the header 434 associated with the signed firmware package 456. In some examples, Rivest-Shamir-Adleman (RSA) signature verification is implemented to verify the signature 3. In response to receiving the verify signature 3 request 512, HSM ROM 448 (particularly firmware updater 446) is configured to provide a confirmation of signature 3 verification 516 to system ROM 462 (particularly firmware verifier 440). Confirmation of signature 3 verification 516 may indicate whether the verification of signature 3 passed or failed.

[0060] The system ROM 462 (particularly the firmware verifier 440) is further configured to provide a verify signature 2 request 520 to the HSM ROM 448 (particularly the firmware updater 446) to verify the signature 2 included in the header 434 associated with the signed firmware package 456. In some examples, RSA signature verification is implemented to verify the signature 2. In response to receiving the verify signature 2 request 520, the HSM ROM 448 (particularly the firmware updater 446) is configured to provide a confirmation of the signature 2 verification 524 to the system ROM 462 (particularly the firmware verifier 440). The confirmation of the verification of the signature 2 524 can indicate whether the verification of the signature 2 passed or failed.

[0061] Figure 7 An example diagram 800 of decryption of an encrypted enhanced firmware image 430 at a computing platform 104 is depicted. Figure 7 As can be seen in FIG. 5 , the system ROM 462 (particularly the firmware verifier 440) is configured to provide an Advanced Encryption Standard (AES) decryption request 528 to the HSM ROM 448 (particularly the firmware updater 446). In response to receiving the AES decryption request 528, the HSM ROM 448 (particularly the firmware updater 446) is configured to decrypt the encrypted enhanced firmware image 430 using the AES key stored in the HSM asset repository 444 to provide a decrypted enhanced firmware image 426. Figure 7 The decrypted enhanced firmware image 426 and Figure 3 The enhanced firmware image 426 in is the same, so the same numbering is used herein. In this example, the complete decrypted enhanced firmware image 426 is stored in RAM 465 (e.g., volatile memory) of the FLASH / RAM memory 464. The FLASH / RAM memory 464 further includes flash memory 463 (e.g., non-volatile memory). Alternatively, in other examples, the complete decrypted enhanced firmware image 426 is not stored in RAM 465, but blocks of the decrypted enhanced firmware image 426 can be stored in RAM 465 and transferred to the HSM to be written to the HSM firmware area 450; this option is considered in computing platforms that do not have enough volatile memory / RAM to save the complete decrypted enhanced firmware image. Blocks of the decrypted enhanced firmware image can be written in a volatile memory-limited device by supporting all required passwords and firmware update functions (including HSM FW decryption, verification, and writing to the HSM flash area) through the firmware updater 446, and by verifying the second signature, which confirms that a valid firmware image has been received before starting to overwrite the HSM firmware area. Furthermore, in some examples, neither the complete decrypted enhanced firmware image 426 nor blocks of the decrypted enhanced firmware image 426 are stored in RAM 465 , but rather the firmware updater 446 decrypts the encrypted enhanced firmware image 430 and writes the decrypted enhanced firmware image 426 directly into the HSM firmware area 450 .

[0062] Figure 8 An example diagram 900 is depicted of verifying a first signature at a computing platform 404 when a complete decrypted enhanced firmware image 426 is stored in RAM 465 (eg, volatile memory). Figure 8 As can be seen in FIG. 5 , the system ROM 462 (particularly the firmware verifier 440) is optionally configured to provide a verify signature 1 request 536 to the HSM ROM 448 (particularly the firmware updater 446) to verify the signature 1 included in the header 432 associated with the decrypted enhanced firmware image 426. In some examples, Rivest-Shamir-Adleman (RSA) signature verification is implemented to verify the signature 1. The HSM ROM 448 (particularly the firmware updater 446) is configured to verify the signature 1 by using the public key 1 stored in the HSM asset repository 444. In response to verifying the signature 1, the HSM ROM 448 (particularly the firmware updater 447) is configured to provide a confirmation 540 of the verification of the signature 1 to the system ROM 462 (particularly the firmware verifier 440). The confirmation 540 of the verification of the signature 1 can indicate whether the verification of the signature 1 passed or failed.

[0063] Fig.9AAn example diagram 1000 of a procedure for transferring a decrypted enhanced firmware image stored in volatile memory to an HSM is depicted. Fig.9A As can be seen in FIG. 5 , the decrypted enhanced firmware image 426 stored in the volatile memory / RAM 465 is copied / transferred from the RAM 465 to the HSM firmware area 450 via the copy / transfer message 544. In some examples, the complete / full decrypted enhanced firmware image 426 is stored in the volatile memory / RAM 465, and the complete / full decrypted enhanced firmware image 426 is copied / transferred from the RAM 465 to the HSM firmware area 450 via the copy / transfer message 544. Alternatively, in other examples, blocks of the decrypted enhanced firmware image 426 are stored in the volatile memory / RAM 465 as they are decrypted, and then the blocks of the decrypted enhanced firmware image 426 are copied / transferred from the RAM 465 to the HSM firmware area 450 via the copy / transfer message 544. Fig. 9B An example diagram 1100 of a procedure for transferring a decrypted enhanced firmware image 426 directly to an HSM without storing the entire decrypted enhanced firmware image 426 or a block of the decrypted enhanced firmware image 426 in volatile memory is depicted. Fig. 9B As can be seen, via the decryption and copy / transfer message 546, the encrypted enhanced firmware image 430 is decrypted by the firmware updater 446 to provide a decrypted enhanced firmware image 426, and the decrypted enhanced firmware image 426 is directly copied / transferred to the HSM firmware area 450, and then the decrypted enhanced firmware image 426 is written to the HSM firmware area 45.

[0064] Fig.10 An example diagram 1500 of a procedure for deleting a decrypted enhanced firmware image 426 from volatile memory / RAM 465 associated with a computing platform 404 is depicted. Fig.10 As can be seen in FIG. 4 , the decrypted enhanced firmware image 426 is deleted / erased from RAM 465. In some examples, the firmware verifier 440 is configured to delete / erase the complete or residual decrypted enhanced firmware image 426 in response to receiving an indication from the HSM ROM 448 (particularly the firmware updater 446) that the writing of the decrypted enhanced firmware image 426 and the verification of the valid signature have been completed. In some examples, such as Fig.10As can be seen in FIG, the firmware verifier 440 is further configured to provide a boot command 548 to the HSM ROM 448 (particularly the firmware updater 446) to boot the HSM with the updated firmware (e.g., the firmware image 416). In response to providing the boot command 548, the firmware verifier 440 waits until the firmware image 416 is accepted by the HSM (verified by checking a read status register associated with the HSM). In response to the HSM accepting the firmware image 416, the firmware verifier 440 is configured to update a monotonic counter associated with the HSM to indicate / reflect the version / version number of the firmware image 416. Once the monotonic counter is updated, the firmware verifier 440 is configured to clear the HSM flag associated with the computing platform 404 and exit the process for updating the firmware.

[0065] Fig.11 A flowchart illustrating a method 1200 for generating a firmware package to be used to update firmware associated with a hardware security module (HSM). In some examples, the method 1200 may use Figure 1 For clarity, this article refers to Figure 1 The computing system 100 and Figure 3 The method 1200 is explained with reference to the secure computing platform 402 in FIG. 1202. At 1202, a first private key of a first public key private key pair (eg, Figure 3 420) for a firmware image (e.g., Figure 3 The firmware image 416 in the embodiment is signed to provide a first signature (eg, Figure 3 At 1204, the firmware image is provided with a header including a first signature (e.g., Figure 3 header 432 in the header 432) to provide an enhanced firmware image (e.g., Figure 3 At 1206, the enhanced firmware image 426 in FIG. 1 is generated using a symmetric key (e.g., Figure 3 The enhanced firmware image is encrypted using the AES key 422 in the embodiment of the present invention to provide an encrypted enhanced firmware image (e.g., Figure 3 At 1208, the encrypted enhanced firmware image is signed with the first private key of the first public-private key pair to provide a second signature (e.g., Figure 3 At 1210, the encrypted enhanced firmware image is enhanced with a second signature to provide a firmware package (e.g., Figure 3 At 1212, a second private key of a second public key-private key pair (eg, Figure 3 The firmware package is signed using the private key 2 454 in to provide a third signature (e.g., Figure 3In some examples, the second public-private key pair is associated with the customer. At 1214, the firmware package is enhanced with a third signature to provide a signed firmware package (e.g., Figure 3 In some examples, signing the firmware package with the second private key to provide a third signature (e.g., at 1212) and enhancing the firmware package with the third signature to provide a signed firmware package (e.g., at 1214) are omitted.

[0066] Fig.12 A flowchart illustrating a method 1300 for verifying a firmware image to be used to update firmware associated with a hardware security module (HSM). In some examples, the method 1300 may use Figure 1 The firmware verifier 140 and the firmware updater 146 in the embodiment are implemented. For the sake of clarity, this article refers to Figure 1 , Figure 3 and Figures 6 to 10 Method 1300 is explained. At 1302, using a firmware verifier (e.g., Figure 6 The firmware verifier 440 in the embodiment receives the firmware package (e.g., downloaded to Figure 6 404 in the computing platform 404). In some examples, the firmware package corresponds to Figure 6 The signed firmware package 456 in includes signature 1, signature 2 and signature 3. Alternatively, in other examples, the firmware package may correspond to Figure 3 The firmware package 408 in includes signature 1 and signature 2, but does not include signature 3.

[0067] At 1304, a firmware verifier request is used (eg, via Figure 6 Request 610 in the HSM verifies the first signature of the firmware package (e.g., Figure 6 2 in the signature). It should be noted that the ordinal numbers first, second, and third used to refer to the signatures used herein are not intended to have a temporal relationship, but are used herein only for the purpose of distinction. The HSM uses the first public key of the first public key-private key pair (e.g., Figure 6 The first signature is verified using the public key 1 in the HSM. The first public key is a public key associated with the supplier. At 1306, in response to an indication from the HSM that the first signature has been verified (e.g., Figure 6 524), extracting the encrypted enhanced firmware image from the firmware package (e.g., Figure 7 The encrypted enhanced firmware image 430 in .

[0068] At 1308, the firmware verifier requests (eg, via Figure 7 The HSM decrypts the encrypted enhanced firmware image. In response to the decryption request, the HSM uses a symmetric key (e.g., Figure 7 ) to provide a decrypted enhanced firmware image (e.g. Figure 7 At 1310, the decrypted enhanced firmware image (e.g., via Fig.9A Copy / transfer message 544 or via Fig. 9B decryption and copy / transfer information 546 in the HSM (e.g., to Fig.9A or Fig. 9B In particular, in some examples, the complete decrypted enhanced firmware image is stored (or temporarily stored) in volatile memory before the complete decrypted enhanced firmware image is transmitted to the HSM. Alternatively, in other examples, blocks of the decrypted enhanced firmware image are stored in volatile memory / RAM and then transmitted to the HSM without storing the complete decrypted enhanced firmware image in volatile memory. Furthermore, in some examples, the decrypted enhanced firmware image is transmitted to the HSM without storing the complete decrypted enhanced firmware image or blocks of the decrypted enhanced firmware image in volatile memory. At 1312, the decrypted enhanced firmware image is written to the HSM using the firmware updater / firmware verifier (e.g., written to Fig.9A or Fig. 9B The firmware package received at 1302 includes a third signature (e.g., Figure 6 In the example of a signature 3 in the signed firmware package 456 in , before requesting verification of the first signature at 1304, a firmware verifier request is used (e.g., via Figure 6 In particular, in response to an indication from the HSM that the third signature has been verified (e.g., via Figure 6 516), performs a request to verify the first signature of the firmware package. At 1314, by the firmware updater (e.g., Fig.9A or Fig. 9B The firmware updater 446 in the example uses the first public key (eg, Fig.9A or Fig. 9B 1) to verify the second signature in the decrypted enhanced firmware image (e.g., Fig.9A or Fig. 9B The signature in 1).

[0069] Modifications may be made in the described embodiments, and other embodiments are possible, within the scope of the claims.

Claims

1. A non-transitory machine-readable medium having machine-readable instructions comprising a firmware generator, the machine-readable instructions for the firmware generator being executable by a processor core to perform operations comprising: Signing a firmware image of a hardware security module (HSM) with a private key of a public-private key pair to provide a first signature; enhancing the firmware image with a header including the first signature to provide an enhanced firmware image; encrypting the enhanced firmware image with a symmetric key to provide an encrypted enhanced firmware image; signing the encrypted enhanced firmware image with the private key to provide a second signature; as well as The encrypted enhanced firmware image is enhanced with the second signature to provide a firmware package for the HSM.

2. The non-transitory machine-readable medium of claim 1, wherein the private key is a first private key and the public-private key pair is a first public-private key pair, the operations for the firmware generator further comprising: Signing the firmware package with a second private key of a second public-private key pair to provide a third signature; as well as The firmware package is enhanced with the third signature to provide a signed firmware package.

3. A non-transitory machine-readable medium having machine-readable instructions including a firmware verifier, the machine-readable instructions for the firmware verifier being executable by a processor core to perform operations comprising: Requesting a hardware security module (HSM) to verify a first signature of a firmware package for the HSM, wherein the HSM verifies integrity of the firmware package using a public key of a public-private key pair; extracting an encrypted enhanced firmware image from the firmware package in response to an indication from the HSM that the first signature is verified; requesting the HSM to decrypt the encrypted enhanced firmware image, wherein in response to the decryption request, the HSM provides a decrypted enhanced firmware image using a symmetric key; as well as The decrypted enhanced firmware image is transmitted to the HSM, wherein the decrypted enhanced firmware image includes a second signature that can be verified using the public key.

4. The non-transitory machine-readable medium of claim 3, wherein the decrypted enhanced firmware image or the block of the decrypted enhanced firmware is stored in a volatile memory.

5. The non-transitory machine-readable medium of claim 4, wherein the copy of the firmware package is stored in a non-volatile memory.

6. The non-transitory machine-readable medium of claim 5, wherein prior to requesting verification of the first signature, a firmware package is copied to the volatile memory.

7. The non-transitory machine-readable medium of claim 3, wherein the operations further comprise reading a version of firmware stored in the HSM, and wherein the transmitting is performed in response to a version of a firmware image in the decrypted enhanced firmware image being later than the version of the firmware stored in the HSM.

8. The non-transitory machine-readable medium of claim 3, wherein the operations further comprise requesting the HSM to verify the second signature of the decrypted enhanced firmware image, wherein the HSM verifies the integrity of the decrypted enhanced firmware image using the public key, and the transmission is a response to an indication from the HSM that the second signature has been verified.

9. The non-transitory machine-readable medium of claim 3, wherein the operations further comprise adding a bus identifier (ID) to a command that initiates the transfer, wherein the bus ID matches a read-only memory (ROM) firmware ID in the HSM.

10. A system comprising: Hardware security modules (HSMs) that store updateable firmware; a non-transitory memory having machine-readable instructions; as well as a processor core that accesses the non-transitory memory and executes the machine-readable instructions, the machine-readable instructions comprising a firmware validator executable by the processor core to perform operations comprising: Requesting the HSM to verify a first signature of a firmware package for the HSM, wherein the HSM verifies the integrity of the firmware package using a public key of a public key-private key pair; extracting an encrypted enhanced firmware image from the firmware package in response to an indication from the HSM that the first signature is verified; requesting the HSM to decrypt the encrypted enhanced firmware image, wherein in response to the decryption request, the HSM provides a decrypted enhanced firmware image using a symmetric key; and transmitting the decrypted enhanced firmware image to the HSM; wherein in response to the transmission, the decrypted enhanced firmware image is written to the HSM firmware area; wherein the HSM includes a firmware updater that can be executed by the HSM to perform operations, and the operations for the firmware updater include: The second signature in the decrypted enhanced firmware image is verified using the public key to verify the integrity of the firmware image in the decrypted enhanced firmware image.

11. The system of claim 10, wherein the firmware package includes a third signature, and the public key is a first public key, and the public-private key pair is a first public-private key pair, the operations for the firmware verifier further comprising: Requesting the HSM to verify a third signature of the firmware package, wherein the HSM verifies the integrity of the firmware package using a second public key of a second public-private key pair, and in response to an indication from the HSM that the third signature has been verified, executing the request to verify the first signature of the firmware package.

12. The system of claim 11, further comprising an HSM asset repository storing the first public key, the symmetric key, and the second public key, wherein the HSM asset repository is stored in a secure memory of the HSM.

13. The system of claim 10, wherein the operations for the firmware updater further include confirming that the transmitted bus identifier (ID) matches a read-only memory (ROM) firmware ID of the HSM, and the verification of the second signature is responsive to the confirmation.

14. The system of claim 10, wherein the decrypted enhanced firmware image or the block of the decrypted enhanced firmware is stored in a volatile memory of the non-transitory memory.

15. The system of claim 14, wherein the operations for the firmware updater further comprise providing an indication of write completion to the firmware verifier.

16. The system of claim 15, wherein the operations for the firmware verifier further comprise deleting the decrypted enhanced firmware image from the non-transitory memory in response to the indication that the write is complete.

17. The system of claim 14, wherein the firmware package is stored in a volatile memory of the non-transitory memory.

18. The system of claim 17, wherein the copy of the firmware package is stored in a non-volatile memory of the non-transitory memory.

19. The system of claim 18, wherein the firmware verifier is configured to copy the firmware package to the volatile memory of the non-transitory memory before requesting verification of the first signature.

20. The system of claim 10, wherein the operation for the firmware verifier further comprises reading a version of firmware stored in the HSM, and wherein the transmitting is performed in response to a version of a firmware image in the decrypted enhanced firmware image being later than a version of the firmware stored in the HSM.

Images