Secure serial peripheral interface (SPI) flash memory

Abstract

This application relates to secure serial peripheral interface (SPI) flash memory. A secure memory device is disclosed. In one embodiment, the memory device includes a controller configured to decode and execute commands issued by a host device, a cryptographic engine configured to authenticate a subset of the commands, the subset of the commands each including a digital signature, and a first monotonic counter that is incremented after execution of at least some of the subset of the commands, wherein a value of the first monotonic counter is used to generate the digital signature.

Description

[0001] Related applications

[0002] This application claims the filing date benefit of Provisional U.S. Patent Application No. 63 / 052,122, entitled "Secure Serial Peripheral Interface (SPI) Flash", filed on July 15, 2020, the entire disclosure of which is hereby incorporated by reference.

[0003] This application relates to U.S. Patent No. 10,296,421, filed June 26, 2017, and International Application No. PCT / US2019 / 023551, filed March 22, 2019, the entire contents of which are incorporated herein by reference. Technical Field

[0004] At least some of the embodiments disclosed herein generally relate to semiconductor devices, and more specifically to providing a secure interface for accessing memory devices such as NOR flash memory devices. Background Technology

[0005] Currently, many semiconductor devices are used to store critical information. Examples of such devices include, but are not limited to, NAND flash memory, NAND flash memory, and other non-volatile semiconductor devices. Access to these devices is restricted or protected by software or firmware by default. However, hardware attacks on such devices can compromise their integrity. Generally, a hardware attack on a memory device refers to an attack in which an attacker physically accesses the memory device. For example, an attacker can modify the contents of the memory by desoldering and reprogramming or replacing components. Alternatively, or in combination with the foregoing, a victim can use a logic analyzer to probe commands transmitted to the memory device and replay the commands if necessary. Various other hardware attacks exist, but for the sake of brevity, these other hardware attacks are not described.

[0006] Many attacks involve extracting known values ​​from memory. For example, memory can store security credentials. Despite encryption, an attacker can identify a given, fixed fragment of ciphertext and use that ciphertext to exploit the memory device or credentials. Essentially, encryption cannot adequately protect the underlying plaintext if the ciphertext is always associated with a piece of plaintext. Therefore, a user can use ciphertext instead of plaintext without "breaking" the encryption because the ciphertext is always the same and can be identified through hardware attacks.

[0007] One attempt to prevent this attack is to use a replay-protected monotonic counter (RPMC) or multiple RPMCs. These counters generate pseudo-random values ​​that are appended to commands and responses to ensure that each command or response is unique, thus preventing command replay.

[0008] When the security provided by RPMCs is low, they cannot adequately protect the contents of the memory device. The disclosed embodiments provide additional security built on top of RPMCs, which protect the memory device while maintaining backward compatibility with RPMC-enabled devices. Summary of the Invention

[0009] This application relates to a memory device comprising: a controller configured to decode and execute commands issued by a host device; a cryptographic engine configured to authenticate subsets of the commands, each subset of the commands containing a digital signature; and a first monotonic counter incrementing after at least some subsets of the commands are executed; wherein the value of the first monotonic counter is used to generate the digital signature.

[0010] Another aspect of this application relates to a method comprising: receiving a security command from a host device at a memory device, the security command including a first digital signature; authenticating the security command by the memory device by generating a second digital signature of the command and comparing the second digital signature with the first digital signature; incrementing the first monotonic counter by the memory device upon successful completion of the security command; generating a response to the security command by the memory device, the response including the value of the first monotonic counter; signing the response by the memory device; and returning the response to the host device by the memory device. Attached Figure Description

[0011] Figure 1 This is a block diagram illustrating a system for protecting a memory device according to one embodiment.

[0012] Figure 2 This is a flowchart illustrating a method for maintaining a plurality of monotonic counters according to some embodiments of the present disclosure.

[0013] Figure 3 This is a swimlane diagram illustrating a security command for requesting parameters stored in a memory device according to some embodiments of the present disclosure.

[0014] Figure 4 This is a swimlane diagram illustrating security commands for provisioning and deprovisioning security features of memory devices according to some embodiments of the present disclosure.

[0015] Figure 5 This is a swimlane diagram illustrating security commands for protecting data reading and writing to media of a memory device according to some embodiments of the present disclosure.

[0016] Figure 6 This is a swimlane diagram illustrating security commands for protecting register data reads and writes of a memory device according to some embodiments of the present disclosure.

[0017] Figure 7 This is a swimlane diagram illustrating security commands for block locking and unlocking of a memory device according to some embodiments of the present disclosure. Detailed Implementation

[0018] The disclosed embodiments relate to improved memory systems, such as NOR flash memory devices.

[0019] The disclosed embodiments fully utilize the RPMC cycle and packet format to extend security functionality beyond that provided by RPMC. Additional non-volatile keys can be pre-shared according to any protocol required by the memory vendor. Replay protection is implemented via a separate monotonic counter (A-MTC0) that acts as a secure command counter. The value of A-MTC0 increments upon power-on and upon successful completion of a secure command. In some embodiments, the value does not increment for RPMC commands or similar insecure commands. In one embodiment, A-MTC0 is a 32-bit counter matched to the RPMC counter and is sufficient given a command that fully utilizes this counter type. No changes are made to the existing RPMC counter functionality, and there is no interaction between the RPMC and the secure cycle command counter. The A-MTC value can be obtained in three ways: automatic power-on, in response to a direct read of the security register, and after each successful secure write command. In the illustrated embodiments, a secure read cycle is performed to retrieve the HMAC signature output after one of these three events. Therefore, it is very easy for the software to keep "synchronized" with the memory device via this counter. The disclosed embodiments further describe a second additional counter (A-MTC1) that can be used to count power cycles. This counter provides information and is used to deactivate security.

[0020] The disclosed embodiments utilize the device root key based on a manufacturer-selected key-sharing method. In one embodiment, a device session key is generated based on an HMAC operation performed on the value of A-MTC1 and the root key. This session key derivation method conforms to the RPMC specification. The security packet format follows the RPMC packet format, as follows:

[0021] byte RPMC command Secure write command 1 Command type Command type 2 Counter address Configuration data 3 reserve change 4-end change change (End-to-X) sign sign

[0022] Various commands are disclosed herein. The following table briefly illustrates the commands implemented in the disclosed embodiments.

[0023]

[0024]

[0025] Figure 1 This is a block diagram illustrating a system for protecting a memory device according to one embodiment.

[0026] exist Figure 1 In this configuration, host device 102 can communicate with memory device 104 via a communication channel. Host device 102 can be a computer with one or more central processing units (CPUs), and computer peripherals (e.g., memory device 104) can be attached to the computer via interconnects (e.g., computer buses (e.g., Peripheral Component Interconnect (PCI), Extended PCI (PCI-X), PCI High Speed ​​(PCIe)), communication components, and / or computer networks).

