GB2520113A - Virtual bands concentration for self encrypting drives - Google Patents

Abstract

An apparatus comprises a storage device 102 and a host device 105. The storage device is configured to encrypt and decrypt user data during write and read operations, respectively. The host device is configured to communicatively couple to the storage device, and to execute the write and read operations by concentrating a first number of virtual bands into a smaller second number of real bands. The host device may comprise a virtual machine manager 120, which may comprise one or more virtual band managers 122, which may map a number of virtual bands to one or more real bands. The bands may be data bands comprising logical block address ranges. The storage device may comprise a band manager 110 configured to store key material 114. A media encryption key for each real data band may be generated by wrapping an authentication key 104 with the corresponding key material (341 in Figure 3). The invention facilitates the alleviation of band limitation issues for a self encrypting drive in an environment hosting many virtual machines.

Description

VIRTUAL BASES CONCENTRATION

FOR SELF ENCRYPTING DRIVES

Field of the Invention

The invention relates to storage systems generally and, more particularly, to a method and/or apparatus for implementing virtual bands concentration for self encrypting drives.

Background

Self encrypting drives (SEDs) usually employ hardware to encrypt and decrypt user data during write and read operations, respectively. Encryption and decryption are accomplished using a media encryption key (MEK) . The MEK is normally a function of logical block address (LBA), where an entire LEA space is subdivided into several LEA ranges (referred to as "data bands" or simply "bands") with a unique MEK for each band. Because of hardware limitations, the number of bands that an SED can support without serious performance degradation is limited (16 would be a reasonably high number) . Having more active bands than the number of LBA ranges supported by hardware will have a negative effect on performance due to constant key swapping.

From a perspective of a host in a traditional implementation, user data to which the host has access control under a single authentication key (AK) needs to be contiguously stored in a single LBA range. The single L1BA range or band limitation makes it difficult for certain types of applications (like Virtual Machines -VMs) to benefit fully from SED deployment, because VMs might need many (perhaps, thousands) of bands to enable more flexible and efficient usage of the storage device.

It would be desirable to have virtual bands concentration for self encrypting drives.

Summary

According to an aspect of the present invention, there is provided an apparatus as claimed in claim 1. According to another aspect of the present invention, there is provided a method as claimed in claim 11. Embodiments of the present invention seek to provide an apparatus including a storage device and a host device. The storage device may be configured to encrypt and decrypt user data during write and read operations, respectively. The host device is preferably communicatively coupled to the storage device. The host device may be configured to execute the write and read operations by concentrating a first number of virtual bands into a second number of real bands, wherein said second number may be smaller than said first number.

Brief Description of the Fim2res

mbodiments of the invention will be apparent from the following detailed description and the appended claims and drawings in which: FIG. 1 is a diagram illustrating a system in accordance with an embodiment of the invention; FIG. 2 is a diagram illustrating a host portion of a virtual bands concentrator in accordance with an embodiment of the invention; FIG. 3 is a diagram illustrating a storage device portion of the virtual bands concentrator in accordance with an embodiment of the invention; FIG. 4 is a diagram illustrating a process in accordance with an embodiment of the invention; FIG. 5 is a diagram illustrating a virtual band manager with multiple bands in accordance with an embodiment of the invention; and FIG. 6 is a diagram illustrating a ho9t having multiple virtual band managers with one or more bands in accordance with an embodiment of the invention.

Detailed Description of the Embodiments

Embodiments of the invention include providing virtual S bands concentration (VEC) for self encrypting drives that may Ci) implement a virtual band manager (VaN) as part of a virtual machine manager (VMN), (ii) generate media encryption keys on a per input/output (I/C) basis, (iii) support thousands of virtual data bands with hardware encryption/decryption, (iv) facilitate virtual machine migration, (v) enable a crypto erase on a per data band basis, (vi) reduce the number of bands an SED needs to support while still supporting multiple virtual bands on a host side, (vii) concentrate a first number of virtual bands into a significantly smaller second number of real bands, and/or (viii) allow authentication data to be supplied by a host for each read/write operation.

