Dual packaging for authentication

Abstract

This application relates to double wrapping for verification. In some cases, a memory sub-system can receive a firmware image for the memory sub-system, where the firmware image is signed with a first signature according to a first signing procedure. The memory sub-system can then verify the integrity of the firmware image based on the first signing procedure. After verifying the integrity of the firmware image, the memory sub-system can then generate a second signature for the firmware image based on a second signing procedure that is different from the first signing procedure. The memory sub-system can then write the second signature to the firmware image. The memory sub-system can then conduct a verification process to verify the integrity of the firmware image based on one or both of the first or second signing procedures. In this case, a first verification time is associated with the first signing procedure and is greater than a second verification time associated with the second signing procedure.

Description

[0001] Information related to divisional application

[0002] This application is a divisional application of Chinese invention patent application No. 202011546806.2, filed on December 24, 2020, entitled "Double Packaging for Verification".

[0003] Cross-references

[0004] This patent application claims priority to U.S. Patent Application No. 16 / 731,918, filed December 31, 2019, entitled “Double Wrapping for Verification”, by Markey et al., which has been assigned to its assignee and is expressly incorporated herein by reference in its entirety. Technical Field

[0005] The technical field relates to double packaging for verification. Background Technology

[0006] The memory subsystem may include one or more memory devices for storing data. These memory devices may be, for example, non-volatile memory devices and volatile memory devices. Typically, the host system can utilize the memory subsystem to store data at the memory devices and retrieve data from the memory devices. Summary of the Invention

[0007] A method is described. In some instances, the method may include: receiving a firmware image of a memory subsystem at a memory subsystem, the firmware image being signed with a first signature according to a first signing procedure; verifying the integrity of the firmware image at least in part based on the first signing procedure; after verifying the integrity, generating a second signature of the firmware image at least in part based on a second signing procedure different from the first signing procedure; writing the second signature into the firmware image by the memory subsystem; and performing a verification process of the firmware image at least in part based on one or both of the first signing procedure or the second signing procedure to verify the integrity of the firmware image, wherein a first verification time associated with the first signing procedure is greater than a second verification time associated with the second signing procedure.

[0008] A method is described. In some instances, the method may include: generating a first signature of a firmware image of a memory subsystem according to a first signing procedure; writing the first signature into the firmware image; verifying the integrity of the firmware image at the memory subsystem based at least in part on the first signing procedure and the first signature; after verifying the integrity, writing a second signature into the firmware image based at least in part on a second signing procedure different from the first signing procedure; and performing a verification process of the firmware image according to the second signing procedure to verify the integrity of the firmware image, wherein a first verification time associated with the first signing procedure is greater than a second verification time associated with the second signing procedure.

[0009] A non-transitory computer-readable storage medium is described. In some instances, the non-transitory computer-readable storage medium may include instructions that, when executed by a processing device, cause the processing device to: receive a firmware image of the memory subsystem at a memory subsystem, the firmware image being signed with a first signature according to a first signing procedure; verify the integrity of the firmware image at least in part based on the first signing procedure; after verifying the integrity, generate a second signature of the firmware image at least in part based on a second signing procedure different from the first signing procedure; write the second signature into the firmware image by the memory subsystem; and perform a verification process of the firmware image at least in part based on one or both of the first signing procedure or the second signing procedure to verify the integrity of the firmware image, wherein a first verification time associated with the first signing procedure is greater than a second verification time associated with the second signing procedure. Attached Figure Description

[0010] Figure 1 This is an example of a computing system based on the examples disclosed in this article.

[0011] Figure 2 This is a flowchart of an exemplary method for verifying the integrity of a firmware image of a memory subsystem according to some embodiments of the present disclosure.

[0012] Figure 3 This is a diagram of an exemplary system for verifying the integrity of a firmware image supporting a memory subsystem according to some embodiments of this disclosure.

[0013] Figure 4 This is an exemplary machine of a computer system in which the examples disclosed herein may operate. Detailed Implementation

[0014] Various aspects of this disclosure relate to dual packaging for verification. The memory subsystem may be a storage device, a memory module, or a hybrid of both. References Figure 1 Examples of storage devices and memory modules are described. Typically, a host system may utilize a memory subsystem that includes one or more components, such as a memory device for storing data. The host system can provide data to be stored in the memory subsystem and can request to retrieve data from the memory subsystem.