[0027] Memory device 104 can be used, for example, to store data from host device 102 in non-volatile storage medium 108. Generally, examples of memory devices include hard disk drives (HDDs), solid-state drives (SSDs), flash memory, dynamic random access memory, magnetic tape, network attached storage devices, etc. Memory device 104 has a host interface 110 that uses a communication channel to implement communication with host device 102. For example, in one embodiment, the communication channel between host device 102 and memory device 104 is a Peripheral Component Interconnect High Speed ​​(PCI High Speed ​​or PCIe) bus; and host device 102 and memory device 104 communicate with each other using the NVMe protocol (Non-Volatile Memory Host Controller Interface Specification (NVMHCl), also known as NVM High Speed ​​(NVMe)).

[0028] In some implementations, the communication channel between host device 102 and memory device 104 includes a computer network, such as a local area network, wireless local area network, wireless personal area network, cellular communication network, or broadband high-speed always-connected wireless communication connection (e.g., current or future generation mobile network link); and host device 102 and memory device 104 may be configured to communicate with each other using data storage management and commands similar to those in the NVMe protocol.

[0029] The controller 106 may run firmware 122 to perform operations and / or other operations in response to communications from the host device 102. As will be discussed, these operations may include both secure and insecure operations of accessing the non-volatile storage medium 108. Generally, firmware is a computer program that provides control, monitoring, and data manipulation of an engineered computing device. In some embodiments, the firmware controls the operation of the controller 106 when operating the memory device 104, such as the operation of the cryptographic engine 120, as further discussed below.

[0030] The memory device 104 has a non-volatile storage medium 108, such as a NOR flash memory, a NAND flash memory, or other types of storage media. The non-volatile storage medium 108 is non-volatile because no power is required to maintain the data / information stored in it, and the data / information can be retrieved after the non-volatile storage medium 108 is powered off and then powered on again. Various memory / storage device technologies can be used to implement the memory cell, such as NAND or NOR gate-based flash memory, phase-change memory (PCM), magnetic RAM (MRAM), resistive random access memory, and 3D XPoint, so that the non-volatile storage medium 108 is non-volatile and can retain the data stored therein for days, months, and / or years without power.

[0031] Memory device 104 may include volatile dynamic random access memory (DRAM) (120) for storing runtime data and instructions used by controller 106 to improve the computing performance of controller 106 and / or provide a buffer for data transferred between host device 102 and non-volatile storage medium 108. DRAM is volatile because it requires power to maintain the data / information stored therein, which is immediately or rapidly lost when power is interrupted.

[0032] Volatile DRAM typically has lower latency than non-volatile storage medium 108, but it loses its data rapidly upon power loss. Therefore, it is advantageous to use volatile DRAM to temporarily store instructions and data for the controller 106 in its current computational task to improve performance. In some cases, volatile DRAM is replaced by volatile static random access memory (SRAM), which uses less power than DRAM in some applications. Volatile DRAM can be eliminated when non-volatile storage medium 108 has similar data access performance to volatile DRAM (e.g., in terms of latency, read / write speed); and the controller 106 can perform computations by operating on non-volatile storage medium 108 for instructions and data instead of volatile DRAM.

[0033] For example, crosspoint memory devices and memory devices (e.g., 3D XPoint memory) have data access performance similar to volatile DRAM. Crosspoint memory devices use transistorless memory elements, each having memory cells and selectors stacked together in a column. The column of memory elements is connected via two vertical conductor layers, one above the column and the other below. Each memory element can be selected individually at the intersection of a conductor on each of the two layers. Crosspoint memory devices are fast and non-volatile and can be used as a general-purpose memory pool for processing and storage.

[0034] In some cases, controller 106 has an in-processor cache memory whose data access performance is superior to volatile DRAM and / or non-volatile storage media 108. Therefore, it is preferable to cache a portion of the instructions and data used in the current computational task in the in-processor cache memory of controller 106 during computational operations of controller 106. In some cases, controller 106 has multiple processors, each with its own in-processor cache memory.

[0035] Optionally, controller 106 uses data and / or instructions organized in memory device 104 to perform centralized memory processing of data. For example, in response to a request from host device 102, controller 106 performs real-time analysis on the dataset stored in memory device 104 and transmits a reduced dataset to host device 102 in response. For example, in some applications, memory device 104 is connected to a real-time sensor to store sensor inputs; and the processor 112 of controller 106 is configured to perform machine learning and / or pattern recognition based on sensor inputs to support an artificial intelligence (AI) system implemented at least in part via memory device 104 and / or host device 102.

[0036] In some implementations, the processor of controller 106 is integrated with memory during computer chip manufacturing to enable in-memory processing and thus overcome the von Neumann bottleneck, which limits computational performance due to throughput limitations caused by latency in data movement between the processor and memory, which are separately configured according to the von Neumann architecture. The integration of processing and memory increases processing speed and memory transfer rate, and reduces latency and power consumption.

[0037] The storage device 104 can be used in various computing systems, such as cloud computing systems, edge computing systems, fog computing systems, and / or standalone computers. In cloud computing systems, remote computer servers connect to a network to store, manage, and process data. Edge computing systems optimize cloud computing by performing data processing at the edge of a computer network, close to the data source, and thus reduce data communication with centralized servers and / or data storage areas. Fog computing systems use one or more end-user devices or near-user edge devices to store data, and thus reduce or eliminate the need to store data in a centralized data warehouse.

[0038] At least some of the embodiments disclosed herein can be implemented using computer instructions executed by controller 106 (e.g., firmware). In some cases, hardware circuitry can be used to implement at least some of the functions of the firmware. The firmware may be initially stored in non-volatile storage medium 108 or another non-volatile device and loaded into volatile DRAM and / or processor cache for execution by controller 106.

[0039] For example, firmware can be configured to operate a secure environment using the techniques discussed below. However, the techniques discussed below are not limited to... Figure 1 Used in computer systems and / or in the examples discussed above.

[0040] In the illustrated embodiment, the controller further includes a cryptographic engine 124. In one embodiment, the cryptographic engine 124 processes all security commands received by the controller 106 via the host interface 110. In some embodiments, the security commands include a subset of all commands that the controller 106 can process. In some embodiments, the cryptographic engine 124 may be implemented as part of the controller 106, but is described separately for convenience. The cryptographic engine 124 is communicatively coupled to a key store 118 and a monotonic counter store 114. In some embodiments, both devices include low-latency storage locations, such as registers in a register set. In some embodiments, during power-on, the key store 118 and the monotonic counter store 114 are populated from data stored in the non-volatile storage medium 108, and the key store 118 and the monotonic counter store 114 serve as cache memories for the data stored therein. As will be discussed, the key store 118 stores a plurality of cryptographic keys, including a root key set by the manufacturer or other entity and a session key generated each time the memory device 104 is powered on. Monotonic counter storage area 114 stores multiple monotonic counters, and cryptographic engine 124 is configured to access and update these counters. Cryptographic engine 124 is further configured to authenticate and execute secure commands. In some embodiments, cryptographic engine 124 includes a hardware-based hash calculator, such as a hardware HMAC-SHA1 calculator. In the following... Figures 2 to 7 The discussion provides details of the operation of cryptographic engine 124.

