Using a "Type" encryption key with a Key-Par-IO compatible device

Abstract

A device implementation method according to one aspect of the present invention comprises the step of receiving a command having an address field of a predetermined length. A first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of several type keys associated with different data types. The external key identified by the first subset of bits is obtained. The type key corresponding to the second subset of bits is also obtained. The tenant and type keys are combined to create a combined key used to encrypt and / or decrypt the data associated with the command. (Figure 2)

Description

Background Art

[0001] The present invention relates to Key Per IO (KPIO), and more specifically, to techniques and systems that enable the specification of key types for use with KPIO-compatible devices.

[0002] Modern data centers may employ Encryption-Capable Drives (ECDs). ECDs are encryption-capable regardless of whether they are of the self-encrypting drive (SED) type and regardless of the storage technology (e.g., solid state drive (SSD), hard disk drive (HDD), hybrid drive that includes both solid state and hard disk technologies, or alternative non-volatile storage technology drives).

[0003] Data on an ECD can be encrypted and decrypted using a Media Encryption Key (MEK) that is simply a media encryption key created by a given tenant or a unique key created by combining the ECD's encryption key with a unique encryption key created for the given tenant, where the tenant can be an individual, server, virtual machine (VM), container, etc. Thus, each particular tenant storing data on a shared ECD cannot gain access to the data of other tenants.

[0004] The term "cryptographic erasure" generally refers to destroying the encryption key necessary to decrypt data in some way, or permanently disabling access to it. This can be done, for example, by erasing all copies of the encryption key, removing parts of the encryption key, or disabling access to the associated keys necessary to generate or unwrap the encryption key. By permanently disabling the encryption key, data encrypted with that key cannot be decrypted; the encrypted data becomes effectively undecryptable.

[0005] Encryption erasure can be performed at the drive level, for example, by permanently invalidating all copies of the encryption key used by the drive on which all data is stored. Encryption erasure can also be performed at the user level, for example, by permanently invalidating the user's encryption key. However, invalidating a user's encryption key will render all data associated with that user unreadable.

[0006] The problem is that encryption devices can often only process a subset of keys simultaneously, the number necessary to provide adequate granularity for all desired types of cipherdecryption. One example of this is the Key Per IO (KPIO) standard developed by the Key Per IO (KPIO) subgroup of the Trusted Computing Group's Storage Working Group.

[0007] KPIO currently allows a 16-bit NVMe header field to specify which key should be used to encrypt and / or decrypt a given host write and / or read. This potentially allows a KPIO-compliant ECD or other KPIO-compliant cryptographic device to handle up to 2^16 = 65,536 keys simultaneously. Each of these keys can be thought of as a corresponding tenant external key (Kext), and will be referred to as such here. However, most KPIO-compliant ECDs (whether HDDs or SSDs) are actually only capable of holding and / or handling a maximum of several thousand keys simultaneously. For example, a conventional KPIO-compliant ECD is estimated to be able to hold a maximum of 4,096 different keys.

[0008] Those 4,096 keys could be used to adapt to 4,096 different tenants simultaneously. However, it is necessary to imagine that each of those tenants will handle different types of data, such as data with different levels of confidentiality, or data with different levels of privacy, or data related to different projects that need to remain separate from one another.

[0009] In this example, we assume that a given tenant has 16 different types of data it can process. To ensure that all of the given types of data are independently encrypted, we need to start by assigning multiple keys per tenant for all tenants. In the given example, to enable independent encryption of up to 16 different types of data, we need to use up to 16 keys per tenant. Such multiple key assignments quickly exhaust the available key space. If a given KPIO-compliant device can only hold 4,096 different keys at a time, and needs to hold up to 16 keys per tenant, then that device can only accommodate 4,096 / 16 = 256 different tenants.

[0010] A trade-off may occur (for example, by limiting the number of data types to 8, allowing a device capable of handling 4,096 keys to accommodate a maximum of 512 tenants), but accommodating more data types directly reduces the number of tenants that a device can handle. [Overview of the Initiative]

[0011] A device implementation method according to one aspect of the present invention comprises the step of receiving a command having an address field of a predetermined length. A first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types. The external key identified by the first subset of bits is obtained. The type key corresponding to the second subset of bits is also obtained. The tenant and type keys are combined to create a combined key used to encrypt and / or decrypt the data associated with the command.

[0012] The methodology described above allows a device capable of processing a smaller number of keys simultaneously to adapt to approximately the same number of tenants as the number of keys, while also enabling the use of unique keys for different data types for each tenant, as if the device were capable of processing many times more keys. The methodology also enables, as will be explained in more detail below, the cryptographic erasure of specific types of data for all tenants.

[0013] Data types may include privacy types, confidentiality types, etc. As described above, the methodology here allows for the use of specific keys for such data types.

[0014] In one preferred approach, the command is a Non-Volatile Memory Express (NVMe) compliant command. This methodology enables the use of NVMe commands to specify the type key.

[0015] The device can be configured as a KPIO-enabled device. This methodology provides new functionality for KPIO-enabled devices.

[0016] In one method, the procedure comprises the steps of accessing an internal key stored within the device, generating a unique medium encryption key using the internal key and a combined key, and encrypting and / or decrypting the data associated with the command using the medium encryption key. This feature adds an additional layer of security, as the internal key is required to access the data stored in the device. Furthermore, cryptographic erasure can be performed on the device simply by destroying the internal key, and the MEK if it is stored in the device. Also, if the MEK is created by a combination of a tenant key, a type key, and an internal key, the MEK can be cryptographically erased by destroying its tenant key, its type key, or its internal key. Thus, in this latter example, cryptographic erasure can be performed at three different levels of granularity, depending on which key is destroyed.

[0017] Preferably, the device is configured to prohibit the transfer of the internal key outside the device in any form. This ensures that all data encrypted using the internal key is invalidated by cryptographic erasure performed at the device level.

[0018] In one method, multiple external keys are individually associated with unique data stored in different locations within the same logical block address range. This feature allows tenants to share the same storage area without the risk of one tenant being able to access another tenant's data. Therefore, even if tenants share an address space, other tenants cannot decrypt the first tenant's data without the first tenant's external key.

[0019] In one method, the cryptographic erasure of all data associated with a tenant is carried out by destroying the external key used by the tenant. This is an effective means of erasing the data of that tenant.

[0020] In one method, the cryptographic erasure of a particular type of data for all tenants is performed by destroying the type key associated with that particular type of data. This is an effective means of cryptographically erasing all of a particular type of data. This ensures that the cryptographic erasure of all data of that type can be performed simply by completely deleting its type key.

[0021] When using dedicated address bits, a null sequence in the second subset of bits indicates setting (e.g., importing) and / or deleting (e.g., removing all copies of the key in the ECD) an external key for a given tenant. This has the effect of enabling the setting and / or deletion of an external key for a given tenant.

[0022] In a preferred approach, type keys are generated outside the ECD. Type keys can be supplied to the ECD as needed from, for example, a key manager infrastructure, key store, etc. This allows for further control over the provision of type keys to the ECD, thereby enhancing security. It should be noted that type keys can, in effect, be dynamically assigned by, for example, some software that classifies data in any given I / O into data types.

[0023] In alternative methods, the type key is generated within the device and stored only within the device. This ensures that cryptographic erasure can be performed simply by deleting the type key within the device, and that there is no possibility of the type key being obtained from outside the device. This provides further control over the distribution of the type key. If the type key is prohibited from leaving the device, deleting the type key from the device ensures the cryptographic erasure of data encrypted with it.

[0024] A device implementation method according to another aspect of the present invention comprises the steps of generating a command having an address field of a predetermined length, wherein a first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types. The command is sent to a key-pass-IO-enabled device configured to encrypt and / or decrypt the data associated with the command using a combination key generated from the external key and the type key associated with the second subset of bits.

[0025] The methodology described above allows a device capable of processing a smaller number of keys simultaneously to adapt to approximately the same number of tenants as the number of keys, while also enabling the use of unique keys for different data types for each tenant, as if the device were capable of processing many times more keys. The methodology also enables, as will be explained in more detail below, the cryptographic erasure of specific types of data for all tenants.

[0026] Data types can include privacy types, confidentiality types, and so on. The methodology here enables the use of specific keys for such data types.

[0027] In one preferred approach, the command is a Non-Volatile Memory Express (NVMe)-compliant command. This methodology enables the use of NVMe commands to specify type keys.

[0028] In one approach, the cryptographic erasure of all data corresponding to a tenant is required by demanding the destruction of an external key stored in a key-per-IO device. This is an effective means for cryptographic erasure of the tenant's data.

[0029] In one approach, the cryptographic erasure of a specific type of data for all tenants is required by demanding the destruction of the type key for that specific type of data. This is an effective means for cryptographic erasure of all of a specific type of data.

[0030] A computer program product comprises a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a device configured to perform data operations on the storage medium, and causing the device to execute any of the methodologies presented herein.

[0031] A system according to various aspects of the present invention includes a key-per-IO device, the device having a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic being configured to cause the device to execute any of the methodologies presented herein.

[0032] The various techniques described herein are applicable to many types of storage media including non-volatile memory and magnetic recording tape.

[0033] Other aspects and techniques of the present invention will become apparent from the following detailed description, which, when read in conjunction with the drawings, illustrate by way of example the principles of the invention. [Brief explanation of the drawing]

[0034] [Figure 1] This is a diagram of a computing environment according to one aspect of the present invention.

[0035] [Figure 2] This is a diagram of a hierarchical data storage system according to one aspect of the present invention.

[0036] [Figure 3] This is a flowchart of a method according to one aspect of the present invention.

[0037] [Figure 4] This is a flowchart of a method according to one aspect of the present invention.

[0038] [Figure 5] This is a flowchart of a method according to one aspect of the present invention.

[0039] [Figure 6] This is a flowchart of a method according to one aspect of the present invention.

