Method for generating initialization vector for nvme inline encryption

Abstract

Various embodiments include methods of implementing cryptographic functions for non-volatile memory express (NVMe) inline storage cryptography at computing devices. Embodiments may include receiving an NVMe command, generating at least a first initialization vector for the NVMe command, receiving the first initialization vector and a data for the NVMe command as inputs of a cryptographic function, and implementing the cryptographic function based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output. In some embodiments, the first initialization vector is configured for the data for the NVMe command at a first namespace and at a first logical block of an NVMe memory device, and configured to differ from a second initialization vector for another NVMe command configured for data for the another NVMe command at a second namespace and the first logical block of the NVMe memory device.

Description

TITLEMethod For Generating Initialization Vector For NVMe Inline EncryptionRELATED APPLICATIONS

[0001] This application claims the benefit of priority from Israeli Patent Application No. 305055, filed August 8, 2023; the entire contents of which is herein incorporated by reference.BACKGROUND

[0002] The nonvolatile memory express (NVMe) protocol for solid state memory devices enables a fast and high throughput communication between an NVMe memory device and a processing system. A peripheral component interface express (PCIe) controller may be configured to implement NVMe protocol communications between an NVMe device and components of a processing system. Processing system data for transmission to and transmitted from the NVMe device is vulnerable to manipulation by a malicious actor.SUMMARY

[0003] Various aspects include apparatuses, processing systems and methods for implementing cryptographic functions for non-volatile memory express (NVMe) inline storage cryptography in a processing system. Various aspects may include receiving an NVMe command, generating at least a first initialization vector for the NVMe command, receiving the first initialization vector and a data for the NVMe command as inputs of a cryptographic function, and implementing the cryptographic function based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output.

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

[0005] Some aspects may further include parsing at least a first data from the NVMe command, in which the first initialization vector is based on at least the first data from the NVMe command. Some aspects may further include parsing at least a second data from the NVMe command, in which the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe command. Some aspects may further include parsing at least a third data from the NVMe command, in which 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. Some aspects the first data from the NVMe command may be a namespace identifier of a namespace of an NVMe memory device, and the second data from the NVMe command may be a start logical block address of the name space.

[0006] Some aspects the first initialization vector for the NVMe command may be based on at least the first data that is modified by at least one of at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudorandom value, at least a second data parsed from the NVMe command, at least one modified value of at least the second data parsed from the NVMe command, at least one data from an NVMe identify controller data structure, or at least one modified value of the at least one data from the NVMe identify controller data structure.

[0007] Some aspects may further include retrieving at least a second data from an NVMe identify controller data structure, in which the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe identify controller data structure.

[0008] Some aspects further include parsing from the NVMe command at least an initialization vector data generated by a software implemented in a computing device that includes the processing system, in which the first initialization vector is based on at least the initialization vector data.

[0009] Further aspects include computing devices including a plurality of processors configured to perform operations of any of the methods summarized above. Further aspects include computing devices having means for performing any of the functions of the methods summarized above. Further aspects include a power management integrated circuit configured to perform any of the methods summarized above.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] The accompanying drawings, which are incorporated herein and constitute part of this specification, illustrate example embodiments of various embodiments, and together with the general description given above and the detailed description given below, serve to explain the features of the claims.

[0011] FIG. 1 is a component block diagram illustrating an example computing device suitable for implementing various embodiments.

[0012] FIG. 2 is a component block diagram illustrating an example inline cryptography nonvolatile memory express (NVMe) system suitable for implementing various embodiments.

[0013] FIG. 3 is a component block diagram illustrating an example inline cryptographic module of the inline cryptography NVMe system for implementing various embodiments.

[0014] FIG. 4 is a component block diagram and process flow illustrating an example of the inline cryptography NVMe system in accordance with some embodiments.

[0015] FIG. 5 is a command structure diagram illustrating a command for the inline cryptography NVMe system according to some embodiments.

[0016] FIG. 6 is an information structure diagram illustrating an NVMe identify controller data structure for the inline cryptography NVMe system according to some embodiments.

[0017] FIG. 7 is a process flow diagram illustrating a method of inline cryptography for NVMe devices according to some embodiments.

[0018] FIG. 8 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.

[0019] FIG. 9 is a component block diagram illustrating an example mobile computing device suitable for implementing various embodiments.DETAILED DESCRIPTION

[0020] The various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts. References made to particular examples and implementations are for illustrative purposes and are not intended to limit the scope of the claims.

[0021] Various embodiments include methods, and processing systems and / or computing devices implementing such methods, for implementing cryptographic functions for non-volatile memory express (NVMe) inline storage cryptography. In some embodiments an inline cryptographic module may be configured to generate one or more initialization vectors for implementing cryptographic functions on data of an NVMe command. Generating the one or more initialization vectors may be based on one or more initialization vector generation data and / or one or more initialization vector generation algorithms. The initialization vector generation data may include data of typical fields in the NVMe command structure, data provided by anapplication of one or more repurposed fields in the NVMe command structure, and / or data from an NVMe identify controller data structure, and / or modified data of 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 cryptographic module may generate an initialization vector for data for the NVMe command at a namespace of an NVMe memory device and at a logical block of the NVMe memory device in a maimer to differ from another initialization vector for data of another NVMe command at another namespace of the NVMe memory device and the same logical block of the NVMe memory device.

[0022] The term “computing device” is used herein to refer to any one or all of cellular telephones, smartphones, personal or mobile multi-media players, personal data assistants (PDA’s), laptop computers, tablet computers, convertible laptops / tablets (2-in-l computers), smartbooks, ultrabooks, netbooks, palm-top computers, wireless electronic mail receivers, multimedia Internet enabled cellular telephones, mobile gaming consoles, wireless gaming controllers, and similar personal electronic devices that include a memory, and a programmable processor. The term “computing device” may further refer to stationary computing devices including personal computers, desktop computers, all-in-one computers, workstations, super computers, mainframe computers, embedded computers, servers, home theater computers, and game consoles.

[0023] The NVMe protocol for memory devices enables a fast and high throughput communication between an NVMe memory device and a system on chip (SoC). A peripheral component interface express (PCIe) controller may be configured to implement NVMe protocol communications between an NVMe device and components of a processing system. Processing system data for transmission to and transmitted from the NVMe device is vulnerable to manipulation by a malicious actor.

[0024] Various embodiments address and cure the foregoing problems of NVMe protocol communication by providing inline cryptographic functionality to secure the data at the SoC for transmission to and transmitted from the NVMe device. An inline cryptographic module may implement cryptographic functions of encrypting data sent from a processing system to an NVMe device and / or decrypting data received at the SoC from the NVMe device using the information stored at the inline cryptographic module. The inline cryptographic module may implement the cryptographic functions based on multiple inputs, including one or more initialization vectors, data for an NVMe command, and / or one or more encryption keys.