[0041] Figure 2 This is a flowchart illustrating a method for maintaining a plurality of monotonic counters according to some embodiments of the present disclosure.

[0042] Figure 2 The method shown begins at step 202, at which point the memory device is powered on. In some embodiments, Figures 2 to 7 The methods described herein can be implemented in the hardware of a memory device. Alternatively, Figures 2 to 7 The method described herein can be implemented in a controller, such as a reprogrammable microcontroller with a memory device. In either scenario, whenever the device is powered on, Figure 2 The method is executed within.

[0043] In step 204, the memory device increments a power-on monotonic counter (MTC). As used herein, the power-on monotonic counter is referred to as A-MTC1. As will be discussed, a separate security command MTC is referred to as A-MTC0. Both A-MTC0 and A-MTC1 include a fixed-width counter that increments from a starting value (e.g., 0x0). In some embodiments, A-MTC1 is stored in a non-volatile location (e.g., sectors and pages of a lower-level non-volatile storage medium) to remain constant during power cycles. Optionally, the value of A-MTC1 may be stored in a register or other low-latency storage location. In this embodiment, the value of A-MTC1 is read from non-volatile storage and written to volatile (e.g., register) storage for faster access. Because the value of A-MTC1 is updated only upon power-on, the copying of the value to lower-latency storage may only occur once during operation of the memory device.

[0044] In step 216, the memory device generates a session key based on the value of A-MTC1 and the root key.

[0045] In the illustrated embodiments, the memory device is configured to store a root key. This root key includes a pre-shared key (PSK) used in symmetric encryption systems. In some embodiments, the host device additionally accesses the same PSK, and the host and memory device can communicate securely using the PSK, as will be described. The root key is stored in a secure storage location on the memory device. Optionally, the root key can be written by the manufacturer of the memory device during manufacturing.

[0046] As described, cryptography is used to protect some or all communication between a memory device and an external device. The memory device and the external device utilize a unique session key each time the memory device is powered on. This prevents the reuse of a single key (e.g., a root key), which could lead to vulnerabilities in the memory device. Session keys can be generated in various ways, and the specific methods for generating session keys should not be overly restricted.

[0047] As an example, a session key can be generated using the value of A-MTC1 and the root key. In this example, a hash-based Message Authentication Code (HMAC) algorithm (e.g., HMAC-SHA1) is used to generate the session key. In this example, the session key can be defined as K. session =H(K) root ,A-MTC1), where H represents the selected HMAC (or similar) function, K root This includes the root key onboard to the memory device, and A-MTC1 is the current value of the power-on MTC. In this and other instances, the session key is guaranteed to be unique each time the memory device is powered on based on the A-MTC1 value.

[0048] In step 222, after generating the session key, the memory device increments the value of the security command monotonic counter (A-MTC0). Optionally, the memory device may skip step 220. In one embodiment, the value of A-MTC0 is reset to zero during a power cycle. Alternatively, the value of A-MTC0 may remain constant during a power cycle.

[0049] After incrementing the value of A-MTC0, the memory device receives a command in step 206. As will be discussed, the command may include an insecure command (e.g., an unsigned command) or a secure command. In one embodiment, a secure command includes a subset of all commands. Generally, a secure command will contain a signature that can be used to verify the integrity of the transmitter and the message. A secure command is a command that performs authorized operations on the underlying non-volatile storage medium after authentication. In contrast, insecure commands include existing commands that do not utilize the signatures and MTC values ​​described in this disclosure. For example, existing RPMC commands may include insecure commands in the context of the disclosed embodiments.

[0050] If the memory device receives an insecure command in step 208, the memory device processes the insecure command in step 214. The memory device processes the insecure command in any reasonable manner known in the art, and details of processing the insecure command are not provided herein.

[0051] If the memory device receives a security command in step 208, the memory device begins processing the security command from step 210. In one embodiment, the memory device may decode the command. In one embodiment, the memory device may decode both insecure and secure commands. In one embodiment, the memory device may selectively decode only secure commands. The memory device distinguishes between insecure and secure commands during command decoding (e.g., by identifying the opcode and command type). In one embodiment, secure commands comprise a subset of all commands. In one embodiment, the memory device may decode the command based on its command structure. In one embodiment, the memory device may decode the command based on its opcode. In one embodiment, the memory device may decode the command based on its flags or other information.

[0052] In step 210, the memory device attempts to process a security command after processing (e.g., performing a decoding operation) the command. Details of processing various security commands are provided in the following flowchart and will not be repeated herein. Generally, processing a security command involves verifying the command's signature and checking the MTC value within the command. As will be discussed, a security command contains one or more MTC values ​​synchronized between the command issuer (i.e., the host device) and the memory device. The memory device compares the received MTC value with the expected MTC value to prevent replay attacks. Additionally, the host device signs each command using a session key, and the memory device verifies this signature, which ensures that the sending device can access the session key (and therefore the root key), verifying that the sending device is authorized to issue security commands. Regarding Figures 3 to 7 The method described in the text provides a more detailed account of variations of this general method.

[0053] In step 212, the memory device branches based on whether the security command was successful. In short, a security command can fail for three main reasons. First, the security command may fail due to physical or logical defects. For example, the security command may access an invalid address, or the memory device may contain physical defects that prevent it from responding. Although such failures exist, they are not elaborated in this disclosure. Second, the security command may fail because the signature cannot be verified. Thus, the security command may be a valid command, but the lack of a valid signature means that the memory device cannot verify the sender's identity. Therefore, the memory device considers it a failed security command. Third, the MTC value in the command may not match the corresponding MTC value stored in the memory device. In this scenario, the security command may be a replay of a previous command (specifically, when the signature is valid). Therefore, the memory device also considers this scenario a failed command.

[0054] As illustrated in one embodiment, if the memory device detects a security command failure, the memory device stops processing the security command. Optionally, the memory device may return an error response indicating that the command failed.

[0055] Alternatively, if the memory device determines that the security command is valid and successful, the memory device increments the value of A-MTC0 in step 218. As illustrated, the memory device increments A-MTC0 for each valid security command and continues to increment A-MTC0 until its maximum value is reached or the device is powered off. Optionally, the value of A-MTC0 may exceed a limit and be "reset" to zero after reaching the maximum storable value.

[0056] In an alternative embodiment, the memory device may perform step 218 only in response to a secure write command. That is, the memory device increments A-MTC0 only in response to a secure request to write data to memory.