[0040] [Figure 7] This is a flowchart of a method according to one aspect of the present invention. [Modes for carrying out the invention]

[0041] The following description is provided for illustrative purposes only to illustrate the general principles of the present invention and is not intended to limit the concepts of the invention claimed herein. Furthermore, certain features described herein can be used in combination with other described features in each of the various possible combinations and substitutions.

[0042] Unless otherwise specifically defined herein, all terms shall be given the broadest possible interpretation, including the meaning implied by the specification, the meaning understood by those skilled in the art, and / or the meaning defined in dictionaries, papers, etc.

[0043] When used herein and in the appended claims, it should be noted that the singular forms “a,” “an,” and “the” also include plural references unless otherwise specified. When used herein, the terms “comprises” and / or “comprising” specify the presence of the described features, integers, steps, actions, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, actions, elements, components, and / or groups thereof.

[0044] This specification discloses several preferred methods of systems, methods, and computer program products (e.g., ECDs, computers, key servers, etc., any of which may be described as “computers” elsewhere in this specification) for dramatically increasing the number of keys that can be processed per tenant by a key-per-IO-enabled device. For example, a device capable of processing only about 4,096 keys simultaneously could potentially accommodate about 4,096 tenants and, furthermore, use a unique key for each of 16 (or a somewhat smaller, greater-than-1) different data types for each of those 4,096 tenants, as if the device were capable of processing about 65,536 keys. In a preferred embodiment, only the number of address bits necessary to address all the different tenants are used for that purpose, and the remaining available address bits are used to address “type” keys. Thus, the full number of addressing bits provided by the relevant specification may be used to simultaneously indicate tenants and data types. For example, under the NVMe specification, which allows 16 bits for the address field in the command header, a 12-bit address field may be used to identify the tenant, and a 4-bit address field may be used to identify the type of data in the underlying read or write requested by the command.

[0045] A device implementation method according to one aspect of the present invention comprises the step of receiving a command having an address field of a predetermined length. A first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types. The external key identified by the first subset of bits is obtained. The type key corresponding to the second subset of bits is also obtained. The tenant and type keys are combined to create a combined key used to encrypt and / or decrypt the data associated with the command.

[0046] The methodology described above allows a device capable of processing a smaller number of keys simultaneously to adapt to approximately the same number of tenants as the number of keys, while also enabling the use of unique keys for different data types for each tenant, as if the device were capable of processing many times more keys. The methodology also enables, as will be explained in more detail below, the cryptographic erasure of specific types of data for all tenants.

[0047] Data types may include privacy types, confidentiality types, etc. As described above, the methodology here allows for the use of specific keys for such data types.

[0048] In one preferred approach, the command is a Non-Volatile Memory Express (NVMe) compliant command. This methodology enables the use of NVMe commands to specify the type key.

[0049] The device can be configured as a KPIO-enabled device. This methodology provides new functionality for KPIO-enabled devices.

[0050] In one method, the procedure comprises the steps of accessing an internal key stored within the device, generating a unique medium encryption key using the internal key and a combined key, and encrypting and / or decrypting the data associated with the command using the medium encryption key. This feature adds an additional layer of security, as the internal key is required to access the data stored in the device. Furthermore, cryptographic erasure can be performed on the device simply by destroying the internal key, and the MEK if it is stored in the device. Also, if the MEK is created by a combination of a tenant key, a type key, and an internal key, the MEK can be cryptographically erased by destroying its tenant key, its type key, or its internal key. Thus, in this latter example, cryptographic erasure can be performed at three different levels of granularity, depending on which key is destroyed.

[0051] Preferably, the device is configured to prohibit the transfer of the internal key outside the device in any form. This ensures that all data encrypted using the internal key is invalidated by cryptographic erasure performed at the device level.

[0052] In one method, multiple external keys are individually associated with unique data stored in different locations within the same logical block address range. This feature allows tenants to share the same storage area without the risk of one tenant being able to access another tenant's data. Therefore, even if tenants share an address space, other tenants cannot decrypt the first tenant's data without the first tenant's external key.

[0053] In one method, the cryptographic erasure of all data associated with a tenant is carried out by destroying the external key used by the tenant. This is an effective means of erasing the data of that tenant.

[0054] In one method, the cryptographic erasure of a particular type of data for all tenants is performed by destroying the type key associated with that particular type of data. This is an effective means of cryptographically erasing all of a particular type of data. Preferably, the type key is stored only on the device, and the device is configured to prohibit the type key from being transferred outside the device in any form. This ensures that cryptographic erasure can be performed simply by deleting the type key, and that there is no possibility of the type key being obtained from outside the device.

[0055] In one method, a null sequence in the second subset of bits indicates setting (e.g., importing) and / or deleting (e.g., removing all copies of the key in the ECD) an external key for a given tenant. This has the effect of enabling the setting and / or deletion of an external key for a given tenant.

[0056] In a preferred approach, type keys are generated outside the ECD. Type keys can be supplied to the ECD from sources such as a key store or tenant, as needed. This allows for further control over how type keys are provided to the ECD, thereby enhancing security. It should be noted that type keys can, in effect, be dynamically assigned by some software that classifies data in any given I / O into data types.

[0057] In alternative methods, the type key is generated within the device and stored only within the device. This ensures that cryptographic erasure can be performed simply by deleting the type key, and that there is no possibility of the type key being obtained from outside the device. This provides greater control over the distribution of the type key. If the type key is prohibited from leaving the device, deleting the type key from the device ensures the cryptographic erasure of data encrypted with it.

[0058] A device implementation method according to another aspect of the present invention comprises the steps of generating a command having an address field of a predetermined length, wherein a first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types. The command is sent to a key-pass-IO-enabled device configured to encrypt and / or decrypt the data associated with the command using a combination key generated from the external key and the type key associated with the second subset of bits.

[0059] The methodology described above allows a device capable of processing a smaller number of keys simultaneously to adapt to approximately the same number of tenants as the number of keys, while also enabling the use of unique keys for different data types for each tenant, as if the device were capable of processing many times more keys. The methodology also enables, as will be explained in more detail below, the cryptographic erasure of specific types of data for all tenants.

[0060] Data types can include privacy types, confidentiality types, and so on. The methodology here enables the use of specific keys for such data types.

[0061] In one preferred approach, the command is a Non-Volatile Memory Express (NVMe) compliant command. This methodology enables the use of NVMe commands to specify the type key.

[0062] In one method, the cryptographic erasure of all data corresponding to a tenant is required by demanding the destruction of an external key stored on a key-pass-IO-enabled device. This is an effective means of cryptographically erasing the data of that tenant.

[0063] In one method, the cryptographic erasure of a specific type of data for all tenants is required by demanding the destruction of the type key associated with that specific type of data. This is an effective means of cryptographically erasing all of a particular type of data.

[0064] A computer program product comprises a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a device configured to perform data operations on the storage medium, causing the device to execute one of the methodologies presented herein.

[0065] Systems according to various aspects of the present invention include a key-pass-IO compatible device, the device having a processor and logic integrated into the processor, executable by the processor, or integrated into and executable by the processor, the logic being configured to cause the device to execute any of the methodologies presented herein.

[0066] Exemplary computing environment

[0067] Various aspects of this disclosure are illustrated by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) aspects of the present invention. With respect to any flowchart, depending on the technology involved, operations may be performed in a different order than those shown in a given flowchart. For example, also depending on the technology involved, two operations shown in consecutive blocks of a flowchart may be performed in reverse order, as a single integrated step, simultaneously, or with at least partial time overlap.

[0068] Computer program product embodiment ("CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") that are collectively included in a set of one or more storage devices that collectively contain machine-readable code corresponding to instructions and / or data for performing computer operations specified in a given CPP claim. A "storage device" is any tangible device capable of holding and storing instructions for use by a computer processor. Computer-readable storage media may be, but are not limited to, electronic storage media, magnetic storage media, optical storage media, electromagnetic storage media, semiconductor storage media, mechanical storage media, or any preferred combination thereof. Some known types of storage devices, including these media, include diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disk read-only memory (CD-ROM), digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices (such as pits / lands formed on the main surface of punch cards or disks), or any preferred combination of those described above. When the term "computer-readable storage medium" is used in this disclosure, it shall not be construed as storage in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, optical pulses passing through optical fiber cables, electrical signals communicated through wires, and / or other transmission media. As those skilled in the art will understand, data is moved at several intermittent points in the normal operation of the storage device, such as during access, defragmentation, or garbage collection; however, data is not transient while it is stored, so the foregoing does not make the storage device transient.