In various embodiments, a method and/or apparatus are provided to generate unique media encryption keys (MEKs) for a plurality of data bands dynamically. The term "data bands" (or simply "bands") generally refers to a range of logical block addresses (LEAs) -an entire LBA space is subdivided into several LEA ranges (bands). Each band is associated with a unique MEK.

The MEKs are based on authentication information dynamically provided by a host (e.g., as part of "metadata" associated with a user authentication operation) -Dynamically genera.ting the MERs generally refers to a process of creating a new key per each I/O S operation. The dynamic generation of MEKs is generally described as "on the fly." In various embodiments, the use of a common authentication key (AK) is allowed across multiple bands to simulate a non-contiguous band of logical block address (ISA) space for host data that needs to be managed with a single authentication key. The key material (e.g., authentication data) is supplied by the host (e.g., a VM Player ar VM Manager-VT.114, etc.) for each read/write operation, which provides a secure method of enabling thousands (or more) of bands.

Referring to FIG. 1, a diagram of a system 100 is shown implementing a virtual bands concentration scheme in accordance with an embodiment of the invention. In various embodiments, the system 100 may be implemented as a self encrypting storage system.

In some embodiments, the system 100 comprises a block 101, a block 103, and a black 105. The block 101 comprises a storage controller implementing a band manager and an encryption/decryption circuit in accordance with an embodiment of the invention. The block 103 implements a storage medium. In some embodiments, the block 103 comprises a non-volatile memory (NVM) media (e.g., magnetic memory, ELASH memory, etc.). However, other types of media (e.g., volatile memory with or without battery support) may be implemented accordingly to meet the design criteria of a particular application. Although, with volatile memory, security (and data) would be lost upon power loss. The block 105 comprises a host implementing a virtual memory manager (VMM) in accordance with an embodiment of the invention. The block 101 and 103 are operatively coupled to form a storage device (SD) 102. The SD 102 and the host 105 are configured to be communicatively coupled to each other.