[0057] In an optional embodiment, the memory device may perform step 218 first, followed by step 210. In this embodiment, the value of A-MTC0 is incremented for each received security command compared to each valid security command. That is, the memory device increments A-MTC0 for both valid and invalid security commands (e.g., those with incorrect signatures or MTC values).

[0058] In step 220, after incrementing the value of A-MTC0, the memory device generates and returns a response to the security command. Figure 3-7 The details of generating a response for a specific command are described in more detail. Generally, the memory device extracts the incremented value of A-MTC0 and, for some commands, extracts the value of A-MTC1. The memory device combines one or more MTC values ​​with response data (e.g., read results, status register data, etc.) to form the payload. The memory device then uses cryptographic functions such as the HMAC function to generate a digital signature for the payload.

[0059] Similar to the discussion of step 216, the memory device can use the HMAC function to sign the payload using the session key. Therefore, the response can include the payload and the signature S = H(K). session The payload is a cryptographic function such as HMAC (e.g., HMAC-SHA1) and includes the data to be returned, containing any MTC values.

[0060] If in Figures 3 to 7As described in more detail, the receiving device (e.g., the host device) locally stores the MTC value and uses it in subsequent security requests, thereby ensuring freshness in communications with the memory device. Compared to existing systems where the host device needs to actively query for the MTC value, the memory device automatically includes the MTC value in each response to a security command, thus ensuring that the host device and the memory device are always synchronized.

[0061] The values ​​of A-MTC0 and A-MTC1 can be provided to the host device in various ways. In the illustrated embodiment, the values ​​of A-MTC0 and A-MTC1 are provided in the response packet of a security command. However, in an alternative embodiment, the memory device may provide the values ​​of A-MTC0 and A-MTC1 in other ways. As a first example, the memory device can provide the value of A-MTC0 or A-MTC1 when the memory device is powered on. Therefore, when the memory device is powered on, the host device can listen for the value of A-MTC0 or A-MTC1. As a second example, the memory device may provide the value of A-MTC0 or A-MTC1 via a direct read of a register—containing the value of A-MTC0 or A-MTC1. In some embodiments, this direct read may include a security command as previously described. Alternatively, the direct read may include an insecure command.

[0062] The various steps of the foregoing method are described as being performed by a memory device. In some embodiments, these steps may be performed in a similar manner by other types of devices. Additionally, the various steps may be performed by different components of the memory device.

[0063] Figure 3 This is a swimlane diagram illustrating security commands for requesting parameters to be stored in a memory device according to some embodiments of the present disclosure. In one embodiment, the security commands include a subset of all commands.

[0064] In the illustrated embodiment, the host sends a command to the memory device to retrieve a unique identifier (UID) stored in the memory device. In some embodiments, the UID includes a unique value for the memory device and is unique among all such memory devices manufactured by a single manufacturer.

[0065] In step 302, the host device generates a random value. In one embodiment, the random value includes a random or pseudo-random value generated on the host. In the illustrated embodiment, the random value is used to prevent the replay of the issued command in step 304.

[0066] In step 304, the host issues a command to request a UID. In some embodiments, the command has the following form:

[0067]

[0068] Table 1

[0069] Request UID command format

[0070] As illustrated in Table 1, a command contains a predetermined opcode (e.g., 9Bh) and a type modifier indicating a specific command (e.g., 0x3E). Optionally, the command contains one byte of configuration data (“Config”). Finally, the last four bytes of the command contain a host-generated random value. The specific forms of commands in Table 1 and all tables are merely exemplary, and other forms may be used. It should be noted that commands issued in step 304 include unsigned commands. Therefore, commands can be issued by any device, regardless of whether the device contains a pre-shared key (PSK), as will be discussed.

[0071] In the illustrated embodiments, the host and memory devices may include integrated circuit devices that communicate via wired connections such as SPI or UART.

[0072] In step 306, after receiving the command, the memory device reads the UID. In some embodiments, the UID includes a fixed identifier permanently stored on the memory device. In some embodiments, the UID may be stored in a segmented section of a non-volatile storage medium. In some embodiments, the UID may be burned into a fuse in a separate storage location on the memory device board. Specific methods of storing the UID are not limiting.

[0073] Next, in step 308, the memory device increments the MTC. In the illustrated embodiment, this MTC corresponds to the security command MTC and is labeled A-MTC0. As discussed, the memory device increments the value of A-MTC0 for each security command that is successfully completed. In one embodiment, security commands include a subset of all commands. In the illustrated embodiment, the command issued in step 304 is unsigned and is therefore assumed to have been successfully completed. In some embodiments, when the value of A-MTC0 is incremented, the memory device retains the incremented value to include in the response data packet, as will be discussed.

[0074] In step 310, the memory device generates a response data packet and signs the response. An example format of the response data packet is provided below:

[0075]

[0076] Table 2

[0077] Request UID response format

[0078] In the illustrated embodiment, the response includes a first byte returning the contents of the Extended Status Register (ESR). In some embodiments, the ESR stores the condition or state of the memory device and may take one of a known set of values. The specific format of the ESR is not limiting. The response also includes various reserved fields (referred to simply as "Res.") that are not limiting.

[0079] In the illustrated embodiment, the response additionally returns a one-byte status field indicating the provision status (“Prov.Status”) of the memory device. Provisioning and de-provisioning respectively enable and disable security features of the memory device. Similar to ESR, the provision status may include one of a set of values ​​representing the security configuration of the memory device. In some embodiments, the response additionally includes a 3-byte modification field returning the current modifications to the memory device and / or firmware.

[0080] In some embodiments, all fields described above are optional or can be modified based on system needs. In contrast, in most embodiments, the A-MTC0, UID, and signature fields are mandatory, but their positions can vary.

[0081] In the illustrated embodiment, the A-MTC0 field returns the current value of the security command MTC. As illustrated, the MTC value is a 32-bit value, but different widths can be used as needed based on the underlying register structure. (See also...) Figure 2 As described, the security command MTC is incremented for each security command, but not for insecure commands. In the illustrated embodiment, the value of A-MTC0 is incremented in response to a request for a UID. In other alternative embodiments, the value of A-MTC0 may not be incremented, and step 308 may be omitted.

[0082] In the illustrated embodiment, the UID includes a unique identifier for the memory device and comprises a 128-bit identifier. Other identifier widths may be used.

[0083] Finally, the response includes a 256-bit signature. In one embodiment, the signature is generated by a memory device using the session key described above. Specifically, in the illustrated embodiment, a one-way hash function (e.g., a hash-based Message Authentication Code) can be used to generate the signature. When using a hash-based Message Authentication Code (HMAC), the session key and all fields of the response message (except the signature) are used as inputs to the HMAC. Therefore, the HMAC employs H = (K... session The form is {A-MTC0, UID, ...}, where H includes HMAC functions such as HMAC-SHA1, A-MTC0 includes the value of the security command MTC, UID includes the unique identifier of the memory device, and K... sessionThis includes the session key generated upon power-on, and the ellipsis indicates any additional data in the response (e.g., ESR, providing status, etc.). As noted, except for K... session The external values ​​can be concatenated or otherwise combined to form a single message m, such that m = {A-MTC0, UID, ...}, and therefore the signature includes S = H(K). session ,m).