[0069] The computing environment 100 includes an example of an environment for executing at least some computer code associated with performing the method of invention, such as code for extending key-per-IO using type encryption keys in block 150. In addition to block 150, the computing environment 100 includes, for example, a computer 101, a wide area network (WAN) 102, an end-user device (EUD) 103, a remote server 104, a public cloud 105, and a private cloud 106. In this method, the computer 101 includes a processor set 110 (including processing circuits 120 and a cache 121), a communication fabric 111, volatile memory 112, persistent storage 113 (including an operating system 122 and block 150 identified above), a peripheral device set 114 (including a user interface (UI) device set 123, storage 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud orchestration module 141, a host physical machine set 142, a virtual machine set 143, and a container set 144.

[0070] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device that is currently known or may be developed in the future, capable of running programs, accessing networks, or querying databases such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, the execution of a computer implementation may be distributed among multiple computers and / or multiple locations. On the other hand, in this description of the computing environment 100, in order to make the explanation as concise as possible, the detailed discussion will focus on a single computer, specifically computer 101. Although computer 101 is not shown in the cloud in Figure 1, it may be located in the cloud. On the other hand, computer 101 does not need to be located in the cloud, except to any extent that can be definitively shown.

[0071] The processor set 110 includes one or more computer processors of any kind currently known or to be developed in the future. The processing circuitry 120 may be distributed across multiple packages, for example, multiple interconnected integrated circuit chips. The processing circuitry 120 may implement multiple processor threads and / or multiple processor cores. The cache 121 is memory located within the processor chip package and is typically used for data or code that should be available for high-speed access by threads or cores running on the processor set 110. The cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache for the processor set may be located "off-chip". In some computing environments, the processor set 110 may operate using qubits and be designed to perform quantum computing.

[0072] Computer-readable program instructions are typically loaded onto computer 101 and cause the processor set 110 of computer 101 to execute a series of operational steps, thereby realizing the computer implementation method. As a result, the instructions thus executed instantiate the methods specified in the flowcharts and / or descriptions of the computer implementation methods contained herein (collectively referred to as the "Methods of the Invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor set 110 to control and direct the execution of the Methods of the Invention. In computing environment 100, at least some of the instructions for executing the Methods of the Invention may be stored in block 150 in persistent storage 113.

[0073] The communication fabric 111 is a signal conduction path that enables various components of the computer 101 to communicate with one another. Typically, this fabric is made up of switches and conductive paths, such as buses, bridges, physical input / output ports, and similar components. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0074] The volatile memory 112 is any type of volatile memory currently known or to be developed in the future. Examples include dynamic random-access memory (RAM) or static RAM. Typically, volatile memory 112 is characterized by random access, but this is not required unless explicitly stated. In computer 101, the volatile memory 112 is located in a single package and resides inside computer 101, but alternatively or additionally, the volatile memory may be distributed across multiple packages and / or located externally to computer 101.

[0075] The persistent storage 113 is any form of non-volatile storage for a computer, currently known or to be developed in the future. The non-volatility of this storage means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the persistent storage 113. The persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows for writing, deleting, and rewriting of data. Some well-known forms of persistent storage include magnetic disks and solid-state storage devices. The operating system 122 may take several forms, such as various known proprietary operating systems employing a kernel or open-source portable operating system interface type operating systems. The code contained in block 150 typically includes at least some computer code involved in performing the method of the present invention.

[0076] The peripheral device set 114 includes a set of peripheral devices for the computer 101. Data communication connections between the computer 101's peripheral devices and other components may be implemented in various ways, such as Bluetooth® connections, near-field communication (NFC) connections, connections made by cables (such as Universal Serial Bus (USB) type cables), insert-type connections (e.g., Secure Digital (SD) cards), connections made through local area communication networks, and even connections made through wide area networks such as the Internet. In various embodiments, the UI device set 123 may include components such as a display screen, speakers, microphones, wearable devices (goggles and smartwatches), keyboards, mice, printers, touchpads, game controllers and haptic devices, etc. Storage 124 is external storage such as an external hard drive, or insertable storage such as an SD card. Storage 124 may be persistent and / or volatile. In some techniques, storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In methods where computer 101 is required to have a large amount of storage (for example, computer 101 locally stores and manages a large database), this storage may be provided by peripheral storage devices designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor may be a thermometer and another may be a motion detector.

[0077] The network module 115 is a collection of computer software, hardware, and firmware that enables computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or Wi-Fi signal transceiver, software for packetizing and / or depacketizing data for communication network transmission, and / or web browser software for transmitting data over the internet. In some methods, the network control and network forwarding functions of the network module 115 are performed on the same physical hardware device. In other methods (e.g., using software-defined networking (SDN)), the control and forwarding functions of the network module 115 are performed on physically separate devices, so that the control function manages several different network hardware devices. Computer-readable program instructions for performing the method of the present invention can typically be downloaded to computer 101 from an external computer or external storage device via a network adapter card or network interface included in the network module 115.

[0078] WAN102 is any wide area network (e.g., the Internet) that can transmit computer data over non-local distances using any currently known or future-developed technology for transmitting computer data. In some cases, WAN102 may be replaced and / or complemented by a local area network (LAN), such as a Wi-Fi network, designed to transmit data between devices located in a local area. WANs and / or LANs typically include computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers.

[0079] The end-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of the company operating computer 101), and may take any of the forms described above in relation to computer 101. The EUD 103 typically receives useful and valuable data from the operation of computer 101. For example, in a hypothetical case where computer 101 is designed to provide recommendations to the end-user, these recommendations would typically be transmitted from computer 101's network module 115 to the EUD 103 via the WAN 102. Thus, the EUD 103 can display or otherwise present recommendations to the end-user. In some methods, the EUD 103 may be a client device such as a thin client, heavy client, mainframe computer, or desktop computer.

[0080] The remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. The remote server 104 may be controlled and used by the same entity that operates computer 101. The remote server 104 represents a machine that collects and stores useful and beneficial data for use by other computers, such as computer 101. For example, in a hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, this historical data may be provided to computer 101 from the remote database 130 of the remote server 104.

[0081] The public cloud 105 is any computer system available for use by multiple entities, providing on-demand availability of computer system resources and / or other computing capabilities, particularly data storage (cloud storage) and computing power, without requiring direct and active management by the user. Cloud computing typically leverages resource sharing to achieve coherence and economies of scale. Direct and active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine set 142, which is a universe of physical computers located within and / or available to the public cloud 105. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine set 143 and / or containers from the container set 144. These VCEs can be stored as images and transferred between and between various physical machine hosts, either as images or after VCE instantiation. The cloud orchestration module 141 manages the transfer and storage of images, deploys new VCE instantiations, and manages the active instantiation of VCE deployments. The gateway 140 is a collection of computer software, hardware, and firmware that enables the public cloud 105 to communicate over the WAN 102.

[0082] Here, some further explanation of virtualized computing environments (VCEs) is provided. A VCE can be stored as an "image." A new active instance of a VCE can be instantiated from an image. Two well-known types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows for the existence of multiple isolated user-space instances called containers. These isolated user-space instances typically behave like actual computers in terms of the programs running within them. Computer programs running on a normal operating system can utilize all of that computer's resources, including connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running inside a container can only use the contents of the container and the devices allocated to the container; this feature is known as containerization.

[0083] A private cloud 106 is similar to a public cloud 105, except that its computing resources are available only for use by a single enterprise. While private cloud 106 is illustrated as being in communication with WAN 102, in other approaches, a private cloud may be completely disconnected from the internet and accessible only via a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different vendors. Each of the multiple clouds remains a separate, discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple configuration clouds. In this approach, both public cloud 105 and private cloud 106 are part of the larger hybrid cloud.

[0084] In some embodiments, systems of various methods may include a processor and logic integrated into and / or executable by the processor, the logic configured to perform one or more of the processing steps enumerated herein. The processor may be any configuration as described herein, such as a discrete processor or processing circuit, including many components such as processing hardware, memory, I / O interfaces, etc. Integrated means that the processor incorporates the logic as hardware logic, such as an application-specific integrated circuit (ASIC), FPGA, etc. Executable by the processor means that the logic is hardware logic, software logic such as firmware, parts of an operating system, parts of an application program, etc., or any combination of hardware and software logic that is accessible by the processor and configured to cause the processor to perform certain functions when executed by the processor. As known in the art, software logic may be stored in local and / or remote memory of any memory type. Software processor modules and / or any processor known in the art, such as hardware processors, such as ASICs, FPGAs, central processing units (CPUs), integrated circuits (ICs), graphics processing units (GPUs), etc., may also be used.

[0085] Naturally, this logic can be implemented, according to various aspects of the present invention, as a method on any device and / or system, or as a computer program product.

[0086] Referring here to Figure 2, a storage system 200 according to one aspect of the present invention is shown. Note that some of the elements shown in Figure 2 can be implemented as hardware and / or software by various methods. The storage system 200 may include a storage system manager 212 for communicating with multiple media and / or drives on at least one upper storage tier 202 and at least one lower storage tier 206. The upper storage tier 202 may preferably include one or more random access and / or direct access media 204, examples of which include hard disks in hard disk drives (HDDs), non-volatile memory (NVM), solid-state memory in solid-state drives (SSDs), flash memory, SSD arrays, flash memory arrays, or others described herein and / or known in the art. The lower storage tier 206 may preferably include one or more lower execution storage media 208, which include sequential access media such as magnetic tape and / or optical media of tape drives, slow access HDDs, slow access SSDs, and / or others described herein or known in the art. One or more additional storage tiers 216 may include any combination of storage memory media as desired by the designer of the system 200. In addition, either the upper storage tier 202 and / or the lower storage tier 206 may include any combination of storage devices and / or storage media.

[0087] The storage system manager 212 may communicate with drives and / or storage media 204, 208 on the upper storage tier 202 and lower storage tier 206 through a network 210 such as a storage area network (SAN) as shown in Figure 2, or any other suitable network type. The storage system manager 212 may also communicate with one or more host systems (not shown) via a host interface 214, which may or may not be part of the storage system manager 212. The storage system manager 212, and / or any other components of the storage system 200, may be implemented in hardware and / or software and may use processors (not shown), such as a central processing unit (CPU), a field-programmable gate array (FPGA), or an application-specific integrated circuit (ASIC), to execute commands of the kind known in the art. Of course, any configuration of storage system may be used, as will be apparent to those skilled in the art by reading this specification.

[0088] In many configurations, the storage system 200 may include any number of data storage tiers, and each storage tier may include the same or different storage memory media. For example, each data storage tier may include the same type of storage memory media, such as HDDs, SSDs, sequential access media (tapes in tape drives, optical discs in optical disc drives, etc.), direct access media (CD-ROMs, DVD-ROMs, etc.), or any combination of media storage types. In one such configuration, the upper storage tier 202 may include most of the SSD storage media for storing data in the upper-level active storage environment, while the remaining storage tiers, including the lower-level storage tier 206 and the additional storage tier 216, may include any combination of SSDs, HDDs, tape drives, etc., for storing data in the lower-level active storage environment. Thus, data that is accessed more frequently, data with higher priority, data that needs to be accessed more quickly may be stored in the upper storage tier 202, while data that does not possess any of these attributes may be stored in the additional storage tier 216 (including the lower-level storage tier 206). Naturally, those skilled in the art can, by reading this specification, devise many other combinations of storage media types according to the methods presented herein and implement them in different storage schemes.