The controller 101 may be configured to control one or more individual memory channels. En some embodiments, the controller 101 may implement multiple memory channel controller instances to control a plurality of memory channels. The controller 101 has a media interface configured to couple the controller 101 to the storage media 103. In non-volatile memory (NVM) embodiments, the storage media 103 may comprises one or more non-volatile memory devices 107. The non-volatile memory devices 107 have, in some embodiments, one or more non-volatile memory targets (e.g., die, disk platter, etc.) 109, According to a type of a particular one of the non-volatile memory devices 107, a plurality of non-volatile memory targets 109 in the particular non-volatile memory device 107 are optionally and/or selectively accessible in parallel. The non-volatile memory devices 107 are generally representative of one type of storage device enabled to communicatively couple to the controller 101. However, in various S embodiments, any type of storage device is usable, such as magnetic storage, optical storage, SLC (single level cell) NAND flash memory, MLC (multi-level cell) NM4D flash memory, TLC (triple level cell) NAITh flash memory, NOR flash memory, electrically programmable read-only memory (EPROM), static random access memory (SRAN), dynamic random access memory (DRAM), magneto-resistive random-access memory (MILAN), ferromagnetic memory (e.g., PeRP,N, F-PAN, FRAN, etc.). phase-change memory (e.g., PRAM, PCRAM, etc.), racetrack memory (or domain-wall memory (DWMH, resistive random-access memory (RRAM or ReRAN), or any other type of memory device or storage medium.

In some embodiments, the controller 101 and the non-volatile memory media 103 are implemented on separate integrated circuits (or devices). When the controller 101 and the non-volatile memory media 103 are implemented as separate integrated circuits (or devices), the media interface of the controller 101 is generally enabled to manage a plurality of data input/output (I/o) pins and a plurality of control I/o pins. The data I/O pins and the control I/O pins may be configured to connect the device containing the controller 101 to the external devices farming the non-volatile memory media 103. In various embodiments, the controller 101 is implemented as an embedded controller. In S various embodiments, the controller 101 and the WIN media 103 implement a solId state hybrid hard disk drive (SSHD), a hard disk drive (HDD), or a solid-state drive/disk (SSD).

The controller 101 also has a command interface configured to receive commands and send responses to the host 105.

In embodiments implementing a plurality of non-volatile memory devices, the controller 101 includes at least one NW control processor that manages the non-volatile memory devices via proprietary processes, and a host processor that manages the host interface according to other processes. The NVM control processor(s) and the host processor communicate via predetizied interfaces. The host processor communicates host commands to the NVM control processor, which processes the commands according to predefined communication interfaces (or protocols) The controller 101 also includes a band manager (BM) 110 and an encryption/decryption CE/fl) block (or circuit) 112 configured to implement a virtual bands concentration scheme in accordance with an embodiment of the invention. The band manager 110 includes a

S

key storage (KS) 114 that stores key material (1CM) used by the storage device 102. In some embodiments, the key storage 114 may also store virtual key material (VKM) used by the host 105.

The host 105 includes a virtual machine manager (VMM) block 120. The VMM 120 is configured to implement a virtual bands concentration scheme in accordance with an embodiment of the invention. The VMM 120 comprises one or more virtual band managers (VBMs) 122. In some embodiments, the VMM 120 runs a separate VEM 122 instance for each real band. Each VM 122 includes a virtual key storage Wi(S) 124 that stores virtual key material (VIM) -Each VBM 122 concentrates a plurality of virtual bands (yEs) into a real band 130 for storage on the SD 102. The plurality of virtual bands received by each VBM 122 are from a number of virtual machines (VMS) running on the host 105 that are associated with each VEM 122 by the 11MM 120. A single VBM 122 can manage one or more real bands. Each VEM 122 authenticates itself to the storage device 102 by providing a respective authentication key (AK) 104.

Referring to FIG. 2, a diagram of the host 105 is shown illustrating a host portion of a virtual bands concentrator in accordance with an embodiment of the invention. Embodiments of the invention are described below using a generic security paradigm which may be used in several security protocols including, but not limited to TCG Enterprise SSC, TCG Opal and ATA security. In various embodiments, self encrypting drives WEDs) operate on logical block address (LEA) ranges (or data bands). For example, a band 130 having a LBA range of LBA1.1 to LRA1.2 is shown in FIGS. 2 and 3. In various embodiments, the host 105 may run some sort of security application (A?) that authenticates itself with the storage device (SD} 102, using an authentication key (AK) 104.

Tn a conventional SED, the nunther of bands is limited, because to maintain data rate, LBA range lookup is often implemented in hardware and hardware tables are limited in size.

So conventional SEDs rarely support more than 16 LBA ranges without performance impact. While this figure is quite enough for most applications (e.g., TCG Opal 2.0 as1cs just f or 8 bands), it creates difficulties for the very popular Virtual Machines (VM) environment.

