CN119475442A

CN119475442A - Hardware Security Module Firmware Update

Info

Publication number: CN119475442A
Application number: CN202411075557.1A
Authority: CN
Inventors: P·程; B·尼萨嘎
Original assignee: Texas Instruments Inc
Current assignee: Texas Instruments Inc
Priority date: 2023-08-11
Filing date: 2024-08-07
Publication date: 2025-02-18
Also published as: US20250053407A1

Abstract

The present disclosure relates to a non-transitory machine-readable medium having machine-readable instructions comprising a firmware generator (114), the machine-readable instructions for the firmware generator (114) being executable by a processor core (112) to perform operations comprising signing a firmware image (116) of a Hardware Security Module (HSM) (106) with a private key (120) of a public key private key pair to provide a first signature, and augmenting the firmware image (116) with a header (132) comprising the first signature to provide an augmented firmware image (126). The operations further include encrypting the enhanced firmware image (126) with the symmetric key (122) to provide an encrypted enhanced firmware image (130). Further, the operations include signing the encrypted enhanced firmware image (130) with the 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

Hardware security module firmware update

Technical Field

The present disclosure relates to Hardware Security Modules (HSMs), and in particular, the present specification relates to systems and methods for updating firmware in HSMs.

Background

A Hardware Security Module (HSM) is a physical device that provides additional security for sensitive data. HSM is a hardware encryption accelerator module that includes its own Core (CPU), encryption accelerator, and memory. HSM is used to provide encryption keys for functions such as encryption, decryption, and authentication for application, identity, and database usage. HSMs may be embedded in other hardware, including smart cards, appliances, and other external devices. Protecting keys in a cryptographic system helps to maintain a secure system. The HSM protects the encryption keys and handles the encryption and decryption processes. The HSM may also create and verify digital signatures.

Firmware is software embedded in hardware. Firmware consists of programs written by software developers to make the hardware devices function properly. Firmware updates are similar to software updates. The device manufacturer creates updated and better firmware. Updates will add or overwrite existing software on the device to support improved efficiency. Firmware updates may also adjust the performance of the firmware or device drivers, possibly enhancing the performance of the processor or other device hardware. HSM firmware updates enable repair of security vulnerabilities that might otherwise jeopardize the security of the device or the system in which the device is used.

Disclosure of Invention

The first example involves 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 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-key private key pair to provide a first signature, and augmenting the firmware image with a header including the first signature to provide an augmented firmware image. The one or more operations further include encrypting the enhanced firmware image with the symmetric key to provide an encrypted enhanced firmware image. In addition, the one or more operations include signing the encrypted enhanced firmware image with the private key to provide a second signature, and enhancing the encrypted enhanced firmware image with the second signature to provide a firmware package for the HSM.

A second example involves a non-transitory machine-readable medium having machine-readable instructions comprising a firmware verifier, the machine-readable instructions for the firmware verifier being executable by a processor core to perform one or more operations. One or more operations include receiving a firmware package for a Hardware Security Module (HSM), and requesting verification of a first signature of the firmware package by the HSM, wherein the HSM verifies an integrity of the firmware package using a public key of a public-key-private key pair. The one or more operations further include extracting the encrypted enhanced firmware image from the firmware package in response to the indication that the first signature from the HSM is verified, and requesting the HSM to decrypt the encrypted enhanced firmware image, wherein the HSM uses the symmetric key to provide the decrypted enhanced firmware image in response to the decryption request. Further, 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 verifiable using the public key.

A third example relates to a system that includes a Hardware Security Module (HSM) to store updateable firmware, and a non-transitory memory having machine readable instructions. The system further includes a processor core accessing the non-transitory memory and executing machine-readable instructions comprising a firmware verifier executable 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 verification of a first signature of the firmware package by the HSM, wherein the HSM verifies an integrity of the firmware package using a public key of a public-key private key pair, and in response to an indication from the HSM that the first signature is verified, extracting an encrypted enhanced firmware image from the firmware package. The one or more operations further include requesting decryption of the encrypted enhanced firmware image by the HSM, wherein the HSM uses the symmetric key to provide the 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 executable by the HSM to perform operations for the firmware updater including writing the decrypted enhanced firmware image to an HSM firmware area of the HSM and verifying a second signature in the decrypted enhanced firmware image using a public key to verify the integrity of the firmware image in the decrypted enhanced firmware image.

Drawings

FIG. 1 illustrates an example computing system.

Fig. 2A and 2B illustrate a flow chart for a computing system that illustrates a process for updating firmware associated with a Hardware Security Module (HSM).

FIG. 3 depicts a block diagram depicting a procedure for forming a signed firmware package.

Fig. 4 illustrates a transmission procedure for transmitting various keys to an HSM asset repository.

FIG. 5 illustrates an example of receiving a signed firmware package at a computing platform.