[0025] Generation of the one or more initialization vectors may be based on initialization vector generation data. The initialization vector generation data may include data of typical fields in the NVMe command structure, data provided by an application of one or more repurposed fields in the NVMe command structure, and / or data from an NVMe identify controller data structure, and / or modified data of any one or more of the foregoing examples. In some embodiments, initialization vector generation data may include: a logical block address (LB A), such as a starting LB A (SLBA) from an NVMe command for a block of data of the NVMe command and / or an LBA calculated for a subsequent block of data of the NVMe command; a namespace identifier (ID) for the data of the NVMe command; one or more other data commonly in the NVMe command; one or more data provided by an application executed by the processor 14 in a repurposed field of the NVMe command; one or more data from an NVMe identify controller data structure located at a memory of and / or accessible by the inline cryptographic module 38; and / or one or more modified data of one or more of the foregoing examples.

[0026] One or more initialization vector generation algorithms may be configured to combine and / or modify one or more of the initialization vector generation data. In some embodiments, initialization vector generation algorithms may include operations on initialization vector generation data, including combining operations, logicaloperations, mathematical operations, linear operations, nonlinear operations, randomizing operations, pseudo-randomizing operations, etc. In some embodiments, the operations of the initialization vector generation algorithms may involve using data from an NVMe command, data from a NVMe identify controller data structure, etc. for which the data may be in unmodified and / or modified forms.

[0027] The initialization vectors generated by the inline cryptographic module may be used for implementation of cryptographic functions according to various known, proprietary, and / or to be developed cryptographic methods and / or circuitry. Nonlimiting examples of cryptographic methods that may be used include the Advanced Encryption Standard (AES) and variants thereof, such as AES XOR-encrypt-XOR tweakable block ciphertext stealing (XTS). In some embodiments, the initialization vectors may be 64 bits, 128 bits, 256 bits, etc. As another example, the cryptographic methods may provide per-application and / or file-based cryptographic functions. Initialization vectors may be generated so that the initialization vectors differ for data for an NVMe command at a namespace of an NVMe memory device and at a logical block of the NVMe memory device and for other data of another NVMe command at another namespace of the NVMe memory device and the same logical block of the NVMe memory device.

[0028] FIG. 1 illustrates a system including a computing device 10 suitable for use with various embodiments. The computing device 10 may include a processing system 12 with 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 further include a communication component 22, such as a wired or wireless modem, a storage memory 24, an antenna 26 for establishing a wireless communication link, a power manager 28, and a memory 36. The processor 14 may include any of a variety of processing devices, for example a number of processor cores.

[0029] The term “system-on-chip” (SoC) is used herein to refer to a set of interconnected electronic circuits typically, but not exclusively, including a processing device, a memory, and a communication interface. A processing system 12 may include a variety of different types of processors 14 some of which may include multiple processor cores. Non-limiting examples of processors that may be included in a computing device 10 and implemented in or coupled to a processing system 12 include a general purpose processor, a central processing unit (CPU), a digital signal processor (DSP), a graphics processing unit (GPU), an accelerated processing unit (APU), a secure processing unit (SPU), a neural network processing unit (NPU), a subsystem processor of specific components of the computing device, such as an image processor for a camera subsystem or a display processor for a display, an auxiliary processor, a single-core processor, a multicore processor, a controller, and a microcontroller. A processing system 12 may further embody other hardware and hardware combinations, such as a field programmable gate array (FPGA), an application- specific integrated circuit (ASIC), other programmable logic device, discrete gate logic, transistor logic, performance monitoring hardware, watchdog hardware, and time references. Integrated circuits may be configured such that the components of the integrated circuit reside on a single piece of semiconductor material in what may be referred to as a system-on-chip (SoC).

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

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

[0032] The computing device 10 may include any number and combination of memories, such as the memory 16 integral to the processing system 12 and the memory 36 separate from the processing system 12. The computing device 10 and / or 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 the memory 16, dynamic RAM (DRAM), such as the memory 36, or cache memory.

[0033] The memories 16, 36 may be configured to temporarily store a limited amount of data. For example, the data may be received from a data sensor or subsystem. As another example, the data may be data and / or processor-executable code instructions that are requested from a non-volatile memory 16, 24, 36 loaded to the memories 16, 36 from the non-volatile memory 16, 24, 36 in anticipation of future access based on a variety of factors. As another example, the data may be intermediary processing data and / or processor-executable code instructions produced by the processor 14 and temporarily stored for future quick access without being stored in non-volatile memory 16, 24, 36.

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

[0035] The storage memory interface 20 and the storage memory 24 may work in unison to allow the computing device 10 to store data and processor-executable code on a non-volatile storage medium, such as a nonvolatile memory express (NVMe) memory device. The storage memory 24 may be configured much like an embodiment of the memory 16 in which the storage memory 24 may store the data or processor-executable code for access by one or more of the processors 14. The storage memory 24, being non-volatile, may retain the information after the power of the computing device 10 has been shut off. When the power is turned back on and the computing device 10 reboots, the information stored on the storage memory 24 may be available to the computing device 10. The storage memory interface 20 may control access to the storage memory 24 and allow the processor 14 to read data from and write data to the storage memory 24.

[0036] The inline cryptographic module 38 may be configured to implement cryptographic functions, such as encryption and decryption, of data for transactions of the memory storage device 24. Data transmitted between the memory 36 and the storage memory 24 may be encrypted and decrypted by the inline cryptographic module 38 to secure the data stored and the memory storage device 24 by encrypting the data, and make usable, by the SoC, the encrypted data retrieved from the memory storage device 24 by decrypting the data. In some but not all embodiments, the inline cryptographic module 38 may be configured to implement hash generation and validation for device hints related to the data transmitted between the memory 36 and the storage memory 24 to assess integrity of the device hints for use in evaluating whether to use the data.

[0037] The power manager 28 may be configured to control power states of one or more power rails (not shown) for power delivery to the components of the processing system 12. In some embodiments, the power manager 28 may be configured to control the amount of power provided to the components of the processing system 12. For example, the power manager 28 may be configured to control connections between components of the processing system 12 and the power rails. As another example, the power manager 28 may be configured to control amounts of power on the power rails connected to the components of the processing system 12. The power manager 28 may be configured as a power management integrated circuit (power management ICs or PMIC).

[0038] A clock controller 30 may be configured to control clock signals transmitted to the components of the processing system 12. For example, the clock controller 30 may gate a component of the processing system 12 by disconnecting the component of the processing system 12 from a clock signal and may ungate the component of the processing system 12 by connecting the component of the processing system 12 to the clock signal.

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

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

[0041] FIG. 2 illustrates an example of an inline cryptography NVMe system 200 suitable for implementing various embodiments. With reference to FIGs. 1 and 2, the inline cryptography NVMe system 200 may be implemented in a computing device (e.g., computing device 10 in FIG. 1), include the memory 36, a processing system 202 (e.g., processing system 12 in FIG. 1), and an NVMe device 214 (or NVMe memory device) (e.g., storage memory 24 in FIG. 1) connected to each other by various communication buses.