[0015] The storage subsystem can receive firmware images (e.g., firmware used to update the storage subsystem). Firmware images can be downloaded (e.g., from a server) or sent to the storage subsystem from another source (e.g., the storage subsystem's manufacturer or firmware manufacturer). However, if the firmware image is corrupted (e.g., the firmware data is unreadable or invalid) or compromised by an attacker, resulting in the firmware image containing code different from its source code, the storage subsystem loading the corrupted or compromised firmware may be susceptible to inoperability, data loss, or other malicious attacks. In some instances, the firmware image may become corrupted after it has been received and loaded (e.g., stored) at the storage subsystem. To address corruption or other firmware issues, the storage subsystem can be configured to verify the integrity of the firmware image to ensure it is not corrupted or compromised. Verification can be performed when the storage subsystem receives the firmware image and / or when the storage subsystem is powered on (e.g., booted) and running the firmware. Depending on the verification technology used by the storage subsystem, the time required to verify the integrity of the firmware image may introduce delays in the operation or startup process of the storage subsystem.

[0016] Various aspects of this disclosure address the above and other shortcomings by having a memory subsystem comprising a verification manager that can use multiple types of cryptographic programs and / or redundant cryptographic programs to verify the integrity of the firmware image. For example, the verification manager can verify the firmware image based on symmetric cryptography, asymmetric cryptography, or both. The ability to verify the firmware image via different cryptographic programs enables the memory subsystem to maintain its security while reducing the latency impact of firmware verification on the memory subsystem.

[0017] First, the features of this disclosure are described in the context of the computing environment, as referenced in [reference]. Figure 1 The features of this disclosure are described in the context of flowcharts and system diagrams, as referenced. Figure 2 and 3 As described. These and other features of this disclosure are further illustrated by a computer system involving double packaging for verification, and these and other features are described with reference to the computer system, as referenced in [reference]. Figure 4As described.

[0018] Figure 1 This is an example of a computing system 100 including a memory subsystem 110 according to some embodiments of the present disclosure. The memory subsystem 110 may include media, such as one or more volatile memory devices (e.g., memory device 140), one or more non-volatile memory devices (e.g., memory device 130), or a combination thereof.

[0019] The memory subsystem 110 may be a storage device, a memory module, or a combination of both. Examples of storage devices include solid-state drives (SSDs), flash drives, universal serial bus (USB) flash drives, embedded multimedia controller (eMMC) drives, universal flash storage (UFS) drives, secure digital cards (SD cards), and hard disk drives (HDDs). Examples of memory modules include dual in-line memory modules (DIMMs), small form factor DIMMs (SO-DIMMs), and various types of non-volatile dual in-line memory modules (NVDIMMs).

[0020] The computing system 100 may be a computing device, such as a desktop computer, laptop computer, web server, mobile device, vehicle (e.g., airplane, drone, train, car or other means of transport), Internet of Things (IoT) enabled device, embedded computer (e.g., computer contained in a vehicle, industrial equipment or networked commercial device), or such computing device containing memory and processing power.

[0021] The computing system 100 may include a host system 105 coupled to one or more memory subsystems 110 and / or an asymmetric signature manager 150. In some embodiments, the host system 105 is coupled to different types of memory subsystems 110. Figure 1 An example of a host system 105 coupled to a memory subsystem 110 and / or an asymmetric signature manager 150 is shown. As used herein, “coupled to” or “coupled with” generally refers to a connection between components or devices, which can be an indirect or direct communication connection (e.g., without intermediate components or devices), whether wired or wireless, and includes connections such as electrical, optical, magnetic, etc.

[0022] Computing system 100 may include an asymmetric signature manager 150. In some instances, the asymmetric signature manager 150 may receive a firmware image from a source (e.g., host device 105). The firmware image may be a new firmware image or an updated firmware image communicated to memory subsystem 110 to update the firmware of memory subsystem 110. The firmware image may be received by the asymmetric signature manager 150, and the asymmetric signature manager 150 may sign (e.g., write) a cryptographic signature (e.g., an asymmetric cryptographic signature) into the firmware image. Signing the firmware image with a cryptographic signature can be performed in a secure environment. The asymmetric cryptographic signature may be based on a cryptographic algorithm, such as the Rivest-Shamir-Adleman (RSA) cryptographic algorithm. The cryptographic signature may be associated with a public key that can be shared with one or more devices and a private key that can be shared with a limited number of devices. The public and private keys may be associated with a cryptographic algorithm. The combination of public and private keys can be used to verify the integrity of the firmware image based on one or more cryptographic procedures. For example, asymmetric cryptographic signatures can be verified based on an asymmetric cryptographic procedure that can use an asymmetric cryptographic algorithm. The asymmetric signature manager 150 can communicate the signed firmware image to the memory subsystem 110, where the firmware image can be verified.

[0023] Host system 105 may include a processor chipset and a software stack executed by the processor chipset. The processor chipset may include one or more cores, one or more caches, a memory controller (e.g., an NVDIMM controller), and a storage protocol controller (e.g., a PCIe controller, a SATA controller). Host system 105 may use memory subsystem 110, for example, to write data to and read data from memory subsystem 110.

[0024] Host system 105 can be coupled to memory subsystem 110 via a physical host interface. Examples of physical host interfaces include, but are not limited to, Serial Advanced Technology Attachment (SATA) interfaces, Peripheral Component Interconnect Fast (PCIe) interfaces, Universal Serial Bus (USB) interfaces, Fibre Channel, Serial Attached SCSI (SAS), Double Data Rate (DDR) memory bus, Small Computer System Interface (SCSI), Dual In-line Memory Module (DIMM) interfaces (e.g., DIMM socket interfaces supporting Double Data Rate (DDR)), Open NAND Flash Interface (ONFI), Double Data Rate (DDR), Low Power Double Data Rate (LPDDR), or any other interface. The physical host interface can be used to transfer data between host system 105 and memory subsystem 110. When memory subsystem 110 is coupled to host system 105 via a PCIe interface, host system 105 can further utilize an NVM Fast (NVMe) interface to access components (e.g., memory device 130). The physical host interface can provide an interface for passing control, address, data and other signals between the memory subsystem 110 and the host system 105. Figure 1 The memory subsystem 110 is shown as an example. Typically, the host system 120 can access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or combinations of communication connections.

[0025] Memory devices 130 and 140 may comprise any combination of different types of non-volatile memory devices and / or volatile memory devices. Volatile memory devices (e.g., memory device 140) may be, but are not limited to, random access memory (RAM), such as dynamic random access memory (DRAM) and synchronous dynamic random access memory (SDRAM).

[0026] Some examples of non-volatile memory devices (e.g., memory device 130) include NAND flash memory and write-in-place memory, such as three-dimensional cross-point (“3D cross-point”) memory devices, which are cross-point arrays of non-volatile memory cells. Cross-point arrays of non-volatile memory can perform bit storage based on changes in bulk resistance, together with stackable cross-grid data access arrays. Furthermore, cross-point non-volatile memory allows for write-in-place operations, where non-volatile memory cells can be programmed without prior erasing, compared to many flash-based memories. NAND flash memory includes, for example, two-dimensional NAND (2DN NAND) and three-dimensional NAND (3D NAND).

[0027] Each of the memory devices 130 may contain one or more arrays of memory cells. One type of memory cell (e.g., single-level cell (SLC)) may store one bit per cell. Other types of memory cells (e.g., multi-level cell (MLC), triple-level cell (TLC), and quadruple-level cell (QLC)) may store multiple bits per cell. In some embodiments, each of the memory devices 130 may contain one or more arrays of memory cells, such as SLC, MLC, TLC, QLC, or any combination thereof. In some embodiments, a particular memory device may contain an SLC portion of memory cells as well as an MLC portion, a TLC portion, or a QLC portion. The memory cells of the memory device 130 may be grouped into pages, where a page may refer to a logical unit of the memory device used to store data. Using some types of memory (e.g., NAND), pages can be grouped to form blocks.

[0028] Although non-volatile memory components (e.g., 3D cross-point arrays of non-volatile memory cells and NAND types (e.g., 2D NAND, 3D NAND)) are described, memory device 130 may be based on any other type of non-volatile memory, such as read-only memory (ROM), phase-change memory (PCM), auto-select memory, other chalcogenide-based memories, ferroelectric transistor random access memory (FeTRAM), ferroelectric random access memory (FeRAM), magnetic random access memory (MRAM), spin-transfer torque (STT)-MRAM, conductive bridged RAM (CBRAM), resistive random access memory (RRAM), oxide-based RRAM (OxRAM), NOR flash memory, and electrically erasable programmable read-only memory (EEPROM).

[0029] The memory subsystem controller 115 (or, for simplicity, controller 115) can communicate with the memory device 130 to perform operations such as reading data, writing data, or erasing data at the memory device 130, and other such operations. The memory subsystem controller 115 may include hardware such as one or more integrated circuits and / or discrete components, buffer memories, or combinations thereof. The hardware may include a digital circuit system with dedicated (i.e., hard-coded) logic to perform the operations described herein. The memory subsystem controller 115 may be a microcontroller, a dedicated logic circuit system (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), or other suitable processor.

[0030] The memory subsystem controller 115 may include a processor 120 (e.g., a processing device) configured to execute instructions stored in local memory 125. In the illustrated example, the local memory 125 of the memory subsystem controller 115 includes an embedded processor configured to store instructions for performing various processes, operations, logical flows, and routines for controlling the operation of the memory subsystem 110 (including handling communication between the memory subsystem 110 and the host system 105).

[0031] In some instances, local memory 125 may include memory registers that store memory pointers, acquired data, etc. Local memory 125 may also include read-only memory (ROM) for storing microcode. Although Figure 1 The exemplary memory subsystem 110 has been shown to include a memory subsystem controller 115, but in another embodiment of this disclosure, the memory subsystem 110 does not include a memory subsystem controller 115, but may rely on external control (e.g., provided by an external host, or by a processor or controller separate from the memory subsystem).

[0032] Typically, the memory subsystem controller 115 can receive commands or operations from the host system 105 and can translate these commands or operations into instructions or appropriate commands to achieve the desired access to the memory device 130. The memory subsystem controller 115 may handle other operations such as wear leveling, garbage collection, error detection and error correction code (ECC) operations, encryption, caching, and address translation between logical addresses (e.g., logical block addresses, namespaces) and physical addresses (e.g., physical block addresses) associated with the memory device 130. The memory subsystem controller 115 may further include a host interface circuitry for communicating with the host system 105 via a physical host interface. The host interface circuitry can translate commands received from the host system into command instructions for accessing the memory device 130 and translate responses associated with the memory device 130 into information for the host system 105.

[0033] The memory subsystem 110 may also include additional circuitry or components not shown. In some instances, the memory subsystem 110 may include caches or buffers (e.g., DRAM) and address circuitry (e.g., row decoders and column decoders) that can receive addresses from the memory subsystem controller 115 and decode the addresses to access the memory device 130.

[0034] In some embodiments, memory device 130 includes a local media controller 135 that operates together with memory subsystem controller 115 to perform operations on one or more memory cells of memory device 130. An external controller (e.g., memory subsystem controller 115) can manage memory device 130 from an external source (e.g., perform media management operations on memory device 130). In some embodiments, memory device 130 may be a locally managed memory device, which is a native memory device combined with local media controller 135, which performs memory management operations on memory device 130 within the same memory device package.

[0035] The memory subsystem 110 includes a symmetric signature manager 155 that can sign a firmware image using cryptographic signatures. The firmware image can be received by the memory device 110, which may contain a first cryptographic signature that an asymmetric signature manager 150 checks into the firmware image. The symmetric signature manager 155 can then check into (e.g., write) a second cryptographic signature (e.g., a symmetric cryptographic signature) into the firmware image. The symmetric cryptographic signature can be based on a second cryptographic algorithm, such as a hash-based message authentication code (HMAC) algorithm. The cryptographic signature can be generated using a secret key that is not shared with any device outside the memory subsystem 110. The secret key can be associated with a symmetric cryptographic algorithm. The secret key can be used to verify the integrity of the firmware image based on one or more cryptographic procedures. For example, the symmetric cryptographic signature can be verified based on a symmetric cryptographic procedure that can use a symmetric cryptographic algorithm.

[0036] In some instances, the memory subsystem controller 115 includes at least a portion of the symmetric signature manager 155. For example, the memory subsystem controller 115 may include a processor 120 (e.g., a processing device) configured to execute instructions stored in local memory 125 for performing the operations described herein. In some instances, the symmetric signature manager 155 is part of a host system 105, an application, or an operating system. Further details regarding the operation of the symmetric signature manager 155 are described herein.

[0037] The memory subsystem 110 includes a verification manager 160, which verifies the integrity of a received firmware image through a verification process. The verification manager 160 can receive a signed firmware image from an asymmetric signature manager 150, which has already been signed with a first (e.g., asymmetric) cryptographic signature. The asymmetric cryptographic signature can be generated using a private key associated with an asymmetric cryptographic algorithm. In some cases, the signed firmware image may also contain a symmetric cryptographic signature checked in by a symmetric signature manager 155. The symmetric cryptographic signature can be generated using a secret key associated with a symmetric cryptographic algorithm. The verification manager 160 can first verify the firmware image based on a public key associated with the secret key used by the asymmetric signature manager 150 to sign the firmware image. This can occur before the symmetric signature manager 155 signs the firmware image with a symmetric cryptographic signature.

[0038] Upon booting the memory subsystem 110, the verification manager 160 may re-verify the firmware image. However, instead of verifying the firmware image based on an asymmetric cryptographic signature at boot time, the verification manager 160 may use a verification procedure involving a second (e.g., symmetric) cryptographic signature and / or an asymmetric cryptographic signature. For example, the verification procedure may include an attempt to verify a symmetric cryptographic signature. If the verification manager 160 verifies the firmware image based on a symmetric cryptographic signature, the memory subsystem 110 may be allowed to boot using the firmware image. If the verification manager 160 fails to verify the firmware image based on a symmetric cryptographic signature, the verification manager may attempt to verify the firmware image based on an asymmetric cryptographic signature. If the verification manager 160 verifies the asymmetric cryptographic signature, the memory subsystem 110 may be allowed to boot using the firmware image. However, if the verification manager 160 fails to verify the firmware image based on an asymmetric cryptographic signature other than a symmetric cryptographic signature, the memory subsystem may indicate a firmware image verification failure and prevent the memory subsystem 110 from booting using the firmware image. In some cases, verification using a symmetric cryptographic signature may take less time than verification using an asymmetric cryptographic signature. This is likely due to the cryptographic algorithms used in the generation and verification of the cryptographic signature. For example, a symmetric cryptographic algorithm (e.g., HMAC) might be used to generate and verify the symmetric signature. In some cases, because the asymmetric signature is generated and verified using an asymmetric cryptographic algorithm (e.g., RSA), the verification of the symmetric signature may be faster than that of the asymmetric signature. In this case, due to the difference in the cryptographic algorithms used to generate and verify the signature, the verification of the symmetric signature may take less time than that of the asymmetric signature. Therefore, when verifying the integrity of the firmware image using a symmetric cryptographic signature, latency in the boot process can be reduced. However, even if the verification of the symmetric cryptographic signature fails, a fallback verification using the asymmetric cryptographic signature can still allow the device to boot.

[0039] Figure 2 This is a flowchart of an exemplary method 200 for verifying a new firmware image received by a memory subsystem, according to some embodiments of this disclosure. The method 200 may be performed by processing logic, which may include hardware (e.g., processing device, circuit system, dedicated logic, programmable logic, microcode, device hardware, integrated circuit, etc.), software (e.g., instructions that run or execute on the processing device), or a combination thereof. In some embodiments, the method 200 is performed by… Figure 1 One or more of the asymmetric signature manager 150, symmetric signature manager 155, and / or verification manager 160 are performed. Although shown in a specific order or sequence, the order of the processes can be modified unless otherwise stated. Therefore, the illustrated embodiments should be understood as examples only, and the illustrated processes can be performed in different orders, and some processes can be performed in parallel. In addition, one or more processes may be omitted in various embodiments. Therefore, not all processes are required in every embodiment. Other process flows are also possible.

[0040] In operation 205, the storage subsystem may receive a new firmware image. The new firmware image can be received from various sources (including host systems, cloud services) via the Internet and / or servers (e.g., servers hosting the firmware image, such as servers associated with the firmware image manufacturer). The new firmware image may contain a first cryptographic signature written to the firmware image using a first signing procedure. This cryptographic signature can be used to verify the integrity of the firmware image based on the first signing procedure. For example, the new firmware image may be received by a storage subsystem containing an asymmetric cryptographic signature based on an asymmetric signing procedure. The asymmetric cryptographic signature may be part of the firmware image and used to verify the signature of the firmware image based on an associated cryptographic algorithm. For example, an asymmetric cryptographic algorithm, such as the Rivest Shamir Adleman (RSA) algorithm, may be used in the generation of the symmetric cryptographic signature. The signing of the asymmetric cryptographic signature may be performed by a signature manager (e.g., reference...) Figure 1The asymmetric signature manager 150 discussed in the memory subsystem is used for this purpose. In some cases, the asymmetric cryptographic algorithm (e.g., RSA) may be associated with two keys (e.g., a private key and a public key). The private key can be used when generating an asymmetric cryptographic signature for the signed-in firmware image. The public key can be shared (e.g., publicly) with multiple devices outside the memory subsystem and used to verify the asymmetric cryptographic signature. In this case, the signing of the firmware image (e.g., based on the private key) can be performed in a secure environment (e.g., a hardware signing machine) separate from the memory subsystem. A secure environment can be used to ensure that the private key is not improperly shared with external devices. The public key can then be used to verify the integrity of the firmware image within the memory subsystem based on the asymmetric cryptographic signature.

[0041] In operation 210, the memory subsystem can verify the integrity of the new firmware image based on a first (e.g., asymmetric) signing procedure. For example, the memory subsystem can receive a new firmware image signed with asymmetric cryptography in a secure environment, as discussed herein. The memory subsystem can verify the new firmware image based on an asymmetric signing procedure. For example, the memory device can verify the firmware image based on a public key associated with a private key used by the asymmetric signature manager 150 to sign the firmware image. Verification can be performed in a verification manager (e.g., referencing...) Figure 1 The verification is performed or is conducted by the verification manager (160) of the memory subsystem discussed in this paper. The verification manager may verify the public key based on an asymmetric cryptographic algorithm (e.g., RSA algorithm). Since the private key cannot be shared with external devices, and the firmware image is verified using the public key associated with the private key, asymmetric signatures can provide a highly secure form of determining the integrity of the firmware image (e.g., that the firmware image is not corrupted). In some cases, verification based on asymmetric signature procedures occurs outside the normal operation of the memory subsystem (e.g., during firmware updates or debugging of the memory subsystem). Therefore, the impact on the normal operation of the memory subsystem (e.g., booting), such as the increased latency due to two-key verification, can be avoided.

[0042] In operation 215, the memory subsystem can generate a second cryptographic signature. The generation of the second signature can occur after the initial verification of the firmware image (e.g., operation 210). Similar to the first cryptographic signature, the second cryptographic signature can be checked in (e.g., written) to the firmware image and can be used to verify the integrity of the firmware image based on the second signature procedure. For example, the memory subsystem can generate a symmetric cryptographic signature based on a symmetric cryptographic algorithm (e.g., the HMAC algorithm). This symmetric cryptographic signature can contain a secret key associated with the symmetric cryptographic algorithm. Similar to the private key of an asymmetric signature procedure, the private key of a symmetric cryptographic signature cannot be shared with other devices (e.g., it is private to the memory subsystem). In this case, the private key can be used to verify the integrity of the firmware image in the memory device without using a public key. The generation of the symmetric cryptographic signature (containing the secret key) can occur in a signature manager (e.g., reference) in the memory device. Figure 1 The symmetric signature manager (155) discussed in the memory subsystem is used.

[0043] In operation 220, a symmetric cryptographic signature can be written to the firmware image. As discussed earlier, the new firmware image may have already been verified for the first time at the memory subsystem based on an asymmetric signature. In addition to or as an alternative to asymmetric cryptographic signatures, a symmetric cryptographic signature can be checked in (e.g., written) to the firmware image. Similar to generating an asymmetric cryptographic signature, a symmetric signature manager (e.g., refer to...) can... Figure 1 The symmetric signature manager 155 discussed in the memory subsystem can write (e.g., check in) a symmetric signature to a firmware image. A secret key, which may be a unique random key generated by the memory device, can be used to generate the symmetric cryptographic signature. The secret key can be used to verify the firmware image, as discussed herein.

[0044] In some cases, the memory subsystem can verify the firmware image each time it boots. During boot, the integrity of the firmware can be checked to ensure the memory subsystem operates correctly. The firmware image may have become corrupted when the memory subsystem loses power. Therefore, verifying the integrity of the firmware image upon booting the memory subsystem ensures proper operation. However, in some cases, the verification process may be time-constrained, requiring verification to be performed within a given (e.g., finite) time frame to avoid impacting (or minimizing) the operation of the memory subsystem during boot. For example, verification should be performed within approximately a few milliseconds. In such cases, a verification process utilizing symmetric and / or asymmetric cryptographic signatures can be used to support relatively rapid booting of the memory subsystem compared to other verification techniques.

[0045] In operation 225, a verification process for verifying the firmware image can be performed. The verification process can be performed during the startup of the memory subsystem to ensure the integrity of the firmware image operating on the memory subsystem. The verification process can be used to reduce the latency introduced during memory device startup due to firmware image verification. The verification process can verify the firmware image based on a first (e.g., asymmetric) signing procedure, a second (e.g., symmetric) signing procedure, or a combination of asymmetric and symmetric signing procedures. The verification process includes operation 230 and optionally includes operations 235, 240, 250, and 255, which will be discussed herein.

[0046] In operation 230, the memory subsystem can verify the firmware image based on a symmetric signature procedure. For example, the memory subsystem can first verify the firmware image based on a secret key used to sign the firmware image and associated with a symmetric cryptographic algorithm (e.g., HMAC algorithm). See reference... Figure 3 As discussed in the memory subsystem, the verification manager 345 can be used by the memory subsystem to verify the secret key. In some cases, the symmetric verification procedure can be performed very quickly (e.g., within approximately a few milliseconds). This may be due to the algorithms and / or operations associated with the verification of symmetric signatures. For example, verification using a secret key (e.g., verification of symmetric cryptographic signatures) can be associated with less complex algorithms and / or operations compared to verification using a public key (e.g., verification of asymmetric cryptographic signatures). Therefore, in the case of verifying firmware images based on symmetric verification procedures, the startup latency of the device can be reduced.

[0047] If the firmware image is verified based on a symmetric signature procedure, the memory subsystem can securely boot the firmware. In some instances, such as in optional operation 235, the memory subsystem can additionally re-verify the firmware image based on an asymmetric signature procedure. The asymmetric signature verification can be similar to the asymmetric verification procedure of operation 240, which will be discussed herein. Re-verification of the firmware image can serve as a backup to the verification of the symmetric cryptographic signature and can provide enhanced security to confirm the integrity of the firmware image (e.g., dual authentication). However, since operation 235 is optional, re-verification based on an asymmetric signature procedure is not required. Therefore, any additional delays introduced by the asymmetric signature verification procedure can be optionally avoided.

[0048] In some cases, the memory subsystem can determine the failure of firmware image verification based on a second (e.g., symmetric) signature procedure. This could be due to failure of firmware image verification based on the secret key associated with the symmetric signature algorithm. In this situation, the memory subsystem can verify the firmware image based on an asymmetric signature procedure.

[0049] For example, in optional operation 240, the firmware image can be verified based on an asymmetric signature procedure. Similar to operation 210, verification can rely on a public key associated with a private key used to generate an asymmetric cryptographic signature based on an asymmetric cryptographic algorithm (e.g., RSA algorithm). The verification manager (e.g., reference...) Figure 1 The manager (160) discussed in the memory subsystem can be used by the memory subsystem to verify the public key. In some cases, firmware image verification based on asymmetric signature procedures can be a fallback verification procedure, which serves as a supplement to verification based on symmetric signature procedures or is used after verification based on symmetric signature procedures fails.

[0050] In some cases, firmware images can be verified based on asymmetric signature procedures. In such cases, even if verification of the firmware image using a symmetric signature procedure fails, the memory subsystem can still be properly started based on verification using asymmetric signature procedures.

[0051] In some cases, after determining that verification of the firmware image based on a first (e.g., asymmetric) signature procedure has failed, the memory subsystem may determine that verification of the firmware image based on a second (e.g., symmetric) signature procedure has failed. This could be due to failures in verifying the firmware image based on both symmetric and asymmetric cryptographic signatures. In this case, both failures may indicate corruption of the firmware image and that the firmware image is insecure and unusable by the memory subsystem, thus allowing the memory subsystem to avoid booting with an unverified firmware image. In this case, in optional operation 250, the memory subsystem may send an indication of firmware image verification failure. The failure indication may be an error status indication, such as an error status code, sent from the memory subsystem. The memory subsystem may send the indication to the device from which the firmware image was received during operation 205, or it may send the indication to a different device. In operation 255, in response to the indication, the memory subsystem may receive a new firmware image from the device to which the memory subsystem sent the indication. The memory device may use the new firmware image instead of the initial firmware image, and the new firmware image may undergo a similar verification procedure discussed herein (e.g., operations 205-225). In some cases, a new firmware image can be received after it has been signed with a new asymmetric cryptographic signature.

[0052] It should be noted that the above methods describe possible implementation schemes, and the operations and steps can be rearranged or otherwise modified, and other implementation schemes are also possible. Furthermore, parts from two or more methods can be combined.

[0053] Figure 3An example of a system 300 supporting the verification of the integrity of a firmware image for a memory subsystem, according to the examples disclosed herein, is shown. In some cases, system 300 may be used for reference. Figure 2 Method 200 is described.

[0054] System 300 includes an asymmetric signature manager 315. The asymmetric signature manager 315 can be used as a reference. Figure 1 An example of the described asymmetric signature manager 150. In some cases, the asymmetric signature manager 315 can receive firmware images from a source external to system 300. The external source can be a host system, such as [reference needed]. Figure 1 The host system 105 described herein. The received firmware image can be signed by an asymmetric signature manager 315. In some cases, the asymmetric signature manager 315 may be located in a secure environment 310. For example, the asymmetric signature manager 315 may be part of a hardware signature machine (HSM) located in a secure facility. The secure environment 310 may be the location where the system 300 is initially manufactured, or it may be a secure location for receiving secure firmware images. The secure environment 310 can be used to ensure that the firmware image signed by the asymmetric signature manager 315 is a valid firmware image that has not been corrupted or tampered with by external sources. Therefore, the secure environment 310 can ensure that the asymmetric signature of the signed-in firmware is a valid cryptographic signature.

[0055] The asymmetric signature manager 315 may include a private key signature manager 325. The asymmetric signature manager 315 can sign the firmware image using a private key associated with an asymmetric cryptographic algorithm (e.g., RSA algorithm), as shown in the reference. Figure 2 The verification method discussed earlier. The private key signature manager 325 can generate a private key associated with an asymmetric cryptographic algorithm, and can use the private key to sign (e.g., write) an asymmetric cryptographic signature into a firmware image signature. As previously discussed, the public key can be publicly shared with many devices, while the private key cannot be shared with any other external device. The public key associated with the private key can be used by the memory subsystem 330 to verify the integrity of the firmware image.

[0056] The asymmetric signature manager 315 can communicate with the memory subsystem 330. The memory subsystem 330 can receive signed firmware images from the asymmetric signature manager 315, for example, in the reference... Figure 2 Operation 205 is described. In this case, the received firmware image can be signed with an asymmetric cryptographic signature, which may contain a private key and a public key associated with an asymmetric cryptographic algorithm (e.g., the RSA algorithm).

[0057] The memory subsystem 330 includes a symmetric signature manager 335. The symmetric signature manager 335 can be a reference... Figure 1 An example of the described symmetric signature manager 155. The symmetric signature manager 335 can generate a symmetric cryptographic signature and sign it in (e.g., write it) to a received firmware image, as described in the reference. Figure 2 Operations 215 and 220 are described. The symmetric signature manager 335 may include a secret key signature manager 340. The secret key signature manager 340 can generate a secret key associated with a symmetric cryptographic algorithm (e.g., the HMAC algorithm). The generated secret key can be used to generate a symmetric signature on a firmware image written into the memory subsystem 330 by the secret key signature manager 340. Because the secret key signature manager 340 can be part of the memory subsystem 330, the secret key generation and the signing of the symmetric cryptographic signature can be isolated from external damage.

[0058] The memory subsystem 330 includes a verification manager 345. The verification manager 345 may be a reference... Figure 1 An example of the described verification manager 160. Verification manager 345 can be used to verify the integrity of a firmware image based on an asymmetric signing program, a symmetric signing program, or both. Verification manager 345 includes an asymmetric signature verification manager 350, which can be used to verify the integrity of the firmware image based on an asymmetric signing program. Verification manager 345 also includes a symmetric signature verification manager 355, which can be used to verify the integrity of the firmware image based on a symmetric signing program. Verification manager 345 can use asymmetric signature verification manager 350 to verify a signed firmware image from an asymmetric signature manager 315, as described in the reference. Figure 2 As described in operation 210. The verification manager 345 may also use a symmetric signature verification manager 355 and / or an asymmetric signature verification manager 350 during the verification process, which can verify the integrity of the firmware image at startup, as referenced... Figure 2 Operation 225 is described.

[0059] The asymmetric signature verification manager 350 includes a public key verification manager 360. The public key verification manager 360 can be used to verify asymmetric signatures using a public key associated with a private key used to sign the firmware image with asymmetric cryptographic signatures. As previously discussed, the asymmetric signature verification manager 350 can receive a firmware image already signed with asymmetric cryptographic signatures from the asymmetric signature manager 315. Also as previously discussed, the asymmetric cryptographic signature can contain a signature generated using a public key associated with an asymmetric cryptographic algorithm, signed by the private key signature manager 325. The asymmetric signature verification manager 350 can receive signed firmware images and can first verify the integrity of the received firmware image based on the public key associated with the private key used to generate the asymmetric cryptographic signature using the asymmetric signature program. The asymmetric signature program can verify the asymmetric cryptographic signature based on an asymmetric cryptographic algorithm (e.g., the RSA algorithm). Once the firmware image has been successfully verified, the memory subsystem 330 can be allowed to use the firmware image.

[0060] In some cases, the asymmetric signature verification manager 350 can also be used to verify the firmware image when booting the memory subsystem 330. Similar to the initial verification of the firmware image, the public key verification manager 360 can be used to verify the firmware image based on an asymmetric signature procedure (e.g., verifying public and private keys based on an asymmetric cryptographic algorithm). In some cases, the asymmetric signature verification manager 350 can verify the firmware image after the symmetric signature verification manager 355 has verified it, as in the reference... Figure 2 Operation 240 is described. In other cases, in addition to the verification of the firmware image by the symmetric signature verification manager 355, the asymmetric signature verification manager 350 can also verify the firmware image, as described in reference [reference missing]. Figure 2 Operation 235 is described.

[0061] The symmetric signature verification manager 355 includes a secret key verification manager 370. The secret key verification manager 370 can be used to verify the secret key associated with the symmetric cryptographic signature. As previously discussed, the symmetric signature manager 335 can generate a symmetric cryptographic signature and sign it in (e.g., write it) to a received firmware image, which may contain a signature generated using a secret key associated with a symmetric cryptographic algorithm (e.g., HMAC). The symmetric signature verification manager 355 can receive a signed firmware image and can use a symmetric signing procedure to verify the integrity of the firmware image based on the secret key. Similar to the asymmetric signature verification manager 350, the symmetric signature verification manager 355 can be used to verify the integrity of the firmware image when booting the memory subsystem 330. For example, the symmetric signature verification manager 355 can verify the firmware image when booting the memory subsystem, as referenced... Figure 2As described in operation 230. This allows the asymmetric signature verification manager 350 to verify the firmware image during startup (e.g., see reference 230). Figure 2 The described operation 240) occurs before, or as an alternative to the asymmetric signature verification manager 350 verifying the firmware image at startup.

