Method for generating initialization vector for NVMe inline encryption

Abstract

Various embodiments include a method of implementing a cryptographic function at a computing device for a non-volatile memory fast (NVMe) inline storage cryptographic. Embodiments may include receiving an NVMe command; generating at least a first initialization vector for the NVMe command; receiving data of the first initialization vector and the NVMe command as input of a password function; and implementing the cryptographic function based at least on the first initialization vector, the data of the NVMe command, and the cryptographic key that generates the cryptographic function output. In some embodiments, a first initialization vector is configured for data of an NVMe command at a first namespace and at a first logical block of an NVMe memory device, and is configured to be different from a second initialization vector for another NVMe command, a second initialization vector for the other NVMe command is configured for a second namespace of the NVMe memory device and data for the other NVMe command at the first logical block.

Description

Related applications

[0001] This application claims priority to Israeli Patent Application No. 305055, filed on August 8, 2023, the entire contents of which are incorporated herein by reference. Background Technology

[0002] The Non-Volatile Memory Fast (NVMe) protocol for solid-state storage devices enables fast and high-throughput communication between NVMe memory devices and processing systems. Peripheral Component Interface Fast (PCIe) controllers can be configured to enable NVMe protocol communication between NVMe devices and components of the processing system. Data sent to and from NVMe devices to the processing system is vulnerable to manipulation by malicious actors. Summary of the Invention

[0003] Various aspects include apparatus, processing systems, and methods for implementing cryptographic functions for Non-Volatile Memory Fast (NVMe) inline storage cryptography in a processing system. These aspects may include: receiving an NVMe command; generating at least a first initialization vector for the NVMe command; receiving the first initialization vector and data from the NVMe command as input to the cryptographic function; and implementing the cryptographic function based at least on the first initialization vector, the data from the NVMe command, and a cryptographic key for generating the output of the cryptographic function.

[0004] In some aspects, the first initialization vector for an NVMe command is configured for the data of an NVMe command at a first namespace of the NVMe storage device and at a first logical block of the NVMe storage device, and is configured differently from the second initialization vector for another NVMe command, which is configured for the data of another NVMe command at a second namespace of the NVMe storage device and at a first logical block of the NVMe storage device.

[0005] Some aspects may also include parsing at least first data from an NVMe command, wherein the first initialization vector is based on at least first data from the NVMe command. Some aspects may also include parsing at least second data from an NVMe command, wherein the first initialization vector is based on at least first data from the NVMe command and second data from the NVMe command. Some aspects may also include parsing at least third data from an NVMe command, wherein the first initialization vector is based on at least first data from the NVMe command, second data from the NVMe command, and third data from the NVMe command. In some aspects, the first data from the NVMe command may be a namespace identifier of the namespace of the NVMe memory device, and the second data from the NVMe command may be the starting logical block address of the namespace.

[0006] In some respects, the first initialization vector for NVMe commands may be based on at least first data modified by at least one of the following: at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudo-random value, at least second data parsed from NVMe commands, at least one modified value of at least second data parsed from NVMe commands, at least one data from an NVMe identity controller data structure, or at least one modified value of at least one data from an NVMe identity controller data structure.

[0007] Some aspects may also include retrieving at least second data from the NVMe Identifier Controller data structure, wherein the first initialization vector is based on at least first data from the NVMe command and second data from the NVMe Identifier Controller data structure.

[0008] Some aspects may also include parsing at least initialization vector data generated by software implemented in a computing device including a processing system from NVMe commands, wherein the first initialization vector is based on the at least initialization vector data.

[0009] Another aspect includes computing devices comprising multiple processors configured to perform operations of any of the methods outlined above. Another aspect includes computing devices having components for performing any of the functions outlined above. Another aspect includes a power management integrated circuit configured to perform any of the methods outlined above. Attached Figure Description

[0010] The accompanying drawings, incorporated herein and forming part of this specification, illustrate exemplary embodiments of various implementations and, together with the general description given above and the detailed description given below, serve to interpret the features of the claims.

[0011] Figure 1 This is a component block diagram illustrating an example computing device suitable for implementing various implementation schemes.

[0012] Figure 2 This is a component block diagram illustrating an example inline cryptographic non-volatile memory fast (NVMe) system suitable for implementing various implementation schemes.

[0013] Figure 3 This is a component block diagram illustrating an example inline cryptography module for implementing various inline cryptography NVMe systems.

[0014] Figure 4 This is a component block diagram and process flow illustrating an example of an inline cryptographic NVMe system according to some implementation schemes.

[0015] Figure 5 This is a command structure diagram illustrating commands for an inline cryptographic NVMe system according to some implementation schemes.

[0016] Figure 6 This is an information structure diagram illustrating the NVMe identifier controller data structure for an inline cryptographic NVMe system according to some implementation schemes.

[0017] Figure 7 This is a flowchart illustrating a method for inline cryptography in NVMe devices according to some implementation schemes.

[0018] Figure 8 This is a component block diagram illustrating an example mobile computing device suitable for implementing various implementation schemes.

[0019] Figure 9 This is a component block diagram illustrating an example mobile computing device suitable for implementing various implementation schemes. Detailed Implementation

[0020] Various embodiments will be described in detail with reference to the accompanying drawings. Where possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. References to specific examples and embodiments are for illustrative purposes and are not intended to limit the scope of the claims.

[0021] Various implementations include methods for implementing cryptographic functionality for Non-Volatile Memory Fast (NVMe) inline storage cryptography, and processing systems and / or computing devices implementing such methods. In some implementations, an inline cryptography module may be configured to generate one or more initialization vectors for implementing cryptographic functionality for data of NVMe commands. Generating one or more initialization vectors may be based on data generated from one or more initialization vectors and / or one or more initialization vector generation algorithms. Initialization vector generation data may include data from typical fields in an NVMe command structure, data provided by the application of one or more repurposed fields in an NVMe command structure, and / or data from an NVMe identity controller data structure and / or modified data from any one or more of the foregoing examples. One or more initialization vector generation algorithms may be configured to combine and / or modify one or more of the one or more initialization vector generation data. The inline cryptography module may generate initialization vectors for data of NVMe commands at a namespace and a logical block of an NVMe memory device in a manner different from another initialization vector for data of another NVMe command at another namespace and the same logical block of an NVMe memory device.

[0022] The term "computing device" as used herein refers to any or all of the following: cellular phones, smartphones, personal or mobile multimedia players, personal data assistants (PDAs), laptop computers, tablet computers, convertible laptops / tablets (2-in-1 computers), smartbooks, ultrabooks, netbooks, handheld computers, wireless email receivers, internet-enabled multimedia cellular phones, mobile game consoles, wireless game controllers, and similar personal electronic devices including memory and programmable processors. The term "computing device" may also refer to resident computing devices, including personal computers, desktop computers, standalone computers, workstations, supercomputers, mainframe computers, embedded computers, servers, home theater computers, and game consoles.

[0023] The NVMe protocol for memory devices enables fast and high-throughput communication between NVMe memory devices and the System-on-Chip (SoC). The Peripheral Component Interface Fast (PCIe) controller can be configured to enable NVMe protocol communication between NVMe devices and components of the processing system. Processing system data sent to and from NVMe devices is vulnerable to manipulation by malicious actors.

[0024] Various implementations address and mitigate the aforementioned issues in NVMe protocol communication by providing inline cryptographic functionality to protect data sent to and from NVMe devices at the SoC. The inline cryptographic module enables cryptographic functions to encrypt data transmitted from the processing system to the NVMe device and / or to decrypt data received from the NVMe device at the SoC using information stored within the inline cryptographic module. The inline cryptographic module can implement cryptographic functionality based on multiple inputs, including one or more initialization vectors, NVMe command data, and / or one or more encryption keys.

[0025] One or more initialization vectors may be generated based on the initialization vectors to generate data. The initialization vector generation data may include data from typical fields in the NVMe command structure, data provided by an application from one or more repurposed fields in the NVMe command structure, and / or data from the NVMe Identity Controller Data Structure and / or modified data from any one or more of the foregoing examples. In some implementations, the initialization vector generation data may include: logical block addresses (LBAs), such as the starting LBA (SLBA) of a data block for an NVMe command and / or the LBA calculated for subsequent data blocks of the NVMe command; namespace identifiers (IDs) for the data used in the NVMe command; one or more other data typically in the NVMe command; one or more data provided by an application executed by processor 14 in a repurposed field of the NVMe command; one or more data from the NVMe Identity Controller Data Structure located in memory belonging to and / or accessible by the inline cryptographic module 38; and / or one or more modified data from one or more of the foregoing examples.