In some embodiments, a single computer can host multiple so-called Virtual Machines (VMS), each of which needs some range of LBAs for respective operations (e.g., FIG. 2 shows three virtual machines, VMs 311, 312, and 313, running on the host 105). From the perspective of each virtual machine 311-313 (e.g.. labeled VM-x, x=l,2,..j, each VN-x might use LEAs from 0 to LEA_MAX(x) where x is the number of the VM. The LBAs used by the VMs are called "Virtual LEAs" (VLBAs) to distinguish them from the real L871⁄4s, known to the storage device 102. The VM Manager (1MM) 120 is responsible for mapping the VLBAs into the real LBAs that the storage device 102 can understand.

Because VMs are created and deleted all the time, allocating a contiguous real LEA range for each VII is not always possible. Instead, a set of bands is allocated, "sliced' arbitrarily out of the real LEA space of the storage device 102.

Thus, as shown in the example in FIG. 2, two Virtual Bands (VBs) 320 and 321 of the virtual machine VM-l are mapped into the single real LEA band 130, In general, the number of real bands is smaller than the number of virtual bands, and in many cases the number of real bands can be significantly smaller than the number of virtual bands. For example, between ten and twenty real bands would be considered a reasonably high number of real bands, while the number of virtual bands needed by a particular application could be in the hundreds, the thousands, or an even greater number. Thus, the number of real data bands and the number of virtual data bands could differ, for example, by one or more orders of magnitude.

Each VM 311-313, acting almost as an individual host, can authenticate itself with the storage device 102 with the help of the VEIl 122, which performs the translation between the virtual LBAs and the real LBAs, and vice versa. Implementation of the VEM 122 is in accordance with the same security standards as the implementation of the EM 110 of the storage device 102, especially with regard to VICS maintenance and access.

£ The VBM 122 authenticates the VMs 311-313 and provides the authentication key (AX) 104 and security protocol (e.g., TCG or any other) termination to the storage device (Sn) 102. On the host side, the VEM 122 may be configured to support any number of virtual bands (VBs). On the storage device side, the IBM 122 may support only a few real data bands into which the VBM 122 consolidates or concentrates multiple virtual bands as explained below. In many embodiments, the VM 122 is configured to support just one storage device side (real) data band 130 as shown on the FIG. 2.

In some embodiments, the VBM 122 persistently saves the virtual key Storage (VKS) 124 itself, for example, on a separate flash device or LEPROM. The VKS 124 stores virtual key material (VKM) for each virtual band (e.g., virtual key material VKM1.l 381 and ViUfl.2 382 are shown in FIG. 2 for VS1.1 and VE1.2, respectively) . In other embodiments, the storage device 102 provides a so-called opaque key storage (al(S) 362 (illustrated in FIG. 3) to store the virtual key material. The ORG 362 is called "opaque" because the SD 102 has no knowledge of the virtual bands and, therefore, does not know that the OKS 362 contains any key material. As far as the SD 102 is concerned, the OKS 362 is just another block of data.

Storing the virtual key material in the ORB 362 located in the SD 102 facilitates VM migration from one host to another host. As long as VMM credentials (e.g., the AK 104) are known, the VN}4 120 can restore the respective VKS 124 on another host using content 389 from the OKS 362. The SD 102 is oblivious as to the type of information saved in OKS 362. When the VEM 122 changes any of the virtual key materials (e.g., VKI41.l 381, VKM1,2 382, etc., the entire OKS 362 is rewritten and the old copy is zeroized (e.g., the SD 102 needs to provide this type of service upon a host request).

Referring to FIG. 3, a diagram of the storage device 102 is shown illustrating a storage device portion of a virtual bands concentrator in accordance with an embodiment of the invention. In various embodiments, the SD 102 runs the band manager (BM) application 110, containing the key storage (KS) 114. It is important to keep in mind that when the KS 114 is overwritten, all older copies of the 1(5 114 need to be sanitized, or zeroized (e.g., the sanitization procedure depends on the type of the storage media 103 and may inc1ude but is not limited to, degaussing of the magnetic media, erasing the flash device, etc.). In some embodiments, the KS 114 contains one sample of key material (1(M) 361 for each real data band. A single sample of key material 361 (KM1) for the band 130 is shown in FIG. 3.

A media encryption key (MEK) 341 for each real data band is generated by "wrapping" the AX 104 with the corresponding KM.

An example of generating a media encryption key Mfll by wrapping AK 104 and key material KM1 is shown in FIG. 3. The wrapping 1.0 operation is illustrated by a multiplier 351. Wrapping is used here in a very generic sense. In some embodiments, the KM 361 is simply the correspondent MEK, encrypted with the AX 104 (e.g., the AK 104 is used as a key encryption key (KEK), so "wrapping" 351 is equivalent to an encryption operation). Encryption/decryption may include, but is not limited to, some version of AES or XTS. In some embodiments, wrapping may include, but is not limited to, performing an XOR between the AK 104 and the key material 361 (e.g., K'I1 in FIG. 3). However, any operation that does not reduce randomality of the key material 361 nay be implemented accordingly to meet the design criteria of a particular application. In multi-band embodiments1 respective MEKs (e.g., MEK1, ?IEK2 MEKn) are generated for each of n bands by wrapping the AK 104 with the respective key material 361 (e.g., XMl, KM2, . .., xn) In various embodiments, the Encryptor/Decryptor (ED) 112 is implemented as a hardware (RW) module. The ED 112 maintains a S table where boundaries of each band (e.g. LBA1.1-LBA1.2 for band shown in FIG. 3) are defined. The Mfl 341 for each band is calculated by the wrapping operation 351 based on the AX 104 and correspondent key material 361, then loaded into the ED 112. In these embodiments, when read/write data requests 311 arrive from the host 105, the ED 112 performs a lookup to classify the LBAs of the request to a data band and to select the appropriate MElt 341 (e.g., MEX1 f or real band 130). In a conventional SED, read data would be decrypted with the selected MEK, while write data would be encrypted with the selected MEK. In virtual bands concentration embodiments, the selected MElt 341 is not used to encrypt/decrypt data, but rather the selected MElt 341 is used to calculate an actual MElt (e.g., MEK11 344, MEK1.2 345, MEK3.1 347, MEK3.2 349, etc.) used for encryption/decryption of each I/C) request by wrapping operations 342-348. The wrapping operations 342-348 may be implemented similarly to the wrapping operation 351 (described below).

In various embodiments, the MEK 341 is not sent to the host 105 and (as a good practice) is not stored on the media 103 in plain form. Instead, only key material KM 361 is stored and the authentication key (AK) 104 is needed to recover the MEK 341.

provided that the SD 102 is configured properly, reading or writing data from/to the media 103 is not possible for anyone who does not know the correct credentials.

In some embodiments, a cryptoerase of each individual band is allowed. For example, when a user changes the KM 361 or the 11KM 381,382 for a particular band and all old copies of the KM 361 or the VKM 381,382 (even encrypted ones) are sanitized according to the particular media sanitizing rules (e.g., degauss for magnetic media, erase for flash, etc.), the data in the particular band cannot be read anymore by anyone1 including anyone knowing the correct credentials. A so-called "Crypto_Erase" function provides a fast, reliable and precise method for data removal and allows for sate storage device reuse.

In virtual band concentration embodiments, the VBM 122 authenticates itself, using the AK 104, with the SD Band Manager (BM) 110. After authentication, the VBM 122 loads the respective WE 124 either from another device or from the OKS 362. Each of the VMs 311-313 will need to authenticate itself using a respective authentication key (e.g., VM-1 311 authenticates itself using AlCi 304, VM-3 313 authenticates itself using AK3 305, an so forth) Respective virtual MEKs (VMEKs) 384, 386, 387, 388 are generated for each Virtual Band (1/B) by wrapping (e.g. respective wrapping operations 383, 385, etc.) the respective authentication key AKx with the appropriate virtual key material (e.g., VKM1.1 381, VKM1.2 382, etc.). The corresponding VMEIC is attached to each i/o request being sent to the SD 102. The ED 112 wraps the VMEIC attached to each I/O request with the MEK 341 for the data band (e.g.. MEK1 is used for data band 130 shown in FIGS. 2 and 3), creating individual MEKs (e.g., MEK1.1, MEK1.2, MEK3.1, MEK3.2, etc.) for the particular data operations.

In NVM Express (NVME) host protocol embodiments, a vendor specific read/write could be defined in which a special SGL (Scatter-Gather List) is provided. The SGL contains the VMEK information for each I/o operation. In the SATA protocol, the host may simply append the VMEK to a write command. either by extending the number of sectors in a write and indicating where the key is being provided or transferring larger sectors (e.g., 520 Byte sectors) and putting the key material into the larger sectors themselves. Reading is more difficult to I it into the existing SATA (ACS) protocol. In one example, a vendor unique command may be defined that allows transferring the VMEK with the LEA to be read. In another example, the host may transfer a table of VMEK into a buffer resident in the storage device and use the reserved bits (7 total) to index into the table for the storage device to S look up the VMEI< quickly on a transfer. This embodiment allows use of existing SArA HW automation in the controllers.

Ref erring to FIG. 4, a diagram is shown illustrating an example process 400 in accordance with an embodiment of the invention. In some embodiments, the process (or method) 400 may comprise a step (or state) 402, a step (or state) 404, a step (or state) 406, a step (or state) 408, a step (or state) 410, and a step (or state) 412. In the step 402, the virtual band manager (VBM) 122 in the host los authenticates itself using the authentication key (AK) 104 with the band manager (SM) 110 in the storage device 102. In the step 404, VEM 122 loads the virtual key storage (VKS) 124 either from another device or from the opaque key storage (0Kg) 362 in the storage device 102. tn the step 406, each virtual machine (VMx) authenticates itself using a respective authentication key (AXx). In the step 408, virtual media encryption keys (VMEKs) are generated for each v±rtual band (yE) by wrapping the respective authentication keys AXx with a respective virtual key material (e.g., VKNx) from the VKS 124. In the step 410, the appropriate VMEK is attached to each I/o request being sent to the storage device 102. In the step 412, the encryption/decryption hardware 112 in the storage device 102 wraps the VMEK attached to each I/O request with the media encryption key (MEK) generated in the storage device 102 for the corresponding data band, creating an individual MEK for the particular data operation.

Referring to FIG 5, a diagram is shown illustrating a system 500 implementing a virtual band manager with multiple real bands in accordance with an embodiment of the invention. The system 500 comprises a storage device 502 with storage media 503 and a host 505. The storage device 502 also includes a band manager (SM) 510 and an encryption/decryption (/D) block (or circuit) 512 configured to implement a virtual bands concentration scheme in accordance with an embodiment of the invention (described above in connection with FIGS. 2 and 3). The encryption/decryption (B/fl) block 512 is configured to handle a number of real bands 130- 1 to 130-N. The band manager 510 includes a key storage (KS) 514 that stores key material (e.g., KM1 561 to KMN 562). The key material is used by the storage device 502 in connection with the encryption/decryption of the real bands 130-1 to 130-N (e.g., using respective media encryption keys generated by wrapping operations 551 to 552). The wrapping operations 551 to 552 may be implemented similarly to the wrapping operations 351, 383 and 385 described above in connection with FZGS. 2 and 3).

The host 505 includes a virtual machine manager (VMM) S configured to implement a virtual bands concentration scheme in accordance with an embodiment of the invention. The V}'IM comprises a virtual band manager (VEM) 522. The YSM 522 is configured to manage the plurality of real bands 130-1 to 130-N. The 1/EM 522 may be configured to operate similarly to the lIEN 122 of FlO. 2. The ITEM 522 concentrates a plurality of virtual bands (yEs) into the real bands 130-1 to 130-N for storage on the SD 502. The plurality of virtual bands received by the ITEM 522 may come from a number of virtual machines (VMs) running on the host 505.

Referring FIG. 6, a diagram is shown illustrating a system 600 implementing a host with multiple virtual band managers in accordance with an embodiment of the invention. The system 600 comprises a storage device 602 with storage media 603 and a host 605. The storage device 602 also includes a band manager (EM) 610 and an encryption/decryption (/]D) block (or circuit) 612 configured to implement a virtual bands concentration scheme in accordance with an embodiment of the invention (described above in connection with FIGS. 2 and 3). The encryption/decryption (E/D) block 612 is configured to handle a number of real bands 130-1 to 130-N. The band manager 610 includes a key storage (KS) 614 that stores key material (e.g., KM1 661 to KMN 662). The key material is used by the storage device 602 in connection with S encryption/decryption of the real bands 130-1 to 130-N (e.g., using respective media encryption keys generated by wrapping operations 651 to 652). The wrapping operations 651 to 652 may be implemented similarly to the wrapping operations 351, 383 and 385 described above in connection with PIGS. 2 and 3).

The host 605 includes a virtual machine manager (VMM) configured to implement a virtual bands concentration scheme in accordance with an embodiment of the invention. The VMM comprises a plurality of virtual band managers (VDMs) 622-1 to 622-N. The VBMs 622-1 to 622-N are configured to manage the plurality of real bands 130-1 to 130-N. The \TBMs 622-1 to 622-N may be configured to operate similarly to the VBM 122 of FIG. 2. The VBMs 622-1 to 622-N concentrate a plurality of virtual bands (lJBs) into the real bands 130-1 to 130-N for storage on the SD 602. The plurality of virtual bands received by the VBMs 622-1 to 622-N may come from a number of virtual machines (VMS) running on the host 605.

Each of the VBMS 622-1 to 622-N may concentrate a number of virtual bands into one or more of the real bands 130-1 to 130-N.

Each of the VBMs 622-1 to 622-N authenticates itself with a respective authentication key AR]. to ARM. The band manager 610 of the storage device 602 generates the respective media encryption keys for the bands 130-1 to 130-N by wrapping the respective authentication keys AK1 to AKN and the respective key material KN1 66]. to KMN 662, The terms "may" and "generally" when used herein in conjunction with "is(are)" and verbs are meant to communicate the intention that the description is exemplary and believed to be broad enough to encompass both the specific examples presented in the disclosure as well as alternative examples that could be derived based on the disclosure. The terms "may" and "generally" as used herein should not be construed to necessarily imply the desirability or possibility of omitting a corresponding element.