[0062] In some cases, the symmetric signature verification manager 355 can verify a firmware image in less time compared to the asymmetric signature verification manager 350. This can be based on the algorithm used and / or the operations associated with each cryptographic algorithm. For example, the verification of an asymmetric cryptographic algorithm may take more time than the verification of a symmetric cryptographic algorithm. Therefore, in some cases, verifying the firmware image through the symmetric signature verification manager 355 can reduce the latency of the boot process of the memory subsystem 110 because it requires less time to verify the firmware image.

[0063] Figure 4 This is an exemplary machine of a computer system 400 in which examples of this disclosure may operate. The computer system 400 may contain a set of instructions for causing the machine to perform any one or more of the techniques described herein. In some instances, the computer system 400 may correspond to a system including a memory subsystem (e.g., reference...). Figure 1 The described memory subsystem 110), and the host system coupled thereto or utilizing it (e.g., reference 110) Figure 1 The described host system 105, or a system that can be used to operate the controller (e.g., execute an operating system to perform operations with reference to the reference). Figure 1 The operations corresponding to the symmetric signature manager 155 and the verification manager 160 described herein. In some instances, the machine may connect to other machines in a LAN, intranet, extranet, and / or the Internet (e.g., networked). The machine may operate as a server or client machine in a client-server network environment, as a peer machine in a peer-to-peer (or distributed) network environment, or as a server or client machine in a cloud computing infrastructure or environment.