[0042] The processing system 202 may include one or more processors 14, a peripheral component interface express (PCIe) controller 212 (e.g., storage memory interface 20 in FIG. 1), and an inline cryptographic module 38 connected to each other by various communication buses. The one or more processors 14 may be configured to implement software, such as applications 204, including a high-level operating system, a kernel 206, an NVMe driver 208, and a PCIe driver 210. The PCIe controller 212 may manage communication between components of the processing system 202, including the inline cryptographic module 38, and the NVMe device 214. Such communications may include communications for preparation and implementation of NVMe commands from the 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 integral to the processing system 202. The inline cryptographic module 38 may implement cryptographic functions, such as encrypting, decrypting, and / or bypassing, for data of the NVMe commands. For example, the inline cryptographic module 38 may encrypt data sent to the NVMe device 214 and decrypt data received from the NVMe device 214. The cryptographic functions implemented by the inline cryptographic module 38 may be of any known, proprietary, and / or to be developed encryption and decryption methods and / or circuitry. In some embodiments, the inline cryptographic module 38 may implement Advanced Encryption Standard (AES) and / or variants thereof, such as AES xor-encrypt-xor tweakable block ciphertext stealing (XTS). For example, theinline cryptographic module 38 may provide per-application and / or file-based cryptographic functions.

[0044] In some embodiments, one or more security contexts, including 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 keystoragestructure, one or more initialization vector generation data, and / or one or more initialization vector generation algorithms may be preprogrammed at the inline cryptographic module 38. The one or more security contexts may be stored at a memory (e.g., memory 16, storage memory 24 in FIG. 1, memory 36 in FIGS. 1 and 2) of and / or accessible by the inline cryptographic module 38. In some embodiments, the one or more security contexts may be set at the inline cryptographic module 38, such as at the memory of and / or accessible by the inline cryptographic module 38, by any of the software running on the processing system 202, the NVMe driver 208, and / or the application 204. The inline cryptographic module 38 may implement cryptographic functions based on the one or more security contexts. In some embodiments, software running on the processing system 202, the NVMe driver 208, and / or the application 204, may issue a request to use a specific security context and / or a specific aspect of a 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 to send data without encryption.

[0045] In some embodiments, the inline cryptographic module 38 may function independently of PCIe structures and its different layers, enable scalable storage throughput, and be compliant with NVMe device protocols. In other examples, the inline cryptographic module 38 may be part of the PCIe controller 212. The inline cryptographic module 38 is described further herein.

[0046] FIG. 3 illustrates an example of an inline cryptographic module 38 suitable for implementing various embodiments. With reference to FIGs. 1-3, the inlinecryptographic 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. The encryption module 304, the decryption module 306, and the initialization vector generation module 308 are described herein as separate components for ease of explanation and clarity consistent with a nonlimiting embodiment. However, such separate descriptions are not intended to limit the scope of the claims and specification, and in some implementations and embodiments, the encryption module 304, the decryption module 306, and / or the initialization vector generation module 308 may be implemented as a single combined module.

[0047] The inline cryptographic module 38, including any combination of the encryption module 304, the decryption module 306, and / or the initialization vector generation module 308, may use any combination of security context data for implementing cryptographic functions on data of NVMe commands. 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 the 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, initialization vector generation data may include: a logical block address (LB A), such as a starting LB A (SLBA) from an NVMe command for a block of data of the NVMe command and / or an LBA calculated for a subsequent block of data of the NVMe command; a namespace identifier (ID) for the data of the NVMe command; one or more other data commonly in the NVMe command; one or more data provided by an application executed by the processor 14 in a repurposed field of the NVMe command; one or more data from an NVMe identify controller data structure located at a memory (e.g., memory 16, storage memory 24 in FIG. 1, memory 36 in FIGS. 1 and 2) of and / or accessible by the inline cryptographic module 38; and / or one or more modified data of one or more of the foregoing examples. In some embodiments, initialization vectorgeneration algorithms may include operations on one or more initialization vector generation data, including combining operations, logical operations, mathematical operations, linear operations, nonlinear operations, randomizing operations, pseudorandomizing operations, etc. In some embodiments, the operations of the initialization vector generation algorithms may involve using data from an NVMe command, data from a NVMe identify controller data structure, data from a security context, etc. for which the data may be in unmodified and / or modified forms. In some embodiments, the one or more initialization vector generation algorithms may be represented by a value configured to be interpreted by the inline cryptographic module 38 to implement the one or more initialization vector generation algorithms.

[0048] The security context data may be preprogrammed at the inline cryptographic module 38, provided by the application executed by the processor 14, and / or retrieved from a memory of and / or accessible by the inline cryptographic module 38. For example, the inline cryptographic module 38 may use only security context data preprogrammed at the inline cryptographic module 38, only security context data provided by an application executed by the processor 14, only security context data retrieved from the memory, and / or a combination of security context data preprogrammed at the inline cryptographic module 38, provided by an application executed by the processor 14, and / or retrieved from the memory.

[0049] The preprogrammed security context data may be stored in a memory of and / or accessible by the inline cryptographic module 38. The security context data provided by an application executed by the processor 14 may be provided at initialization of the inline cryptographic module 38 and / or as part of an NVMe command to the inline cryptographic module 38 and / or to the memory of and / or accessible by the inline cryptographic module 38. The security context data retrieved from the memory of and / or accessible by the inline cryptographic module 38 may be preprogrammed data from an NVMe identify controller data structure.

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

[0051] The NVMe command submission queue identifier may identify an NVMe command submission queue to which the NVMe driver 208 may write the NVMe command. The NVMe command submission queue may include a tail pointer configured to trigger a doorbell signal configured to indicate to the NVMe device 214 that one or more NVMe commands in the NVMe command submission queue are ready for execution when the NVMe command. The NVMe command ID may identify the NVMe command.

[0052] The buffer address lookup structure 300 may also store data of a sector offset for the NVMe command in association with the buffer address and the NVMe security ID. In some embodiments, the sector offset may be used in generation of an initialization vector for a cryptographic function. The initialization vector may be used as and / or to generate an input to an encryption algorithm and be configured to affect encryption of data in a maimer in which the data encrypted multiple times may result in different encrypted values. The buffer address lookup structure 300 may store any amount of associated data, such as more than one set of associated data for more than one NVMe command.

[0053] The security context structure 302 may be a data structure, such as a table, array, linked list, graph, etc., stored at the memory of and / or accessible by the inline cryptographic module 38 and configured to store various data in association with each other. In some embodiments, the security context structure 302 may store data of the NVMe security ID and a security context for the NVMe command in association with each other. The NVMe security ID in the buffer address lookup structure 300 and the security context structure 302 for the same NVMe command may be the same. The 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 the 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 embodiments, some or all of the security context may be preprogrammed at the inline cryptographic module 38 and / or the memory of and / or accessible to the inline cryptographic module 38. In some embodiments, some or all of the security context may be provided in the NVMe command. In some embodiments, some or all of the security context may be provided by an application executed by the processor 14 from the execution of which the NVMe command originates. The 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 the security context structure 302 may be configured in the inline cryptographic module 38 during an NVMe command submission stage. In some embodiments, the NVMe driver (e.g., NVMe driver 208 in FIG. 2) may configure the buffer address lookup structure 300 and the security context structure 302 at the inline cryptographic module 38 in response to receiving an NVMe command issued by the processor 14. The NVMe driver may provide the inline cryptographic module 38 with the data for populating the buffer address lookup structure 300 and the security context structure 302, and the inlinecryptographic module 38 may 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 the NVMe command. Such data may include any combination of buffer addresses, NVMe security IDs, sector offsets, and / or security contexts for NVMe commands. In such embodiments, the NVMe driver may maintain the same address information at two different locations, a processing system memory (e.g., memory 16, 36 in FIG. 1) and at the buffer address lookup structure 300.