The term "significantly smaller" is generally meant to communicate the intention that the items compared may differ, for example, by one or more orders of magnitude.

While the invention has been particularly shown and described with reference to embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made without departing from the scope of the invention.

The disclosures in United States patent application nos.

14/033,753 and 61/870,936, from which this application claims priority, and in the abstract accompanying this application are incorporated herein by reference.

Claims (17)

1. CLAIMS1. An apparatus comprising: a storage device configured to encrypt and decrypt user data during write and read operations, respectively; and a host device configured to communicatively couple to said storage device, said host device further configured to execute said write and read operations by concentrating a first number of virtual bands into a second number of real bands, wherein said second number is smaller than said first number.
2. 2. The apparatus according to claim 1, wherein said host device comprises a virtual machine manager configured to map said first number of virtual bands to said second number of real bands.
3. 3. The apparatus according to claim 1 or 2, wherein said virtual machine manager comprises one or more virtual band managers configured to map said first number of virtual bands to said second number of real bands.
4. 4. The apparatus according to claim 1, 2 or 3, wherein each of said one or more virtual band managers is configured to map a number of said virtual bands to one or more of said second number of real bands.
5. 5. The apparatus according to any preceding claim, wherein said storage device comprises a band manager configured to store key material.
6. 6. The apparatus according to claim 3 or claim 4 or 5 when dependent on claim 3, wherein said band manager comprises an opaque key storage.
7. 7. The apparatus according to any preceding claim, wherein said storage device comprises an encryption and decryption module.
8. 8. The apparatus according to any preceding claim, wherein said encryption and decryption module is implemented in hardware.
9. 9. The apparatus according to any preceding claim, wherein each virtual band is still fully protected from a security perspective with unique authentication and encryption keys.
10. 10. The apparatus according to any preceding claim, wherein said second number is significantly smaller than said first number.
11. 11. A method of concentrating a number of virtual bands into a real band for storage on a self encrypting storage device, said method comprising: associating one or more portions of a virtual logical block address range of each of said number of virtual bands with portions of a logical block address range of said real band; generating a respective virtual media encryption key for each of said number of virtual bands based upon an authentication key of a virtual machine and virtual key material stored on a host device running said virtual machine; and associating the respective virtual media encryption key for a particular one of said number of virtual bands with I/O requests involving portions of the logical block address range of said real band associated with the particular one of said number of virtual bands.
12. 12. The method according to claim 11, further comprising: generating a first media encryption key for said real band based upon an authentication key of said host device and key material stored on said self encrypting storage device; and generating a number of second media encryption keys for said I/o requests involving portions of the logical block address range of said real band associated with the particular one of said number of virtual bands based on said first media encryption key and each of the respective virtual media encryption keys associated with the I/O requests.
13. 13. The method according to claim 12, further comprising: encrypting data associated with write I/O requests using said second media encryption keys prior to writing said data on a storage medium; and decrypting data associated with read I/O requests using said second media encryption keys after reading said data from said storage medium.
14. 14. The method according to claim 11, 12 or 13, wherein a first number of virtual bands are concentrated into a second number of real bands, where said second number is smaller than said first number.
15. 15. The method according to claim 14, wherein said second number is significantly smaller than said first number.
16. 16. An apparatus as herein described and as illustrated in the accompanying drawings.
17. 17. A method as herein described and as illustrated in the accompanying drawings.