[0089] According to several approaches, a storage system (such as 200) may include logic configured to receive requests to open a dataset, logic configured to determine whether the requested dataset is stored in a lower storage tier 206 of the tiered data storage system 200 in multiple associated parts, logic configured to move each associated part of the requested dataset to a higher storage tier 202 of the tiered data storage system 200, and logic configured to assemble the requested dataset from the associated parts on the higher storage tier 202 of the tiered data storage system 200.

[0090] Basics of Key-Par-IO

[0091] In some cases, it is desirable to allow different entities to use the same address space on a storage device. However, this simple implementation does not provide the first entity with any guarantee of privacy from a second entity that can simply read what the first entity has written to the storage device. One solution to this is for each entity (e.g., tenant) to use a unique key that can be managed outside the device, which the device requires to encrypt the data it writes and to decrypt the encrypted ciphertext. This key will be referred to herein as the external key, external MEK, and Kext. In particular, each tenant has a unique Kext that it uses to encrypt its own data, and that Kext is different from the Kexts of other tenants. This scheme is generally referred to as the key-per-IO scheme.

[0092] When a key-per-IO enabled device (e.g., an ECD, computer, etc.) starts up, it does not have a Kext to perform encryption or decryption. Rather, the Kext is supplied to it in any desired manner (e.g., along with a request for a read or write operation, as needed). For example, a tenant may send a Kext along with a key tag (e.g., T) that the device will store in volatile memory for future reference. Then, when the device receives a command (e.g., an NVMe command) that includes the key tag T as part of the command header, the key-per-IO enabled device retrieves the associated Kext from memory and uses it to encrypt plaintext data that is written by the host before the ciphertext is stored in non-volatile memory, or to decrypt ciphertext data that is read from non-volatile memory before the corresponding plaintext is sent to the host. The device may store multiple Kexts associated with different key tags. In some methods, if power is lost, Kexts stored only in volatile memory are lost and therefore need to be supplied to the device again before they can be used again after restarting.

[0093] The goal of many key-per-IO schemes is to enable different tenants (users, applications, computers, etc.) to share the same address space. Prior to the teachings presented herein, tenant Kexts were used directly as MEKs to encrypt and decrypt tenant data. Theoretically, as long as each Kext is unique to each other and remains secure against use by other tenants, encrypted data of a first tenant remains secure against cleartext access by a second tenant. When a first tenant, or the control infrastructure responsible for the first tenant's data, wishes to erase the first tenant's data on a device, the first tenant or control infrastructure may destroy the first tenant's Kext outside the device by, for example, erasing the Kext, overwriting the Kext, or otherwise destroying the Kext, including any remaining copies of the Kext outside the device as well as any copies or multiple copies stored in the volatile memory inside the device. Specifically, if there is any possibility that a first tenant's Kext has been supplied to the device since its last power cycle or cold boot, the first tenant should instruct the device to erase the Kext used as the MEK inside the device. By destroying all instances of the Kext both externally and internally, this effectively cryptographically erases any data encrypted using that MEK that is still stored in the device and recoverable from it.

[0094] However, as described above, destroying a tenant's Kext renders all data unreadable by that tenant. Prior to the disclosure of the invention herein, the only way to enable tenants to store different types of data was to assign additional Kexts to that tenant. However, given the limitations on how many keys a key-per-IO enabled device can process and / or store, the more types of data to apply, the fewer tenants can be processed.

[0095] A method for substantially increasing the number of usable keys in a key-pass-IO compatible device.

[0096] Various aspects of the present invention provide a mechanism for substantially increasing the number of keys available in a key-per-IO enabled device without sacrificing the number of tenants that the key-per-IO enabled device can handle. The following description discloses several preferred techniques for using “type” keys with a key-per-IO enabled device in a version of KPIO described herein and modified to be referred to hereafter as Extended KPIO or abbreviated as KPIO-X.

[0097] Much of the explanation presented herein relates to exemplary implementations using key-pass-IO compatible devices, such as any type of SED or ECD, but these are merely examples and provide context to aid the reader. Therefore, the concepts and teachings presented herein are equally applicable to implementations using storage media and related devices, such as magnetic recording tapes, memory cards, and optical media.

[0098] Referring now to Figure 3, a flowchart of a device mounting method 300 according to one aspect of the present invention is shown. Method 300 can be performed in accordance with the present invention in any of the environments illustrated in Figures 1 and 2, among a variety of methods. Naturally, as will be understood by those skilled in the art by reading this specification, more or less operations than those specifically described in Figure 3 may be included in Method 300.

[0099] Each step of Method 300 may be performed by any suitable component of the operating environment. For example, in various methods, Method 300 may be performed in part or in whole by a key-per-IO compatible device, storage controller, key server, or several other devices having one or more processors configured to operate according to KPIO-X. Preferably, a processor having at least one hardware component (e.g., a processing circuit, chip, and / or module implemented in hardware and / or software) may be used in any device to perform one or more steps of Method 300. Exemplary processors include, but are not limited to, central processing units (CPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), combinations thereof, or any other suitable computing devices known in the art.

[0100] Method 300 may be performed by a key-pass-IO enabled device that stores data on a storage medium, which may be any type disclosed herein (e.g., magnetic tape, magnetic disk, nonvolatile random access memory (NVRAM), etc.). Thus, the device may be any type of data storage device (e.g., tape drive, SSD, HDD, encrypted USB drive, NVRAM module, etc.). The device may also be an encrypted drive (ECD) of a removable data storage type, such as an encrypted USB drive, encrypted tape drive, or self-encrypting drive (SED).

[0101] As shown in Figure 3, method 300 may begin with operation 302, where a command is received having an address field of bits of a predetermined length (for example, as specified by the specification). Note that any field in the command header, or some other predetermined location in the command, may be considered an address field as used herein. In some methods, the command is an NVMe-compliant command. In other methods, the command is a command of a different type of known but modified in accordance with the teachings herein to include a subset of bits described immediately below.

[0102] A first subset of bits in the address field identifies a particular tenant's foreign key (Kext). For example, a particular sequence of bits may correspond to a particular Kext, and identification can be performed (e.g., using a table of such sequences and the Kexts corresponding to such sequences).

[0103] A second (typically decoupled) subset of bits in the address field corresponds to one of several type keys associated with different data types. Any type of data may be specified, as will become apparent to those skilled in the art by reading this disclosure. For example, data types may include privacy and / or confidentiality types.

[0104] The lengths of the first and / or second subsets of bits are preferably predetermined. In the example above, where the address field specification is 16 bits, the first subset of bits is 12 bits long, and the second subset of bits is 4 bits long. Note that the relative lengths can be any predetermined values ​​(e.g., 8 bits and 8 bits, 10 bits and 6 bits, 14 bits and 2 bits, etc.). Also, the combined lengths together may, in some way, be equal to less than the full address field specification (e.g., using only 10 bits and 4 bits in a 16-bit address space). The remaining address space bits may be left set to zero, some other preset null value, etc.

[0105] Commands received by 302 during operation may be received by the device from one or more external sources for key-pass-I / O operations. For example, commands may be received from tenant computers, storage controllers, etc.

[0106] During operation 304, the Kext identified by the first subset of bits is retrieved. The Kext may be stored on the device, retrieved from a key server, etc. A lookup table that associates a Kext with a given sequence of bits may be queried using the first subset of bits.

[0107] During operation 306, a type key corresponding to a second subset of bits is obtained. The type key may be stored on the device or obtained from a key server. A lookup table that associates the type key with a given sequence of bits may be queried using the second subset of bits.

[0108] During operation 308, the tenant and type keys are combined in some way to create a combined key for use in encrypting and / or decrypting data associated with the command. The combination may be a direct combination of the two keys, or it may involve combining one key with a derivative of the other key (e.g., a wrapped key created using the other key, or a combination of derivatives of both keys), as described below. All such variations should be considered equivalent.

[0109] As described in operation 310, the combination key may then be used to encrypt and / or decrypt the data associated with the command.

[0110] In one method, if the keys are substantially independent, a simple XOR operation may suffice. In other methods, more complex key derivation algorithms known in the art may be used.

[0111] Assuming the device can handle a maximum of 4,096 keys and the address field specification is 16 bits, following the example given above, only 12 of the 16 bits need to be used to specify which of those thousands of keys (e.g., the address) is used to encrypt (and / or decrypt) the data associated with a given input / output (IO). Therefore, in this example, up to 4,096 keys can be addressed without requiring more than 12 bits for addressing. If only 12 bits of the header field are used to address the number of simultaneous Kexts in the device, 4 bits may be used for other purposes.

[0112] Accordingly, various aspects of the present invention use address bits that are otherwise unnecessary and / or unused to specify other keys, which are referred to herein as “type keys.” Type keys are also used to encrypt (and / or decrypt) host writes (and / or reads). By referring to the present disclosure following the example of a 16-bit address specification, it can be understood that if only 12 bits are needed to address all supported Kexts, then four otherwise unused sets of address bits exist to address type keys. With the use of those four address bits, up to 16 type keys may be potentially specified, if this entire additional address space is used. Also, one of the 16 address values ​​(e.g., 0000b) may be reserved to specify that a null type key (e.g., substantially all zeros) is “used,” leaving 15 other (non-null) type keys that can be set or specified.

