DATA ENCRYPTION USING STANDARDIZED DATA STORAGE AND RETRIEVAL PROTOCOL

BACKGROUND

I. Reference To Related Applications

[001] This application is a continuation-in-part of U.S. application serial no. 15/907,101, filed on February 27, 2018, incorporated by reference in its entirety herein.

II. Field of Use

[001] The present invention relates to the field of digital data processing and more

specifically to encryption and decryption of large volumes of data.

III. Description of the Related Art

[002] Storage arrays are used to efficiently distribute data across multiple drives and enable fault tolerance through redundant array of independent disks (RAID). Some storage arrays also use virtualization, which provides additional functionality by optimizing storage use and providing greater flexibility for users managing stored data.

[003] In many cases, storage arrays implement at least one form of security so that that only authenticated users gain access to their data. Self-encrypting drives such as the ones that are compliant with TCG-OPAL specifications provide a level of security at the bottom of a storage stack. Array-based and host-based encryption provide additional security at a higher level, ensuring that data in flight or at rest in a buffer or disk remains secure. Storage management software can also be used to manage a virtualized environment with multiple encryption keys that ensure security between virtual functions.

[004] The TCG-OPAL specifications typically use the well-known 128 or 256 bit Advanced Encryption Standard, or AES. Encryption using AES is inherently complex and requires substantial computational resources from a host CPU. Thus, using AES to encrypt large amounts of data takes computational resources away from the host that could be used for other computations. The result is slow processing speed for other applications.

[005] It would be desirable to encrypt large volumes of data without taking computational resources from a host CPU. SUMMARY

[006] The embodiments herein describe methods and apparatus for encrypting and decrypting data using a block I/O device coupled to a host processor and a host memory. In one embodiment, a block I/O device is described, comprising a controller configured to retrieve an encryption command issued by a host processor, the controller coupled to the host processor and a host memory by a high-speed data bus, the encryption command retrieved in accordance with a standardized data storage and retrieval protocol, to cause the data to be encrypted in accordance with an encryption algorithm, and to provide a completion queue entry into a completion queue upon completion of the encryption, and a memory coupled to the controller for storing an encryption algorithm to encrypt the data.

[007] In another embodiment, a computer system is described for encrypting data, comprising a host processor for generating an encryption command and storing the encryption command into a submission queue, the encryption command comprising a modified version of a command defined by a standardized data storage and retrieval protocol, a host memory for storing the submission queue and a completion queue, a data bus, a block I/O device electronically coupled to the host processor and the host memory by the data bus, the block I/O device comprising a controller configured to retrieve the encryption command from the submission queue in accordance with the standardized data and retrieval protocol, to cause the data to be encrypted in accordance with an encryption algorithm, and to provide a completion queue entry into a completion queue upon completion of the encryption, and a memory coupled to the controller for storing an encryption algorithm used to encrypt the data, and for storing the submission queue and the completion queue..

[008] In yet another embodiment, a method is described for encrypting data, comprising generating, by a host processor, an encryption command, the encryption command comprising a modified version of a Vendor Specific Command as defined by an NVMe data storage and retrieval protocol, storing, by the host processor, the encryption command in a submission queue, retrieving, by a controller in an I/O block device coupled to the host processor by a data bus, the encryption command from the submission queue in accordance with the NVMe data storage and retrieval protocol, retrieving, by the controller, data from an input buffer coupled to the controller at an input buffer address identified by the modified version of the Vendor Specific Command, encrypting the block of data in accordance with the encryption command to generate an encrypted block of data, and storing, by the controller in a completion queue, a result of encrypting the block of data.

BRIEF DESCRIPTION OF THE DRAWINGS

[009] The features, advantages, and objects of the present invention will become more apparent from the detailed description as set forth below, when taken in conjunction with the drawings in which like referenced characters identify correspondingly throughout, and wherein:

[0010] FIG. 1 illustrates a functional block diagram of one embodiment of a computer system utilizing the inventive concepts described herein;

[0011] FIG. 2 is a functional block diagram of a block I/O device as shown in FIG. 1;

[0012] FIG. 3 is another embodiment of the computer system shown in FIG. 1 having multiple block I/O devices; and