[0056] In some embodiments, the inline cryptographic module 38 may retrieve security context data from an NVMe identify controller data structure. The NVMe identify controller data structure may be a data structure, such as a table, array, linked list, graph, etc., configured to store data for identifying and / or configuring an NVMe controller, which may be a component of the NVMe device 214, as described further herein with reference to FIG. 6. The NVMe identify controller data structure may be stored at the memory of and / or accessible by the inline cryptographic module 38. The NVMe identify controller data structure may be preprogrammed.

[0057] In some embodiments, the inline cryptographic module 38 may configure the buffer address lookup structure 300 and the security context structure 302 at the inline cryptographic module 38 in response to receiving an NVMe command from the NVMe driver. The inline cryptographic module 38 may process the NVMe command, extracting the data for populating the buffer address lookup structure 300 and the security context structure 302, and the inline cryptographic module 38 may store the data at the buffer address lookup structure 300 and the security context structure 302. In some embodiments, the inline cryptographic module 38 may retrieve security context data from the NVMe identify controller data structure for populating the security context structure 302, and the inline cryptographic module 38 may store the data at the security context structure 302. The inline cryptographic module 38 configuring the buffer address lookup structure 300 and the security context structure302, rather than the NVMe driver, eliminates an address redundancy issue and maintains data integrity. Further, overhead on software to configure the buffer address lookup structure 300 in the inline cryptographic module 38 is reduced.

[0058] The inline cryptographic module 38 may be configured to forward a doorbell signal configured to indicate to an NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2) of a pending NVMe command. For example, the inline cryptographic module 38 may update an NVMe command submission queue tail pointer to a submission queue tail doorbell register of the NVMe device. Forwarding the doorbell signal may enable bypassing or foregoing inclusion of software configured to write two doorbells, as per known implementations of the NVMe protocol, and may ensure that the operation of the cryptographic module 38 and the NVMe device are synchronized.

[0059] In response to receiving an NVMe transaction from the NVMe device, In some embodiments, the inline cryptographic module 38 may retrieve a buffer address from the NVMe transaction and use the buffer address to retrieve the associated data, such as the NVMe security ID, from the buffer address lookup structure 300. In some embodiments, the inline cryptographic module 38 may use the buffer address to retrieve the associated sector offset from the buffer address lookup structure 300. The inline cryptographic module 38 may use the retrieved NVMe security ID to retrieve the associated security context for the NVMe command from the security context structure 302. For example, the retrieved security context from the security context structure 302 may include as one or more encryption algorithms, one or more encryption keys, 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, one or more initialization vector generation algorithms, etc.

[0060] In some embodiments, the inline cryptographic module 38 may retrieve data from the from the NVMe transaction. For example, the retrieved data from the from the NVMe transaction may include one or more initialization vector generation dataand / or one or more initialization vector generation algorithms. In some embodiments, the inline cryptographic module 38 may retrieve data from the NVMe identify controller data structure. For example, the retrieved data from the from the NVMe identify controller data structure may include one or more initialization vector generation data.

[0061] Using the retrieved information, such as the sector offset, the security context from the security context structure 302, the data from the NVMe transaction, and / or the data from the NVMe identify controller data structure, the encryption module 304, the decryption module 306, and / or the initialization vector generation module 308 may implement the cryptographic function for the data of the NVMe transaction. The initialization vector generation module 308 may use the retrieved information of the sector offset, one or more initialization vector generation data from the security context from the security context structure 302, one or more initialization vector generation data from the NVMe transaction, and / or one or more initialization vector generation data from the NVMe identify controller data structure to generate one or more initialization vectors. In some embodiments, the initialization vector generation module 308 may use the retrieved information of one or more initialization vector generation algorithms from the security context from the security context structure 302 and / or one or one or more initialization vector generation algorithms from the NVMe transaction to generate one or more initialization vectors.

[0062] The encryption module 304 may use the one or more initialization vectors and the retrieved information of the security context to encrypt the data to be sent to the NVMe device for the NVMe transaction. The decryption module 306 may use the one or more initialization vectors and the retrieved information of the security context to decrypt the data received from the NVMe device for the NVMe transaction.

[0063] FIG. 4 illustrates an inline cryptography NVMe system 400 (e.g., inline cryptography NVMe system 200 in FIG. 2) suitable for implementing various embodiments. With reference to FIGs. 1-5, the inline cryptography NVMe system400 may include a host 402 (e.g., processing system 12 in FIG. 1, processor 14 in FIGs. 1 and 2, processing system 202 in FIG. 2), a host memory 404 (e.g., memory 16 in FIG. 1, memory 36 in FIGs. 1 and 2), and an NVMe device controller 410 of an NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2). The host memory 404 may include the inline cryptographic module 38, which may be an encryption / decryption layer between a host driver executed by the host 402 and the NVMe device controller 410.

[0064] Command submission operations of the inline cryptography NVMe system 400 may include that (1) the NVMe Device driver (e.g., NVMe driver 208 in FIG. 2) at the host 402 may write commands to a submission queue (SQ) 406 at the host memory 404. (2) The NVMe Device driver at the host 402 may configure the inline cryptographic module 38 for inlining encryption of NVMe transactions. (3) The NVMe device driver at the host 402 may write an updated submission queue tail pointer (a pointer to “Tail” in the submission queue 406 in FIG. 4) to the SQ tail doorbell 412 (e.g., an SQ tail doorbell register) at the NVMe device controller 410.

[0065] Command processing operations may include that (4) the NVMe device controller 410 may fetch a command from the submission queue 406 and update a submission queue head pointer (a pointer to “Head” in the submission queue 406 in FIG. 4) to a next command of the submission queue 406. (5) The NVMe device controller 410 may process the command. (6) The inline cryptographic module 38 may encrypt and / or decrypt data for the command that is processed. For example, the inline cryptographic module 38 may encrypt write data sent 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 that (7) the NVMe device controller 410 may write completion of the command to the completion queue (“CQ” in FIG. 4) 408 at the host memory 404 and may update a completion queue tail pointer (a pointer to “Tail” in the completion queue 408 in FIG. 4) to the completion of thecommand writen to the completion queue 408. (8) The NVMe device controller 410 may generate a platform specific completion interrupt, such as an MSI-X interrupt, configured for notification of a completion status of the command to the host driver. (9) The host 402 may process completion of the command. (10) The host 402 may write a completion queue (CQ) head pointer (a pointer to “Head” in the completion queue 408 in FIG. 4) to the CQ tail doorbell 414 (e.g., a CQ tail doorbell register) at the NVMe device controller 410.