[0084] In step 312, the memory device returns a signed message to the host. As discussed, the signed message contains at least the value of A-MTC0, the value of UID, and a signature.

[0085] In step 314, the host retrieves the value of A-MTC0 and stores it locally. In this way, both the memory device and the host are synchronized with the value of A-MTC0, as will be discussed. This is because the memory device continuously provides the latest value of A-MTC0 during each security command, thus enabling the host to manage synchronization.

[0086] Figure 4 This is a swimlane diagram illustrating security commands for provisioning and deprovisioning security features of memory devices according to some embodiments of the present disclosure. In one embodiment, the security commands include a subset of all commands.

[0087] In step 402, the host device reads the value of A-MTC0 and generates a random value. Figure 3 The generation of random values ​​is described above and will not be repeated here. As described above, the host device receives the latest value of A-MTC0 from the memory device. In step 402, the host device reads this current value and then sends a provide or cancel provide command.

[0088] In step 404, the host device signs the provide or cancel provide command. In one embodiment, the provide and cancel provide commands share the following format:

[0089]

[0090] Table 3

[0091] Provide / Cancel Provide Command Format

[0092] As illustrated in Table 3, the provide and cancel provide commands share the same format. Both commands begin with a specified opcode (e.g., 9Bh) and include the command type (e.g., 0x35 for provide and 0x33 for cancel provide), a one-byte configuration field, and a four-byte host-generated random value. Additionally, the host device inserts the current value of A-MTC0. In one embodiment, the host device maintains this value by receiving it from a memory device. As described above, this value can be received in response to an explicit read command or various security commands when the memory device is powered on. Finally, the host device generates a secure signature of zero to ten bytes and appends the signature to the first ten bytes. In one embodiment, the signature is generated using an HMAC function such as HMAC-SHA1 and using the session key as the signature key. In another embodiment, the host device generates its own session key by retrieving the value of A-MTC1 and generating a session key using the shared root key. In an alternative embodiment, the host device can read the session key directly from the memory device.

[0093] In step 406, the host device sends a signed provide or cancel provide command to the memory device.

[0094] In step 408, the memory device verifies the signature. In the illustrated embodiment, the memory device extracts the unsigned bytes of the command and generates its own signature using the session key. If the signature generated by the memory device matches the signature in the command (e.g., by comparing values), the memory device verifies the authenticity of the sender.

[0095] In step 410, the memory device activates (provides the command) or deactivates (cancels the provision of the command) the security feature. In one embodiment, the memory device updates a configuration or status register indicating whether the memory device supports the security command. The memory device updates the value of this register based on whether the command is provided or canceled. In one embodiment, upon provision, the memory device will accept the signed security command as described throughout this specification. In contrast, upon cancellation, the memory device will no longer accept the security command. Optionally, the memory device may ignore the security command. As another option, the memory device may process the security command as insecure (e.g., read and write, but not authenticated locks) where appropriate. As discussed above, the security command processing routine is stored in firmware or in dedicated hardware circuitry or devices. Therefore, the memory device "short-circuits" this logic upon cancellation and enables it upon provision.

[0096] Next, in step 412, the memory device increments MTC. In the illustrated embodiment, this MTC corresponds to the security command MTC and is labeled A-MTC0. As discussed, the memory device increments the value of A-MTC0 for each successfully completed security command. Figure 3 Details of this step are provided in step 308 and will not be repeated herein. Optionally, if the memory device is configured only to update A-MTC0 for a secure write operation, the memory device may not increment A-MTC0 for a provide or cancel provide command.

[0097] In step 414, the memory device generates a response data packet and signs the response. An example format of the response data packet is provided below:

[0098]

[0099]

[0100] Table 4

[0101] Provide response format

[0102] The response to the cancel command can be formatted in a similar manner. The packets in Table 4 share fields with those in Table 2, and descriptions of those shared fields (e.g., signature, UID, A-MTC0, ESR, random number, etc.) are not repeated herein. The formatting and generation of those fields are incorporated herein by reference in their entirety. In addition to A-MTC0, the response packet also contains the powered A-MTC1 value, which can be retrieved in the same manner as A-MTC0.

[0103] In some embodiments, all fields described above are optional or can be modified based on system needs. In contrast, in most embodiments, the A-MTC0, A-MTC1, UID, and signature fields include mandatory fields, but the position of the fields can vary.

[0104] In step 416, the memory device returns the signed message to the host. As discussed, the signed message contains at least the value of A-MTC0, the value of A-MTC1, and a signature.

[0105] In step 418, the host retrieves the values ​​of A-MTC0 and A-MTC1 and stores these values ​​locally. In this way, both the memory device and the host are synchronized with the values ​​of A-MTC0 and A-MTC1, as will be discussed. This is because the memory device continuously provides the latest value of A-MTC0 during each security command, thus enabling the host to manage synchronization.

[0106] Figure 5This is a swimlane diagram illustrating security commands for protecting data reading and writing to media of a memory device according to some embodiments of the present disclosure. In one embodiment, the security commands include a subset of all commands.

[0107] In step 502, the host device reads the value of A-MTC0. As described above, the host device receives the latest value of A-MTC0 from the memory device. In step 502, the host device reads this current value and then sends a provide or cancel provide command.

[0108] In step 504, the host device generates and signs an authenticated modification command to program or erase data from media on the memory device. In one embodiment, the authenticated modification command has the following format:

[0109]

[0110] Table 5

[0111] Authenticated command format modification

[0112] As illustrated in Table 5, a certified modification begins with a specified opcode (e.g., 9Bh) and includes a two-byte configuration field for the command type (e.g., 0x34), any options for the specified command, and a four-byte value for A-MTC0. Like other commands, the host device maintains this value by receiving it from the memory device. As described above, this value can be received in response to an explicit read command or in response to various security commands when the memory device is powered on.

[0113] The command also includes three-digit source and destination address fields, as well as a three-digit size field. The specific format of these fields may vary depending on the implementation, but generally includes any fields required to support programming or erasing (or similar) operations on the memory device.

[0114] Finally, the host device generates a secure signature of zero to eighteen bytes and appends the signature to the first eighteen bytes. In one embodiment, the signature is generated using an HMAC function such as HMAC-SHA1 and using the session key as the signing key. In another embodiment, the host device generates its own session key by retrieving the value of A-MTC1 and generating the session key using the shared root key. In an alternative embodiment, the host device can read the session key directly from a memory device.

[0115] In step 506, the host device sends the signed and authenticated modification command to the memory device.