[0013] FIGs. 4A and 4B are flow diagrams illustrating one embodiment of a method performed by a host processor and an I/O device as shown in FIG. 1.

DETAILED DESCRIPTION

[0014] Methods and apparatus are provided for encrypting large amounts of data by a block I/O device coupled to a host processor and host memory via a high-speed data bus. The block I/O device performs encryption on data stored in an input buffer in accordance with commands issued by the host processer using a standardized data storage and retrieval protocol. This architecture enables the host processor to delegate burdensome encryption processing to the block I/O device, thus freeing up host processor resources for other tasks. This method is suitable for a scale-out architecture in which data may be encrypted in parallel by multiple block I/O devices, each coupled to the host processor via the high-speed data bus.

[0015] FIG. 1 illustrates a functional block diagram of one embodiment of a computer system 100 using the inventive concepts described herein. Shown is computer system 100, comprising host processor 102, host memory 104, I/O device 106, user interface 108, and network interface 110. Host processor 102, host memory 104 and I/O device 106 are electronically coupled via data bus 112. I/O device typically comprises a connector that plugs into an expansion port on a motherboard of computer system 100. [0016] Computer system 100 may comprise a personal computer or cloud-based server to perform a variety of tasks such as word processing, web browsing, email, web-hosting and certain specialized tasks, such as data encryption and decryption. In some embodiments, block I/O device 106 may comprise a large-capacity SSD for storing large volumes (1 terabyte or more) of data. The term“block” refers to a peripheral device that processes and/or stores data in addressable, fixed-sized blocks. In other embodiments, block I/O device is a specialized encryption/decryption device (throughout this specification, it should be understood that the term“encryption” typically also refers to decryption). The specialized encryption/decryption device may be pre-configured with one or more encryption algorithms and encryption keys. In some embodiments, an encryption key index is used to associate a plurality of encryption keys each with a respective encryption key index value (such as 1, 2, 3, 4...). In this way, host processor 102 may specify a particular encryption key for block I/O device to use without providing the encryption key itself to block I/O device 106.

[0017] Computer system 100 may be used to encrypt data destined for transmission to remote locations or decrypt encrypted data received via network interface 110 from a wide- area data network, such as the Internet. In order to quickly encrypt or decrypt large volumes of data, host processor 102 off-loads computationally-intensive encryption activities to block I/O device 106.

[0018] Processor 102 is configured to provide general operation of computer system 100 by executing processor-executable instructions stored in host memory 104, for example, executable computer code. Processor 102 typically comprises a general purpose microprocessor or microcontroller manufactured by Intel Corporation of Santa Clara, California or Advanced Micro Devices of Sunnyvale, California, selected based on computational speed, cost and other factors.

[0019] Host memory 104 comprises one or more non-transitory information storage devices, such as RAM, ROM, EEPROM, UVPROM, flash memory, SD memory, XD memory, or other type of electronic, optical, or mechanical memory device. Host memory 104 is used to store processor-executable instructions for operation of computer system 100, as well as data destined for encryption, encrypted data, an encryption key index, one or more submission queues, one or more completion queues, and one or more administrative queues (such queues will be explained in more detail later herein). It should be understood that in some embodiments, a portion of host memory 104 may be embedded into processor 102 and, further, that host memory 104 excludes media for propagating signals. [0020] Data bus 112 comprises a high-speed command and data interface between host processor 102 and peripheral devices such as block 170 device 106. In one embodiment, data bus 112 conforms to the well-known Peripheral Component Interconnect Express, or PCIe, standard. PCIe is a high-speed serial computer expansion bus standard designed to replace older PCI, PCI-X, and AGP bus standards. Data bus 112 is configured to allow high speed data transfer between host processor 102 and I/O device 106, such as data storage and retrieval, but may also transport configuration information, operational instructions and related parameters for processing by I/O device 106 as described in greater detail later herein. Data bus 112 may comprise a multi-strand data cable or be embedded into a motherboard of computer system 100.