[0067] The inline cryptographic module 38 may provide data security and privacy at the storage level by enabling encryption of data that is sent from the host 402 to the NVMe device controller 410. This may be achieved by inserting a layer of encryption between the host 402 and the NVMe device controller 410, which may allow each command processed to have the data of the command encrypted before being passed on to the NVMe device controller 410 for further processing. When a write command is writen by the host driver and queued onto the submission queue 406 or when the write command from the submission queue 406 is fetched by the NVMe device controller 410, the data of the command from the most memory 404 may be encrypted by the inline cryptographic module 38 before being passed on to the NVMe device controller 410 for further processing. When a read command from the submission queue 406 is fetched and processed by the NVMe device controller 410, the encrypted data of the command from the NVMe device may be passed by the NVMe device controller 410 to and decrypted by the inline cryptographic module 38 before being passed on to the host 402 for further processing.

[0068] The process flows described above may ensure that all data sent between the host 402 and NVMe device controller 410 are encrypted and secure while providing a performance-efficient solution that maintains low latency regardless of workload or data size due to its position in line with other required steps in the process of sending commands from the host 402 and receiving results back from a NVMe device controller 410. Further, in some embodiments, all data may be secured usinghardware-based encryption mechanisms so that no additional software implementation is required on either the host side or NVMe device side. As a result, the embodiments may be implemented without any major changes to existing architectures and systems for users looking for improved security solutions for their workloads without sacrificing performance or latency.

[0069] FIG. 5 illustrates an example of a structure of a command processed by the NVMe inline cryptographic module 38. With reference to FIGs. 1-5, a structure of a command 500 may be for I / O accesses involving user data transfer that should be encrypted for security purposes, including read and / or write commands. In some embodiments, the structure of the command 500 may be that of a common submission command format for NVMe implementation, which may include aspects typically included in a submission command format, such as a namespace identifier (NSID) and a starting logical block address (SLBA). The structure of the command 500 may include other common aspects (not shown), such as a command identifier (CID), a physical region page (PRP) or scatter gather list (SGL) for data transfer indicator (PSDT), a fuse indicator, opcode, a number of logical blocks, a namespace identifier (NSID), a metadata pointer or of metadata SGL segment pointer, PRP pointers, etc. The one or more initialization vector generation data included in the command 500 may include the NSID, the SLBA, and / or any other of the common aspects of the submission command 500.

[0070] In some embodiments, the structure of the command 500 may be a modified version of a common submission command format for NVMe implementation. For example, the structure of a command 500 may include the aspects typically included in a submission command format and data provided by an application executed by the processor 14 in one or more repurposed fields (not shown) of the NVMe command. The one or more repurposed fields may be fields that are reserved for future specification and / or not used for commands for I / O accesses involving user data transfer. The data of the one or more repurposed fields of the NVMe command mayinclude 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 the command 500 may include the NSID, the SLBA, data of the one or more repurposed fields of the NVMe command, and / or any other of the common aspects of the submission command 500.

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

[0072] The initialization vector generation module 308 may implement generation of one or more initialization vectors for implementation of cryptographic functions on data of the NVMe command by the encryption module 304 and / or the decryption module 306. The initialization vector generation module 308 may generate the one or more initialization vectors using the one or more initialization vector generation data from the command 500. The initialization vector generation module 308 may implement one or more initialization vector generation algorithms using the one or more initialization vector generation data as inputs and output the one or more initialization vectors. In some embodiments, initialization vector generation module 308 may interpret an indication of the one or more initialization vector generation algorithms from the command 500 and implement the corresponding one or more initialization vector generation algorithms.

[0073] FIG. 6 illustrates an example of an NVMe identify controller data structure. With reference to FIGs. 1-6, an NVMe identify controller data structure 600 may be a data structure, such as a table, array, linked list, graph, etc., configured to store data for identifying and / or configuring an NVMe controller, which may be a component ofthe NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2). The data for identifying and / or configuring an NVMe controller may include: a peripheral component interface (PCI) vendor ID (VID); a PCI subsystem vendor ID (SSVID); a serial number (SN); a model number (MN); a firmware revision (FR); a recommend arbitration burst (RAB); an Institute of Electrical and Electronics Engineers organizationally unique identifier (OUI) ID (IEEE); controller multi-path I / O and namespace sharing capabilities (CMIC); a maximum data transfer size (MDTS); a controller ID (CNTLID); a version (VER); an runtime D3 resume latency (RTD3R); runtime D3 entry latency (RTD3E); an optional asynchronous events supported (OAES); controller attributes (CTRATT); one or more reserved fields; a field-replaceable unit (FRU) globally unique identifier (FGUID); etc. The NVMe identify controller data structure may be stored at the memory (e.g., memory 16, storage memory 24 in FIG. 1, memory 36 in FIGS. 1 and 2, host memory 404 in FIG. 4) of and / or accessible by the inline cryptographic module 38. The NVMe identify controller data structure may be preprogrammed.

[0074] The NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2) may read the command 500, which may prompt the NVMe inline cryptographic module 38 (which may include the initialization vector generation module 308 without specific reference unless otherwise stated)to parse the command 500. The NVMe inline cryptographic module 38 may read the one or more initialization vector generation data and / or the one or more initialization vector generation algorithms. In some embodiments, reading the command 500 may also prompt the NVMe inline cryptographic module 38 to retrieve one or more data of the data for identifying and / or configuring an NVMe controller of the NVMe identify controller data structure 600. The one or more of the data for identifying and / or configuring an NVMe controller of the NVMe identify controller data structure 600 may be used along with data in the command 500 as one or more initialization vector generation data by the NVMe inline cryptographic module 38.

[0075] The initialization vector generation module 308 may implement generation of one or more initialization vectors for implementation of cryptographic functions on data of the NVMe command by the encryption module 304 and / or the decryption module 306. The initialization vector generation module 308 may generate the one or more initialization vectors using the one or more initialization vector generation data from the command 500. The initialization vector generation module 308 may implement one or more initialization vector generation algorithms using the one or more initialization vector generation data as inputs and output the one or more initialization vectors. In some embodiments, initialization vector generation module 308 may interpret an indication of the one or more initialization vector generation algorithms from the command 500 and implement the corresponding one or more initialization vector generation algorithms.

[0076] FIG. 7 illustrates a method 700 of inline cryptography for NVMe devices according to some embodiments. With reference to FIGs. 1-7, the method 700 may be implemented in a computing device (e.g., computing device 10 in FIG. 1, inline cryptography NVMe system 200, 400 in FIGs. 2 and 4), in software executing in a processor (e.g., processor 14 in FIGs. 1 and 2, inline cryptographic module 38 in FIGs. 1-3, host 402 in FIG. 4), in general purpose hardware, in dedicated hardware (e.g., inline cryptographic module 38 in FIGs. 1-3, encryption module 304, decryption module 306, initialization vector generation module 308 in FIG. 3), or in a combination of a software-configured processor and dedicated hardware, such as a processor executing software within a system (e.g., inline cryptography NVMe system 200, 400 in FIGs. 2 and 4) that includes other individual components, and various memory / cache controllers. Means for implementing the method 400 may include a processing system or other processors (e.g., one or more processors 14, an inline cryptographic module 38, an encryption module 304, a decryption module 306, an initialization vector generation module 308, and / or host 402). Further, one or more processors may be configured with software or firmware to perform some or all of the operations of the method 700. In order to encompass the alternative configurationsenabled in various embodiments, the hardware implementing the method 700 is referred to herein as an “inline cryptographic device.”