FIG. 6 illustrates an example of verifying a firmware version and signature at a computing platform.

FIG. 7 depicts an example diagram of decrypting an encrypted enhanced firmware image at a computing platform.

FIG. 8 depicts an example diagram of verifying a first signature at a computing platform.

Fig. 9A depicts an example diagram of a procedure for transferring a decrypted enhanced firmware image stored in volatile memory to an HSM.

Fig. 9B depicts 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.

FIG. 10 depicts an example diagram of a procedure for deleting a decrypted enhanced firmware image from volatile memory/RAM associated with a computing platform.

Fig. 11 illustrates a flow chart of an example method for generating a firmware package to be used for updating firmware associated with a Hardware Security Module (HSM).

Fig. 12 illustrates a flow chart of an example method for validating a firmware image to be used for updating firmware associated with a Hardware Security Module (HSM).

Detailed Description

The present description relates to updating firmware for a Hardware Security Module (HSM). The update of firmware of the HSM may be used to adjust the performance of the HSM. The HSM described herein has an HSM Read Only Memory (ROM) and an HSM firmware region. The HSM firmware area stores firmware that can be updated. In some examples, the HSM firmware region is read/write protected and is only accessible by the HSM ROM and the corresponding system ROM. In some examples, after HSM delivery/provisioning to the site (or client), firmware of the HSM needs to be updated. When a firmware update of an HSM is involved (which plays an important role in the security of the system), the confidentiality and integrity of the HSM firmware update (e.g., an updated version of the firmware) needs to be verified before the firmware of the HSM is updated. In addition, rollback protection (e.g., preventing execution of incorrect firmware versions) needs to be supported.