[0116] In step 508, the memory device verifies the signature. In the illustrated embodiment, the memory device extracts the unsigned bytes of the command and generates its own signature using the session key. If the signature generated by the memory device matches the signature in the command (e.g., by comparing values), the memory device verifies the authenticity of the sender.

[0117] In step 510, the memory device performs the requested programming or erasing operation represented by a certified modification command. In some embodiments, programming or erasing can be performed in any manner known in the art to program or erase the memory device.

[0118] Next, in step 512, the memory device increments MTC. In the illustrated embodiment, this MTC corresponds to the security command MTC and is labeled A-MTC0. As discussed, the memory device increments the value of A-MTC0 for each successfully completed security command. Figure 3 Details of this step are provided in step 308 and will not be repeated herein. Optionally, if the memory device is configured only to update A-MTC0 for a programming operation, the memory device may not increment A-MTC0 for a provide or cancel provide command.

[0119] In step 514, the memory device reads the value of A-MTC1, and in step 616, the memory device generates a response data packet and signs the response. An example format of the response data packet is provided below:

[0120]

[0121] Table 6

[0122] Provide response format

[0123] The data packets in Table 6 share fields with those in Tables 2 and 4, and descriptions of those shared fields (e.g., signature, A-MTC0, A-MTC1ESR, etc.) are not repeated herein. The formatting and generation of those fields are incorporated herein by reference in full.

[0124] As shown in the figure, in addition to A-MTC0, the response packet also contains the powered A-MTC1 value, which can be retrieved in the same manner as A-MTC0. Since the register read is unsigned, a register read command can be used to obtain the current value of A-MTC1. Then, as described above, the host device can use the value of A-MTC1 to generate a session key. Therefore, in some embodiments, the host device will read the register value and then issue a secure command (and sign the secure command). The response packet returns the register value requested in the read command, or a zero-padded copy of the data to be written in the write command. Additionally, in some embodiments, the command includes a copy signature (DupSig), which includes a portion of the total signature. Finally, the source, destination, and size fields can be returned to the host device to confirm the operation.

[0125] In some embodiments, all fields described above are optional or can be modified based on system needs. In contrast, in most embodiments, A-MTC0, A-MTC1, and the signature field include mandatory fields, but the position of the fields can vary.

[0126] In step 516, the memory device returns the signed message to the host. As discussed, the signed message contains at least the value of A-MTC0, the value of A-MTC1, and a signature.

[0127] In step 518, the host retrieves the values ​​of A-MTC0 and A-MTC1 and stores these values ​​locally. In this way, both the memory device and the host are synchronized with the values ​​of A-MTC0 and A-MTC1, as will be discussed. This is because the memory device continuously provides the latest value of A-MTC0 during each security command, thus enabling the host to manage synchronization.

[0128] Figure 6 This is a swimlane diagram illustrating security commands for protecting register data reads and writes of a memory device according to some embodiments of the present disclosure. In one embodiment, the security commands include a subset of all commands.

[0129] In step 602, the host device reads the value of A-MTC0. As described above, the host device receives the latest value of A-MTC0 from the memory device. In step 602, the host device reads this current value and then sends a provide or cancel provide command.

[0130] In step 604, the host device generates and signs a secure register read or write command to read or write data from or to the registers of the memory device. In one embodiment, the secure read or write command has the following format:

[0131]

[0132] Table 7 Format of Secure Register Read Command

[0133]

[0134] Table 8

[0135] Secure Write to Register Command Format

[0136] As illustrated in Tables 7 and 8, the security register read and write commands share the same format of bytes zero through eight. Each command begins with a specified opcode (e.g., 9Bh) and includes a command type (e.g., 0x38 for read, 0x3C for write), a one-byte configuration field, a four-bit value for A-MTC0, and a two-bit register address to be read from or written to. Additionally, the write register commands in Table 8 contain four bits of any data to be written. It should be noted that in the illustrated embodiments, only the write register commands include a signature field. As with the previous commands, the host device generates this signature based on data of bytes zero through twelve in Table 8. In one embodiment, the signature is generated using an HMAC function such as HMAC-SHA1 and using the session key as the signature key. In another embodiment, the host device generates its own session key by retrieving the value of A-MTC1 and generating the session key using the shared root key. In an alternative embodiment, the host device can read the session key directly from the memory device.

[0137] In step 606, the host device sends a signed read or write register command to the memory device.

[0138] In step 608, the memory device verifies the signature. In the illustrated embodiment, the memory device extracts the unsigned bytes of the command and generates its own signature using the session key. If the signature generated by the memory device matches the signature in the command (e.g., by comparing values), the memory device verifies the authenticity of the transmitter. As illustrated in Table 7, step 608 can be skipped for register reads.

[0139] In step 610, the memory device reads or writes to the identified register following the authentication command. The memory device reads or writes to the register in any manner known in the art.

[0140] Next, in step 612, the memory device increments MTC. In the illustrated embodiment, this MTC corresponds to the security command MTC and is labeled A-MTC0. As discussed, the memory device increments the value of A-MTC0 for each successfully completed security command. Figure 3Details of this step are provided in step 308 and will not be repeated here. Optionally, if the memory device is configured only to update A-MTC0 for safe write operations such as register writes, the memory device may not increment A-MTC0 for provide or cancel provide commands.

[0141] In step 614, the memory device generates a response data packet and signs the response. An example format of the response data packet is provided below:

[0142]

[0143]

[0144] Table 9

[0145] Register read / write response format

[0146] The data packets in Table 9 share fields with those in Table 3, and descriptions of those shared fields (e.g., signature, A-MTC0, ESR, etc.) are not repeated herein. The formatting and generation of those fields are incorporated herein by reference in full.

[0147] As shown in the figure, in addition to A-MTC0, the response packet also includes the powered A-MTC1 value, which can be retrieved in the same manner as A-MTC0. Since the register read is unsigned, the register read command can be used to obtain the current value of A-MTC1. Then, as described above, the host device can use the value of A-MTC1 to generate a session key. Therefore, in some embodiments, the host device will read the register value and then issue a security command (and sign the security command). The response packet returns the register value requested in the read command, or a zero-padded copy of the data to be written in the write command. Both commands contain the addresses of the affected registers.

[0148] In some embodiments, all fields described above are optional or can be modified based on system needs. In contrast, in most embodiments, A-MTC0, A-MTC1, and the signature field include mandatory fields, but the position of the fields can vary.

[0149] In step 616, the memory device returns the signed message to the host. As discussed, the signed message contains at least the value of A-MTC0, the value of A-MTC1, and a signature.

[0150] In step 618, the host retrieves the values ​​of A-MTC0 and A-MTC1 and stores these values ​​locally. In this way, both the memory device and the host are synchronized with the values ​​of A-MTC0 and A-MTC1, as will be discussed. This is because the memory device continuously provides the latest value of A-MTC0 during each security command, thus enabling the host to manage synchronization.