[0077] In block 702, the inline cryptographic device may receive an NVMe command (e.g., NVMe command 500 in FIG. 5). In some embodiments, the inline cryptographic device receiving the NVMe command in block 702 may include an inline cryptographic module (e.g., inline cryptographic module 38 in FIGs. 1-3) and / or an initialization vector generation module (e.g., initialization vector generation module 308 in FIG. 3).

[0078] An NVMe device (e.g., storage memory 24 in FIG. 1, NVMe device 214 in FIG. 2) may fetch the NVMe command from an NVMe command submission queue (e.g., submission queue 406 in FIG. 4). The inline cryptographic device may receive the NVMe command fetched by the NVMe device. In some embodiments, the inline cryptographic device may receive the NVMe command while being fetched by the NVMe device. For example, as part of transmitting the NVMe command from the NVMe command submission queue, the inline cryptographic device may receive the NVMe command and forward the NVMe command to the NVMe device. As another example, in parallel to transmitting the NVMe command from the NVMe command submission queue, the inline cryptographic device may receive a copy of the NVMe command sent to the NVMe device.

[0079] In some embodiments, the inline cryptographic device may receive the NVMe command from the NVMe device after being fetched after being fetched the NVMe device. The NVMe command may be received by inline cryptographic device from the NVMe device via a device interface (e.g., storage memory interface 20 in FIG. 1, PCIe controller 212 in FIG. 2). The NVMe command may be transmitted by the NVMe device to the inline cryptographic device as part of the NVMe device processing the NVMe command.

[0080] In block 704, the inline cryptographic device may retrieve one or more initialization vector generation parameters. In some embodiments, the inlinecryptographic device retrieving the one or more initialization vector generation parameters in block 704 may include the inline cryptographic module and / or the initialization vector generation module. The one or more initialization vector generation parameters may include initialization vector generation parameters retrieved from one or more of the command, an NVMe identify controller data structure (e.g., NVMe identify controller data structure 600 in FIG. 6), a security context (e.g., security context structure 302 in FIG. 3), etc. The inline cryptographic device may parse the one or more initialization vector generation parameters from one or more of the command, the NVMe identify controller data structure, the security context (e.g., security context structure 302 in FIG. 3), etc.

[0081] The one or more initialization vector generation parameters may include one or more initialization vector generation data. In some embodiments, initialization vector generation data may include: an LB A, such as an SLBA from the NVMe command for a block of data of the NVMe command and / or an LBA calculated for a subsequent block of data of the NVMe command; an namespace ID for the data of the NVMe command; one or more other data commonly in the NVMe command; one or more data provided by an application executed by a processor (e.g., processor 14 in FIGs. 1 and 2, host 402 in FIG. 4) in a repurposed field of the NVMe command; one or more data from the NVMe identify controller data structure located at a memory (e.g., memory 16, storage memory 24 in FIG. 1, memory 36 in FIGS. 1 and 2, host memory 404 in FIG. 4) of and / or accessible by the inline cryptographic device; and / or one or more modified data of one or more of the foregoing examples.

[0082] In some embodiments, the 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 one or more initialization vector generation data, including combining operations, logical operations, mathematical operations, linear operations, nonlinear operations, randomizing operations, pseudo-randomizing operations, etc. In some embodiments,the operations of the initialization vector generation algorithms may involve using data from the NVMe command, data from the NVMe identify controller data structure, data from the security context, etc. for which the data may be unmodified and / or modified. In some embodiments, the one or more initialization vector generation algorithms may be represented by a value configured to be interpreted by the inline cryptographic device to implement the one or more initialization vector generation algorithms. The one or more initialization vector generation algorithms may be retrieved from the command and / or the memory of and / or accessible by the inline cryptographic device.

[0083] In block 706, the inline cryptographic device may generate an initialization vector. Using the one or more initialization vector generation data as inputs to the one or more initialization vector generation algorithms, the inline cryptographic device may generate an initialization vector. In some embodiments, the inline cryptographic device may be preconfigured to implement the one or more initialization vector generation algorithms, such as through hardware, firmware, and / or software preconfiguration. In some embodiments, the inline cryptographic device may be configured to implement the one or more initialization vector generation algorithms retrieved in block 704, such as through hardware, firmware, and / or software configuration. The inline cryptographic device may implement one or more of the operations of the one or more initialization vector generation algorithms on the one or more initialization vector generation data and / or data derived therefrom by previous operations of the one or more initialization vector generation algorithms to generate the initialization vector. The inline cryptographic device may parse the one or more initialization vector generation parameters from one or more of the command, the NVMe identify controller data structure, the security context (e.g., security context structure 302 in FIG. 3), etc. In some embodiments, the inline cryptographic device generating the initialization vector in block 706 may include the inline cryptographic module and / or the initialization vector generation module.

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

[0085] In block 710, the inline cryptographic device may implement a cryptographic function on the data for the NVMe command based on the initialization vector. In some embodiments, the inline cryptographic device implementing the cryptographic function on the data for the NVMe command based on the initialization vector in block 710 may include the inline cryptographic module, an encryption module (e.g., encryption module 304 in FIG. 3), and / or a decryption module (e.g., decryption module 306 in FIG. 3). Using the initialization vector, the data for the NVMe command, and an encryption key as inputs to the cryptographic function, the inline cryptographic device may implement the cryptographic function on the data of the NVMe transaction. For example, the inline cryptographic device may encrypt the data to be sent to the NVMe device for a write NVMe command. As another example, the inline cryptographic device may decrypt the data received from the NVMe device for a read NVMe command. In some embodiments, the data of the NVMe command on which the cryptographic function is implemented may be a subset, or portion, of the data of the NVMe command. The subset of the data of the NVMe command may be of any size, such as one or more bits, bytes, words, blocks, segments, lines, etc.

[0086] In some embodiments, at various points of the implementation of the cryptographic function, the data for the NVMe command and / or the initialization vector may be in unmodified and / or modified forms. For example, in implementing AES-XTS, the initialization vector may be modified, and the modified initializationvector may be used to modify the data for the NVMe command prior to implementing an AES cryptographic function on the modified data of the NVMe command, and the output of the AES cryptographic function may be modified by the modified initialization vector.

[0087] In some embodiments, the inline cryptographic device may be configured to implement cryptographic functions for multiple subsets of the data of the NVMe command rather than all the data of the NVMe command at once. In optional block 712, the inline cryptographic device may identify that data remains for the NVMe command. The remaining data may be any subset of the data of the NVMe command other than a subset of the data of the NVMe command on which the on which the cryptographic function was already implemented in block 710. For example, the NVMe command may include a value configured to indicate to the inline cryptographic device an amount of data for the command, such as a total amount of data and / or an amount of subsets of data. The inline cryptographic device may be configured to track an amount of data for the command on which the cryptographic function was already and / or is yet to be implemented, such as a total amount of data and / or an amount of subsets of data. Data may remain for the NVMe command for in response to the inline cryptographic device identifying that less than all of the data for the NVMe command has had implemented the cryptographic function and / or more than none of the data for the NVMe command has yet to have implemented the cryptographic function. In some embodiments, the inline cryptographic device identifying that data remains for the NVMe command in optional block 712 may include the inline cryptographic module and / or the initialization vector generation module.