[0113] As an example of use, assume that 15 non-null type key address values ​​are used as follows: 0000b = Null key (for example, all zeros) 0001b=COc=Tenant's Corporate (CO) Confidential Data 0010b=COp=Private Tenant Data (e.g., Personal Identifier (PII)) 0011b=COo=PII is not independent trade secret, but general-purpose data for tenants. 0100b=ProjXr=Project X (ProjX) data, which is confidential company information. 0101b=ProjXc=Tenant's ProjX-related data, which is a trade secret. 0110b=ProjXp=ProjX-related data for tenants that are private (e.g., including PII) 0111b=ProjXo=PII is not an independent trade secret; it is the tenant's ProjX data. 1000b=ProjYr=Project Y (ProjY) data, which is confidential company information. 1001b=ProjYc=Tenant's ProjY-related data, which is a trade secret. 1010b=ProjYp=ProjY-related data for tenants that are private (e.g., including PII) 1011b=ProjYo=PII is not an independent trade secret; it is the tenant's ProjY data. 1100b=ProjZr=Project Z (ProjZ) data, which is confidential company information. 1101b=ProjZc=Tenant's ProjZ-related data, which is a trade secret. 1110b=ProjZp=ProjZ-related data for tenants that are private (e.g., including PII) 1111b=ProjZo=PII, and not independent trade secrets, are tenant ProjZ data.

[0114] The lower 12 bits of the 16-bit header field are used to identify up to 4096 "tenant" keys. If the data written by a given tenant (Ten_X) always has the exact lower 12 bits, then that data is associated with one of up to 4096 Kexts. If each record is tagged by some software as confidential corporate data written by that tenant, the upper 4 bits of the key ID field are set to 0001b. As a final result, one key associated with Ten_X and another key associated with COc are obtained and combined in some way, for example, by a simple XOR or another known key derivation algorithm, to create a combined key used to encrypt (and / or decrypt) host writes (and / or reads).

[0115] media encryption key

[0116] In some methods, a medium encryption key (MEK) created using a combination key may be used to encrypt and / or decrypt data. MEKs may be used in various ways as described elsewhere herein. For example, a MEK may be created by accessing a stored internal key within a device. A unique MEK is created using the internal key and the combination key referred above, for example, by performing an XOR operation on the keys together or by using a known key derivation technique. In another method, a MEK may be formed by combining a tenant key with a type key. In yet another method, a MEK may be formed by combining a tenant key, a type key, and the device's internal key.

[0117] The MEK thus formed is then used to encrypt and / or decrypt the data associated with the command. This feature adds another layer of security, as an internal key is required to access the data stored on the device. Furthermore, cryptographic erasure can be performed on the device simply by destroying the internal key and any volatile copies of the MEK stored on the device.

[0118] Preferably, the device is configured to prohibit the transfer of the internal key outside the device in any form. This ensures that cryptographic erasure performed at the drive level invalidates all data encrypted using the internal key, for example, as described in more detail below.

[0119] In some embodiments, a type key is combined with a tenant's specific Kext to create a combined key used to write and read data for that tenant, so that even if tenants share an address space, other tenants cannot decrypt the first tenant's data without the first tenant's Kext. Thus, Kexts from multiple different tenants can be individually associated with unique data stored in different locations within the same logical block address range, which is a permitted range of logical blocks on the storage medium (e.g., in the NVMe namespace), and this can be millions of sectors long. It should be noted that the assignment of key IDs to keys is usually done substantially outside the boundaries of the ECD by some logic on the ECD. That logic on the ECD should work perfectly in a hack-proof deployment so that no commands are given to the ECD with key IDs specifying address bits other than what they should be.

[0120] Cryptographic erasure using type key

[0121] To encrypt and / or decrypt host write sectors using a combination key, data encrypted with that combination key can here be cryptographically erased in essentially one of two basic methods: the Kext (e.g., Ten_X) or the type key (e.g., COc) can be erased from all locations where it is stored (e.g., keystore), including the device itself. Thus, cryptographic erasure of all data corresponding to a tenant can be performed by destroying all instances of the Kext and, where applicable, all associated media encryption keys on devices created using that Kext.

[0122] Note that a given Ten_X Kext can be used with any type key (corresponding to any type of data written by that tenant). If so, regardless of type, deleting the Ten_X key will cryptographically erase all data written by the given tenant.

[0123] However, it should be noted that the ProjXr type key may potentially be used by other or all tenants. If so, deleting the type key ProjXr will simultaneously cryptographically erase all confidential corporate data associated with ProjX written by any tenant. If the type keys associated with ProjXc, ProjXp, and ProjX0 are additionally deleted, all data associated with Project X will be cryptographically erased. Thus, a particular type of data can be cryptographically erased for all tenants by destroying all instances of the type key corresponding to that type of data, and, if applicable, all associated MEKs created using that type key. Preferably, the type keys are stored only on the device, and the device is configured to prevent the type keys from being transferred outside the device in any form.

[0124] Any of these methods of cryptographic erasure may be used, modified, and / or combined with the features described below with respect to additional techniques for cryptographic erasure.

[0125] Device configuration for using type keys

[0126] The following description illustrates one possible method for adapting any type of KPIO-enabled device, referred to herein as Extended KPIO or KPIO-X as mentioned above, to operate as described herein. Note that in most cases described in detail herein, there are viable alternative equivalent methods for adapting devices and KPIO commands to achieve the same objective, which will become apparent to those skilled in the art after reading this disclosure.

[0127] Multi-mode operation.

[0128] A simple way to adapt a device to enable KPIO-X operation is to start with a device that can operate in accordance with KPIO, and then extend that device to enable it to operate in a different operating mode, specifically, to enable KPIO-X operation. Such a device may be extended to be able to operate in one of the following ways:

[0129] The first method strictly adheres to the existing KPIO specification (i.e., no type key), while the second method (which the drive may configure to use instead) operates in a way that supports type keys and therefore conforms to the KPIO-X operation described herein. The device is then configured with predefined commands to control the device to operate in one or the other mode, for example, KPIO or KPIO-X.

[0130] Specify the number of external keys and the number of type keys.

[0131] The current KPIO specification allows users to query a device (e.g., a drive) for the total number of encryption keys that can be supported, and the number of encryption keys per NVMe namespace. This should allow the drive to report the number of supported Kexts, and should be the simplest way to report the number of supported Kexts when operating in KPIO-X mode.

[0132] One technique to enable a drive to report the total number of supported type keys and the number of supported type keys per NVMe namespace involves creating vendor-specific commands that enable such reporting using a large portion of the same command construct.

[0133] When a device is operating in KPIO-X mode in some way, it should be noted that the two reported numbers (for example, for a given NVMe namespace) should be consistent with each other so that tenant and type keys can be addressed independently with different address bits. For example, for support of up to 4,096 Kexts (but not strictly 2^N), the use of the lower 12 address bits in the NVMe command is required. This leaves up to four remaining upper address bits for type key addressing. If one of those type key addresses is reserved for use as a null key (for example, as described in more detail below), the number of supported type keys can be up to (2^4)-1=15 (but not strictly (2^M)-1, and could be zero (although in the latter case it would be essentially like regular KPIO rather than KPIO-X, except that it is possible to support vendor-specific commands)).

[0134] In some methods, the type / tenant segmentation described herein can be managed in a manner that does not require the storage of any additional keys. For example, suppose a given SSD can hold 4096 keys, thus consuming 12 of the 16 address bits. The goal is to enable the use of 15 unique type keys plus one null type key (addressed by the remaining 4 address bits). However, assume there is no additional place to store these type keys. This can be handled by reducing the number of keys assigned to a tenant from 4096 to 4080. Thus, 4080 is the number reported as the number of available external key locations, at least in KPIO-X mode. In KPIO mode, the device may report either 4080 or 4096 (to be consistent with KPIO-X mode), and assume that the last of those keys is available for the tenant. The simplest implementation (from both an ASIC design perspective and a user-understanding perspective) is to always report 4080 external keys. In KPIO-X mode, the device reports 15 types of key settings, for example, via vendor-specific query commands. Each of the 4080 external keys can potentially be used with each of the 15 types of key settings, enabling 4080 × 15 = 61,200 key combinations, which is close to 64,000, the number that 16 bits can handle.

[0135] Exemplary techniques for setting and deleting external keys

[0136] In some methods, a null sequence in the second subset of bits (the most significant bits) indicates the setting and / or deletion of a Kext. A null sequence can be all zeros, as in the example above. However, in other methods, a null sequence can instead be all ones, or some pre-specified sequence of zeros and ones that is not used to specify a type key.

[0137] In one exemplary approach, the tenant Kext (or MEK) key may be configured using a standard KPIO scheme adapted for this purpose, for example, by setting all of the upper “type key” address bits to zero.

[0138] Similarly, tenant Kext (or MEK) keys can be removed from the device using a standard KPIO scheme adapted for this purpose, for example, by setting all the upper “type key” address bits to zero.

[0139] Exemplary techniques for setting type keys

[0140] In some methods, the type key is generally adapted for this purpose, but it can be set in the standard KPIO manner, with a non-zero value in the upper "type key" address bits. Note that the values ​​transmitted in the lower "external key" address bits can be set to zero (if desired), or they can be any value, if desired.

[0141] Exemplary techniques for removing type keys

[0142] In some methods, the type key is adapted for this purpose but can be removed from the device using a standard KPIO scheme with a non-zero value in the upper "type key" address bits. As described above, the values ​​transmitted in the lower "external key" address bits can all be set to zero (if desired), or they can be any value, if desired.

[0143] The advantages of ensuring a "null key" setting

[0144] The explanation in the preceding paragraph explicitly uses the setting of all zeros in the upper “type key” address bits to specify an action on a Kext (e.g., set or delete) without affecting any type key. Similarly, a non-zero setting in the upper “type key” address bits, when used in conjunction with commands to set and delete keys, indicates that the action is specific to a particular type key and, preferably, does not affect any external keys.