[0151] Figure 7 This is a swimlane diagram illustrating security commands for block locking and unlocking of a memory device according to some embodiments of the present disclosure.

[0152] In step 702, the host device reads the value of A-MTC0. As described above, the host device receives the latest value of A-MTC0 from the memory device. In step 702, the host device reads this current value and then sends an unlock command.

[0153] In step 704, an authenticated lock or unlock command is generated and signed. In one embodiment, the authenticated lock or unlock command includes a command type field identifying the command as an unlock command and a value for A-MTC0. The authenticated lock or unlock command is then signed using a session key shared between the host device and the memory device. The foregoing operations are similar to the previous operations and are not repeated in detail herein. In some embodiments, the authenticated lock or unlock command may include a block address for unlocking a block. In other embodiments, the unlock command may apply to all blocks in the memory device.

[0154] In step 706, the host device sends a signed, authenticated lock or unlock command to the memory device.

[0155] In step 708, the memory device verifies the signature. In the illustrated embodiment, the memory device extracts the unsigned bytes of the command and generates its own signature using the session key. If the signature generated by the memory device matches the signature in the command (e.g., by comparing values), the memory device verifies the authenticity of the sender.

[0156] In step 710, the memory device unlocks one or more blocks of the memory device. As used herein, block locking refers to protecting an entire memory device or block range from programming and erasing. However, in conventional memory devices, there are no constraints regarding block locking or unlocking from the hardware level. Therefore, in existing memory devices with block locking, block locking prevents malicious users from programming and erasing, but those same users can unlock the block locks without penalty, thus hindering the purpose of locking blocks.

[0157] In some embodiments, the memory device maintains a dedicated register storing the authenticated lock state. Because the authenticated lock or unlock command is signed, only an authenticated user can update this register. In some embodiments, the memory device blocks conventional unlocking operations when the register indicates that an authenticated lock command has been received but a corresponding authenticated unlock command has not been received. When an authenticated unlock command is received, the register is updated, and future conventional programming and erasing commands function normally. In this way, a manufacturer or other entity with root key access can quickly program or erase the device using the authenticated unlock command and conventional programming / erasing commands before issuing an authenticated lock command, thereby preventing future unauthenticated programming or erasure. Because conventional programming / erasing operations do not require the generation of a signature, they can be performed much faster than more secure operations that require such a signature.

[0158] Next, in step 712, the memory device increments MTC. In the illustrated embodiment, this MTC corresponds to the security command MTC and is labeled A-MTC0. As discussed, the memory device increments the value of A-MTC0 for each successfully completed security command. Figure 3 Details of this step are provided in step 308 and will not be repeated here. Optionally, if the memory device is configured only to update A-MTC0 for a secure write operation, the memory device may not increment A-MTC0 for an authenticated lock or unlock command.

[0159] In step 714, the memory device generates a response data packet and signs the response.

[0160] In step 716, the memory device returns the signed message to the host. As previously discussed regarding other commands, the signed message contains at least the values ​​of A-MTC0, A-MTC1 (if transmitted), and a signature.

[0161] In step 718, the host retrieves the values ​​of A-MTC0 and A-MTC1 (if they have been transmitted) and stores them locally. In this way, both the memory device and the host are synchronized with the values ​​of A-MTC0 and A-MTC1, as will be discussed. This is because the memory device continuously provides the latest value of A-MTC0 during each security command, thus enabling the host to manage synchronization.

[0162] In addition to the commands described above, the memory device may support a signed transaction cache command set. This set includes commands to start a transaction and second commands to end a transaction, thereby supporting transaction operations on the underlying memory media.

[0163] The foregoing embodiments provide various improvements and benefits compared to existing memory devices such as NOR flash memory devices. As an initial benefit, the aforementioned commands enable the reuse of existing NOR drives. Specifically, the commands are designed to reuse familiar RPMC hardware sequencing and require only security-specific middleware to support additional commands. Providing and deproviding commands allow security commands to be programmatically enabled and disabled. Therefore, memory devices can be provisioned or deprovisioned at the factory or in fields. Additionally, platform startup and read performance are maintained by fully supporting legacy read operations. Finally, legacy non-volatile block locking is enhanced with cryptographic protection when combined with authenticated lock or unlock commands. Specifically, a locked block can be unlocked using only authenticated lock or unlock commands and modified while locked using only authenticated modification commands. While legacy software can still erase blocks when unlocked using insecure commands, using authenticated lock or unlock and modification commands allows for more customizable control over security features, especially as the device moves through the supply chain.

[0164] This disclosure includes various apparatuses for performing methods and implementing the systems described above, including a data processing system for performing these methods, and a computer-readable medium containing instructions that, when executed on the data processing system, cause the system to perform these methods.

[0165] The descriptions and figures are illustrative and should not be construed as limiting. Many specific details are described to provide a thorough understanding. However, in some cases, well-known or conventional details are omitted to avoid obscuring the description. References to one or more embodiments in this disclosure do not necessarily refer to the same embodiment; and such references imply at least one.

[0166] In this specification, references to "an embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of this disclosure. The appearance of the phrase "in one embodiment" at various points throughout this specification does not necessarily refer to the exact same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. Furthermore, various features that may be demonstrated by some embodiments but not by others are described. Similarly, various requirements are described, which may be requirements for some embodiments but not for others.

[0167] In this description, various functions and operations may be described as being executed or caused by software code for the sake of simplicity. However, those skilled in the art will recognize that such expressions mean that the functions are caused by the execution of code by one or more processors, such as microprocessors, application-specific integrated circuits (ASICs), graphics processors, and / or field-programmable gate arrays (FPGAs). Alternatively or in combination, functions and operations may be implemented using dedicated circuit systems (e.g., logic circuit systems) with or without software instructions. Embodiments may be implemented using wired circuit systems without software instructions or in combination with software instructions. Therefore, the techniques described are not limited to any particular combination of hardware circuit systems and software, nor are they limited to any particular source of instructions executed by a computing device.

[0168] While some embodiments can be implemented in fully functional computers and computer systems, various embodiments can be distributed as a variety of computing products and are applicable regardless of the specific type of machine or computer-readable medium actually used to implement the distribution.

[0169] At least some of the disclosed aspects may be embodied, at least in part, in software. That is, the techniques may be performed in a computing device or other system in response to its processor (e.g., a microprocessor) executing a sequence of instructions contained in memory (e.g., ROM, volatile RAM, non-volatile memory, cache memory, or remote storage device).

[0170] The routines executed to implement embodiments can be implemented as part of an operating system, middleware, business delivery platform, software development kit (SDK) component, network service, or other specific application, component, program, object, module, or sequence of instructions referred to as a "computer program." The calling interface to these routines can be exposed to the software development community as an application programming interface (API). Computer programs typically include one or more sets of instructions stored in various memories and storage devices within a computer at various times, and these sets of instructions, when read and executed by one or more processors in the computer, cause the computer to perform operations necessary for the execution of elements involving various aspects.