[0026] One or more initialization vector generation algorithms can be configured to combine and / or modify one or more of the initialization vector generation data. In some embodiments, the initialization vector generation algorithm may include operations on the initialization vector generation data, including combinational operations, logical operations, mathematical operations, linear operations, nonlinear operations, randomization operations, pseudo-randomization operations, etc. In some embodiments, the operation of the initialization vector generation algorithm may involve using data from NVMe commands, data from NVMe identity controller data structures, etc., wherein the data may be in unmodified and / or modified form.

[0027] The initialization vector generated by the inline cryptographic module can be used to implement cryptographic functions based on a variety of known, proprietary, and / or to-be-developed cryptographic methods and / or circuits. Non-limiting examples of usable cryptographic methods include the Advanced Encryption Standard (AES) and its variants, such as AES XOR Encryption XOR Adjustable Block Ciphertext Theft (XTS). In some implementations, the initialization vector can be 64-bit, 128-bit, 256-bit, etc. As another example, the cryptographic method can provide application-specific and / or file-based cryptographic functions. The initialization vector can be generated such that the initialization vector differs from the data of NVMe commands at the namespace and logical block of the NVMe memory device, and from other data of another NVMe command at another namespace and the same logical block of the NVMe memory device.

[0028] Figure 1An example is illustrated comprising a computing device 10 suitable for use with various implementations. The computing device 10 may include a processing system 12 having one or more processors 14, memory 16, a memory interface 34, an inline cryptographic module 38 (also referred to herein as an NVMe inline cryptographic module), a communication interface 18, a storage memory interface 20, a clock controller 30, and a bus 32. The computing device 10 may also include communication components 22 (such as a wired or wireless modem), storage memory 24, an antenna 26 for establishing wireless communication links, a power manager 28, and memory 36. The processor 14 may include any of a variety of processing devices, such as multiple processor cores.

[0029] The term "System-on-a-Chip" (SoC) is used herein to refer to a collection of interconnected electronic circuits, generally but not exclusively including processing devices, memory, and communication interfaces. Processing system 12 may include various types of processors 14, some of which may include multiple processor cores. Non-limiting examples of processors that may be included in computing device 10 and implemented in or coupled to processing system 12 include general-purpose processors, central processing units (CPUs), digital signal processors (DSPs), graphics processing units (GPUs), accelerated processing units (APUs), security processing units (SPUs), neural network processing units (NPUs), subsystem processors for specific components of computing devices (such as image processors for camera subsystems or display processors for displays), auxiliary processors, single-core processors, multi-core processors, controllers, and microcontrollers. Processing system 12 may also embody other hardware and hardware combinations such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), other programmable logic devices, discrete gate logic components, transistor logic components, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that components of the integrated circuit reside on a single piece of semiconductor material; this may be referred to as a System-on-a-Chip (SoC).

[0030] Processing system 12 may be implemented in a SoC and / or may include circuitry coupled to multiple chips within the SoC. Computing device 10 may include more than one processing system 12, thereby increasing the number of processors 14, wherein any one or more processors may include multiple processor cores. Computing device 10 may also include other processors (not shown) not associated with processing system 12. Processors 14 may each be configured for a specific purpose that may be the same as or different from other processors 14 of computing device 10. One or more of processors 14 and processor cores with the same or different configurations may be grouped together.

[0031] Processing system 12 may be implemented using a bus architecture generally represented by bus 32. Bus 32 may include any number of interconnect buses and bridges, depending on the specific application of processing system 12 and overall design constraints. Bus 32 links together various circuits including one or more processors 14 and / or hardware components (represented by processor (or processing circuitry) 14, illustrated components, and computer-readable medium / memory (or memory circuitry) 16). Processor 14 may include multiple processors. Memory 16 may include multiple memories. Bus 32 may also link various other circuits, such as clock controller 30, interface circuits 18, 20, voltage regulators (not shown), and / or power management circuitry (e.g., power manager 28).

[0032] The computing device 10 may include any number and combination of memories, such as memory 16 integrated with the processing system 12 and memory 36 separate from the processing system 12. The computing device 10 and / or the processing system 12 may include one or more memories 16, 36 configured for various purposes. One or more memories 16, 36 may include volatile memories, such as random access memory (RAM) or main memory, including static RAM (SRAM) (such as memory 16), dynamic RAM (DRAM) (such as memory 36), or cache memory.

[0033] Memory 16, 36 can be configured to temporarily store a limited amount of data. For example, data can be received from a data sensor or subsystem. As another example, the data can be data and / or processor-executable code instructions requested from non-volatile memory 16, 24, 36, which are loaded from non-volatile memory 16, 24, 36 into memory 16, 36 upon anticipated future access based on various factors. As another example, the data can be intermediate-processed data and / or processor-executable code instructions generated by processor 14 and temporarily stored for rapid future access without being stored in non-volatile memory 16, 24, 36.

[0034] The memory interface 34 can work in harmony with the memory 36 to enable the computing device 10 to store and retrieve data and processor-executable code from the memory 36. The memory interface 34 can control access to the memory 36 and allow the processor 14 to read data from and write data to the memory 36.

[0035] Storage interface 20 and storage memory 24 can operate in concert to allow computing device 10 to store data and processor-executable code on a non-volatile storage medium, such as a non-volatile memory fast (NVMe) memory device. Storage memory 24 can be configured very similarly to an embodiment of memory 16, wherein storage memory 24 can store data or processor-executable code for access by one or more processors in processor 14. Non-volatile storage memory 24 can retain information after computing device 10 has been powered off. When power is restored and computing device 10 restarts, the information stored on storage memory 24 becomes available to computing device 10. Storage interface 20 can control access to storage memory 24 and allow processor 14 to read data from and write data to storage memory 24.

[0036] The inline cryptographic module 38 can be configured to implement cryptographic functions, such as encryption and decryption, for data transactions used with the memory storage device 24. Data transmitted between memory 36 and memory storage device 24 can be encrypted and decrypted by the inline cryptographic module 38 to protect the stored data and memory storage device 24 by encrypting the data, and the encrypted data retrieved from memory storage device 24 can be made available by the SoC by decrypting the data. In some, but not all, embodiments, the inline cryptographic module 38 can be configured to implement hash generation and verification of device hints associated with data transmitted between memory 36 and memory storage device 24 to assess the integrity of the device hints for use when evaluating whether to use the data.

[0037] Power manager 28 can be configured to control the power state of one or more power rails (not shown) for power delivery to components of processing system 12. In some embodiments, power manager 28 can be configured to control the amount of power supplied to components of processing system 12. For example, power manager 28 can be configured to control the connection between components of processing system 12 and power rails. As another example, power manager 28 can be configured to control the amount of power on power rails connected to components of processing system 12. Power manager 28 can be configured as a power management integrated circuit (power management IC or PMIC).

[0038] The clock controller 30 can be configured to control the clock signals sent to the components of the processing system 12. For example, the clock controller 30 can gate the components of the processing system 12 by disconnecting them from the clock signals, and can degated them by connecting them to the clock signals.

[0039] Bus 32 may be a communication texture, such as a communication bus, configured to communicatively connect components of processing system 12. Bus 32 may transmit signals between components of processing system 12. In some embodiments, bus 32 may be configured to control signals between components of processing system 12 by controlling the timing and / or transmission paths of control signals.

[0040] Some or all of the components of the computing device 10 and / or processing system 12 may be arranged differently and / or combined, while still providing the functionality of various implementations. The computing device 10 may not be limited to one component of each of these components, and multiple instances of each component may be included in various configurations of the computing device 10.