[0145] The cost of securing a null key setting is that it consumes one of the "type key" address bit settings, resulting in, for example, 15 type key settings being available instead of 16. However, it may be desirable to enable encryption using only the external key without using any arbitrary type key (which could be considered a known default type key, e.g., an all-zero key). In that case, this 16th type key setting is effectively used to specify the use of a known default "type" key.

[0146] Regarding the reservation of one null "type" key setting, it should be noted that in other methods, one null "tenant" key setting may similarly be reserved for use when setting or deleting type keys. This is optional and not strictly necessary, in that the logic simply needs to be able to detect non-zero values ​​in the type key, and in response to such detection, the device needs to recognize that the setting or deleting key is simply intended for the type key being addressed. If a null "tenant" key setting is desirable, such a setting should preferably be all 1s for the lower address bits associated with the external key, because it is the last external key address to be used and therefore the least likely to be used in most use cases. Reservation of one null "tenant" key setting results in one less tenant Kext available (for example, if 12 bits are reserved for the use of the external key, it may support only 4095 tenants instead of 4096).

[0147] Additional security features available using the methodology presented herein

[0148] In some methods, the KPIO-X configurations described herein may be configured to allow the key to be stored only on the device and therefore discoverable. Such configurations are described elsewhere in this specification.

[0149] In one approach, the type key is generated outside the device. The type key may be supplied to the device from some external key management entity, in a similar manner to how tenant keys may be supplied to the device.

[0150] Alternatively, all type keys may be generated internally by the device and stored within the device. For example, type keys may be generated within the device and stored only within the device. This provides greater control over the distribution of type keys. If type keys are prohibited from leaving the device, deleting the type keys from the device ensures the cryptographic erasure of data encrypted with those type keys.

[0151] In yet another method, any key of a Kext in cleartext form (e.g., unwrapped), and, where applicable, the MEK, is stored only on the device, ideally in volatile memory. Therefore, a power cycle or power loss of the device will cause these keys to be lost from the device. Type keys can be stored on the device in non-volatile memory, in clear and / or wrapped form. In one method, an externally provided Kext is combined with an internally generated type key, and the resulting combined key is used for the actual bulk encryption.

[0152] In other methods, one or more key types (Kext, type key, combination key, MEK) may be stored within the device, for example, in the device's non-volatile memory. This non-volatile memory may be on an application-specific IC such as NAND flash, or it may be incorporated into some larger IC such as an FPGA, ASIC, or CPU. In some methods, at least one type of key is stored in the device in its raw (decrypted) form. In other methods, one or more types of keys are stored in the device in a wrapped form (e.g., encrypted form, password-protected form, obscured form, etc.). When one or more types of keys are stored in a wrapped form, information such as another key, password, etc., for unwrapping the key may be retrieved and / or received and used to unwrap the key. For example, a PIN or password required to manage the device may be used as a wrap key to wrap the internal key. Alternatively, a Key Encrypting Key (KEK) may be used as a wrap key to wrap the key. Preferably, only the non-volatile storage of one or more types of keys is in a wrapped form.

[0153] As mentioned above, a combination key can be constructed from multiple keys using any preferred technique which will become apparent to those skilled in the art after reading this disclosure. For example, a simple XOR may be used. In any of the techniques used herein, a National Institute of Standards and Technology (NIST) approved key derivation function (KDF) may be used to compute the bulk encryption key actually used. This is an improvement over the direct key model used by KPIO today in that it ensures the ability to perform cryptographic erasure on the drive and uses externally provided entropy.

[0154] A system according to one aspect of the present invention comprises a key-pass-IO compatible device, the device having a processor and logic integrated into the processor, executable by the processor, or integrated into and executable by the processor. The logic is configured to cause the device to perform any of the methodologies presented herein, including the method shown in Figure 3.

[0155] Tenant device operation using KPIO-X

[0156] Referring now to Figure 4, a flowchart of Method 400 according to one aspect of the present invention is shown. Method 400 can be carried out according to the present invention in any of the various methods, in particular in any of the environments illustrated in Figures 1 to 3. Naturally, as will be understood by those skilled in the art by reading this specification, Method 400 may include more or fewer operations than those specifically described in Figure 4.

[0157] Each step of Method 400 may be performed by any suitable component of the operating environment. For example, in various methods, Method 400 may be performed in part or in whole by a tenant computer or any other device having one or more processors therein. Preferably, a processor having at least one hardware component (e.g., a processing circuit, chip, and / or module implemented in hardware and / or software) may be used in any device to perform one or more steps of Method 400. Exemplary processors include, but are not limited to, central processing units (CPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), combinations thereof, or any other suitable computing devices known in the art.

[0158] As shown in Figure 4, method 400 may begin with operation 402, in which a command having an address field of a predetermined length is generated. In one method, the command is an NVMe-compliant command, but other types of commands known in the art may be adapted for use according to various aspects of the present invention. A first subset of bits in the address field identifies the Kext of a particular tenant, and a second subset of bits in the address field corresponds to one of several type keys associated with different data types.

[0159] During operation 404, the command is sent to a key-per-IO-enabled device configured to encrypt and / or decrypt the data associated with the command using a combination key generated from the Kext and a type key associated with a second subset of bits. As described above, the combination can be a direct combination of the two keys, or it may involve combining one key with a derivative of the other key, e.g., a wrapped key created using the other key, as described below. All such variations should be considered equivalent.

[0160] Furthermore, as described above, data types may include privacy types and / or confidentiality types.

[0161] In one method, the cryptographic erasure of all data corresponding to a tenant is required by requesting the destruction of Kexts stored on a key-per-IO-enabled device, and, where applicable, all associated media encryption keys on devices created using those Kexts. If more than one instance of a Kext exists on the device, the request preferably causes the destruction of all instances of that Kext.

[0162] Alternatively, the decryption of a specific type of data for all tenants by requiring the destruction of the type keys for all instances and, where applicable, all associated media encryption keys on devices created using those type keys. Example of adding encryption erasure to key-pass I / O compatible devices

[0163] The following description discloses several preferred methods of systems, methods, and computer program products for enabling local encrypted data to be cryptographically erased by internal actions in key-per-IO compatible devices configured for KPIO-X, such as ECDs. Generally, data is encrypted and / or decrypted using MEKs created from combination keys, as described above, and internal keys (Kints) stored in storage devices, such as ECDs, SEDs, tape cartridges, and portable memory. Destruction of Kints and all MEKs created therefrom cryptographically erases all data that has been encrypted and stored using those MEKs, and is therefore irrecoverable. Similarly, destruction of all copies of a combination key and the Kexts used to create the combination key cryptographically erases the data corresponding to those Kexts. Similarly, destruction of all copies of a combination key and the type keys used to create the combination key cryptographically erases the data corresponding to those type keys.

[0164] Furthermore, a Kint is combined with a key created using a tenant's specific Kext to create a MEK that is then used to write and read data for that tenant. Therefore, even if tenants share an address space, other tenants cannot decrypt the first tenant's data without the first tenant's Kext or its associated key. Thus, multiple Kexts can be individually associated with unique data stored in different locations within the same logical block address range, within a permitted range of logical blocks on the storage medium (e.g., in the NVMe namespace), which can be millions of sectors long. This must not be mixed with the range of individual write commands, which are all written using a single Kext specified by a key tag reached in the header of that write command using key-per-IO.

[0165] Encryption and erasure in ECD and SED

[0166] The majority of the explanations presented herein relate to exemplary implementations involving any type of SED or ECD, but this is done merely as an example, and only to provide context for the reader. Thus, the concepts and teachings presented herein are equally applicable to implementations using storage media and related devices such as magnetic recording tapes, memory cards, and optical media.

[0167] Referring now to Figure 5, a flowchart of Method 500 using one technique is shown. Method 500 can be carried out in accordance with the present invention in any of the environments illustrated in other figures described herein, among various techniques. Naturally, as will be understood by those skilled in the art who read this specification, Method 500 may include more or fewer operations than those specifically described in Figure 5.

[0168] Each step of Method 500 may be performed by any suitable component of the operating environment. For example, in various methods, Method 500 may be performed in part or in whole by a device such as a computer, a drive, or any other device having one or more processors therein. Preferably, a processor having at least one hardware component (e.g., a processing circuit, chip, and / or module implemented in hardware and / or software) may be used in any device to perform one or more steps of Method 500. Exemplary processors include, but are not limited to, central processing units (CPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), combinations thereof, or any other suitable computing devices known in the art.

[0169] As shown in Figure 5, method 500 may begin with operation 502, where a device configured to perform data operations on a storage medium, such as reading data from and / or writing data to the storage medium, receives one or more unique external encryption keys (Kexts). The one or more Kexts are supplied to the device from one or more external sources for use in key-per-IO operations. The external sources can be any external sources. For example, the external source could be a virtual machine or container, or an application running on a host server that natively writes or reads data, or a control infrastructure that transparently handles all key provisioning to those applications, virtual machines, containers, or host servers. The external source could also be a key store, a key server, or a key entered by a user (e.g., via a keyboard, by inserting a flash drive, etc.).

[0170] Kext is used, for example, with a type key specified in the command header to generate a combination key, as described in more detail above. Note operation 503.

[0171] Kexts and combination keys are preferably stored in volatile memory only on the device so that they are destroyed when the power is turned off or the device is rebooted. Kexts may be received in any preferred manner, such as all at once as needed, in response to a request for Kexts (e.g., from the device). For example, Kexts may be received in an encrypted form along with a request to read or write data stored or to be stored on the storage medium.

[0172] The storage medium may be any type disclosed herein, such as magnetic tape, magnetic disk, or non-volatile random-access memory (NVRAM). Therefore, the device may be any type of data storage device (e.g., tape drive, SSD, HDD, encryption-enabled USB drive, NVRAM module, etc.). The device may also be an encryption-enabled drive (ECD) of a removable data storage type, such as an encryption-enabled USB drive, encryption-enabled tape drive, or self-encrypting drive (SED).