[0171] Machine-readable media can be used to store software and data that, when executed by a computing device, cause the device to perform various methods. Executable software and data can be stored in various locations, including, for example, ROM, volatile RAM, non-volatile memory, and / or cache memory. A portion of this software and / or data can be stored in any of these storage devices. Additionally, data and instructions can be obtained from a centralized server or a peer-to-peer network. Different portions of data and instructions can be obtained from different centralized servers and / or peer-to-peer networks at different times and in different communication sessions or within the same communication session. All data and instructions can be obtained before the application is executed. Alternatively, portions of data and instructions can be obtained dynamically and as needed for execution. Therefore, it is not required that all data and instructions be on the machine-readable media at any given moment.

[0172] Examples of computer-readable media include, but are not limited to, recordable and non-recordable media, such as volatile and non-volatile memory devices, read-only memory (ROM), random access memory (RAM), flash memory devices, solid-state drive storage media, removable disks, disk storage media, optical storage media (e.g., optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), etc.). Computer-readable media can store instructions.

[0173] Generally, tangible or non-transitory machine-readable media includes any mechanism that provides (e.g., stores) information in a form accessible to a machine (e.g., a computer, mobile device, network device, personal digital assistant, manufacturing tool, any device having one or more processor sets, etc.).

[0174] In various embodiments, the wired circuit system can be used in combination with software and firmware instructions to implement the technology. Therefore, the technology is neither limited to any particular combination of hardware circuit systems and software, nor to any particular source of instructions executed by a computing device.

[0175] A wide variety of computing devices of different types can be used to implement the various embodiments described herein. As used herein, examples of “computing devices” include, but are not limited to, servers, centralized computing platforms, systems with multiple computing processors and / or components, mobile devices, user terminals, vehicles, personal communication devices, wearable digital devices, electronic self-service terminals, general-purpose computers, electronic document readers, tablet computers, laptops, smartphones, digital cameras, home appliances, televisions, or digital music players. Additional examples of computing devices include those part of what is known as the “Internet of Things” (IoT). Such “things” may interact incidentally with their owners or administrators who may monitor or modify settings on these things. In some cases, such owners or administrators act as users of the “thing” devices. In some instances, a user’s primary mobile device (e.g., an Apple iPhone) may be an administrator server for paired “thing” devices worn by the user (e.g., an Apple Watch).

[0176] In some embodiments, the computing device may be a computer or a host system, such as a desktop computer, a laptop computer, a web server, a mobile device, or another computing device including memory and processing means. The host system may include or be coupled to a memory subsystem, such that the host system can read data from or write data to the memory subsystem. The host system may be coupled to the memory subsystem via a physical host interface. Generally, the host system may access multiple memory subsystems via the same communication connection, multiple separate communication connections, and / or a combination of communication connections.

[0177] In some embodiments, a computing device is a system that includes one or more processing devices. Examples of processing devices may include a microcontroller, a central processing unit (CPU), a dedicated logic circuit system (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.), a system-on-a-chip (SoC), or another suitable processor.

[0178] Although some diagrams illustrate multiple operations in a specific order, non-orderly dependent operations can be reordered and other operations can be combined or decomposed. While some reorderings or other groupings are specifically mentioned, other reorderings or groupings will be obvious to those skilled in the art, and therefore an exhaustive list of alternatives is not provided. Furthermore, it should be recognized that stages can be implemented in hardware, firmware, software, or any combination thereof.

[0179] In the foregoing description, this disclosure has been described with reference to specific exemplary embodiments. It will be apparent that various modifications may be made thereto without departing from the broader spirit and scope set forth in the appended claims. Therefore, the description and drawings should be viewed in an illustrative rather than restrictive sense.

Claims

1. A memory device comprising: A controller configured to decode and execute commands issued by a host device; A cryptographic engine configured to authenticate a subset of commands, each of the subsets of commands containing a digital signature; as well as A first monotonic counter increments after at least some of the subsets of the command are executed; The value of the first monotonic counter is used to generate the digital signature to authenticate the subset of the command.

2. The memory device according to claim 1, further comprising a second monotonic counter that increments when the memory device is powered on.

3. The memory device of claim 2, wherein the digital signature is generated by performing an HMAC operation on the payload using a session key.

4. The memory device according to claim 3, wherein the session key is generated by performing an HMAC operation on the value of the second monotonic counter.

5. The memory device of claim 1, wherein the controller is configured to return the value of the first monotonic counter in response to each security command issued by the host device.

6. The memory device of claim 1, wherein the controller is configured to return the value of the first monotonic counter in response to each security command issued by the host device to write data to the memory device.

7. The memory device of claim 1, wherein the subset of commands comprises commands selected from the group consisting of: provide commands, cancel provide commands, authenticated modify commands, write register commands, authenticated lock commands, and authenticated unlock commands.

8. A method comprising: Receive a security command from the host device at the memory device, the security command including a first digital signature; The memory device authenticates the security command by generating a second digital signature of the security command and comparing the second digital signature with the first digital signature. The memory device increments the first monotonic counter after the security command is successfully completed; The memory device generates a response to the security command, the response including the value of the first monotonic counter and the value of the second monotonic counter; The response is signed by the memory device; as well as The memory device returns the response to the host device.

9. The method of claim 8, further comprising: The second monotonic counter increments when the memory device is powered on.

10. The method of claim 9, further comprising using the value of the second monotonic counter to generate a session key.

11. The method of claim 10, wherein the session key is generated by performing an HMAC operation on the value of the second monotonic counter after the memory device is powered on.

12. The method of claim 10, wherein the second digital signature is generated by performing an HMAC operation on the payload using the session key.

13. The method of claim 8, wherein the security command is selected from the group consisting of: provide command, cancel provide command, authenticated modify command, write register command, authenticated lock command, and authenticated unlock command.

14. The method of claim 12, wherein the security command includes a provision command, and the method further includes enabling processing of the security command in response to executing the provision command.

15. The method of claim 12, wherein the security command includes a cancel provision command, and the method further includes disabling processing of the security command in response to executing the cancel provision command.

16. The method of claim 12, wherein the security command includes an authenticated modification command, and the method further comprises: In response to the certified modification command, the data stored in the memory device is programmed or erased.

17. The method of claim 12, wherein the security command includes a write register command, and the method further includes writing data into a register of the memory device.

18. The method of claim 12, wherein the security command includes an authenticated locking command, and the method further includes locking one or more blocks of the memory device.

19. The method of claim 12, wherein the security command includes an authenticated unlock command, and the method further includes unlocking one or more blocks of the memory device.

20. The method of claim 8, further comprising receiving an insecure command and executing the insecure command, wherein the value of the first monotonic counter is not incremented in response to the insecure command.

Images