[0064] The machine may be a personal computer (PC), tablet computer, set-top box (STB), personal digital assistant (PDA), cellular phone, web device, server, network router, switch, or bridge, or a machine capable of executing a set of instructions (sequentially or otherwise) that specify the actions to be performed by the machine. Furthermore, although a single machine is shown, the term "machine" may also include any collection of machines that individually or collectively execute a set (or more) of instructions to perform any one or more of the methods discussed herein.

[0065] The exemplary computer system 400 may include a processing device 405, a main memory 410 (e.g., read-only memory (ROM), flash memory, DRAM (e.g., synchronous DRAM (SDRAM) or RDRAM)), a static memory 415 (e.g., flash memory, static random access memory (SRAM)), and a data storage system 425, which communicate with each other via a bus 445.

[0066] Processing device 405 represents one or more general-purpose processing devices, such as microprocessors, central processing units, etc. More specifically, the processing device may be a Complex Instruction Set Computing (CISC) microprocessor, a Reduced Instruction Set Computing (RISC) microprocessor, a Very Long Instruction Word (VLIW) microprocessor, or a processor implementing other instruction sets or multiple processors implementing combinations of instruction sets. Processing device 405 may also be one or more special-purpose processing devices, such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), network processors, etc. Processing device 405 is configured to execute instructions 435 for performing the operations and steps discussed herein. Computer system 400 may further include network interface device 420 for communication via network 440.