[0173] During operation 504, Kint stored in the device is accessed, for example, from the device's non-volatile memory. This non-volatile memory may be on an application-specific IC such as NAND flash, or it may be incorporated into some larger IC such as an FPGA, ASIC, or CPU. In some methods, Kint is stored in the device in its raw (decrypted) form. In other methods, Kint is stored in the device in a wrapped form (e.g., encrypted, password-protected, obscured, etc.). When Kint is stored in a wrapped form, information such as another key, PIN, or password may be retrieved and / or received to unwrap the Kint and used to unwrap it. For example, a PIN or password required to manage the device may be used as a wrap key to wrap the internal key. Alternatively, a key encryption key (KEK) may be used as a wrap key to wrap the internal key. Preferably, only the non-volatile storage of the internal key is typically in a wrapped form.

[0174] In a preferred embodiment, the device is configured to prevent Kint from being transferred outside the device in any form. However, a microprocessor or controller inside the device may access Kint within the device.

[0175] During operation 506, a unique MEK is generated for each of at least some Kexts using the Kint and one of the associated combination keys. In other words, the MEK associated with a given Kext used for its generation is different from any other MEK. Any known technique may be used to create a MEK from a combination key and a Kint by applying another known key derivation or hash algorithm, for example, by performing an XOR operation on the combination key and the Kint together, or by concatenating the two keys together to create a larger MEK, etc.

[0176] A MEK for a given dataset can be created at any desired time. In one method, the MEK is generated in response to the creation of a combinatorial key. In another method, the MEK is created in response to receiving a request to perform data operations on the data associated with the Kext.

[0177] Regardless of when the MEK is created, it may be stored volatilely within the device for use and / or reuse, used for data manipulation and then discarded, etc. Preferably, the MEK is stored in clear text form within the device, only in volatile memory, and as a result is lost when the device is powered off or reset. This helps ensure that the MEK is not accessible from outside the device or when the device is disabled and consequently powered off and removed from the storage system.

[0178] During operation 508, in response to receiving a request to perform a data operation on data associated with one of the combination keys, the MEK associated with the combination key is used to encrypt and / or decrypt the data, for example, using otherwise conventional encryption / decryption techniques. For example, in response to receiving a read request, the ciphertext of the requested data is decrypted during operation 508 using the appropriate MEK to give the unencrypted (i.e., cleartext) form of the requested data, which may then be output to the requester. The ciphertext of the requested data may be copied into a buffer and then decrypted, decrypted "on the fly" during reading, etc. The decrypted data is output to the data requester, for example, through a host interface.

[0179] In some methods, the MEK is deleted upon completion of the associated request. In other methods, the MEK may be retained in some form of volatile memory or register for reuse. In any case, the storage device may retain the Kext, combination key, and / or associated MEK until it is instructed to forget them by an explicit command or reset, or until they are forgotten by power off.

[0180] Various modes of operation of Figure 5 are provided below. Such modes are presented merely as examples and are not intended to be limiting. As stated above, much of this description refers to the ECD; however, it should be noted that this is done merely as an example. Furthermore, such modes can be combined in any way according to a great many possible modes and methods for carrying out the invention.

[0181] A MEK can be constructed from two separate keys using any technique known in the art and / or which will become apparent to those skilled in the art by reading this specification. For example, one way of constructing a MEK that requires the use of both a Kint and a combination key to compute is to make the Kint a generated random number, and then compute the MEK by performing a computation that requires both the Kint and the combination key, such as bitwise XORing the two together or concatenating these two values.

[0182] Kint can originate from any conceivable source. Kint is preferably created within the ECD, which is the most secure method, because a copy of Kint never needs to exist outside the ECD unless it is deliberately copied from it. For example, Kint can be generated in a known manner using the output from a random number generator within the ECD.

[0183] In other methods, Kint can be created outside of the ECD and supplied to the ECD. For example, Kint can be programmed into the device during the manufacturing build, programmed into the device by an administrator, or inserted into the device during its configuration or formatting.

[0184] In one embodiment, a Kint may be specific to a particular set of data, and therefore, a device may store multiple unique Kints, each associated with its own unique dataset.

[0185] Preferably, the ECD is configured not to allow any external visibility of Kint, or transfer or copying of Kint from the ECD.

[0186] In one exemplary method, only the combined key and Kint in their wrapped forms are stored in the ECD in non-volatile memory. The Kext is stored only outside the ECD in a non-volatile form and therefore needs to be supplied to (or accessed by) the ECD at least once after a power cycle and / or cold boot to enable the MEK to be computed. The MEK can only be computed when the ECD has both the Kint and the Kext. Therefore, the Kext needs to be supplied to (or accessed by) the ECD in some form in order to compute the combined key. According to various embodiments, there are many ways in which this can be done. One method is to have the Kext introduced into the ECD wrapped with the Key Encryption Key (KEK). Alternatively, if the ECD supports a Key Management Interoperability Protocol (KMIP) client, it may request and receive the Kext from an external key manager of the type known in the art via a secure channel (such as one protected by TLS or IPsec). Alternatively, Kext can be supplied to the ECD in a manner similar to that of a Personal Identification Number (PIN), for example, in cleartext form, through a secure tunnel established for Security Protocol In and Security Protocol Out commands.

[0187] Kint is preferably stored in the ECD in a wrapped form and is not wrappable until a wrapping key (which may be a KEK, or alternatively, may depend on one or more passwords or PINs, supplied to the ECD to authenticate one or more different roles supported by the ECD (e.g., Admin1)) is provided. Therefore, any part of the wrapping key provided from outside the ECD is supplied to the ECD, allowing Kint to be unwrapped. Once the ECD is supplied with, or has access to, all the necessary information (including Kext) required to compute the MEK, the ECD can compute the MEK and then decrypt existing ciphertext to generate cleartext as a result (e.g., in response to a host read), or encrypt newly received customer data in cleartext form to ciphertext (e.g., in response to a host write).

[0188] In one approach, Kint is generated internally and wrapped using a PIN associated with the KEK or some administrative security provider (hereinafter, "AdminSP"), such as Admin1. Therefore, Kint can be accessed when KEK is deployed to ECD, or when an entity such as Admin1 authenticates with its password or PIN.

[0189] The KEK or PIN that wraps a Kint may be changed as part of the key change operation (of the wrapping key). The Kint itself can also be key changed, but this results in the decryption of data encrypted by a MEK created from a Kint that was used before the Kint was key changed.

[0190] One implementation involves making ECD the source of Kint generation in some or all cases, using the same type of internal random number generation function invoked, for example, by a random command.

[0191] Referring here to Figure 6, a flowchart of an exemplary method 600 for writing cryptographically erasable data in a key-per-IO scheme using one technique is shown. Method 600 can be performed according to the invention in any of the environments illustrated in this specification, particularly in Figure 5, and in other figures, among a variety of techniques. Naturally, as will be understood by those skilled in the art who read this specification, more or less operations than those specifically described in Figure 6 may be included in Method 600.

[0192] Each step of Method 600 may be performed by any suitable component of the operating environment. For example, in various methods, Method 600 may be performed in part or in whole by a device such as a computer, a drive, or any other device having one or more processors therein. Preferably, a processor having at least one hardware component (e.g., a processing circuit, chip, and / or module implemented in hardware and / or software) may be used in any device to perform one or more steps of Method 600. Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a combination thereof, or any other suitable computing device known in the art.

[0193] During operation 602, a request is received on a device configured to perform a KPIO-X operation on the storage medium. The request is to write the first data to the storage medium in encrypted form using the first Kint associated with the first data.

[0194] During operation 604, Kint stored within the device is accessed.

[0195] During operation 606, the first MEK is generated using a combination key created from the Kint, Kext, and type key.

[0196] During operation 608, the first data is encrypted using the first MEK.

[0197] During operation 610, the encrypted first data is written to the storage medium within a first logical block address range of the storage medium. The first logical block address range is preferably an permitted range of logical blocks on the storage medium (e.g., in the NVMe namespace), which may be several million sectors long. This must not be mixed with a limited range of specific write commands associated with a single Kext.

[0198] During operation 612, a second request is received by the device. The second request requests that the second data be written to the storage medium in an encrypted form using a second external key associated with the second data, where the second external key is different from the first external key.

[0199] During operation 614, the internal key stored within the device is accessed.

[0200] During operation 616, the second MEK is generated using the internal key and a second combination key created using the Kext and type keys.

[0201] During operation 618, the second data is encrypted using the second MEK.

[0202] During operation 620, the encrypted second data is written to the storage medium within the first logical block address range of the storage medium. The second write may or may not overlap with the range of logical blocks written by the first write command, and may be any logical block address range within the permitted range of logical blocks (e.g., in the NVMe namespace).

[0203] Additional operations may be performed in this method 600, and any of the features described herein may be implemented in this method 600.

[0204] Referring now to Figure 7, a flowchart of an exemplary method 700 for performing cryptographic erasure on data in a key-per-IO scheme using one technique is shown. Method 700 can be performed according to the invention in any of the environments illustrated in other figures, particularly those described herein, especially in Figures 4-5, among a variety of techniques. Naturally, as will be understood by those skilled in the art by reading this specification, more or less operations than those specifically described in Figure 7 may be included in Method 700.

[0205] Each step of Method 700 may be performed by any suitable component of the operating environment. For example, in various methods, Method 700 may be performed in part or in whole by a device such as a computer, a drive, or any other device having one or more processors therein. Preferably, a processor having at least one hardware component (e.g., a processing circuit, chip, and / or module implemented in hardware and / or software) may be used in any device to perform one or more steps of Method 700. Exemplary processors include, but are not limited to, central processing units (CPUs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), combinations thereof, or any other suitable computing devices known in the art.