[0021] Block DO device 106 comprises an internal or external peripheral device coupled to processor 102 and host memory 104 via data bus 112. As shown in FIG. 2, block I/O device 106 comprises a controller 200, a controller memory 202, and a host interface 204. in some embodiments, block I/O device additionally comprises buffer 206, programmable circuitry 208 and/or mass storage 210. Host processor 102 communicates with controller 200 via data bus 112 and host interface 204, wiiich comprises circuitry well known in the art for providing a command and data interface between block I/O device 106 and data bus 112 (in other embodiments, host interface 204 is incorporated into processor 200). Block I/O device 106 may be configured to encrypt data arranged in“blocks”, each sometimes referred to as a physical record, is a sequence of bytes or bits, usually containing some whole number of records, having a maximum length, a block size. In one embodiment, the well-known NVMe data storage and retrieval protocol is used to provide communications between block I/O device 106 and host processor 102 and host memory 104. The NVMe protocol defines both a register-level interface and a command protocol used by host processor 102 to communicate with NVMe-compliant devices. In one embodiment, block I/O device 106 is configured to be NVMe compliant.

[0022] In one embodiment, block I/O device 106 comprises a high-capacity SSD, such as a 1 Terabyte, 16-Channel ONFI-comp!iant NAND SSD with an 800 MBps NVMe interface. In this embodiment, block I/O device comprises a number of mass storage 210 devices in the form of a number of NAND flash memory chips, arranged in a series of banks and channels to store one or more terabytes of encrypted data. In this embodiment, block I/O device 106 performs data storage and retrieval in accordance with the NVMe protocol, and also performs encryption prior to storage (and decryption upon data retrieval), in accordance with one or more modified Vendor Specific Commands defined under the NVMe protocol. Embodiments of the present invention define one or more commands to encrypt and decrypt blocks of data, based on the Vendor Specific Command, as described later herein.

[0023] Controller 200 comprises one or more custom ASICs, PGAs, and/or peripheral circuitry to perform the functionality of block I/O device 106. Such circuitry is well-known in the art.

[0024] Controller memory 202 comprises one or more non-transitory information storage devices, such as RAM, ROM, EEPROM, flash memory, SD memory, XD memory, or other type of electronic, optical, or mechanical memory device. Controller memory 202 is used to store processor-executable instructions for operation of controller 200, as well as one or more encryption keys in an encryption key index. In some embodiments, controller memory 202 is also used to store one or more submission queues, one or more completion queues, and/or one or more administrative queues. It should be understood that in some embodiments, controller memory 202 is incorporated into controller 200 and, further, that controller memory 202 excludes media for propagating signals.

[0025] Host interface 204 comprises circuitry and firmware to support a physical connection and logical emulation to host processor 102 and host memory 104. Such circuitry is well-known in the art.

[0026] Input/Output buffer 206 comprises one or more data storage devices for providing temporary storage for data awaiting encryption or decryption and/or data that has been encrypted/decrypted. Buffer 206 typically comprises RAM memory for fast access to the data. In one embodiment, buffer 206 comprises both an input buffer for temporary storage of unencrypted data prior to encryption and/or after decryption and an output buffer for temporary storage of encrypted data after encryption or prior to decryption. The location and sizes of the buffers are determined in accordance with, in one embodiment, the NVMe protocol.

[0027] Programmable circuitry 208 comprises a programmable integrated circuit, such as an embedded FPGA, embedded video processor, a tensor processor, or the like, which typically comprises a large quantity of configurable logic gate arrays, one or more processors, I/O logic, and one or more memory devices. Programmable circuitry’ 208 offers configurability to implement one or more encryption algorithms, including both symmetric and asymmetric encryption techniques, such as various forms of the well-known Advanced Encryption Standard (AES), Data Encryption Standard (DES), and others. Programmable circuitry 206 may be configured by host processor 102 via controller 200 over data bus 112, using a high-speed data protocol normally used to store and retrieve data with block I/O device 106. Programmable circuitry 208 may be coupled to controller 200 via bus 214, connected to the same data and control lines used by controller 200 to store and retrieve data in mass storage 210, in an embodiment that utilizes such mass storage, as programmable circuitry 208 typically comprises a number of bidirectional i/O data lines, a write enable and a read enable, among others. It should be understood that in other embodiments, programmable circuitry could be incorporated into controller 200. In these embodiments, programmable circuitry 208 may still utilize the same data and control lines used to store and retrieve data from mass storage 210.