[0067] In some instances, network interface device 420 can be used as an interface for receiving firmware images from external sources. For example, network interface device 420 can receive firmware images from a host system (e.g., reference 3). Figure 1 The described host system 105, server, or another device communicating with network interface device 420 receives the firmware image. In some cases, the received firmware image may contain a cryptographic signature of the signed-in firmware image. For example, the received firmware image may contain private and public keys for the signed-in firmware image. In this case, the private and public keys may have already been obtained by an asymmetric signature manager (e.g., refer to...). Figure 1 The described asymmetric signature manager 150 signs in the firmware image.

[0068] Data storage system 425 may include machine-readable storage medium 430 (also referred to as computer-readable medium) on which one or more sets of instructions 435 or software embodying any one or more methods or functions described herein are stored. Instructions 435 may also reside wholly or at least partially in main memory 410 and / or processing device 405 during execution by computer system 400, which are also components of the machine-readable storage medium. Machine-readable storage medium 430, data storage system 425, and / or main memory 410 may correspond to a memory subsystem.

[0069] In one instance, instruction 435 includes provisions for implementing a symmetric signature manager 450 and a verification manager 455 (e.g., see reference 450). Figure 1 The instructions for the functions corresponding to the symmetric signature manager 155 and verification manager 160 described herein. Although the machine-readable storage medium 430 is shown as a single medium, the term "machine-readable storage medium" can include a single medium or multiple media storing one or more sets of instructions. The term "machine-readable storage medium" can also include any medium capable of storing or encoding a set of instructions for execution by a machine and causing the machine to perform any one or more methods of this disclosure. The term "machine-readable storage medium" can include, but is not limited to, solid-state memory, optical media, and magnetic media.