[0088] In some embodiments, to implement cryptographic functions on remaining data of the NVMe, the inline cryptographic device may generate a different initialization vector using one or more different initialization vector generation parameters. In block 704, the inline cryptographic device may retrieve one or moreinitialization vector generation parameters in block 704. In some embodiments, the inline cryptographic device retrieving the one or more initialization vector generation parameters in block 704 may include the inline cryptographic module and / or the initialization vector generation module.

[0089] In some embodiments, to implement cryptographic functions on remaining data of the NVMe, the inline cryptographic device may use the same initialization vector. In block 710, the inline cryptographic device may implement a cryptographic function on the data for the NVMe command based on the initialization vector. In some embodiments, the inline cryptographic device implementing the cryptographic function on the data for the NVMe command based on the initialization vector in block 710 may include the inline cryptographic module, the encryption module, and / or the decryption module.

[0090] In some embodiments, to implement cryptographic functions on remaining data of the NVMe, the inline cryptographic device may generate a different initialization vector using one or more modified initialization vector generation data. In optional block 714, the inline cryptographic device may modify one or more of the initialization vector generation data. In some embodiments, the inline cryptographic device may be configured to modify one or more of the initialization vector generation data to differentiate the modified initialization vector generation data from one or initialization vector generation data used for implementing cryptographic functions on other data of the NVMe command. For example, the one or more initialization vector generation data may be data associated with a particular subset of the data of the NVMe command. The one or more initialization vector generation data may be modified in a maimer so that they differ from previously used initialization vector generation data and may be associated with another particular subset of the data of the NVMe command. In some embodiments, the one or more initialization vector generation data for a subset of data of the NVMe command may be an LB A, and the LBA may be modified so that the modified LBA is different from the LBA and themodified may be associated with another subset of data of the NVMe command. In some embodiments, the inline cryptographic device modifying the one or more of the initialization vector generation data in optional block 714 may include the inline cryptographic module and / or the initialization vector generation module.

[0091] Various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-7) may be implemented in a wide variety of computing systems including mobile computing devices, an example of which suitable for use with the various embodiments is illustrated in FIG. 8. The mobile computing device 800 may include a processor 802 coupled to a touchscreen controller 804 and an internal memory 806. The processor 802 may be one or more multicore 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 unsecure and / or unencrypted memory, or any combination thereof. Examples of memory types that can be leveraged include but are not limited to DDR, LPDDR, GDDR, WIDER), RAM, SRAM, DRAM, P-RAM, R- RAM, M-RAM, STT-RAM, and embedded DRAM. The touchscreen controller 804 and the processor 802 may also be coupled to a touchscreen panel 812, such as a resistive-sensing touchscreen, capacitive-sensing touchscreen, infrared sensing touchscreen, etc. Additionally, the display of the mobile computing device 800 need not have touch screen capability.

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

[0093] The mobile computing device 800 may include a peripheral device connection interface 818 coupled to the processor 802. The peripheral device connection interface 818 may be singularly configured to accept one type of connection or may be configured to accept various types of physical and communication connections, common or proprietary, 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 speakers 814 for providing audio outputs. The mobile computing device 800 may also include a housing 820, constructed of a plastic, metal, or a combination of materials, for containing all or some of the components described herein. 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 the peripheral device connection port to receive a 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 inputs. The mobile computing device 800 may also include a power button 826 for turning the mobile computing device 800 on and off.

[0095] The various embodiments (including, but not limited to, embodiments described above with reference to FIGs. 1-7) may be implemented in a wide variety of computing systems including a laptop computer 900 an example of which is illustrated in FIG. 9. Many laptop computers include a touchpad touch surface 917 that serves as the computer’s pointing device, and thus may receive drag, scroll, and flick gestures similar to those implemented on computing devices equipped with a touch screen display and described above. A laptop computer 900 will typically include a processor 902 coupled to volatile memory 912 and a large capacity nonvolatile memory, such as a disk drive 913 of Flash memory. Additionally, the computer 900may have one or more antenna 908 for sending and receiving electromagnetic radiation that may be connected to a wireless data link and / or cellular telephone transceiver 916 coupled to the processor 902. The computer 900 may also include a floppy disc drive 914 and a compact disc (CD) drive 915 coupled to the processor 902. In a notebook configuration, the computer housing includes the touchpad 917, the keyboard 918, and the display 919 all coupled to the processor 902. Other configurations of the computing device may include a computer mouse or trackball coupled to the processor (e.g., via a USB input) as are well known, which may also be used in conjunction with the various embodiments.

[0096] Computer program code or “program code” for execution on a programmable processor for carrying out operations of the various embodiments may be written in a high-level programming language such as C, C++, C#, Smalltalk, Java, JavaScript, Visual Basic, a Structured Query Language (e.g., Transact-SQL), Perl, or in various other programming languages. Program code or programs stored on a computer readable storage medium as used in this application may refer to machine language code (such as object code) whose format is understandable by a processor.

[0097] Implementation examples are described in the following paragraphs. While some of the following implementation examples are described in terms of example systems, devices, or methods, further example implementations may include: the example systems or devices discussed in the following paragraphs implemented as a method executing operations of the example systems or devices, the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising an inline cryptographic module configured to perform operations of the example systems, devices, or methods; the example systems, devices, or methods discussed in the following paragraphs implemented by a computing device comprising a processing device configured with processing deviceexecutable instructions to perform operations of the example systems, devices, or methods; a computing device including means for performing functions of theexample systems, devices, or methods; and the example systems, devices, or methods discussed in the following paragraphs implemented as a non-transitory processor- readable storage medium having stored thereon processor-executable instructions configured to cause a processor of a computing device to perform the operations of the example systems, devices, or methods..

[0098] Example 1. A method of implementing cryptographic functions for nonvolatile memory express (NVMe) inline storage cryptography in a processing system, including: receiving an NVMe command; generating at least a first initialization vector for the NVMe command; receiving the first initialization vector and a data for the NVMe command as inputs of a cryptographic function; and implementing the cryptographic function based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output.

[0099] Example 2. The method of example 1, in which the first initialization vector for the NVMe command is configured for the data for the NVMe command at a first namespace of an NVMe memory device and at a first logical block of the NVMe memory device, and configured to differ from a second initialization vector for another NVMe command configured for data for the another NVMe command at a second namespace of the NVMe memory device and the first logical block of the NVMe memory device.

[0100] Example 3. The method of either examples 1 or 2, further including parsing at least a first data from the NVMe command, in which the first initialization vector is based on at least the first data from the NVMe command.

[0100] Example 4. The method of example 3, further including parsing at least a second data from the NVMe command, in which the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe command.

[0101] Example 5. The method of example 4, further including parsing at least a third data from the NVMe command, in which 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.

[0102] Example 6. The method of example 4, in which: the first data from the NVMe command is a namespace identifier of a namespace of an NVMe memory device; and the second data from the NVMe command is a start logical block address of the name space.

[0103] Example 7. The method of example 3, in which the first initialization vector for the NVMe command is based on at least the first data that is modified by at least one of at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudorandom value, at least a second data parsed from the NVMe command, at least one modified value of at least the second data parsed from the NVMe command, at least one data from an NVMe identify controller data structure, or at least one modified value of the at least one data from the NVMe identify controller data structure.