[0028] Mass storage 210 comprises one or more non-transitory information storage devices, such as RAM memory, flash memory, SD memory, XD memory, or other type of electronic, optical, or mechanical memory device, used to store data encrypted data. In one embodiment, mass storage 210 comprises a number of NAND flash memory chips, arranged in a series of banks and channels to provide up to multiple terabytes of data. Mass storage 210 is electronically coupled to controller 200 via a number of data and control lines, shown as bus 214 in FIG. 2. For example, bus 214 may comprise a number of bidirectional I/O data lines, a write enable and a read enable, among others. Mass storage 210 excludes media for propagating signals.

[0029] FIG. 3 is another embodiment of computer system 100, showing five interna] block I/O devices 106a-106e, each mechanically coupled to a motherboard of computer system 100 (not shown) and electrically coupled to host processor 102 and host memory’ 104 via data bus 112. Additionally, block I/O device 106f is externally coupled to data bus 112 via a cable typically comprising a number of power, ground and signal wires and having a connector on each end that interfaces to the motherboard and an external connector on I/O device 106f (not shown). In this embodiment, one or more of the block I/O devices can encrypt data in accordance with commands from host processor 102. Host processor 102 may encrypt a large amount of data by assigning two or more of the block I/O devices to encrypt the data, either in parallel or serially. In one embodiment, after encryption, data is immediately stored in host memory 104, where in other embodiments where the block I/O devices comprise mass storage capabilities, the encrypted data is stored by each block I/O device, respectively.

[0030] FIGs. 4A and 4B are flow diagrams illustrating one embodiment of a method performed by host processor 102 and I/O device 106 to encrypt data. The method is implemented by host processor 102 and controller 200, executing processor-executable instructions stored in host memory 104 and controller memory 202, respectively. It should be understood that in some embodiments, not all of the steps shown in FIGs. 4A and 4B are performed and that the order in which the steps are carried out may be different in other embodiments. It should be further understood that some minor method steps have been omitted for purposes of clarity.

[0031] The method is described in reference to the well-known NVM Express protocol (NVMe) over a computer’s PCIe bus, which allows host processor 102 to control block I/O device 106 to perform encryption and decryption and, in some embodiments, to store and retrieve encrypted data.

[0032] NVMe is a storage interface specification for Solid State Drives (SSDs) on a PCIe bus. The latest version of the NVMe specification can be found at www.nvmexpress.org, presently version 1.3, dated May 1, 2017, and is incorporated by reference in its entirety herein. Encryption and decryption commands are provided in the form of modified Vendor Specific Commands, where a format for Vendor Specific Commands is defined by the NVMe protocol and shown below:

Command Format - Admin and NVM Vendor Specific Commands

[0033] Both administrative and I/O Vendor Specific Commands may defined.

[0034] In one embodiment, a modified version of the Vendor Specific Command is defined to cause block I/O device to encrypt data. Such a modified version of the Vendor Specific Command is shown below:

[0035] In one embodiment, each modified, Vendor Specific Command is 64 bytes long, comprising Command Dword 0, a Namespace Identifier field, a reserved field, a Metadata pointer, a Data pointer, a Number of Dwords in Data Transfer field, a Number of Dwords in Metadata Transfer field, and 4 command Dwords. It should be understood that in other embodiments, a different arrangement of the fields and the number of bits per field could be different than what is described in this embodiment. Each Dword, in this example, is four bytes.

[0036] A definition of this modified, Vendor Specific Command is stored in host memory

104 and in controller memory 202 for use by host processor 102 and controller 200, respectively.