[0070] Some parts of the foregoing detailed description have been presented based on the algorithms and symbolic representations of operations on data bits within computer memory. These algorithmic descriptions and representations are the methods used by those skilled in the art of data processing to most effectively communicate the essence of their work to others skilled in the art. Here, an algorithm is generally considered to be a self-consistent sequence of operations that leads to a desired result. These operations are those that require physical manipulation of physical quantities. Typically, but not necessarily, these quantities take the form of electrical or magnetic signals that can be stored, combined, compared, and otherwise manipulated. It has been shown that, primarily for general reasons, it is sometimes convenient to refer to these signals as bits, values, elements, symbols, characters, items, numbers, etc.

[0071] However, it should be remembered that all these and similar terms should be associated with appropriate physical quantities and are merely convenient labels applied to those quantities. This disclosure may refer to the actions and processes of a computer system or similar electronic computing device that manipulate and convert data represented in physical (electronic) quantities within the registers and memories of the computer system into other data similarly represented in physical quantities within the computer system's memory or registers or other such information storage systems.

[0072] This disclosure also relates to an apparatus for performing the operations described herein. The apparatus may be specifically configured for its intended purpose, or it may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. This computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk (including floppy disks, optical disks, CD-ROMs, and magneto-optical disks), ROM, RAM, EPROM, EEPROM, magnetic cards, or optical cards, or any type of media suitable for storing electronic instructions (each coupled to a computer system bus).