[0041] Figure 2 An example of an inline cryptographic NVMe system 200 suitable for implementing various implementation schemes is shown. References Figure 1 and Figure 2 The inline cryptographic NVMe system 200 can be used on computing devices (e.g., Figure 1 Implemented in computing device 10), including memory 36 interconnected with each other via various communication buses, and processing system 202 (e.g., Figure 1 The processing system 12) and NVMe device 214 (or NVMe storage device) (e.g., Figure 1 (The storage memory 24 in the middle).

[0042] Processing system 202 may include one or more processors 14 interconnected with each other via various communication buses, and a peripheral component interface fast (PCIe) controller 212 (e.g., Figure 1 The system 202 includes a storage memory interface 204 and an inline cryptographic module 38. One or more processors 14 can be configured to implement software such as an application 204 (including an advanced operating system), a kernel 206, an NVMe driver 208, and a PCIe driver 210. The PCIe controller 212 can manage communication between the components of the processing system 202 (including the inline cryptographic module 38) and the NVMe device 214. Such communication may include communication for preparing and implementing NVMe commands from one or more processors 14 for data transactions, such as read and / or write transactions, at the NVMe device 214.

[0043] The inline cryptographic module 38 may be a hardware module integrated into the processing system 202. The inline cryptographic module 38 can implement cryptographic functions for data used in NVMe commands, such as encryption, decryption, and / or bypassing. For example, the inline cryptographic module 38 can encrypt data transmitted to the NVMe device 214 and decrypt data received from the NVMe device 214. The cryptographic functions implemented by the inline cryptographic module 38 can be any known, proprietary, and / or to-be-developed encryption and decryption methods and / or circuitry. In some implementations, the inline cryptographic module 38 may implement Advanced Encryption Standard (AES) and / or variations thereof, such as AES XOR Encryption XOR Tunable Block Ciphertext Theft (XTS). For example, the inline cryptographic module 38 may provide per-application and / or file-based cryptographic functions.

[0044] In some implementations, one or more security contexts may be pre-programmed at the inline cryptographic module 38. These security contexts may include one or more encryption keys, one or more encryption algorithms, one or more encryption key slots for retrieving the one or more encryption keys from an encryption key storage structure, one or more initialization vector generation data, and / or one or more initialization vector generation algorithms. The one or more security contexts may be stored in memory belonging to and / or accessible by the inline cryptographic module 38 (e.g., [missing information]). Figure 1 Memory 16, storage memory 24, Figure 1 and Figure 2 The memory 36 is located in the inline cryptographic module 38. In some embodiments, one or more security contexts may be set in the inline cryptographic module 38, such as in memory belonging to the inline cryptographic module 38 and / or accessible by the inline cryptographic module, the software running on the processing system 202, the NVMe drive 208, and / or the application 204. The inline cryptographic module 38 may implement cryptographic functions based on one or more security contexts. In some embodiments, the software running on the processing system 202, the NVMe drive 208, and / or the application 204 may issue requests to use a specific security context and / or specific aspects of the security context (such as one or more encryption keys, one or more encryption algorithms, one or more encryption key slots, one or more initialization vector generation data, and / or one or more initialization vector generation algorithms), and / or request the transmission of data without encryption.

[0045] In some implementations, the inline cryptographic module 38 can operate independently of the PCIe architecture and its different layers, achieving scalable storage throughput and conforming to the NVMe device protocol. In other examples, the inline cryptographic module 38 may be part of the PCIe controller 212. The inline cryptographic module 38 is further described herein.

[0046] Figure 3 Examples of inline cryptographic modules 38 suitable for implementing various schemes are shown. References Figures 1 to 3 The inline cryptographic module 38 may be configured with a buffer address lookup structure 300, a security context structure 302, an encryption module 304, a decryption module 306, and an initialization vector generation module 308. For ease of explanation and clarity in accordance with non-limiting embodiments, the encryption module 304, decryption module 306, and initialization vector generation module 308 are described herein as separate components. However, such separate description is not intended to limit the scope of the claims and specification, and in some specific embodiments and implementations, the encryption module 304, decryption module 306, and / or initialization vector generation module 308 may be implemented as a single combined module.

[0047] The inline cryptographic module 38 (including any combination of encryption module 304, decryption module 306, and / or initialization vector generation module 308) can use any combination of security context data to implement cryptographic functions on the data of the NVMe command. The security context may include any combination of security-related information, such as one or more encryption algorithms, one or more encryption keys, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, one or more initialization vector generation data, one or more initialization vector generation algorithms, etc. In some embodiments, the initialization vector generation data may include: logical block addresses (LBAs), such as the starting LBA (SLBA) of the data block for the NVMe command and / or the LBA calculated for subsequent data blocks of the NVMe command; namespace identifiers (IDs) of the data for the NVMe command; one or more other data typically in the NVMe command; one or more data provided by an application executed by processor 14 in a field for a different purpose in the NVMe command; and data from memory located in and / or accessible by the inline cryptographic module 38 (e.g., ...). Figure 1 Memory 16, storage memory 24, Figure 1 and Figure 2The initialization vector generation algorithm may include one or more data in the NVMe identifier controller data structure located in memory 36; and / or one or more modified data of one or more examples from the foregoing examples. In some embodiments, the initialization vector generation algorithm may include operations on the one or more initialization vector generation data, including combinational operations, logical operations, mathematical operations, linear operations, nonlinear operations, randomization operations, pseudo-randomization operations, etc. In some embodiments, the operation of the initialization vector generation algorithm may involve using data from NVMe commands, data from the NVMe identifier controller data structure, data from the security context, etc., wherein the data may be in unmodified and / or modified form. In some embodiments, the one or more initialization vector generation algorithms may be represented by values ​​configured to be interpreted by the inline cryptographic module 38 to implement the one or more initialization vector generation algorithms.

[0048] Security context data may be pre-programmed at inline cryptographic module 38, provided by an application executing through processor 14, and / or retrieved from memory belonging to and / or accessible by inline cryptographic module 38. For example, inline cryptographic module 38 may use security context data pre-programmed only at inline cryptographic module 38, security context data provided only by an application executing through processor 14, security context data retrieved only from memory, and / or a combination of security context data pre-programmed at inline cryptographic module 38, provided by an application executing through processor 14, and / or retrieved from memory.

[0049] Pre-programmed security context data may be stored in memory belonging to and / or accessible by the inline cryptographic module 38. Security context data provided by an application executed by the processor 14 may be provided to the inline cryptographic module 38 during initialization and / or as part of NVMe commands, and may also be provided to the inline cryptographic module 38 and / or memory belonging to and / or accessible by the inline cryptographic module. Security context data retrieved from memory belonging to and / or accessible by the inline cryptographic module may be pre-programmed data from the NVMe identity controller data structure.

[0050] The buffer address lookup structure 300 may be a data structure stored in memory belonging to and / or accessible by the inline cryptographic module 38 and configured to store various types of data in association with each other, such as a table, array, linked list, graph, etc. In some embodiments, the buffer address lookup structure 300 may store data of at least a buffer address (referred to herein as a buffer address) of memory 36 in association with an NVMe security identifier (ID) used for NVMe commands. The buffer address can be used for NVMe commands to write data from the buffer address of memory 36 to NVMe device 214 and / or to read data from NVMe device 214 into the buffer address of memory 36. The NVMe security ID may be a combination of data, such as an NVMe command submission queue identifier and an NVMe command identifier used for NVMe commands.

[0051] An NVMe command submission queue identifier identifies the NVMe command submission queue to which the NVMe drive 208 can write NVMe commands. The NVMe command submission queue may include a tail pointer configured to trigger a doorbell signal, which instructs the NVMe device 214 that one or more NVMe commands in the NVMe command submission queue are ready for execution at that time. An NVMe command ID identifies the NVMe command.

[0052] The buffer address lookup structure 300 can also store sector offset data used for NVMe commands in association with buffer addresses and NVMe security IDs. In some implementations, the sector offset can be used in the generation of initialization vectors for cryptographic functions. The initialization vector can be used as input to an encryption algorithm and / or as input to generate an encryption algorithm, and is configured to influence the encryption of data in a way that multiple encryptions of data may produce different encryption values. The buffer address lookup structure 300 can store any amount of associated data, such as multiple sets of associated data for more than one NVMe command.

[0053] Security context structure 302 may be a data structure stored in memory belonging to and / or accessible by the inline cryptographic module 38 and configured to store various data in association with each other, such as a table, array, linked list, graph, etc. In some embodiments, security context structure 302 may store NVMe security ID data and security context used for NVMe commands in association with each other. The NVMe security ID in the buffer address lookup structure 300 and security context structure 302 used for the same NVMe command may be the same. Security context may include a combination of security-related information, such as one or more encryption algorithms, one or more encryption keys, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, one or more initialization vector generation data, one or more initialization vector generation algorithms, etc.

[0054] In some implementations, some or all of the security context may be pre-programmed at inline cryptographic module 38 and / or at memory belonging to and / or accessible by inline cryptographic module 38. In some implementations, some or all of the security context may be provided in NVMe commands. In some implementations, some or all of the security context may be provided by an application executed via processor 14, from which NVMe commands are initiated. Security context structure 302 may store any amount of associated data, such as more than one set of associated data for more than one NVMe command.

[0055] The buffer address lookup structure 300 and security context structure 302 can be configured in the inline cryptographic module 38 during the NVMe command submission phase. In some implementations, the NVMe drive (e.g., Figure 2 The NVMe driver 208 can configure a buffer address lookup structure 300 and a security context structure 302 at an inline cryptographic module 38 in response to receiving an NVMe command from the processor 14. The NVMe driver can provide data to the inline cryptographic module 38 for populating the buffer address lookup structure 300 and the security context structure 302, and the inline cryptographic module 38 can store the data as the buffer address lookup structure 300 and the security context structure 302. In some embodiments, the data may be provided by the NVMe driver as part of an NVMe command. Such data may include any combination of buffer address, NVMe security ID, sector offset, and / or security context for the NVMe command. In such embodiments, the NVMe driver may maintain the same address information at two different locations, which are processing system memory (e.g., ...). Figure 1 The memory (16, 36) and buffer address lookup structure 300 are included.

[0056] In some implementations, the inline cryptographic module 38 can retrieve security context data from the NVMe identification controller data structure. The NVMe identification controller data structure can be a data structure configured to store data for identifying and / or configuring the NVMe controller, such as a table, array, linked table, graph, etc., and the NVMe controller can be a component of the NVMe device 214, as referenced herein. Figure 6 Further description. The NVMe identity controller data structure may be stored in memory belonging to and / or accessible by the inline cryptographic module 38. The NVMe identity controller data structure may be pre-programmed.

[0057] In some implementations, the inline cryptographic module 38 may configure the buffer address lookup structure 300 and the security context structure 302 in response to receiving an NVMe command from the NVMe driver. The inline cryptographic module 38 may process the NVMe command, extract data for populating the buffer address lookup structure 300 and the security context structure 302, and store the data in the buffer address lookup structure 300 and the security context structure 302. In some implementations, the inline cryptographic module 38 may retrieve security context data from the NVMe identity controller data structure to populate the security context structure 302, and store this data in the security context structure 302. By configuring the buffer address lookup structure 300 and the security context structure 302 using the inline cryptographic module 38 instead of the NVMe driver, address redundancy issues are eliminated and data integrity is maintained. Furthermore, the software overhead for configuring the buffer address lookup structure 300 in the inline cryptographic module 38 is reduced.

[0058] Inline password module 38 can be configured to forward a doorbell signal, which is configured to send a signal to an NVMe device (e.g., Figure 1 Storage memory 24 in Figure 2 The NVMe device 214 in the NVMe module indicates the pending NVMe command. For example, the inline cryptographic module 38 can update the NVMe command submission queue tail pointer to the NVMe device's submission queue tail doorbell register. According to known specific implementations of the NVMe protocol, forwarding the doorbell signal can bypass or abandon software configured to write to two doorbells, and can ensure that the operation of the cryptographic module 38 and the NVMe device is synchronized.

[0059] In response to receiving an NVMe transaction from an NVMe device, in some implementations, the inline cryptographic module 38 may retrieve a buffer address from the NVMe transaction and use the buffer address to retrieve associated data, such as an NVMe security ID, from the buffer address lookup structure 300. In some implementations, the inline cryptographic module 38 may use the buffer address to retrieve an associated sector offset from the buffer address lookup structure 300. The inline cryptographic module 38 may use the retrieved NVMe security ID to retrieve an associated security context for NVMe commands from the security context structure 302. For example, the security context retrieved from the security context structure 302 may include one or more encryption algorithms, one or more encryption keys, one or more encryption key slots for retrieving one or more encryption keys from an encryption key storage structure, one or more initialization vector generation data, one or more initialization vector generation algorithms, etc.

[0060] In some implementations, the inline cryptographic module 38 may retrieve data from NVMe transactions. For example, the data retrieved from NVMe transactions may include one or more initialization vector generation data and / or one or more initialization vector generation algorithms. In some implementations, the inline cryptographic module 38 may retrieve data from the NVMe identity controller data structure. For example, the data retrieved from the NVMe identity controller data structure may include one or more initialization vector generation data.

[0061] Using retrieved information, such as sector offsets, security context from security context structure 302, data from NVMe transactions, and / or data from the NVMe identity controller data structure, encryption module 304, decryption module 306, and / or initialization vector generation module 308 can implement cryptographic functions for NVMe transaction data. Initialization vector generation module 308 can generate one or more initialization vectors using retrieved information about sector offsets, one or more initialization vector generation data from the security context of security context structure 302, one or more initialization vector generation data from NVMe transactions, and / or one or more initialization vector generation data from the NVMe identity controller data structure. In some implementations, initialization vector generation module 308 can generate one or more initialization vectors using one or more initialization vector generation algorithms from the security context of security context structure 302 and / or retrieved information from one or more initialization vector generation algorithms from NVMe transactions.

[0062] Encryption module 304 can use one or more initialization vectors and information retrieved from the security context to encrypt data for NVMe transactions to be transmitted to the NVMe device. Decryption module 306 can use one or more initialization vectors and information retrieved from the security context to decrypt data received from the NVMe device for NVMe transactions.

[0063] Figure 4 An inline cryptographic NVMe system 400 suitable for implementing various implementation schemes is illustrated (e.g., Figure 2 (Inline cryptography in NVMe systems 200). Reference. Figures 1 to 5 The inline password NVMe system 400 may include host 402 (e.g., Figure 1 The processing system 12 in the middle Figure 1 and Figure 2 Processor 14 in Figure 2 The processing system 202), host memory 404 (e.g., Figure 1 Memory 16 in Figure 1 and Figure 2 The memory 36 in the memory and the NVMe device controller 410 of the NVMe device (e.g., Figure 1 Storage memory 24 in Figure 2 (NVMe device 214 in the host memory 404). The host memory 404 may include an inline cryptographic module 38, which may be an encryption / decryption layer between the host driver executed by the host 402 and the NVMe device controller 410.

[0064] Command submission operations for the inline password NVMe system 400 may include: (1) NVMe device drivers at host 402 (e.g., Figure 2 (1) The NVMe device driver 208 in the host memory 404 can write commands to the commit queue (SQ) 406 at the host memory 404. (2) The NVMe device driver at the host 402 can be configured with an inline cryptographic module 38 for inline encryption of NVMe transactions. (3) The NVMe device driver at the host 402 can update the commit queue tail pointer (pointing to...) Figure 4 The pointer to the "tail" in the commit queue 406 is written to the SQ tail bell 412 (e.g., the SQ tail bell register) at the NVMe device controller 410.

[0065] Command processing operations may include: (4) The NVMe device controller 410 may retrieve commands from the submission queue 406 and set the submission queue head pointer (pointing to...) Figure 4(5) The NVMe device controller 410 can process the command. (6) The inline cryptographic module 38 can encrypt and / or decrypt the data of the processed command. For example, the inline cryptographic module 38 can encrypt write data transmitted to the NVMe device controller 410 for a write command and / or decrypt read data received from the NVMe device controller 410 for a read command.

[0066] Command completion operations may include: (7) The NVMe device controller 410 may write the completion of the command to the completion queue at host memory 404. Figure 4 The "CQ" in the code is 408, and the tail pointer of the completion queue (pointing to...) can be... Figure 4 (8) The NVMe device controller 410 may generate a platform-specific completion interrupt, such as an MSI-X interrupt, configured to notify the host driver of the completion status of a command. (9) The host 402 may process the completion of the command. (10) The host 402 may update the "tail" pointer in the completion queue (CQ) to indicate the completion of the command written to the completion queue 408. Figure 4 The pointer to the “head” in the completion queue 408 is written to the CQ tail bell 414 (e.g., the CQ tail bell register) at the NVMe device controller 410.

[0067] The inline cryptographic module 38 provides data security and privacy at the storage level by encrypting data transmitted from host 402 to NVMe device controller 410. This is achieved by inserting an encryption layer between host 402 and NVMe device controller 410, allowing each command to be processed to have its data encrypted before being passed to NVMe device controller 410 for further processing. When a write command is written by the host drive and queued to commit queue 406, or when a write command from commit queue 406 is retrieved by NVMe device controller 410, the data of the command from host memory 404 can be encrypted by inline cryptographic module 38 before being passed to NVMe device controller 410 for further processing. When a read command from commit queue 406 is retrieved and processed by NVMe device controller 410, the encrypted data of the command from the NVMe device can be passed from NVMe device controller 410 to inline cryptographic module 38, and decrypted by the inline cryptographic module before being passed to host 402 for further processing.

[0068] The process described above ensures that all data transmitted between host 402 and NVMe device controller 410 is encrypted and secure, while providing a high-performance solution with low latency regardless of workload or data size. This is because the data location aligns with other required steps in the process of transmitting commands from host 402 and receiving results from NVMe device controller 410. Furthermore, in some implementations, hardware-based encryption mechanisms can be used to protect all data, eliminating the need for additional software implementations on the host or NVMe device side. This allows users seeking improved security solutions for their workloads without sacrificing performance or latency to implement solutions without significant changes to their existing architecture and systems.

[0069] Figure 5 An example of the structure of a command processed by the NVMe inline cryptographic module 38 is shown. (See reference) Figures 1 to 5 The structure of Command 500 can be used for I / O access involving user data transfers that should be encrypted for security purposes, including read and / or write commands. In some implementations, the structure of Command 500 can be the structure of a common commit command format for an NVMe specific implementation, which may include aspects typically included in the commit command format, such as a namespace identifier (NSID) and a start logical block address (SLBA). The structure of Command 500 may include other common aspects (not shown), such as a command identifier (CID), a physical region page (PRP) or scatter aggregation list (SGL) for a data transfer indicator (PSDT), a fuse indicator, an opcode, multiple logical blocks, a namespace identifier (NSID), a metadata pointer or a metadata SGL segment pointer, a PRP pointer, etc. One or more initialization vector generation data included in Command 500 may include the NSID, SLBA, and / or any other common aspect of the commit command 500.

[0070] In some implementations, the structure of command 500 may be a modified version of a common commit command format for a specific NVMe implementation. For example, the structure of command 500 may include aspects typically included in the commit command format, as well as data provided by an application executed by processor 14 in one or more alternative-purpose fields (not shown) of the NVMe command. The one or more alternative-purpose fields may be fields reserved for future specifications and / or not used for commands involving I / O access to user data transfers. The data in the one or more alternative-purpose fields of the NVMe command may include one or more initialization vector generation data and / or one or more initialization vector generation algorithms. The one or more initialization vector generation data included in command 500 may include NSID, SLBA, data from one or more alternative-purpose fields of the NVMe command, and / or any other common aspect of the common aspects of commit command 500.

[0071] NVMe devices (e.g., Figure 1 Storage memory 24 in Figure 2 The NVMe device 214 can read command 500, which prompts the NVMe inline cryptographic module 38 (unless otherwise specified, the NVMe inline cryptographic module may include an initialization vector generation module 308 without specific reference) to parse command 500. The NVMe inline cryptographic module 38 can read one or more initialization vector generation data and / or one or more initialization vector generation algorithms.

[0072] The initialization vector generation module 308 can generate one or more initialization vectors for use in implementing cryptographic functions on NVMe command data by the encryption module 304 and / or decryption module 306. The initialization vector generation module 308 can use one or more initialization vector generation data from command 500 to generate one or more initialization vectors. The initialization vector generation module 308 can use one or more initialization vector generation data as input to implement one or more initialization vector generation algorithms and output one or more initialization vectors. In some embodiments, the initialization vector generation module 308 can interpret instructions for one or more initialization vector generation algorithms from command 500 and implement the corresponding one or more initialization vector generation algorithms.

[0073] Figure 6 An example of an NVMe identifier controller data structure is shown. (Reference) Figures 1 to 6 The NVMe identifier controller data structure 600 can be a data structure configured to store data for identifying and / or configuring the NVMe controller, such as a table, array, linked table, graph, etc., and the NVMe controller can be a component of an NVMe device (e.g., Figure 1 Storage memory 24 in Figure 2 NVMe device 214 in the context of the controller. Data used to identify and / or configure the NVMe controller may include: Peripheral Component Interface (PCI) Vendor ID (VID); PCI Subsystem Vendor ID (SSVID); Serial Number (SN); Model (MN); Firmware Version (FR); Recommended Arbitration Burst (RAB); Institute of Electrical and Electronics Engineers Organization Unique Identifier (OUI) ID (IEEE); Controller Multipath I / O and Namespace Sharing Capability (CMIC); Maximum Data Transfer Size (MDTS); Controller ID (CNTLID); Version (VER); Runtime D3 Recovery Latency (RTD3R); Runtime D3 Entry Latency (RTD3E); Supported Optional Asynchronous Events (OAES); Controller Attributes (CTRATT); one or more reserved fields; Field Replaceable Unit (FRU) Globally Unique Identifier (FGUID); etc. The NVMe controller identification data structure may be stored in memory belonging to and / or accessible by the inline cryptographic module 38 (e.g., ...). Figure 1 Memory 16, storage memory 24, Figure 1 and Figure 2 Memory 36 in Figure 4 The NVMe identifier controller data structure can be pre-programmed, located at host memory 404.

[0074] NVMe devices (e.g., Figure 1 Storage memory 24 in Figure 2 The NVMe device 214 can read command 500, which prompts the NVMe inline cryptography module 38 (unless otherwise specified, the NVMe inline cryptography module may include an initialization vector generation module 308 without specific reference) to parse command 500. The NVMe inline cryptography module 38 can read one or more initialization vector generation data and / or one or more initialization vector generation algorithms. In some embodiments, reading command 500 may also prompt the NVMe inline cryptography module 38 to retrieve one or more data from the data used to identify and / or configure the NVMe identity controller data structure 600. One or more data from the data used to identify and / or configure the NVMe identity controller data structure 600 may be used by the NVMe inline cryptography module 38, together with the data in command 500, as one or more initialization vector generation data for the NVMe controller.

[0075] The initialization vector generation module 308 can generate one or more initialization vectors for use in implementing cryptographic functions on NVMe command data by the encryption module 304 and / or decryption module 306. The initialization vector generation module 308 can use one or more initialization vector generation data from command 500 to generate one or more initialization vectors. The initialization vector generation module 308 can use one or more initialization vector generation data as input to implement one or more initialization vector generation algorithms and output one or more initialization vectors. In some embodiments, the initialization vector generation module 308 can interpret instructions for one or more initialization vector generation algorithms from command 500 and implement the corresponding one or more initialization vector generation algorithms.

[0076] Figure 7 A method 700 for inline cryptography for NVMe devices, according to some implementation schemes, is illustrated. (Reference) Figures 1 to 7 Method 700 can be used on computing devices (e.g., Figure 1 The computing device 10 in Figure 2 and Figure 4 In the inline password of NVMe systems 200, 400, in the processor (e.g., Figure 1 and Figure 2 Processor 14 in Figures 1 to 3 Inline cryptographic module 38 Figure 4 The software executing in the host (402) in general-purpose hardware, in special-purpose hardware (e.g., Figures 1 to 3 Inline cryptographic module 38 Figure 3 In the encryption module 304, decryption module 306, initialization vector generation module 308, or in a combination of software-configured processor and dedicated hardware (such as in a system including other separate components, e.g., Figure 2 and Figure 4 The inline cryptographic NVMe system 200, 400 implements the software within a processor and various memory / cache controllers. Components used to implement method 400 may include a processing system or other processors (e.g., one or more processors 14, inline cryptographic module 38, encryption module 304, decryption module 306, initialization vector generation module 308, and / or host 402). Furthermore, one or more processors may be configured with software or firmware to perform some or all of the operations of method 700. To cover alternative configurations implemented in various embodiments, the hardware implementing method 700 is referred to herein as an "inline cryptographic device".

[0077] In box 702, the inline cryptographic device can receive NVMe commands (e.g., Figure 5NVMe command 500 in block 702). In some implementations, the inline cryptographic device receiving the NVMe command in block 702 may include an inline cryptographic module (e.g., Figures 1 to 3 Inline cryptographic module 38) and / or initialization vector generation module (e.g., Figure 3 (Initialization vector generation module 308 in the middle).

[0078] NVMe devices (e.g., Figure 1 Storage memory 24 in Figure 2 NVMe device 214 in the middle) can be submitted from the NVMe command queue (e.g., Figure 4 The inline cryptographic device (INCD) retrieves NVMe commands from the NVMe command submission queue (406). The inline cryptographic device can receive NVMe commands retrieved by the NVMe device. In some implementations, the inline cryptographic device can receive NVMe commands as soon as they are retrieved by the NVMe device. For example, as part of sending NVMe commands from the NVMe command submission queue, the inline cryptographic device can receive NVMe commands and forward them to the NVMe device. As another example, in parallel with sending NVMe commands from the NVMe command submission queue, the inline cryptographic device can receive a copy of the NVMe commands transmitted to the NVMe device.

[0079] In some implementations, the inline cryptographic device can receive NVMe commands from the NVMe device after the NVMe command has been acquired by the NVMe device. The NVMe commands can be received by the inline cryptographic device via a device interface (e.g., ...). Figure 1 Storage interface 20 in Figure 2 The PCIe controller 212 in the NVMe device receives commands from the NVMe device. As part of the NVMe device's processing of NVMe commands, the NVMe commands can be sent by the NVMe device to the inline cryptographic device.

[0080] In block 704, the inline cryptographic device may retrieve one or more initialization vector generation parameters. In some embodiments, the inline cryptographic device retrieving one or more initialization vector generation parameters in block 704 may include an inline cryptographic module and / or an initialization vector generation module. The one or more initialization vector generation parameters may include those from commands, NVMe identity controller data structures (e.g., ... Figure 6 NVMe Identifier Controller Data Structure 600), security context (e.g., Figure 3 The initialization vector is retrieved from one or more of the following: the security context structure (302) in the inline cryptographic device. The inline cryptographic device can retrieve parameters from commands, NVMe identity controller data structures, security contexts (e.g., ...). Figure 3 One or more of the security context structures (302) in the system parse one or more initialization vectors to generate parameters.

[0081] One or more initialization vector generation parameters may include one or more initialization vector generation data. In some implementations, the initialization vector generation data may include: LBAs, such as the SLBA of a data block for an NVMe command and / or the LBA calculated for subsequent data blocks for the NVMe command; the namespace ID of the data for the NVMe command; one or more other data typically in the NVMe command; and data generated by a processor (e.g., ...). Figure 1 and Figure 2 Processor 14 in Figure 4 The application executing the host (402) provides one or more data in the field of the NVMe command's purpose change; from memory located in and / or accessible by the inline cryptographic device (e.g., Figure 1 Memory 16, storage memory 24, Figure 1 and Figure 2 Memory 36 in Figure 4 One or more data in the NVMe identifier controller data structure located in host memory 404; and / or one or more modified data of one or more of the examples mentioned above.

[0082] In some implementations, one or more initialization vector generation parameters may include one or more initialization vector generation algorithms. The one or more initialization vector generation algorithms may include operations on the one or more initialization vector generation data, including combinational operations, logical operations, mathematical operations, linear operations, nonlinear operations, randomization operations, pseudo-randomization operations, etc. In some implementations, the operation of the initialization vector generation algorithms may involve using data from NVMe commands, data from NVMe identity controller data structures, data from security contexts, etc., where the data may be unmodified and / or modified. In some implementations, one or more initialization vector generation algorithms may be represented by values ​​configured to be interpreted by an inline cryptographic device to implement one or more initialization vector generation algorithms. The one or more initialization vector generation algorithms may be retrieved from commands and / or from memory belonging to and / or accessible by the inline cryptographic device.

[0083] In box 706, an inline cryptographic device can generate an initialization vector. Using one or more initialization vector generation data as input to one or more initialization vector generation algorithms, the inline cryptographic device can generate an initialization vector. In some embodiments, the inline cryptographic device may be pre-configured to implement one or more initialization vector generation algorithms, such as through hardware, firmware, and / or software pre-configuration. In some embodiments, the inline cryptographic device may be configured to implement one or more initialization vector generation algorithms retrieved in box 704, such as through hardware, firmware, and / or software configuration. The inline cryptographic device can implement one or more operations of one or more initialization vector generation algorithms on one or more initialization vector generation data and / or on data derived from previous operations of one or more initialization vector generation algorithms to generate an initialization vector. The inline cryptographic device can generate an initialization vector from commands, NVMe identity controller data structures, security contexts (e.g., ...). Figure 3 One or more of the security context structures (302) in the protocol parse one or more initialization vector generation parameters. In some implementations, the inline cryptographic device that generates the initialization vector in block 706 may include an inline cryptographic module and / or an initialization vector generation module.

[0084] In block 708, the inline cryptographic device can receive data including an initialization vector and NVMe commands. The NVMe command can be a write command, for which data can be encrypted and written to the NVMe device. The NVMe command can also be a read command, for which previously encrypted data can be read from and decrypted from the NVMe device. In some embodiments, the inline cryptographic device generating the initialization vector in block 706 may include an inline cryptographic module, an encryption module (e.g., ...), Figure 3 The encryption module 304) and / or decryption module (e.g., Figure 3 (Decryption module 306 in the middle).

[0085] In block 710, the inline cryptographic device can implement cryptographic functionality for NVMe command data based on an initialization vector. In some implementations, the inline cryptographic device in block 710 that implements cryptographic functionality for NVMe command data based on an initialization vector may include an inline cryptographic module, an encryption module (e.g., Figure 3 The encryption module 304) and / or decryption module (e.g., Figure 3(Decryption module 306 in the document). Using an initialization vector, NVMe command data, and an encryption key as inputs to the cryptographic functionality, the inline cryptographic device can implement cryptographic functionality on the data of NVMe transactions. For example, the inline cryptographic device can encrypt data to be transmitted to the NVMe device for writing NVMe commands. As another example, the inline cryptographic device can decrypt data received from the NVMe device for reading NVMe commands. In some implementations, the data for which the cryptographic functionality of the NVMe commands is implemented can be a subset or part of the NVMe command data. The subset of the NVMe command data can be of any size, such as one or more bits, bytes, words, blocks, segments, lines, etc.

[0086] In some implementations, at various points in the implementation of the cryptographic functionality, the data and / or initialization vector of the NVMe command may be in unmodified and / or modified form. For example, when implementing AES-XTS, the initialization vector may be modified, and the modified initialization vector may be used to modify the data of the NVMe command before implementing the AES cryptographic functionality on the modified data of the NVMe command, and the modified initialization vector may be used to modify the output of the AES cryptographic functionality.

[0087] In some implementations, the inline cryptographic device may be configured to implement cryptographic functionality for multiple subsets of the data for an NVMe command, rather than for all the data for the NVMe command at once. In optional block 712, the inline cryptographic device may identify the remaining data for an NVMe command. The remaining data may be any subset of the NVMe command's data other than the subset of the data for which cryptographic functionality has been implemented in block 710. For example, an NVMe command may include values ​​of the amount of data configured to indicate to the inline cryptographic device the amount of the command, such as the total amount of data and / or the amount of a subset of data. The inline cryptographic device may be configured to track the amount of data for commands that have been and / or have not yet been cryptographically implemented, such as the total amount of data and / or the amount of a subset of data. The remaining data for an NVMe command may be available in response to the inline cryptographic device identifying that less than all of the data for the NVMe command has been cryptographically implemented and / or that more than none of the data for the NVMe command has not been cryptographically implemented. In some implementations, the inline cryptographic device identifying the remaining data for an NVMe command in optional block 712 may include an inline cryptographic module and / or an initialization vector generation module.

[0088] In some implementations, to implement cryptographic functionality for the remaining data on the NVMe, the inline cryptographic device can use one or more different initialization vector generation parameters to generate different initialization vectors. In block 704, the inline cryptographic device can retrieve one or more initialization vector generation parameters. In some implementations, the inline cryptographic device retrieving one or more initialization vector generation parameters in block 704 may include an inline cryptographic module and / or an initialization vector generation module.

[0089] In some implementations, the inline cryptographic device can use the same initialization vector to implement cryptographic functionality for the remaining NVMe data. In block 710, the inline cryptographic device can implement cryptographic functionality for NVMe command data based on the initialization vector. In some implementations, the inline cryptographic device in block 710 that implements cryptographic functionality for NVMe command data based on the initialization vector may include an inline cryptographic module, an encryption module, and / or a decryption module.

[0090] In some implementations, to implement cryptographic functionality on the remaining data of the NVMe command, the inline cryptographic device can use one or more modified initialization vector generation data to generate different initialization vectors. In optional block 714, the inline cryptographic device can modify one or more of the initialization vector generation data. In some implementations, the inline cryptographic device can be configured to modify one or more of the initialization vector generation data to distinguish the modified initialization vector generation data from one or more initialization vector generation data used to implement cryptographic functionality on other data of the NVMe command. For example, the one or more initialization vector generation data may be data associated with a specific subset of the data for the NVMe command. The one or more initialization vector generation data may be modified in a manner different from previously used initialization vector generation data and may be associated with another specific subset of the data for the NVMe command. In some implementations, one or more initialization vector generation data for the subset of data used for the NVMe command may be an LBA, and the LBA may be modified such that the modified LBA is different from the LBA, and the modified LBA may be associated with another subset of the data for the NVMe command. In some implementations, the inline cryptographic device that modifies one or more of the initialization vector generation data in optional box 714 may include an inline cryptographic module and / or an initialization vector generation module.

[0091] Various implementation plans (including but not limited to the above references) Figures 1 to 7 The described implementation scheme can be implemented in a wide variety of computing systems, including mobile computing devices. Examples of mobile computing devices suitable for use with various implementation schemes are shown in [the following text is missing]. Figure 8The mobile computing device 800 may include a processor 802 coupled to a touchscreen controller 804 and internal memory 806. The processor 802 may be one or more multi-core integrated circuits designated for general or specific processing tasks. The internal memory 806 may be volatile or non-volatile memory, and may also be secure and / or encrypted memory, or insecure and / or unencrypted memory, or any combination thereof. Examples of memory types that can be utilized include, but are not limited to, DDR, LPDDR, GDDR, WIDEIO, RAM, SRAM, DRAM, P-RAM, R-RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 804 and processor 802 may also be coupled to a touchscreen panel 812, such as a resistive-sensing touchscreen, a capacitive-sensing touchscreen, an infrared-sensing touchscreen, etc. Additionally, the display of the mobile computing device 800 does not need to have touchscreen capability.

[0092] Mobile computing device 800 may have one or more radio transceivers 808 (e.g., Peanut, Bluetooth, ZigBee, Wi-Fi, RF radio) and antennas 810 coupled to each other and / or coupled to processor 802 for transmitting and receiving communications. The transceivers 808 and antennas 810 may be used with the circuitry mentioned above to implement various wireless transmission protocol stacks and interfaces. Mobile computing device 800 may include a cellular wireless modem chip 816 that enables communication via a cellular network and is coupled to the processor.

[0093] Mobile computing device 800 may include a peripheral device connection interface 818 coupled to processor 802. The peripheral device connection interface 818 may be configured individually to accept one type of connection, or it may be configured to accept various types of shared or proprietary physical and communication connections, such as Universal Serial Bus (USB), FireWire, Thunderbolt, or PCIe. The peripheral device connection interface 818 may also be coupled to a similarly configured peripheral device connection port (not shown).

[0094] The mobile computing device 800 may also include a speaker 814 for providing audio output. The mobile computing device 800 may also include a housing 820 for accommodating all or some of the components described herein, the housing being constructed of plastic, metal, or a combination of materials. The mobile computing device 800 may include a power source 822 coupled to the processor 802, such as a disposable or rechargeable battery. The rechargeable battery may also be coupled to a peripheral device connection port to receive charging current from a source external to the mobile computing device 800. The mobile computing device 800 may also include a physical button 824 for receiving user input. The mobile computing device 800 may also include a power button 826 for turning the mobile computing device 800 on and off.

[0095] Various implementation plans (including but not limited to the above references) Figures 1 to 7 The described implementation scheme can be implemented in a wide variety of computing systems, including a laptop computer 900, of which an example is... Figure 9 The following is an example. Many laptop computers include a touchpad touch surface 917, which serves as a pointing device for the computer and is therefore capable of receiving gestures similar to those implemented on computing devices equipped with touchscreen displays and as described above. A laptop computer 900 will typically include a processor 902 coupled to volatile memory 912 and a disk drive 913 containing mass non-volatile memory such as flash memory. Additionally, the computer 900 may have one or more antennas 908 for transmitting and receiving electromagnetic radiation, which may be connected to a wireless data link and / or to a cellular transceiver 916 coupled to the processor 902. The computer 900 may also include a floppy disk drive 914 and a compact disc (CD) drive 915 coupled to the processor 902. In a laptop configuration, the computer casing includes a touchpad 917, a keyboard 918, and a display 919, all coupled to the processor 902. Other configurations of the computing device may include a computer mouse or trackball, which are well known to be coupled to the processor (e.g., via USB input), and may also be used in combination with various implementation schemes.

[0096] Computer program code or "program code" intended to be executed on a programmable processor to perform operations of various implementation schemes may be written in high-level programming languages ​​such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic, structured query languages ​​(e.g., Transact-SQL), Perl, or in various other programming languages. Program code or program stored on a computer-readable storage medium as used herein may refer to machine language code (e.g., object code) whose format is understandable by a processor.

[0097] The following paragraphs describe specific implementation examples. While some of the specific implementation examples described below are based on example systems, devices, or methods, other example implementations may include: example systems or devices implemented as methods for performing operations of example systems or devices, as discussed in the following paragraphs; example systems, devices, or methods implemented by computing devices including inline cryptographic modules configured to perform operations of example systems, devices, or methods, as discussed in the following paragraphs; example systems, devices, or methods implemented by computing devices, as discussed in the following paragraphs, including processing devices configured with processing device-executable instructions to perform operations of example systems, devices, or methods; computing devices including components for performing functions of example systems, devices, or methods; and example systems, devices, or methods implemented as non-transitory processor-readable storage media storing processor-executable instructions, as discussed in the following paragraphs, which are configured to cause a processor of a computing device to perform operations of example systems, devices, or methods.

[0098] Example 1. A method for implementing cryptographic functionality for Non-Volatile Memory Fast (NVMe) inline storage cryptography in a processing system, the method comprising: receiving an NVMe command; generating at least a first initialization vector for the NVMe command; receiving the first initialization vector and data from the NVMe command as input to the cryptographic functionality; and implementing the cryptographic functionality based at least on the first initialization vector, the data from the NVMe command, and a cryptographic key for generating the output of the cryptographic functionality.

[0099] Example 2. According to the method of Example 1, wherein the first initialization vector for the NVMe command is configured for the data of the NVMe command at the first namespace of the NVMe memory device and at the first logical block of the NVMe memory device, and is configured differently from the second initialization vector for another NVMe command, the second initialization vector for the other NVMe command being configured for the data of the other NVMe command at the second namespace of the NVMe memory device and at the first logical block of the NVMe memory device.

[0100] Example 3. The method according to any Example 1 or 2, the method further includes: parsing at least first data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command.

[0101] Example 4. According to the method of Example 3, the method further includes: parsing at least second data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe command.

[0102] Example 5. According to the method of Example 4, the method further includes: parsing at least third data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command, the second data from the NVMe command, and the third data from the NVMe command.

[0103] Example 6. The method according to Example 4, wherein: the first data from the NVMe command is a namespace identifier of the namespace of the NVMe memory device; and the second data from the NVMe command is the starting logical block address of the namespace.

[0104] Example 7. According to the method of Example 3, wherein the first initialization vector for the NVMe command is based on at least the first data modified by at least one of the following: at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudo-random value, at least the second data parsed from the NVMe command, at least one modified value of the at least the second data parsed from the NVMe command, at least one data from the NVMe identity controller data structure, or at least one modified value of the at least one data from the NVMe identity controller data structure.

[0105] Example 8. The method according to Example 3, the method further comprising: retrieving at least second data from an NVMe identity controller data structure, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe identity controller data structure.

[0106] Example 9. The method according to Example 1, the method further comprising: parsing from the NVMe command at least initialization vector data generated by software implemented in a computing device including the processing system, wherein the first initialization vector is based on at least the initialization vector data.

[0107] The foregoing method descriptions and process flowcharts are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented. As those skilled in the art will appreciate, the operations of the foregoing embodiments can be performed in any order. Words such as “afterward,” “then,” “next,” etc., are not intended to restrict the order of operations; these words are only used to guide the reader through the description of the method. Furthermore, any reference to singular claim elements (e.g., references using the articles “a,” “an,” or “described”) should not be construed as limiting that element to the singular.

[0108] The various exemplary logic blocks, modules, circuits, and algorithmic operations described in conjunction with various implementation schemes can be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability between hardware and software, various exemplary components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. While those skilled in the art may implement the described functionality in different ways for each specific application, such implementation decisions should not be construed as departing from the scope of the claims.

[0109] Hardware used to implement the various exemplary logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic unit, discrete hardware component, or any combination thereof designed to perform the functions described herein. While the general-purpose processor may be a microprocessor, in alternative embodiments, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry specific to a given function.

[0110] In one or more embodiments, the described functionality can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functionality can be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operation of the methods or algorithms disclosed herein can be implemented in a processor-executable software module that may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium can be any storage medium accessible by a computer or processor. By way of example and not limitation, such non-transitory computer-readable or processor-readable media can include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disc storage devices, disk storage devices or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and is accessible by a computer. As used herein, disks and optical discs include compact optical discs (CDs), laser discs, optical discs, digital versatile optical discs (DVDs), floppy disks, and Blu-ray discs, wherein disks typically magnetically reproduce data, while optical discs optically reproduce data using lasers. Combinations of the above can also be included within the scope of non-transitory computer-readable and processor-readable media. In addition, the operation of a method or algorithm may reside as a single piece of code and / or instruction, or any combination or set of code and / or instructions, on a non-transitory processor-readable medium and / or computer-readable medium that may be incorporated into a computer program product.

[0111] The above description of the disclosed embodiments is provided to enable any person skilled in the art to implement or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein can be applied to other embodiments and implementations without departing from the scope of the claims. Therefore, this disclosure is not intended to be limited to the embodiments and implementations described herein, but should be granted the broadest scope consistent with the appended claims and the principles and novel features disclosed herein.

Claims

1. A method for implementing cryptographic functionality for non-volatile memory fast (NVMe) inline storage cryptography in a processing system, the method comprising: Receive NVMe commands; Generate at least a first initialization vector for the NVMe command; The data from the first initialization vector and the NVMe command are received as input for the cryptographic function. as well as The cryptographic function is implemented based at least on the first initialization vector, the data of the NVMe command, and the cryptographic key output by the cryptographic function.

2. The method of claim 1, wherein the first initialization vector for the NVMe command is configured for the data of the NVMe command at a first namespace of the NVMe memory device and at a first logical block of the NVMe memory device, and is configured differently from the second initialization vector for another NVMe command, the second initialization vector for the other NVMe command being configured for the data of the other NVMe command at a second namespace of the NVMe memory device and at a first logical block of the NVMe memory device.

3. The method according to claim 1, further comprising: At least first data is parsed from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command.

4. The method according to claim 3, further comprising: At least second data is parsed from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe command.

5. The method according to claim 4, further comprising: At least third data is parsed from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command, the second data from the NVMe command, and the third data from the NVMe command.

6. The method according to claim 4, wherein: The first data from the NVMe command is the namespace identifier of the NVMe storage device's namespace; and The second data from the NVMe command is the starting logical block address of the namespace.

7. The method of claim 3, wherein the first initialization vector for the NVMe command is based on at least the first data modified by at least one of the following: at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudo-random value, at least the second data parsed from the NVMe command, at least one modified value of the at least the second data parsed from the NVMe command, at least one data from the NVMe identity controller data structure, or at least one modified value of the at least one data from the NVMe identity controller data structure.

8. The method according to claim 3, further comprising: Retrieve at least second data from the NVMe Identifier Controller data structure, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe Identifier Controller data structure.

9. The method according to claim 1, further comprising: The NVMe command parses at least initialization vector data generated by software implemented in a computing device including the processing system, wherein the first initialization vector is based on at least the initialization vector data.

10. A processing system, the processing system comprising: Memory; An inline cryptographic module, the inline cryptographic module being coupled to the memory; and A memory controller, coupled to the memory and the inline cryptographic module, is configured to: Receive Non-Volatile Memory Fast (NVMe) commands; Generate at least a first initialization vector for the NVMe command; The data from the first initialization vector and the NVMe command are received as input for the cryptographic function. and The cryptographic function is implemented in the inline cryptographic module based at least on the first initialization vector, the data of the NVMe command, and the cryptographic key output by the cryptographic function.

11. The processing system of claim 10, wherein the memory controller is further configured such that: the first initialization vector for the NVMe command is configured for the data of the NVMe command at a first namespace of the NVMe memory device and at a first logical block of the NVMe memory device, and is configured differently from the second initialization vector for another NVMe command, the second initialization vector for the other NVMe command being configured for the data of the other NVMe command at a second namespace of the NVMe memory device and at the first logical block of the NVMe memory device.

12. The processing system of claim 10, wherein the memory controller is further configured to: parse at least first data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command.

13. The processing system of claim 12, wherein the memory controller is further configured to: parse at least second data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe command.

14. The processing system of claim 13, wherein the memory controller is further configured to: parse at least third data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command, the second data from the NVMe command, and the third data from the NVMe command.

15. The processing system of claim 13, wherein the memory controller is further configured such that: The first data from the NVMe command is the namespace identifier of the NVMe storage device's namespace; and The second data from the NVMe command is the starting logical block address of the namespace.

16. The processing system of claim 12, wherein the memory controller is further configured such that: the first initialization vector for the NVMe command is based on at least the first data modified by at least one of the following: at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudo-random value, at least second data parsed from the NVMe command, at least one modified value of the at least second data parsed from the NVMe command, at least one data from the NVMe identity controller data structure, or at least one modified value of the at least one data from the NVMe identity controller data structure.

17. The processing system of claim 12, wherein the memory controller is further configured to: retrieve at least second data from an NVMe identity controller data structure, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe identity controller data structure.

18. The processing system of claim 10, wherein the memory controller is further configured to: parse from the NVMe command at least initialization vector data generated by software implemented in a computing device including the processing system, wherein the first initialization vector is based on at least the initialization vector data.

19. A processing system, the processing system comprising: A component used to receive Non-Volatile Memory Fast (NVMe) commands; Components for generating at least a first initialization vector for the NVMe command; A component for receiving data from the first initialization vector and the NVMe command as input for cryptographic functions; and A component for implementing the cryptographic function based at least on the first initialization vector, the data of the NVMe command, and the cryptographic key for generating the cryptographic function output.

20. The processing system of claim 19, wherein the first initialization vector for the NVMe command is configured for the data of the NVMe command at a first namespace of the NVMe memory device and at a first logical block of the NVMe memory device, and is configured differently from the second initialization vector for another NVMe command, the second initialization vector for the other NVMe command being configured for the data of the other NVMe command at a second namespace of the NVMe memory device and at the first logical block of the NVMe memory device.

21. The processing system according to claim 19, further comprising: A component for resolving at least first data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command.

22. The processing system according to claim 21, further comprising: A component for resolving at least second data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe command.

23. The processing system according to claim 22, further comprising: A component for resolving at least third data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command, the second data from the NVMe command, and the third data from the NVMe command.

24. The processing system according to claim 22, wherein: The first data from the NVMe command is the namespace identifier of the NVMe storage device's namespace; and The second data from the NVMe command is the starting logical block address of the namespace.

25. The processing system of claim 21, wherein the first initialization vector for the NVMe command is based on at least the first data modified by at least one of the following: at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudo-random value, at least the second data parsed from the NVMe command, at least one modified value of the at least the second data parsed from the NVMe command, at least one data from the NVMe identity controller data structure, or at least one modified value of the at least one data from the NVMe identity controller data structure.

26. The processing system according to claim 21, further comprising: A component for retrieving at least second data from an NVMe identity controller data structure, wherein the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe identity controller data structure.

27. The processing system according to claim 19, further comprising: The NVMe command parses at least initialization vector data generated by software implemented in a computing device including the processing system, wherein the first initialization vector is based on at least the initialization vector data.

28. A non-volatile memory having processor-executable instructions stored thereon, the processor-executable instructions being configured to cause one or more processors of a processing system to perform operations implementing cryptographic functions for a non-volatile memory fast (NVMe) inline storage cryptography, the operations including: Receive NVMe commands; Generate at least a first initialization vector for the NVMe command; The data from the first initialization vector and the NVMe command are received as input for the cryptographic function. and The cryptographic function is implemented based at least on the first initialization vector, the data of the NVMe command, and the cryptographic key output by the cryptographic function.

29. The non-volatile memory of claim 28, wherein the stored processor-executable instructions are configured to cause one or more processors of the processing system to perform an operation further comprising: parsing at least first data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command.

30. The non-volatile memory of claim 28, wherein the stored processor-executable instructions are configured to cause one or more processors of the processing system to perform an operation further comprising: parsing from the NVMe command at least initialization vector data generated by software implemented in a computing device including the processing system, wherein the first initialization vector is based on at least the initialization vector data.

Images