[0104] Example 8. The method of example 3, further including retrieving at least a second data from an NVMe identify controller data structure, in which the first initialization vector is based on at least the first data from the NVMe command and the second data from the NVMe identify controller data structure.

[0105] Example 9. The method of example 1, further including parsing from the NVMe command at least an initialization vector data generated by a software implemented in a computing device that includes the processing system, in which the first initialization vector is based on at least the initialization vector data.

[0106] The foregoing method descriptions and the process flow diagrams are provided merely as illustrative examples and are not intended to require or imply that the operations of the various embodiments must be performed in the order presented.As will be appreciated by one of skill in the art the order of operations in the foregoing embodiments may be performed in any order. Words such as “thereafter,”“then,” “next,” etc. are not intended to limit the order of the operations; these words are simply used to guide the reader through the description of the methods. Further, any reference to claim elements in the singular, for example, using the articles “a,” “an” or “the” is not to be construed as limiting the element to the singular.

[0107] The various illustrative logical blocks, modules, circuits, and algorithm operations described in connection with the various embodiments may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0108] The hardware used to implement the various illustrative logics, logical blocks, modules, and circuits described in connection with the embodiments disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general-purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors inconjunction with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuitry that is specific to a given function.

[0109] In one or more embodiments, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a non- transitory computer-readable medium or a non-transitory processor-readable medium. The operations of a method or algorithm disclosed herein may be embodied in a processor-executable software module that may reside on a non-transitory computer- readable or processor-readable storage medium. Non-transitory computer-readable or processor-readable storage media may be any storage media that may be accessed by a computer or a processor. By way of example but not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, FLASH memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store desired program code in the form of instructions or data structures and that may be accessed by a computer. Disk and disc, as used herein, includes compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0110] The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and implementationswithout departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments and implementations described herein but is to be accorded the widest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

CLAIMSWhat is claimed is:

1. A method of implementing cryptographic functions for non-volatile memory express (NVMe) inline storage cryptography in a processing system, comprising: receiving an NVMe command; generating at least a first initialization vector for the NVMe command; receiving the first initialization vector and a data for the NVMe command as inputs of a cryptographic function; and implementing the cryptographic function based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output.

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

3. The method of claim 1, further comprising parsing at least a first data from the NVMe command, wherein the first initialization vector is based on at least the first data from the NVMe command.

4. The method of claim 3, further comprising parsing at least a 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.

5. The method of claim 4, further comprising parsing at least a third data from the NVMe command, wherein the first initialization vector is based on at least the firstdata from the NVMe command, the second data from the NVMe command, and the third data from the NVMe command.

6. The method of claim 4, wherein: the first data from the NVMe command is a namespace identifier of a namespace of an NVMe memory device; and the second data from the NVMe command is a start logical block address of the name space.

7. The method of claim 3, wherein the first initialization vector for the NVMe command is based on at least the first data that is modified by at least one of at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudorandom value, at least a second data parsed from the NVMe command, at least one modified value of at least the second data parsed from the NVMe command, at least one data from an NVMe identify controller data structure, or at least one modified value of the at least one data from the NVMe identify controller data structure.

8. The method of claim 3, further comprising retrieving at least a second data from an NVMe identify 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 identify controller data structure.

9. The method of claim 1, further comprising parsing from the NVMe command at least an initialization vector data generated by a software implemented in a computing device that includes the processing system, wherein the first initialization vector is based on at least the initialization vector data.

10. A processing system, comprising: a memory; an inline cryptographic module coupled to the memory; and a memory controller coupled to the memory and inline cryptographic module, and configured to: receive a non-volatile memory express (NVMe) command; generate at least a first initialization vector for the NVMe command; receive the first initialization vector and a data for the NVMe command as inputs of a cryptographic function; and implement the cryptographic function in the inline cryptographic module based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output.

11. The processing system of claim 10, wherein the memory controller is further configured such that first initialization vector for the NVMe command is configured for the data for the NVMe command at a first namespace of an NVMe memory device and at a first logical block of the NVMe memory device, and configured to differ from a second initialization vector for another NVMe command configured for data for the another NVMe command at a second namespace of the NVMe memory device and 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 a 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 a 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 a 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 a namespace identifier of a namespace of an NVMe memory device; and the second data from the NVMe command is a start logical block address of the name space.

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 that is modified by at least one of at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudorandom value, at least a second data parsed from the NVMe command, at least one modified value of at least the second data parsed from the NVMe command, at least one data from an NVMe identify controller data structure, or at least one modified value of the at least one data from the NVMe identify controller data structure.

17. The processing system of claim 12, wherein the memory controller is further configured to retrieve at least a second data from an NVMe identify 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 identify 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 an initialization vector datagenerated by a software implemented in a computing device that includes the processing system, wherein the first initialization vector is based on at least the initialization vector data.

19. A processing system, comprising: means for receiving a non-volatile memory express (NVMe) command; means for generating at least a first initialization vector for the NVMe command; means for receiving the first initialization vector and a data for the NVMe command as inputs of a cryptographic function; and means for implementing the cryptographic function based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output.

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

21. The processing system of claim 19, further comprising means for parsing at least a 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 of claim 21, further comprising means for parsing at least a second data from the NVMe command, wherein the first initialization vector isbased on at least the first data from the NVMe command and the second data from the NVMe command.

23. The processing system of claim 22, further comprising means for parsing at least a 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 of claim 22, wherein: the first data from the NVMe command is a namespace identifier of a namespace of an NVMe memory device; and the second data from the NVMe command is a start logical block address of the name space.

25. The processing system of claim 21, wherein the first initialization vector for the NVMe command is based on at least the first data that is modified by at least one of at least one logical operation, at least one arithmetic operation, at least one random value, at least one pseudorandom value, at least a second data parsed from the NVMe command, at least one modified value of at least the second data parsed from the NVMe command, at least one data from an NVMe identify controller data structure, or at least one modified value of the at least one data from the NVMe identify controller data structure.

26. The processing system of claim 21, further comprising means for retrieving at least a second data from an NVMe identify 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 identify controller data structure.

27. The processing system of claim 19, further comprising parsing from the NVMe command at least an initialization vector data generated by a software implemented in a computing device that includes the processing system, wherein the first initialization vector is based on at least the initialization vector data.

28. A non-volatile memory having stored thereon processor-executable instructions configured to cause one or more processor of a processing system to perform operations implementing cryptographic functions for non-volatile memory express (NVMe) inline storage cryptography comprising: receiving an NVMe command; generating at least a first initialization vector for the NVMe command; receiving the first initialization vector and a data for the NVMe command as inputs of a cryptographic function; and implementing the cryptographic function based at least on the first initialization vector, the data for the NVMe command, and a cryptographic key generating a cryptographic function output.

29. The non-volatile memory of claim 28, wherein the stored processor-executable instructions are configured to cause one or more processor of the processing system to perform operations further comprising parsing at least a 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 processor of the processing system to perform operations further comprising parsing from the NVMe command at least an initialization vector data generated by a software implemented in a computing device that includes the processing system, wherein the first initialization vector is based on at least the initialization vector data.

Images