[0073] The algorithms and displays presented herein are not inherently associated with any particular computer or other device. Various general-purpose systems can be used with programs based on the teachings herein, or it can be demonstrated that it is convenient to construct more specialized devices to perform the methods described herein. The structures of various such systems will be described in the following description. Furthermore, this disclosure is described without reference to any particular programming language. It will be understood that the teachings of this disclosure described herein can be implemented using various programming languages.

[0074] This disclosure can be provided as a computer program product or software, which may include a machine-readable medium having instructions stored thereon, the instructions being usable for programming a computer system (or other electronic device) to perform processes according to this disclosure. The machine-readable medium includes any mechanism for storing information in a machine-readable (e.g., computer-readable) form. In some instances, machine-readable (e.g., computer-readable) media includes machine-readable storage media such as ROM, RAM, disk storage media, optical storage media, flash memory components, etc.

[0075] In the foregoing description, examples of this disclosure have been described with reference to specific exemplary examples. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope of the examples of this disclosure set forth in the following claims. Therefore, the description and drawings should be considered illustrative rather than restrictive.

Claims

1. A method for verifying a firmware image, comprising: The integrity of the firmware image signed with the first signature is verified at least in part based on the first signing procedure; After successfully verifying the integrity of the firmware image signed with the first signature, a second signature of the firmware image is generated at least in part based on a second signature program that is different from the first signature program, wherein the first verification time associated with the first signature program is greater than the second verification time associated with the second signature program; as well as In response to the boot storage system to verify the integrity of the firmware image, the verification process of the firmware image is performed at least in part based on the second signing program and the first signing program.