[0206] During operation 702, a request is received by a device configured to perform data operations on the storage medium using key-per-IO operations to cause the cryptographic erasure of all data in at least one logical block address range of the storage medium. Each individual portion of the data in at least one logical block address range is associated with a unique Kext, for example, corresponding to a unique data type, for example, corresponding to a unique tenant and / or unique type key. Each individual portion of the data is encrypted using a unique MEK, which is created using the Kint and the unique combination key associated with the portion of data.

[0207] During operation 704, cryptographic erasure is achieved by destroying both the Kint and any MEK on the device created from that Kint (for example, by erasing the Kint, overwriting the Kint, and / or physically destroying the memory storing the Kint).

[0208] Examples of key types and corresponding parameters

[0209] The following description provides exemplary configurations and parameters of various types of keys referred to herein. Any combination of the features below may be used in conjunction with and / or applied to any of the corresponding keys described above.

[0210] Tenant key (or Kext)

[0211] In some methods, one key per tenant is enabled by the first set of address bits, and in some cases, null settings are possible by minus 1 (for example, if the first set of address bits has 12 bits, there is support for 4095 tenants).

[0212] In some methods, after startup, all necessary tenant keys are always supplied to the KPIO-X compliant ECD from some external key manager and are never stored in non-volatile memory in cleartext format. Alternatively, tenant keys may be sent in a wrapped format.

[0213] In some methods, the external key (to the ECD) that manages the entity is responsible for the ability to cryptographically erase all data associated with a given tenant by destroying it in both the ECD and all external key stores (by issuing commands to it).

[0214] In some methods, a given tenant key is not permanently associated with any given setting of the first set of address bits. For example, an external key management entity (e.g., a key manager) (relative to the ECD) could first supply a given tenant key (e.g., for tenant X) to the ECD as a fifth key (so it could be associated with a first 12-bit key ID setting of 000000000101). However, if tenant X's key is not used for some time (e.g., overnight when the tenant is not working), the key manager could overwrite the location of that key with tenant Y's key, and later, when tenant X returns to work and wants to access tenant X's data, tenant X's key is sent to a completely different key location (e.g., associated with a key ID setting of 000101100010).

[0215] In some methods, data for a given tenant is not statically allocated to any given address range in a common namespace. Each time a tenant goes to write data, the write may be dynamically allocated. For example, suppose tenant Y recently deleted some logical entity (e.g., a file) that maps to a set of sectors in a common namespace address range that still contains tenant Y's ciphertext. Now tenant X wants to write some logical entity. Because space is dynamically allocated for tenant X's data, tenant X's ciphertext may overwrite some or all of the sectors that previously held tenant Y's ciphertext and were released in response to tenant Y deleting the file. An external process to the ECD can manage which tenant and type key is associated with which set of sectors, and as a result, when it is necessary to read those sectors, the exact key IDs for both the tenant and type key are sent using a host read command, allowing the ciphertext to be decrypted.

[0216] Type Key

[0217] In some methods, one key per type is permitted by a second set of address bits, and in some cases, a null setting is permitted by minus 1 (resulting in support for 15 types if there are 4 bits in that second set of address bits).

[0218] In some methods, after startup, all necessary type keys are always supplied to the KPIO-X compliant ECD from some external key manager and are never stored in non-volatile memory in clear text format (which would violate the KPIO specification and possibly the KPIO-X specification as well). Preferably, the type keys are sent to the ECD in wrapped format.

[0219] In some methods, the external key (to the ECD) that manages the entity is responsible for the ability to cryptographically erase all data associated with a given type by destroying it in both the ECD and all external key stores (by issuing commands to it).

[0220] In some methods, a given type of key is not necessarily permanently associated with any given setting of a second set of address bits. For example, an external key management entity (e.g., a key manager) (relative to the ECD) could first supply a given type key (e.g., for type X) to the ECD as a fifth key (so it could be associated with the second 4-bit key ID setting 0101). However, if the type X key is not used for some time (e.g., the project is terminated), the key manager could then overwrite the location of that key with a type Y key, and later, if the project is restarted and type X is needed again and it is desired to access the data, the type X key could be sent to some completely different key location (e.g., associated with the key ID setting 0010).

[0221] In some methods, data of a given type may or may not be statically allocated to a given address range in a common namespace. It can be assumed that it is dynamically allocated each time a tenant goes to write data. For example, suppose tenant Y writes something of type A, and then deletes some logical entity (e.g., a file) that still maps to some set of sectors in the address range of the common namespace to which tenant Y's ciphertext is written. Now tenant Y wants to write some other logical entity, e.g., of type B. Because the space is dynamically allocated for tenant Y's type B data, tenant Y's type B ciphertext may overwrite some or all of the sectors that previously held tenant Y's type A ciphertext, which was released when tenant Y deleted that file of type A data. An external process to the ECD can manage which tenant and type keys are associated with which set of sectors, and as a result, when it is necessary to read those sectors, the exact key IDs for both the tenant and type keys are sent using a host read command, allowing the ciphertext to be decrypted.

[0222] internal key

[0223] In some approaches, one internal key may be assigned per namespace. Alternatively, a single common internal key may be used across all namespaces supported by a given ECD.

[0224] In some methods, after power is turned on and the ECD is unlocked, the wrapped internal key is unwrapped each time, making it accessible the next time. Preferably, the internal key is never stored non-volatile in cleartext form.

[0225] In some methods, an external entity responsible for managing the state of the ECD (to the ECD) may, in certain circumstances, issue commands necessary to revert the ECD itself to its original factory state (OFS), and when doing so, the ECD is configured to overwrite or otherwise actively delete any wrapped key structures, including internal keys, and any cleartext versions of internal keys that may be in volatile memory.

[0226] In some methods, each time a namespace is created (or perhaps only once after the drive is initialized after being returned to OFS, regardless of how many namespaces are created afterward (for example, if the ECD can maintain more than one namespace)), a new internal key is generated internally within the ECD.

[0227] It should be clear that the various features of the aforementioned systems and / or methodologies can be combined in any way, creating multiple combinations as described above.

[0228] Furthermore, it will be understood that aspects of the present invention may be provided in the form of a service deployed for the customer in order to provide a service on demand.

[0229] While descriptions of various aspects of the present invention are presented for illustrative purposes, they are not intended to be comprehensive or limit the scope to the disclosed methods. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described aspects. The terminology used herein has been selected to best describe the principles, practical applications, or technical improvements to the techniques found in the market, or to enable other persons skilled in the art to understand the methods disclosed herein.

Claims

1. The step of receiving a command having an address field of a predetermined length, wherein a first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types; A step of obtaining the external key identified by the bits of the first subset; The step of obtaining the type key corresponding to the bits of the second subset; and The step of combining the tenant and type keys to create a combined key for use in encrypting and / or decrypting the data associated with the command. A device implementation method comprising the following features.

2. The device implementation method according to claim 1, wherein the data type includes a privacy type.

3. The device mounting method according to claim 1, wherein the data type includes a confidentiality type.

4. The device implementation method according to claim 1, wherein the command is a non-volatile memory express (NVMe) compliant command.

5. The device implementation method according to claim 1, wherein the device is configured as a key-per-I / O compatible device.

6. The step of accessing the internal key stored in the aforementioned device; A step of generating a unique media encryption key using the internal key and the combined key; and The step of encrypting and / or decrypting the data associated with the command using the aforementioned media encryption key. A device mounting method according to claim 1, comprising:

7. The device implementation method according to claim 6, wherein the device is configured to prevent the internal key from being transferred to the outside of the device in any form.

8. The device implementation method according to claim 1, wherein a plurality of the aforementioned external keys are individually associated with unique data stored in different locations within the same logical block address range.

9. The device implementation method according to claim 1, further comprising the step of performing cryptographic erasure of all data corresponding to the tenant by destroying the external key used by the tenant.

10. The device implementation method according to claim 1, further comprising the step of performing cryptographic erasure of the particular type of data for all tenants by destroying the type key associated with the particular type of data.

11. The device implementation method according to claim 10, wherein the type key is stored only on the device, and the device is configured to prohibit the transfer of the type key to the outside of the device in any form.

12. The device implementation method according to claim 1, wherein a null sequence in the bits of the second subset indicates the setting and / or deletion of the external key.

13. The device implementation method according to claim 1, wherein the type key is generated outside the device.

14. The device implementation method according to claim 1, wherein the type key is generated within the device and stored only within the device.

15. A system comprising a key-per-IO compatible device, wherein the device has a processor and logic integrated into the processor, executable by the processor, or integrated into and executable by the processor, and the logic is provided to the device: A procedure for receiving a command having an address field of a predetermined length by the device, wherein a first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types; A procedure for obtaining the external key identified by the bits of the first subset using the device; A procedure for obtaining the type key corresponding to the bits of the second subset using the device; and The procedure by which the device combines the tenant and type keys to create a combined key used to encrypt and / or decrypt the data associated with the command. A system configured to perform a certain action.

16. A program for causing a processor to execute the device implementation method described in any one of claims 1 to 14.

17. A step of generating a command having an address field of a predetermined length, wherein a first subset of bits in the address field identifies the external key of a particular tenant, and a second subset of bits in the address field corresponds to one of a plurality of type keys associated with different data types; and The step of sending the command to a key-per-IO enabled device configured to encrypt and / or decrypt the data associated with the command using the external key and the type key associated with the bits of the second subset. A device implementation method comprising the following features.

18. The device implementation method according to claim 17, wherein the data type includes a privacy type.

19. The device mounting method according to claim 17, wherein the data type includes a confidentiality type.

20. The device mounting method according to claim 17, wherein the command is a non-volatile memory express (NVMe) compliant command.

21. The device implementation method according to claim 17, further comprising the step of requesting the destruction of the external key stored in the key-per-IO compatible device, thereby requesting the cryptographic erasure of all data corresponding to the tenant.

22. The device implementation method according to claim 17, further comprising the step of requesting the cryptographic erasure of the particular type of data for all tenants by requesting the destruction of the type key associated with the particular type of data.

Images