[0037] At block 400, processor 102 and controller 200 cooperate with each other to determine a number of initial settings, such as to generate one or more encryption keys, formulate an encryption key index associating the one or more encryption keys each with a respective encryption index key value, to determine a number of submission queues, completion queues, and memory allocations, and/or to allocate physical memory to a number of Namespace IDs. One or more encryption keys may be generated as a one-time event, such as upon power-up of computer system 100 for the first time. The keys may be generated by controller 200 executing a predefined command to generate encryption keys, for example, as defined in the VNMe protocol. The encryption key(s) is/are stored in memory 202 in an encryption index, where each encryption key is associated with a respective encryption key index value (such as 1, 2, 3, 4). The encryption keys themselves are generally not provided to host processor 102 or to host memory 200, for security purposes, while the index values may be provided to processor 102, so that processor 102 knows how to reference the encryption keys generated by controller 200.

[0038] A number of Submission queues and Completion queues (both Admin and I/O) may also be determined by processor 102 and/or controller 200, defining a number of each queue, a memory location for each queue and a size for each queue. The location of each queue may be defined by a particular physical memory (i.e., host memory 104, controller memory 202, and/or input/output buffer 206), and a memory address. Initialization of these queues is described in the NVMe specification, version 1.3.

[0039] Memory allocation may also be determined by processor 102 and controller 200.

For example, an input buffer may be defined as part of buffer 206 located in block PO device 106 for use by host processor 102 to temporarily store data destined for encryption or decryption. An output buffer may also be defined as a portion of buffer 206 used to temporarily store encrypted or decrypted data. Associated buffer sizes and memory addresses may also defined at this time. Such memory allocation is also described by the NVMe specification.

[0040] Memory allocation may additionally comprise defining a number of Namespace IDs, each Namespace ID identifying an area of physical memory (a“namespace”), used by processor 102 and controller 200 to logically separate and manage user data. The physical memory might comprise host memory 102, controller memory 200 and/or input/output buffer 206, a SSD coupled to processor 102, or some other information storage device, or portion thereof, located remotely from computer system 100 and accessed via network interface 110 .

[0041] At block 402, processor 102 receives data to be encrypted, for example, a large text, image or video file from network interface 110 or from user interface 108. Processor 102 stores the data in host memory 104, or in input buffer 206, in one embodiment, as a number of logical blocks. Host interface 204 may be used to aid in the transfer of data, and the data may be stored temporarily in input/output buffer 206.

[0042] At block 404, processor 102 generates an encryption command in accordance with the modified Vendor Specific Command, comprising, in this embodiment, 64 bytes. The encryption command comprises Dword 0, representing an“operation code” or“op code”, occupying bytes 0-3 of the encryption command. In this embodiment, Dword 0 comprises 4 bytes with a value of A3 (hex), comprising a generic command field with a value of 1 (bit), a function field with a value of 010 00 (bits) and a data transfer field with a value of 11 (bit), similar to other opcodes as defined in Figure 8 of the NVMe protocol. As an example, the following table summarizes an opcodes for encrypting and decrypting data:

[0043] The encryption command additionally comprises a Namespace Identification field or Namespace ID field. In one embodiment, this field is 4 bytes long, occupying bytes 4-7 in the encryption command. The Namespace ID field is used to identify a quantity of non volatile memory that may be formatted into logical blocks. For example, sixteen Namespace IDs can be defined, each assigned by controller 200 for use by a particular user. Controller 200 additionally associates each Namespace ID with a portion of a physical memory. In this way, users may only access one portion of the hard drive that has been allocated to each of them. Then, as requests to encrypt and decrypt data are received by processor 102, processor 102 formulates an encryption/decryption command, inserting a Namespace ID into the Namespace ID field in association with the user who submitted a request.

[0044] In one embodiment, the Namespace ID is additionally used to identity an encryption key index value, representing a particular encryption key for use in encrypting/decrypting data. Two or more encryption key index values, along with their respective encryption keys, are stored in association as an encryption key index that is pre-stored in controller host memory 104 and in controller memory 202. Each encryption key index value is associated with a particular encryption key used in connection with an encryption algorithm that is executed by block I/O device 106. In operation, processor 102 determines a Namespace ID associated with data to be encrypted and inserts that Namespace ID into the Namespace ID field of the encryption/decryption command, representing an encryption key index value for encryption/decryption. Block I/O device 106 then encrypts or decrypts data using an encryption key associated with the encryption key index value.