2. The method according to claim 1, wherein the verification process of the firmware image includes: The verification of the integrity of the firmware image according to the second signing procedure has failed.

3. The method according to claim 1, wherein the verification process of the firmware image includes: After determining that the integrity of the firmware image has failed to be verified according to the second signing procedure, the integrity of the firmware image is verified according to the first signing procedure.

4. The method according to claim 1, wherein the verification process of the firmware image includes: The integrity of the firmware image is verified according to the second signing procedure.

5. The method according to claim 1, wherein the verification process of the firmware image includes: After verifying the integrity of the firmware image according to the second signing procedure, the integrity of the firmware image is re-verified according to the first signing procedure.

6. The method according to claim 1, wherein the verification process of the firmware image comprises: The verification of the integrity of the firmware image according to the first signing program and the second signing program has failed; and The system receives a second firmware image of the memory system, which is signed with a third signature according to the first signing program.

7. The method of claim 1, wherein the verification process of the firmware image comprises: The indication of failure to verify the firmware image is sent at least in part based on the failure to verify the firmware image according to the first signing program and the second signing program.

8. The method of claim 1, wherein the first signing procedure is at least partially based on a first cryptographic algorithm, and the second signing procedure is at least partially based on a second cryptographic algorithm different from the first cryptographic algorithm.

9. The method of claim 8, wherein the first cryptographic algorithm is at least partially based on the Levitt-Samour-Aardman RSA cryptographic algorithm, and the second cryptographic algorithm is at least partially based on the Hash-based Message Authentication Code (HMAC) cryptographic algorithm.

10. The method of claim 1, wherein writing the second signature into the firmware image comprises: The key is generated at least in part based on the second signing procedure, and the second signature is written based on the key.

11. The method of claim 1, wherein the second signature for generating the firmware image is based at least in part on the success of verifying the integrity of the firmware image according to the first signing procedure.

12. A method for verifying a firmware image, comprising: A first signature of the firmware image of the memory system is generated according to the first signature procedure; The integrity of the firmware image is verified at the memory system based at least in part on the first signing procedure and the first signature; After successfully verifying the integrity of the firmware image, a second signature of the firmware image is generated at least in part based on a second signing program that is different from the first signing program, wherein the first verification time associated with the first signing program is greater than the second verification time associated with the second signing program; as well as In response to starting the memory system to verify the integrity of the firmware image, the verification process of the firmware image is performed according to the first signing program and the second signing program.

13. The method of claim 12, further comprising: Start the memory system; and After the memory system is started, the verification process of the firmware image is performed.

14. The method of claim 12, wherein generating the first signature comprises: The pairing of the first key and the second key of the firmware image is determined according to the first cryptographic signature algorithm.

15. The method of claim 12, wherein writing the second signature comprises: A third key for the firmware image is generated based on the second cryptographic algorithm.

16. The method of claim 12, wherein the verification process of the firmware image comprises: The verification of the integrity of the firmware image according to the first signing program and the second signing program has failed; The indication of failure to verify the firmware image is sent at least in part based on the failure to verify the firmware image according to the first signing program and the second signing program; and The system receives a second firmware image of the memory system, the second firmware image being signed with a third signature according to the first signing procedure, wherein the second firmware image is received at least in part based on the indication that verification of the firmware image has failed.

17. The method of claim 12, further comprising: In an environment separate from the memory system, the first signature is generated according to a third cryptographic algorithm; and At the memory system, the second signature is generated according to the fourth cryptographic algorithm.

18. A non-transitory computer-readable storage medium comprising instructions that, when executed by a processing means, cause the processing means to: The integrity of the firmware image signed with the first signature is verified at least in part based on the first signing procedure. After successfully verifying the integrity of the firmware image, a second signature of the firmware image is generated at least in part based on a second signature program that is different from the first signature program, wherein the first verification time associated with the first signature program is greater than the second verification time associated with the second signature program; as well as In response to the boot storage system to verify the integrity of the firmware image, the verification process of the firmware image is performed at least in part based on the second signing program and the first signing program.

Images