In view of the foregoing, described herein are systems and methods for updating firmware of an HSM that verify confidentiality and integrity of the HSM firmware update prior to updating the firmware of the HSM. Furthermore, the systems and methods described herein support rollback protection. The proposed system for updating firmware of an HSM includes a secure computing platform (e.g., at the vendor side) that generates a firmware package that includes a signed and encrypted firmware image (e.g., an updated version of firmware) that is to be used to update firmware (e.g., existing firmware) of the HSM. In particular, to ensure confidentiality of the firmware image, the firmware image is encrypted using a symmetric key (e.g., a vendor's symmetric key). Further, to ensure the integrity of the firmware image, the firmware image is signed twice with a private key of a public-private key pair (e.g., the private key of the vendor), 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, e.g., a customer private key associated with another public-private key pair. After generating the firmware package, the firmware package is distributed on-site (e.g., to the client) for updating the firmware of the HSM at the client.

The system further includes a computing platform at a receiving end (e.g., client) that receives the 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 updating the firmware of the HSM using the firmware image. 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 vendor's end. In addition, to authenticate the integrity of the firmware image, the system ROM and 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 prior to decrypting the firmware image. In addition, the HSM ROM is configured to verify the signature of the firmware image after decrypting the firmware image.

In addition, the system ROM and the HSM ROM are further configured to verify the version of the firmware image prior to performing the HSM firmware update. In some examples, only authorized root of trust (e.g., system ROM) is allowed to perform HSM firmware updates. In particular, a bus ID is added to the command/request to initiate transfer of the firmware image to the HSM, and the HSM accepts the command/request only if the bus Identifier (ID) matches a Read Only Memory (ROM) ID of the system ROM. By verifying the signature before and after decryption, the system supports a strong security function. Furthermore, by utilizing a system ROM and an HSM ROM, the system is able to update the firmware of the HSM without requiring preprogrammed software in the device. In addition, the system supports rollback protection. In addition, signing the firmware image before and after encryption allows the firmware image to be decrypted before it is moved/copied to the HSM, thereby eliminating the need to reserve additional memory in the HSM to store the encrypted firmware image.

FIG. 1 illustrates an example computing system 100. The computing system 100 includes a secure computing platform 102 and a computing platform 104 that includes a Hardware Security Module (HSM) 106. The secure computing platform 102 is configured to provide/generate firmware packages 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, flash memory, solid state drive, 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. Further, memory 110 is configured to store one or more keys to be used in generating firmware package 108. In particular, the memory 110 is configured to store public and private keys 118, 120 associated with a public-key private key pair and an Advanced Encryption Standard (AES) key 122. In some examples, AES key 122 is a symmetric key.

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

In addition, the signer 124 is configured to sign the encrypted enhanced firmware image 130 with the private key 120 to provide a second signature. In addition, the signer 124 is configured to augment the encrypted augmented firmware image 130 with a second signature to provide the firmware package 108. In some examples, the second signature is included in a header 134 (as shown within firmware package 108 in fig. 1) that is enhanced to the encrypted enhanced firmware image 130. In some examples, header 134 includes information related to image metadata including one or more of a signature (e.g., a second signature) of firmware image 116, public key 118, a header type/version, an image type of firmware image 116, an image size of firmware image 116, a rollback version (e.g., a version of firmware image 116), and the like. Although not shown here, in some examples, firmware generator 114 may be further configured to sign 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, firmware generator 114 is further configured to augment firmware package 108 with a third signature to provide a signed firmware package (not shown herein). Further, in such cases, the memory 110 may be configured to store another private key and public key associated with another public key private key pair (e.g., a client public key private key pair). In some examples, firmware package 108 may be signed with another private key (e.g., a customer private key) outside of secure computing platform 102 (e.g., at a third party computing platform).

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

In some examples, public key 118 and symmetric key 122 are stored in a Factory Configuration (FCFG) area (which is preprogrammed by a vendor root of trust (RoT)) associated with memory 138. 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 memory 138. Firmware verifier 140 is further configured to copy public key 118 and symmetric key 122 from the FCFG area to HSM asset repository 144 stored in secure memory of HSM 106. Public key 118 and symmetric key 122 are copied to HSM asset repository 144 to enable HSM 106 to access public key 118 and symmetric key 122.HSM asset store 144 is only accessible by system ROM and HSM ROM 148. No other application can read the keys (e.g., public key 118 and symmetric key 122) stored in HSM asset store 144 (or area FCFG) and, therefore, the keys stored in HSM asset store 144 are secured. In examples where firmware generator 114 is configured to sign firmware package 108 with another private key of another public-key private key pair (e.g., a customer private key), 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 another public key private key pair is stored in a System Configuration (SCFG) area of memory 138, which is preprogrammed by the customer. Firmware verifier 140 is further configured to copy another private key from the SCFG region to HSM asset repository 144.

In response to receiving the firmware package 108 at the computing platform 104, the firmware verifier 140 is configured to verify and handle the firmware package 108. Validating and handling the firmware package 108 includes downloading the firmware package 108 into a memory 138 associated with the computing platform 104. In some examples, firmware package 108 may be downloaded to a flash memory (e.g., non-volatile memory) associated with memory 138. Alternatively, in other examples, firmware package 108 may be downloaded to volatile memory 151 (e.g., RAM). In response to downloading firmware package 108 to volatile/nonvolatile memory, the HSM flag of firmware validator 140 is set, which provides an indication to the system ROM associated with 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 as to the location where the firmware package 108 was downloaded. Subsequently, the computing platform 104 is reset.

The system ROM (and in particular the firmware validator 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), then in some examples, the system ROM is configured to copy the firmware package to volatile memory 151 (e.g., RAM). Alternatively, in other examples, firmware package 108 is not copied to volatile memory 151 and is saved in the flash memory itself. Subsequently, firmware verifier 140 is configured to request HSM 106 to verify the second signature of firmware package 108. The HSM 106 includes a firmware updater 146 that 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 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 store 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 (in particular the system ROM) indicating whether verification of the second signature passed or failed.

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

In some cases, firmware verifier 140 is configured to request verification of the second signature only if the third signature is verified by firmware updater 146 (in particular, 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), then in some examples, the system ROM (and in particular the firmware verifier 140) may be configured to copy the firmware package 108 with the third signature to 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 and saved in the flash memory itself prior to requesting verification of the third signature. The request from firmware verifier 140 (particularly the system ROM) to verify the second and third signatures may include details of the location of firmware package 108 within firmware verifier 140 to enable firmware updater 146 to verify the second and third signatures.

In response to receiving the indication that verification of the second signature has passed, firmware verifier 140 is configured to extract encrypted enhanced firmware image 130 from firmware package 108. The encrypted enhanced firmware image 130 may be stored in a flash memory (e.g., non-volatile memory) or 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 a request to decrypt the encrypted enhanced firmware image 130, the firmware updater 146 is configured to decrypt the encrypted enhanced firmware image 130 using the symmetric key (e.g., AES key) 122 stored in the HSM asset store 144 to provide a decrypted enhanced firmware image 152. In some examples, decrypted enhanced firmware image 152 is the same as enhanced firmware image 126. In some examples, the decrypted enhanced firmware image 152 is stored in volatile memory 151 of firmware verifier 140. In some examples, if the encrypted enhanced firmware image 130 is stored in a flash memory (e.g., non-volatile memory) of the firmware verifier 140, the firmware verifier 140 (and in particular the system ROM) is optionally configured to copy the encrypted enhanced firmware image 130 to the volatile memory 151 prior to requesting decryption of the encrypted enhanced firmware image 130.

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 transfer the decrypted enhanced firmware image 152 to the HSM 106, particularly to the HSM firmware region 150. Alternatively, in other examples, firmware validator 140 (particularly a system ROM) is configured to transfer decrypted enhanced firmware image 152 as a decrypted data block to HSM firmware region 150 of HSM 106 without storing the complete decrypted enhanced firmware image 152 in volatile memory 151. In such examples, the blocks of the decrypted enhanced firmware image 152 may be stored in the volatile memory 151. Further, in some examples, in response to firmware updater 146 decrypting encrypted enhanced firmware image 130 to form decrypted enhanced firmware image 152, firmware validator 140 is configured to transfer decrypted enhanced firmware image 152 to HSM firmware region 150 without storing complete decrypted enhanced firmware image 152 or blocks of decrypted enhanced firmware image 152 in volatile memory 151. In the example where the decrypted enhanced firmware image 152 is stored in the volatile memory 151, the firmware verifier 140 is optionally configured to request that the HSM 106 verify the first signature of the decrypted enhanced firmware image 152 prior to 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 the public key stored in the HSM asset store 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 verification of the first signature passed or failed.

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

In response to writing the complete decrypted enhanced firmware image 152 to the flash memory associated with the HSM firmware region 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 store 144 to verify the integrity and authenticity of the firmware image 116 of the decrypted enhanced firmware image 152.

In some examples, the firmware updater 146 is configured to confirm that the transmitted bus Identifier (ID) matches a Read Only Memory (ROM) firmware ID of the HSM 106, and that the transmission of the firmware image 116 and verification of the first signature is a response to the confirmation. In some examples, the bus ID is embedded in a system bus associated with the computing platform 104, and the firmware updater 146 is configured to verify the bus ID embedded in the system bus. Alternatively, in other examples, firmware validator 140 may be configured to add a bus Identifier (ID) to the command to initiate the transfer, where the bus ID matches a Read Only Memory (ROM) firmware ID in HSM 106.

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

In response to verification of the first signature passing, firmware updater 146 is configured to provide an indication to firmware verifier 140 that the HSM firmware update is complete. The HSM firmware update is completed only after the decrypted enhanced firmware image 152 is written to the HSM firmware region 150 and after the firmware updater 146 has verified the first signature. Upon receiving an indication that the HSM firmware update is complete, the firmware verifier 140 is configured to delete/erase the decrypted enhanced firmware image 152 from the volatile memory 151 (e.g., where the entire decrypted enhanced firmware image or blocks of the decrypted enhanced firmware image 152 are stored in the volatile memory 151). In addition, firmware verifier 140 is configured to issue/provide boot commands to firmware updater 146 (and in particular to HSM ROM 148) to boot HSM 106. Subsequently, firmware validator 140 waits until firmware image 116 is accepted by HSM 106 (confirmed by checking a read status register associated with 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/version number of the firmware image 116. Once the monotonic counter is updated, firmware verifier 140 is configured to clear the HSM flag associated with memory 138 and exit the process for updating the firmware.

In some examples, computing system 100 is able to update firmware of HSM 106 without requiring preprogrammed software by updating the firmware of HSM 106 with system ROM (e.g., firmware verifier 140) and HSM ROM 148. In addition, computing system 100 facilitates securely updating HSM firmware by storing decrypted enhanced firmware image 152 in volatile memory of computing platform 104 (or by preventing decrypted enhanced firmware image 152 from being stored in non-volatile memory). In particular, in one case, if a power failure occurs during a firmware update of the HSM 106, the decrypted enhanced firmware image 152 may be automatically deleted from volatile memory, thereby preventing the decrypted enhanced firmware image 152 (e.g., unencrypted data) from being compromised. Further, 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 the decrypted enhanced firmware image 152) before moving/copying the firmware image 116 to the HSM 106. Copying the decrypted version of the firmware image 116 to the HSM 106 enables no additional memory to be required to be reserved in the HSM 106 to store the encrypted version of the firmware image 116. Further, in some examples, computing system 100 supports rollback protection by verifying the version of firmware image 116 prior to updating HSM firmware. Further, by verifying the bus ID, computing system 100 allows only authorized root of trust (e.g., system ROM) to update HSM firmware.

Fig. 2A and 2B illustrate a flow chart 200 for a computing system that 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 firmware generator 214. In addition, computing platform 204 includes firmware validator 240 and HSM 206. In some examples, the third party computing platform 203 may be part of the secure computing platform 202. In this example, the computing system is similar to computing system 100 in fig. 1, and thus, the features/functions of computing system 100 apply here.

At 260, firmware generator 214 is configured to sign a firmware image (e.g., firmware image 116 in fig. 1) with a first private key of a Secure Copy Protocol (SCP) (e.g., private key 120 in fig. 1) to provide a first signature. The first private key is associated with the first public key, thereby forming a first public-private key pair. At 262, the firmware generator 214 is configured to augment the firmware image with a header (header 132 in fig. 1) including the first signature to provide an augmented firmware image (e.g., augmented firmware image 126 in fig. 1). At 264, the firmware generator 214 is configured to encrypt the enhanced firmware image using the AES key of the SCP (e.g., AES/symmetric key 122 in fig. 1) to provide an encrypted enhanced firmware image (e.g., encrypted enhanced firmware image 130 in fig. 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.

At 268, firmware generator 214 is configured to augment the encrypted augmented firmware image with a header (e.g., header 132 of fig. 1) including the second signature to provide firmware package 208 (e.g., firmware package 108 of fig. 1). At 270, the third party computing platform 203 or firmware generator 214 is configured to sign the firmware package 208 with a private key of the third party (e.g., a second private key) to provide a third signature.

The second private key is associated with a second public key (or a third party's public key), thereby forming a second public-key private key pair. At 272, the third party computing platform 203 (or firmware generator 214) is configured to augment the firmware package 208 with a 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 is omitted, and the firmware package 208 is enhanced with the third signature at 272.

In some examples, the first public key, the AES key, and the second public key are stored in an HSM asset store associated with HSM 206. At 274, firmware verifier 240 is configured to receive the signed firmware package from firmware generator 214/third party computing platform 203. At 276, firmware verifier 240 is configured to request a firmware version from HSM 206 (in particular, a version of firmware stored in HSM 206). At 278, hsm 206 is configured to provide the firmware version to firmware verifier 240. In particular, HSM 206 is configured to provide firmware verifier 240 with a version/version number of firmware stored within HSM 206. Although not mentioned herein, it should be understood that the operations performed by HSM 206 in FIGS. 2A and 2B are performed by an HSM ROM (e.g., HSM ROM 148 in FIG. 1) or a firmware updater (e.g., firmware updater 146 in FIG. 1) associated with HSM 206. 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 at 280. 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.

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 HSM 206, firmware verifier 240 may no longer proceed with the procedure to update the firmware of 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 HSM 206, firmware verifier 240 proceeds to 282. At 282, the firmware verifier 240 is configured to request verification of the third signature of the signed firmware package from the HSM 206. 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 the third party (e.g., the second public key of the second public-key private-key pair) 284. Further, at 286, hsm 206 is configured to provide a signature verification response to firmware verifier 240. The signature verification response may indicate whether verification of the third signature passed or failed.

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

At 290, in response to receiving the request to verify the second signature, the HSM 206 is configured to verify the second signature using the first public key of the first public-key private-key pair. Further, 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 verification of the second signature passed or failed. If the signature verification response received at 292 indicates that verification of the second signature failed, firmware verifier 240 may no longer proceed with the procedure to update the firmware of HSM 206. Alternatively, if the signature verification response received at 292 indicates that verification of the second signature has passed, firmware verifier 240 proceeds to 294 in fig. 2B. Referring to fig.2B, at 294, 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 computing platform 204.

In response to extracting the encrypted enhanced firmware image, at 296, firmware verifier 240 is configured to request HSM 206 to decrypt the encrypted enhanced firmware package. At 298, the HSM 206 (particularly an HSM firmware updater in the HSM ROM) is configured to decrypt the encrypted enhanced firmware image using a symmetric key (e.g., AES key) to provide a decrypted enhanced firmware image. At 300, 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., volatile memory 151 in fig. 1). Although not shown here, in response to HSM 206 providing the decrypted enhanced firmware image, firmware verifier 240 may be configured to provide a command to HSM 206 (and in particular the HSM ROM associated therewith) to initiate transmission of the decrypted enhanced firmware image to HSM 206. At 302, in response to receiving a command to initiate a transmission, the HSM 206 is configured to confirm that the bus Identifier (ID) of the transmission matches a Read Only Memory (ROM) firmware ID of the HSM 206. In some examples, a bus ID matching the ROM firmware ID provides an indication to HSM 206 indicating that a command to initiate a transmission was received from a system ROM associated with 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, firmware validator 240 may be configured to add a bus Identifier (ID) to the command to initiate the transfer, where the bus ID matches a Read Only Memory (ROM) firmware ID in HSM 206. In response to HSM 106 confirming that the transmitted bus ID matches the ROM firmware ID of HSM 206, firmware verifier 240 is configured to transmit/copy the decrypted enhanced firmware image (e.g., full or block-by-block) to HSM 206 at 304.

In some examples, before transmitting the decrypted enhanced firmware image to HSM 206 at 304, although not shown here, firmware verifier 240 may be configured to request verification of the first signature of the decrypted enhanced firmware image from HSM 206. In response to receiving the request to verify the first signature, the HSM 206 may 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, HSM 206 may be configured to provide a signature verification response to firmware verifier 240. The signature verification response may indicate whether verification of the first signature passed or failed. In some examples, firmware verifier 240 may be configured to transmit the decrypted enhanced firmware image to HSM 206 only if the signature verification response indicates that verification of the first signature has passed.

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

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

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

Fig. 3-10 illustrate various steps in updating HSM firmware. In some examples, the various steps depicted in fig. 3-10 may correspond to one or more steps shown in flowchart 200 in fig. 2A and 2B. Fig. 3-10 depict sequential relationships with respect to each other, and fig. 3-10 depict like structures using like numbers. All features of the computing system 100 in fig. 1 are also applicable to fig. 3-10. Fig. 3 depicts a block diagram 400 illustrating a procedure for forming a signed firmware package. As can be seen in fig. 3, 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, firmware image 416 is enhanced with header 432 including signature 1 (e.g., a first signature) to provide enhanced firmware image 426.

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 private key 1 420 (e.g., the first private key) to provide signature 2 (e.g., the second signature). The encrypted enhanced firmware image 430 is enhanced with a header 434 that includes signature 2 (e.g., a second signature) to provide the firmware package 408. Firmware package 408 is signed using private key 2 454 (e.g., the second private key of the second public-key private key pair) to provide signature 3 (e.g., a third signature). Firmware package 408 is enhanced with signature 3 (i.e., a third signature) in header 434 to provide signed firmware package 456. Public key 1 (e.g., a first public key of a first public-key private key pair), AES key, and public key 2 (e.g., a second public key of a second public-key private key pair) are stored in HSM asset store 444.

Fig. 4 illustrates a transmission procedure 500 for transmitting various keys to an HSM asset repository 444 associated with an HSM (e.g., HSM 106 in fig. 1). In particular, public key 1 and the AES key are copied from FCFG area 458 to HSM asset repository 444 by a firmware verifier (e.g., firmware verifier 140 in fig. 1). Similarly, public key 2 is copied by the firmware verifier from SCFG region 460 to HSM asset repository 444.

FIG. 5 depicts an example diagram 600 of receiving a signed firmware package 456 at computing platform 404. As can be seen in fig. 5, signed firmware package 456 is received at firmware verifier 440. Receiving signed firmware package 456 at firmware verifier 440 includes downloading signed firmware package 456 into a memory associated with the computing platform (e.g., memory 138 in fig. 1). The memory includes a system ROM 462 and FLASH (FLASH)/RAM memory 464 including FLASH memory and RAM. Firmware verifier 440 is configured to download signed firmware package 456 to FLASH or RAM associated with FLASH/RAM memory 464.

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

In response to receiving response 508, system ROM 462 (and in particular firmware verifier 440) is configured to compare the version number included in response 508 with the version/version number of firmware image 416 in signed firmware package 456 and verify whether the version/version number of firmware image 416 in signed firmware package 456 is later than or equal to the version/version number included in response 508. The version/version number of firmware image 416 in signed firmware package 456 may be included in header 432 associated with signed firmware package 456. The system ROM 462 (particularly firmware verifier 440) is further configured to provide a verify signature 3 request 512 to the HSM ROM 448 (particularly firmware updater 446) in order to verify 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 signature 3. In response to receiving verification signature 3 request 512, HSM ROM 448 (particularly firmware updater 446) is configured to provide verification 516 of signature 3 verification to system ROM 462 (particularly firmware verifier 440). The validation 516 of the verification of signature 3 may indicate whether the verification of signature 3 passed or failed.

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

Fig. 7 depicts an example diagram 800 of decryption of an enhanced firmware image 430 encrypted at a computing platform 104. As can be seen in fig. 7, 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 AES decryption request 528, HSM ROM 448 (and in particular firmware updater 446) is configured to decrypt encrypted enhanced firmware image 430 using the AES keys stored in HSM asset store 444 to provide decrypted enhanced firmware image 426. The decrypted enhanced firmware image 426 in fig. 7 and the enhanced firmware image 426 in fig. 3 are identical, and thus the same numbers are used herein. In this example, the complete decrypted enhanced firmware image 426 is stored in RAM 465 (e.g., volatile memory) of FLASH/RAM memory 464. 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 rather blocks of the decrypted enhanced firmware image 426 may be stored in RAM 465 and transferred to the HSM to be written to the HSM firmware area 450, this option being considered in a computing platform that does not have sufficient volatile memory/RAM to hold the complete decrypted enhanced firmware image. All required cryptographic and firmware update functions (including HSM FW decryption, verification, and writing to the HSM flash area) are supported by firmware updater 446, and by verifying a second signature, blocks of the decrypted enhanced firmware image can be written in the volatile memory limited device, which confirms that a valid firmware image was received before overwriting of the HSM firmware area was started. Furthermore, in some examples, neither the complete decrypted enhanced firmware image 426 nor the 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.

FIG. 8 depicts an example diagram 900 of verifying a first signature at the computing platform 404 when the complete decrypted enhanced firmware image 426 is stored in RAM 465 (e.g., volatile memory). As can be seen in fig. 8, system ROM 462 (particularly firmware verifier 440) is optionally configured to provide verification signature 1 request 536 to HSM ROM 448 (particularly firmware updater 446) in order to verify signature 1 included in header 432 associated with decrypted enhanced firmware image 426. In some examples, rivest-Shamir-Adleman (RSA) signature verification is implemented to verify signature 1.HSM ROM 448 (particularly firmware updater 446) is configured to verify signature 1 by using public key 1 stored in HSM asset store 444. In response to verifying signature 1, hsm ROM 448 (particularly firmware updater 447) is configured to provide a verification 540 of signature 1 verification to system ROM 462 (particularly firmware verifier 440). The validation 540 of the verification of signature 1 may indicate whether the verification of signature 1 passed or failed.

Fig. 9A depicts an example diagram 1000 of a procedure for transferring a decrypted enhanced firmware image stored in volatile memory to an HSM. As can be seen in fig. 9A, the decrypted enhanced firmware image 426 stored in the volatile memory/RAM 465 is copied/transferred from the RAM 465 to the HSM firmware region 450 via copy/transfer message 544. In some examples, the complete/full decrypted enhanced firmware image 426 is stored in volatile memory/RAM 465 and the complete/full decrypted enhanced firmware image 426 is copied/transferred from RAM 465 to HSM firmware region 450 via copy/transfer message 544. Alternatively, in other examples, the blocks of decrypted enhanced firmware image 426 are stored in volatile memory/RAM 465 as they are decrypted, and then the blocks of decrypted enhanced firmware image 426 are copied/transferred from RAM 465 to HSM firmware region 450 via copy/transfer message 544. Fig. 9B depicts 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 blocks of the decrypted enhanced firmware image 426 in volatile memory. As seen in fig. 9B, via decryption and copy/transmit message 546, encrypted enhanced firmware image 430 is decrypted by firmware updater 446 to provide decrypted enhanced firmware image 426, and decrypted enhanced firmware image 426 is copied/transmitted directly to HSM firmware region 450, which in turn writes decrypted enhanced firmware image 426 to HSM firmware region 45.

FIG. 10 depicts an example diagram 1500 of a procedure for deleting a decrypted enhanced firmware image 426 from a volatile memory/RAM 465 associated with a computing platform 404. As can be seen in fig. 10, the decrypted enhanced firmware image 426 is deleted/erased from RAM 465. In some examples, firmware verifier 440 is configured to delete/erase a complete or residual decrypted enhanced firmware image 426 in response to receiving an indication from HSM ROM 448 (particularly firmware updater 446) that writing of the decrypted enhanced firmware image 426 and valid signature verification is complete. In some examples, as can be seen in fig. 10, firmware validator 440 is further configured to provide boot command 548 to HSM ROM 448 (particularly firmware updater 446) to boot the HSM using the updated firmware (e.g., firmware image 416). In response to providing boot command 548, firmware verifier 440 waits until 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 firmware image 416, firmware verifier 440 is configured to update a monotonic counter associated with the HSM to indicate/reflect the version/version number of firmware image 416. Once the monotonic counter is updated, firmware verifier 440 is configured to clear the HSM flag associated with computing platform 404 and exit the process for updating the firmware.

Fig. 11 illustrates a flow chart of a method 1200 for generating a firmware package to be used to update firmware associated with a Hardware Security Module (HSM). In some examples, method 1200 may be implemented using firmware generator 114 in fig. 1. For clarity, the method 1200 is explained herein with reference to the computing system 100 in fig. 1 and the secure computing platform 402 in fig. 3. At 1202, a firmware image (e.g., firmware image 416 of fig. 3) is signed using a first private key of a first public-key private key pair (e.g., private key 1 420 of fig. 3) to provide a first signature (e.g., signature 1 of fig. 3). At 1204, the firmware image is enhanced with a header (e.g., header 432 in fig. 3) including the first signature to provide an enhanced firmware image (e.g., enhanced firmware image 426 in fig. 3). At 1206, the enhanced firmware image is encrypted with a symmetric key (e.g., AES key 422 in fig. 3) to provide an encrypted enhanced firmware image (e.g., encrypted enhanced firmware image 430 in fig. 3). At 1208, the encrypted enhanced firmware image is signed with a first private key of the first public-private key pair to provide a second signature (e.g., signature 2 in fig. 3). At 1210, the encrypted enhanced firmware image is enhanced with a second signature to provide a firmware package (e.g., firmware package 408 in fig. 3). At 1212, the firmware package is signed with a second private key of the second public-key private key pair (e.g., private key 2 454 in fig. 3) to provide a third signature (e.g., signature 3 in fig. 3). In some examples, the second public-key private key pair is associated with the client. At 1214, the firmware package is enhanced with a third signature to provide a signed firmware package (e.g., signed firmware package 456 in fig. 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) is omitted.

Fig. 12 illustrates a flow chart of a method 1300 for validating a firmware image to be used for updating firmware associated with a Hardware Security Module (HSM). In some examples, method 1300 may be implemented using firmware verifier 140 and firmware updater 146 in fig. 1. For clarity, method 1300 is explained herein with reference to fig. 1,3, and 6-10. At 1302, a firmware package is received (e.g., downloaded to FLASH/RAM memory 464 associated with computing platform 404 in fig. 6) using a firmware verifier (e.g., firmware verifier 440 in fig. 6). In some examples, the firmware package corresponds to signed firmware package 456 in fig. 6, which includes signature 1, signature 2, and signature 3. Alternatively, in other examples, the firmware package may correspond to firmware package 408 in fig. 3, which includes signature 1 and signature 2, but does not include signature 3.

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

At 1308, the encrypted enhanced firmware image is decrypted using the firmware verifier request (e.g., via decryption request 528 in fig. 7) HSM. In response to the decryption request, the HSM uses a symmetric key (e.g., the AES key in fig. 7) to provide a decrypted enhanced firmware image (e.g., the decrypted enhanced firmware image 426 in fig. 7). At 1310, the decrypted enhanced firmware image is transmitted (e.g., via copy/transmit message 544 in fig. 9A or via decrypt and copy/transmit information 546 in fig. 9B) to the HSM (e.g., to HSM firmware region 450 in fig. 9A or 9B) using the firmware verifier. In particular, in some examples, the complete decrypted enhanced firmware image is stored (or staged) in volatile memory before being transferred to the HSM. Alternatively, in other examples, the blocks of the decrypted enhanced firmware image are stored in volatile memory/RAM and then transferred to the HSM without storing the complete decrypted enhanced firmware image in volatile memory. Further, in some examples, the decrypted enhanced firmware image is transferred 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 (e.g., to HSM firmware region 450 in fig. 9A or 9B) using a firmware updater/firmware verifier. In an example where the firmware package received at 1302 includes a third signature (e.g., signature 3 as in signed firmware package 456 in fig. 6), the third signature is verified using a firmware verifier request (e.g., via request 512 in fig. 6) HSM before the request to verify the first signature is made at 1304. In particular, in response to an indication from the HSM that the third signature has been verified (e.g., via acknowledgement 516 in fig. 6), a request to verify the first signature of the firmware package is performed. At 1314, a second signature (e.g., signature 1 in fig. 9A or 9B) in the decrypted enhanced firmware image is verified by a firmware updater (e.g., firmware updater 446 in fig. 9A or 9B) using a first public key (e.g., public key 1 in fig. 9A or 9B).

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-key private key pair to provide a first signature;

augmenting the firmware image with a header including the first signature to provide an augmented 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, and

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 key private key pair is a first public key private key pair, the operations for the firmware generator further comprising:

Signing the firmware package with a second private key of a second public-key private key pair to provide a third signature, and

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 comprising 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 the 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 that the first signature from the HSM is verified;

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

The decrypted enhanced firmware image is transmitted to the HSM, wherein the decrypted enhanced firmware image includes a second signature verifiable with the public key.

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

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

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

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 firmware image in the decrypted enhanced firmware image being later than the version of 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 an integrity of the decrypted enhanced firmware image using the public key, and the transmission is a response to an indication that the second signature from the HSM 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 to initiate the transmission, wherein the bus ID matches a read-only memory (ROM) firmware ID in the HSM.

10. A system, comprising:

a Hardware Security Module (HSM) storing the updatable firmware;

Non-transitory memory with machine-readable instructions, and

A processor core accessing the non-transitory memory and executing the machine-readable instructions, the machine-readable instructions comprising a firmware verifier executable by the processor core to perform operations comprising:

Requesting the HSM to verify a first signature for a firmware package of the HSM, wherein the HSM verifies the integrity of the firmware package using a public key of a public-key private key pair;

Requesting the HSM to decrypt the encrypted enhanced firmware image, wherein in response to the decryption request, the HSM uses a symmetric key to provide a decrypted enhanced firmware image, and

Transmitting the decrypted enhanced firmware image to the HSM;

wherein the HSM includes a firmware updater executable by the HSM to perform operations in response to the transmission, the operations for the firmware updater comprising:

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-key-private key pair is a first public-key-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 was verified, performing 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 comprise 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 a response to the confirmation.

14. The system of claim 10, wherein the decrypted enhanced firmware image or the block of 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 volatile memory of the non-transitory memory.

18. The system of claim 17, wherein a 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 prior to requesting verification of the first signature.

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