[0045] Bytes 8-15 of the encryption command are reserved for future uses by the NVMe protocol, so processor 102 does not typically assign any value to these bytes. [0046] Bytes 16-23 of the encryption command are used as a pointer to metadata that may be associated with the data stored in host memory 104. Processor 102 does not typically assign any value to these bytes.

[0047] Bytes 24-39 of the encryption command are used as a pointer to the data in host memory 104 or input/output buffer 206 targeted for encryption/decryption by the encryption/decryption command.

[0048] Bytes 40-43 indicate a number of Dwords (amount of data) stored in host memory

104 or input/output buffer 206 destined for encryption/decryption by the encryption/decryption command.

[0049] Bytes 44-47 indicate a number of Dwords in a transfer of metadata from host memory 104 to block I/O device. However, in one embodiment, metadata is typically not used in the data encryption process.

[0050] Bytes 48-63 comprises Dwords 12-15, each Dword 4 bytes long. Dwords 12-15 are combined to form a sixteen-byte address in host memory 104 or input/output buffer 206 where encrypted/decrypted data should be stored.

[0051] At block 406, host processor 102 writes the encryption command to a submission queue stored by host memory 104 or memory 202. The submission queue is a circular buffer with a fixed slot size that host processor 102 uses to submit commands for execution by controller 200. NVMe is based on a paired Submission and Completion Queue mechanism. Commands are placed by host processor 102 into a Submission Queue and completions by controller 200 are placed into an associated Completion Queue. Multiple Submission Queues may utilize the same Completion Queue. Submission and Completion Queues are allocated by host processor 102 and controller 200 in host memory 104 and/or in controller memory 202, as described earlier herein. An Admin Submission Queue (and associated Completion Queue) may exist for purposes of management and control (e.g., creation and deletion of I/O Submission and Completion Queues, aborting commands, etc.).

[0052] At block 408, in response to writing the encryption command to the submission queue, host processor 102 writes a new tail pointer to a hardware doorbell register associated with the submission queue that alerts controller 200 that a command is available for execution in the submission queue.

[0053] At block 410, controller 200 retrieves the encryption command from the submission queue over data bus 112 in accordance with the NVMe protocol. [0054] At block 412, controller 200 identifies the encryption command as an encryption command by comparing the opcode in bytes 0-3 to a list of opcodes stored in controller memory 202.

[0055] At block 414, controller 200 identifies an encryption key index value as the Namespace ID stored in the Namespace ID field (i.e., bytes 4-7 of the encryption command).

[0056] At block 416, in response to identifying the encryption key index value, controller 200 retrieves an encryption key associated with the encryption key index value from an encryption key index stored in controller memory 202.

[0057] At block 418, controller 200 identifies a pointer in the encryption command (i.e., bytes 24-39), pointing to a starting address in host memory 104 or input/output buffer 206 of an amount of data to be encrypted or decrypted. In one embodiment, the amount of data to be encrypted or decrypted comprises a number of blocks of data.

[0058] At block 420, controller 200 identifies a number of Dwords stored in host memory

104 or input/output buffer 206 to be encrypted/decrypted.

[0059] At block 422, controller 200 retrieves the amount of data from host memory 104 or input/output buffer 206, starting at the address provided by the pointer. Host interface 204 may be used to aid in the transfer of data, and the data may be stored temporarily in input/output buffer 206.

[0060] At block 424, controller 200 encrypts the data that was retrieved at block 420, using the encryption key that was retrieved at block 416. In one embodiment, controller 200 performs the encryption, using an encryption algorithm stored in controller memory 202. In another embodiment, controller 200 provides the data to programmable circuitry 208, as well as the encryption key, configured to execute the encryption algorithm using the encryption key to encrypt the data. In this embodiment, programmable circuitry 208 is programmed by host processor 102 over data bus 112 using an Admin Vendor Specific Command.

[0061] The Admin Vendor Specific Command is an administrative command that utilizes the format of the Vendor Specific Command described by Figure 12 in the NVMe specification. In the case where programmable circuitry 110 comprises an FPGA, host processor 102 provides configuration information to controller 200 for controller 200 to manipulate internal link sets of the FPGA in order to execute the encryption algorithm. As an example, the following table defines two opcodes used to identify custom Admin Vendor Specific Commands to configure programmable circuitry 208 to execute a given encryption algorithm:

[0062] In this example, an Encryption Algorithm Download command of 90h is defined to instruct controller 200 to retrieve instructions from host memory 104 for configuring programmable circuitry 208 to perform a particular encryption algorithm, and the Encryption Algorithm Commit command of 94h causes controller 200 to activate the particular Encryption Algorithm. The instructions to configure programmable circuitry 208 are retrieved by controller 200 over data bus 112 in accordance with the NVMe data storage and transfer protocol. Controller 200 then configures programmable circuitry with the instructions that cause programmable circuitry 208 to execute the particular encryption algorithm identified by the Admin Encryption Algorithm Download command.

[0063] At block 426, after the data has been encrypted, controller 200 stores the encrypted data in host memory 104 or in input/output buffer 206, beginning at an address specified in the encryption command, i.e., Dwords 12-15 at bytes 48-63 in the encryption command. In another embodiment, controller 200 stores the encrypted data in mass storage 210 for later retrieval by host processor 102.

[0064] At block 428, controller 200 writes a completion queue entry into a Completion Queue typically stored in host memory 104, indicating successful or unsuccessful completion of the encryption/decryption command. The NVMe specification defines a Completion Queue as a circular buffer with a fixed slot size used to post status for completed commands. A Completion Queue Head pointer is updated by host processor 102 after it has processed Completion Queue entries indicating a last free Completion Queue slot. A Phase Tag (P) bit is defined in the completion queue entry to indicate whether an entry has been newly posted without consulting a register. This enables host processor 102 to determine whether the new entry was posted as part of a previous or current round of completion notifications. Specifically, controller 200 inverts the Phase Tab bit each time that a round of updates through the Completion Queue entries is completed. [0065] At block 430, host processor 102 receives notification of the presence of an entry into the Completion Queue in accordance with the NVMe protocol.

[0066] At block 432, host processor 102 determines if the encryption command was successful or not by evaluating the completion queue entry. Processor 102 may encrypt large amounts of data by providing additional encryption commands to block I/O device 106 in parallel, using up to 64k Submission Queues and up to 64k completion queues. Each queue is capable of storing up to 64k commands. Thus, a large volume of data may be encrypted without consuming excessive host processor resources.

[0067] At block 434, host processor 102 may provide the encrypted/decrypted data from host memory 104 or input/output buffer 206 as identified by a memory address defined by D words 12-15 of the encryption/decryption command, to a remote location over network interface 110 via a wide-area network.

[0068] The methods or algorithms described in connection with the embodiments disclosed herein may be embodied directly in hardware or embodied in processor-readable instructions executed by a processor. The processor-readable instructions may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. In the alternative, the processor and the storage medium may reside as discrete components.

[0069] Accordingly, an embodiment of the invention may comprise a computer-readable media embodying code or processor-readable instructions to implement the teachings, methods, processes, algorithms, steps and/or functions disclosed herein.

[0070] It is to be understood that the decoding apparatus and methods described herein may also be used in other communication situations and are not limited to RAID storage. For example, compact disk technology also uses erasure and error-correcting codes to handle the problem of scratched disks and would benefit from the use of the techniques described herein. As another example, satellite systems may use erasure codes in order to trade off power requirements for transmission, purposefully allowing for more errors by reducing power and chain reaction coding would be useful in that application. Also, erasure codes may be used in wired and wireless communication networks, such as mobile telephone/data networks, local-area networks, or the Internet. Embodiments of the current invention may, therefore, prove useful in other applications such as the above examples, where codes are used to handle the problems of potentially lossy or erroneous data.

[0071] While the foregoing disclosure shows illustrative embodiments of the invention, it should be noted that various changes and modifications could be made herein without departing from the scope of the invention as defined by the appended claims. The functions, steps and/or actions of the method claims in accordance with the embodiments of the invention described herein need not be performed in any particular order. Furthermore, although elements of the invention may be described or claimed in the singular, the plural is contemplated unless limitation to the singular is explicitly stated.