Cryptographic erasure of data stored in KeyPer IO enabled devices via internal operations

Abstract

A device-implemented method for enabling or performing, or enabling and performing, cryptographic erasure in a Key per IO-enabled system via internal or external operations or a combination thereof. In various approaches, cryptographic erasure of data stored in a Key per IO scheme can be achieved by implementing an internal key that is combined with an external key to generate a media encryption key that is used to encrypt / decrypt the data. By restricting access to the internal key, destruction of the internal key and all media encryption keys generated using the internal key renders the data encrypted and unrecoverable.

Description

[Technical Field]

[0001] The present invention relates to crypto-erasure, and more particularly, the present invention relates to techniques and systems that enable crypto-erasure by internal action in Key per IO-enabled devices. [Background technology]

[0002] The term "crypto-erase" (hereafter simply referred to as "crypto-erase") generally refers to disabling access to an encryption key needed to decrypt data in some way. This can be done, for example, by erasing all copies of the encryption key, or by deleting portions of the encryption key, thereby disabling access to the associated keys needed to generate or unwrap the encryption key. By permanently revoking the encryption key, data encrypted with that encryption key can no longer be decrypted, effectively rendering the encrypted data undecryptable.

[0003] In today's data centers, the inability to completely cryptographically erase all failed or retired encryption-capable drives (ECDs) has proven to be a major problem. ECDs can be encrypted regardless of whether they are self-encrypting drive (SED) types and regardless of storage technology, e.g., solid-state drive (SSD), hard disk drive (HDD), hybrid drives consisting of both solid-state and hard disk technologies, or drives with alternative technologies. For example, a failure can occur in which an ECD can no longer communicate with the system. In such a failure state, the ECD cannot receive a cryptographic erase command or respond to such a command with a status indicating that the cryptographic erase command has been successfully completed. This poses a problem for data centers that want to avoid the risk of forensically recovering data from the memory of failed solid-state drives (SSDs) or hard disk drives (HDDs) that could not be completely cryptographically erased. Today, these data centers typically resort to physically destroying these drives to prevent forensic recovery. Users cannot in good conscience return these drives to the manufacturer or reuse them for fear of data leakage.

[0004] Note that the Media Encryption Key (MEK) used to encrypt and decrypt data on the ECD is not stored in cleartext within modern SED drives. Instead, the MEK is cryptographically wrapped, e.g., it is itself encrypted or obfuscated. In the very long term, this may not be strong enough, and there are areas where it is believed that key wrapping techniques may be broken (e.g., via quantum computing) in the foreseeable future.

[0005] Regardless of the scope of the problem, or whether there should be any legitimate concerns that wrapped keys could be decrypted or cracked, it is likely true that there are entities that do not want to rely on or completely trust the drive to handle nonvolatile storage and cryptographic erasure of the MEK. To ensure that the MEK is destroyed and all ciphertext generated using it is cryptographically erased externally, such users may strongly prefer to provide the MEK to the drive after each power-on cycle rather than storing it on the ECD. This allows an external entity to control the MEK outside of the ECD, and the external entity does not need to ensure that special measures must be taken if the ECD fails in a manner that does not allow cryptographic erasure to be performed by the drive. Because the MEK is stored only nonvolatilely outside the drive, it can be destroyed by the user regardless of how the ECD failed. However, the MEK is vulnerable to capture or acquisition by compromising the user's keystore in which it is stored or by eavesdropping on the communication of the MEK to the ECD (and breaching surrounding security).

[0006] One way to enable the ability to cryptographically erase an ECD externally is through the use of the direct key serving model used by LTO-4 (the first generation of encryption-capable LTO tape drives). Note that how a key is handled external to an encryption-enabled device determines whether the key is cryptographically erasable. However, proper key management external to the ECD should ensure that all copies of the MEK associated with a failed ECD drive can be cryptographically erased. However, to ensure that the key is available for data decryption, copies of the key are typically generated and stored in distributed locations. This is because if no copies of the key remain, the data encrypted with that key, i.e., the ciphertext, becomes undecryptable and effectively inaccessible, or "cryptographically erased." Therefore, as copies of the key are increasingly generated external to the ECD to increase resiliency, ensuring secure key management becomes significantly more difficult.

[0007] Starting with LTO-4, self-encrypting drive (SED) technology has been standardized to conform to Trusted Computing Group (TCG) specifications, such as their TCG Storage Security Subsystem Classes (SSCs), including Enterprise and (more recently) Opal. Each of these SSCs supports cryptographic erase functionality within the SED drive (which is a form of ECD) in several different ways. For example, the TCG Opal SSC has at least four different methods for invoking internal cryptographic erase. However, neither of these two TCG SSCs supports cryptographic erase by an external entity independent of the SED itself, i.e., if the SED is unable to honor the method (command) specified by the SSC. The MEK is always stored within the SED, typically in a cryptographically wrapped format. If someone can somehow figure out how to break the wrapped MEK, they can recover all the associated ciphertext stored in a failed SED that complies with either Enterprise or Opal SSC.

[0008] The SSC currently under development is called Key per IO (Key per IO). The fundamental concept of SSC differs from Opal or Enterprise SSC. Instead, Key per IO is expected to require external key management, allowing multiple MEKs to be used within a single namespace—for example, a Non-Volatile Memory Express (NVMe) namespace—corresponding to a single logical block address (LBA) range on a drive (or a subset of the drive, such as the data band). All MEKs provided to an ECD compliant with the proposed Key per IO SSC are stored only in volatile form within the ECD; therefore, all MEKs typically disappear from the ECD once the device is powered off or reset. One problem with the Key per IO scheme is that it does not support internal cryptographic erasure. Therefore, if one of the externally managed MEKs were obtained, for example by an attacker, ciphertext (encrypted data) encrypted with that MEK would be accessible.

[0009] In conventional storage systems based on ECDs, when an ECD is deemed marginal—for example, defective or expected to fail soon—the first thing typically done is to begin the process of removing the marginal ECD from the storage system. Before returning the ECD to its manufacturer, all data on the ECD is typically securely erased in some manner. One way to do this is to erase all ciphertext, preferably verifying and erasing all data on the ECD. For solid-state drive (SSD)-type ECDs, this is often performed by attempting a page erase of all pages in the flash memory chips within the flash drive. This may or may not be successful. For example, some pages may not be completely erased, leaving some bits on the page undeleted, e.g., some residual ciphertext bits. In the worst case scenario (e.g., if the erase line for the page is broken), fully readable ciphertext remains. To prevent this catastrophe, standards such as NIST's SP 800-88r1 for media sanitization require drives to verify the erasure of each page by reading the erased page and verifying that all bits (or at least a sufficient sample of those bits) were actually erased (minus an acceptable background error rate). Unfortunately, it is well known that attempting to perform a page erase on every page can be unsuccessful. In the case of SP 800-88r1, if all data (e.g., ciphertext) cannot be securely erased, the drive must be physically destroyed, e.g., pulverized and incinerated. Such drives cannot be reused, or even returned to the manufacturer.

[0010] One of the changes in the r1 version of SP 800-88 is that for some types of data stored on SSD-type ECD drives, NIST has determined that cryptographic erase is an acceptable method for securely erasing or deleting the SSD (i.e., sufficient to allow the SSD to be reused or returned to the manufacturer). Therefore, for some types of storage media, such as SSD-type ECDs, a cryptographic erase is performed instead of erasing all cryptographic data. The problem is that, as currently proposed, keeper-per-IO-enabled drives cannot independently perform cryptographic erase. Therefore, the only realistic option a storage system using standard keeper-per-IO has is to transparently (to the host) wipe data on marginal drives that are removed from the system and attempt to erase all cryptographic data on them, which can fail as described in the previous paragraph. Summary of the Invention [Means for solving the problem]

[0011] With cryptographic erasure enabled, cryptographic erasure can be performed instead of erasing all ciphertext. Alternatively, cryptographic erasure can be performed in addition to erasing all ciphertext, in which case these two operations can be performed in any order.

[0012] According to one aspect of the invention, a device-implemented method includes receiving, in a device configured to perform data operations on a storage medium, one or more unique external keys, where the one or more external keys are provided to the device from one or more external sources for a key per IO operation. An internal key stored within the device is accessed. A unique MEK is generated for each of at least some of the one or more external keys using the internal key and the associated one of the one or more external keys, where each MEK is associated with the external key used to generate it. In response to receiving a request to perform a data operation for data associated with one of the one or more external keys, the media encryption key associated with that external key is used to encrypt and / or decrypt the data.

[0013] The method described above enables internal crypto-erasure of data stored in a key-per-IO scheme by enforcing the internal key, which is combined with the external key to generate a MEK, which is then used to encrypt / decrypt the tenant's data. Because there are no external tenants to the ECD and ideally no one has access to the internal key, destruction of the internal key causes the data to be crypto-erased and therefore unrecoverable.

[0014] In a preferred approach, the device is configured to prohibit the transfer of the internal key outside of the device, so that since the internal key cannot leave the device, destruction of the internal key and its associated MEK stored within the device effectively cryptographically erases all data written using the MEK and ensures that the MEK cannot be regenerated using the internal key.

[0015] In some approaches, some of the external keys are individually associated with unique data stored at different locations within the same logical block address range. Such an approach advantageously allows tenants to share the same namespace on the ECD. The internal key is combined with a first tenant's specific external key to generate a MEK, which is then used to write and read that tenant's data, so that even if multiple tenants share an address space, other tenants cannot decrypt the first tenant's data without the first tenant's external key.

[0016] According to another aspect of the invention, a device-implemented method includes receiving, at a device configured to perform data operations on a storage medium, a request to write first data to a storage medium in encrypted form using a first external key associated with the first data. An internal key stored within the device is accessed. A first MEK is generated using the internal key and the first external key. The first data is encrypted using the first MEK. The encrypted first data is written to the storage medium within a first logical block address range of the storage medium. A second request is received, the second request being to write second data to the storage medium in encrypted form using a second external key associated with second data. The internal key stored within the device is accessed, and a second MEK is generated using the internal key and the second external key. The second data is encrypted using the second MEK. The encrypted second data is written to the storage medium within a first logical block address range of the storage medium.

[0017] The above-described method allows for internal crypto-erasure of the data stored in a keeper-per-IO scheme. Furthermore, this aspect preserves the keeper-per-IO functionality that allows two or more tenants to share the same namespace on ECD without allowing one tenant to access the data of other tenants within that shared namespace.

[0018] According to yet another aspect of the present invention, a device-implemented method for cryptographic erasure receives a request to cause a cryptographic erasure of all data within at least one logical block address range of a storage medium at a device configured to perform data operations on the storage medium using Key per IO operations. Each individual portion of the data within the at least one logical block address range is associated with a unique external key, and each individual portion of the data is encrypted using a unique media encryption key generated using an internal key and the unique external key associated with the portion of data. The internal encryption of the logical block range can be achieved by destroying the common internal key associated with the logical block range and all one or more media encryption keys associated with the internal key.

[0019] The method described above allows for internal crypto-erasure of data stored encrypted with the Key-Per-IO scheme.

[0020] In a preferred approach, the device is configured to prohibit transfer of the internal key outside of the device, so that since the internal key cannot leave the device, destruction of the internal key stored within the device and all MEKs generated from it effectively cryptographically erases all data written using those MEKs and ensures that MEKs cannot be regenerated using the now-destroyed internal key.

[0021] In some approaches, some of the external keys are individually associated with unique data stored at different locations within the same logical block address range. Such an approach advantageously allows tenants to share the same namespace on the ECD. Because the internal key is combined with a tenant's specific external key to generate a MEK, which is then used to write and read that tenant's data, other tenants cannot decrypt the first tenant's data without the first tenant's external key, even if multiple tenants share the address space.

[0022] A computer program product for enabling cryptographic erasure comprises a computer-readable storage medium having a plurality of program instructions embedded therein, the plurality of program instructions being executable by a device and configured to perform data operations on the storage medium to cause the device to perform any of the methods presented herein.

[0023] Systems according to various aspects of the present invention include a device configured to perform data operations on a storage medium, such device comprising a processor and logic integrated with the processor, the logic executable by the processor or integrated with and executable by the processor, the logic configured to cause the device to perform any of the methods presented herein.

[0024] The various approaches described herein are applicable to many types of storage media, including those mentioned above, including non-volatile memory and magnetic recording tape.

[0025] Other aspects and approaches of the present invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings, illustrating by way of example the principles of the invention. [Brief explanation of the drawings]

[0026] [Figure 1] FIG. 1 is a diagram of a network architecture in accordance with one aspect of the present invention. [Figure 2] FIG. 2 is a diagram of a representative hardware environment that may be associated with the server or client, or a combination thereof, of FIG. 1, in accordance with one aspect of the present invention. [Figure 3] FIG. 3 is a block diagram of a tiered data storage system in accordance with one aspect of the present invention. [Figure 4] FIG. 4 is a flow chart diagram of a method according to one aspect of the present invention. [Figure 5] FIG. 5 is a flow chart diagram of a method according to one aspect of the present invention. [Figure 6] FIG. 6 is a flow chart diagram of a method according to one aspect of the present invention. [Figure 7] FIG. 7 is a flow chart diagram of a method according to one aspect of the present invention. [Figure 8] FIG. 8 is a chart comparing the current state of the art for retiring and securing Keeper-Per-IO enabled storage products with the procedures enabled by aspects of the present invention. DETAILED DESCRIPTION OF THE INVENTION

[0027] The following description is made for the purpose of illustrating the general principles of the present invention and is not intended to limit the inventive concepts claimed herein. Moreover, particular features described herein can be used in combination with other described features in each of the various possible combinations and permutations.

[0028] Unless otherwise defined in this specification, all words should be given the broadest possible interpretation, including the meaning suggested by this specification, the meaning understood by a person skilled in the art, or the meaning defined in dictionaries, specialized books, etc., or a combination thereof.

[0029] It should also be noted that, as used in this specification and the appended claims, the singular forms "a," "an," and "the" include plural references unless otherwise specified. It will be further understood that, as used herein, the words "comprise" and / or "comprising" specify the presence of stated features, integers, steps, operations, elements, or components, or combinations thereof, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, or components, or combinations thereof.

[0030] This specification discloses several preferred approaches for systems, methods, and computer program products for enabling locally encrypted data to be cryptographically erased by internal operations in a KeyPerIO-enabled device. In various approaches, the externally provided "encryption" key Kext is not used directly; instead, an internal key Kint is combined with Kext. The combination of these two keys is used as the actual Media Encryption Key (MEK).

[0031] In one general approach, a device-implemented method includes receiving one or more unique external keys in a device configured to perform data operations on a storage medium, where the one or more external keys are provided to the device from one or more external sources for a Key per IO operation. An internal key stored within the device is accessed. A unique MEK is generated for each of at least some of the one or more external keys using the internal key and the associated one of the one or more external keys, each MEK being associated with the external key used to generate it. In response to receiving a request to perform a data operation for data associated with one of the one or more external keys, the MEK associated with the external key encrypts and / or decrypts the data.

[0032] In another general approach, a device-implemented method includes receiving, at a device configured to perform data operations on a storage medium, a request to write first data to a storage medium in encrypted form using a first external key associated with the first data. An internal key stored within the device is accessed. A first MEK is generated using the internal key and the first external key. The first data is encrypted using the first MEK. The encrypted first data is written to the storage medium within a first logical block address range of the storage medium. A second request is received, wherein the second request writes second data to the storage medium in encrypted form using a second external key associated with the second data. The internal key stored within the device is accessed, and a second MEK is generated using the internal key and the second external key. The second data is encrypted using the second MEK. The encrypted second data is written to the storage medium at a number of second logical block addresses within a first logical block address range of the storage medium.

[0033] In yet another general approach, a device-implemented method for cryptographic erasure includes receiving, at a device configured to perform data operations on a storage medium using Key per IO operations, a request to cause cryptographic erasure of all data within at least one logical block address range of the storage medium. Each individual portion of the data within the at least one logical block address range is associated with a unique external key, and each individual portion of the data is encrypted using a unique MEK generated using an internal key and the unique external key associated with the portion of the data. Crypto-erasure is achieved by destroying the internal key and possibly one or more MEKs generated from the internal key.

[0034] Illustrated Computing Environment

[0035] Figure 1 illustrates an architecture 100 according to one approach. As shown in Figure 1, multiple remote networks 102 are provided, including a first remote network 104 and a second remote network 106. A gateway 101 may be connected between the remote network 102 and a proximate network 108. In the context of this architecture 100, the networks 104 and 106 may each take any number of forms, including, but not limited to, a local area network (LAN), a wide area network (WAN), such as the Internet, a public switched telephone network (PSTN), and an internal telephone network.

[0036] In use, gateway 101 acts as an entry point from remote network 102 to proximal network 108. In this manner, gateway 101 can function both as a router that can direct a given packet of data arriving at gateway 101, and as a switch that provides the actual path in and out of gateway 101 for a given packet.

[0037] Additionally, at least one data server 114 is provided that is connected to the proximate network 108 and accessible from the remote network 102 via the gateway 101. It should be noted that the one or more data servers 114 may comprise any type of computing device / groupware. Connected to each data server 114 are multiple user devices 116. The user devices 116 may also be directly connected through one of the networks 104, 106, and 108. Such user devices 116 may include desktop computers, laptop computers, handheld computers, printers, or any other type of logic. It should be noted that the user devices 116 may also be directly connected to any of the networks in one approach.

[0038] A peripheral device 120 or a series of peripheral devices 120, such as a facsimile machine, a printer, a storage device or system, networked or local, or a combination thereof, may be connected to one or more of networks 104, 106, and 108. It should be noted that databases or additional components, or a combination thereof, may be utilized with or integrated into any type of network element connected to networks 104, 106, and 108. In the context of this description, a network element may refer to any component of a network.

[0039] According to some approaches, the methods and systems described herein may be implemented in conjunction with and / or on a virtual system or a system emulating one or more other systems, or a combination thereof, such as, for example, IBM (登録商標) z / OS (登録商標) UNIX emulating environment (登録商標)System, Microsoft (登録商標) Windows (登録商標) UNIX Virtual Hosting Environment (登録商標) Systems, IBM (登録商標) z / OS (登録商標) Emulate the Microsoft environment (登録商標) Windows (登録商標) This virtualization or emulation or a combination of both is used in some approaches, such as VMware (登録商標) It can be enhanced through the use of software.

[0040] In more approaches, one or more networks 104, 106, and 108 may represent a cluster of systems commonly referred to as a "cloud." In cloud computing, shared resources, such as processing power, peripherals, software, data, servers, etc., are provided on an on-demand basis to any system in the cloud, thereby enabling access and distribution of services across many computing systems. Cloud computing typically involves Internet connectivity between systems operating within the cloud, although other technologies for connecting the systems may also be used.

[0041] Figure 2 shows, according to one approach, a representative hardware environment associated with a user device 116 or a data server 114, or a combination thereof, of Figure 1. Figure 2 illustrates a representative hardware configuration of a workstation having a central processing unit 210, e.g., a microprocessor, and a number of other units interconnected via a system bus 212.

[0042] The workstation shown in FIG. 2 includes random access memory (RAM) 214, read-only memory (ROM) 216, input / output (I / O) adapter 218 for connecting peripheral devices, such as disk storage 220, to bus 212, user interface adapter 222 for connecting keyboard 224, mouse 226, speakers 228, microphone 232, or other user interface devices, such as a touch screen and digital camera (not shown), or a combination thereof, to bus 212, communications adapter 234 for connecting the workstation to communications network 235 (e.g., a data processing network), and display adapter 236 for connecting bus 212 to display device 238.

[0043] The workstation may be equipped with an operating system, e.g., Microsoft (登録商標) Windows (登録商標) Operating system (OS): macOS (登録商標) , UNIX (登録商標) The preferred approach may have a standard operating system, such as a standard operating system (OS), resident thereon. It will be understood that the preferred approach may also be implemented on platforms and operating systems other than those mentioned. The preferred approach may be written using extensible markup language (XML), C or C++, or a combination thereof, or other programming languages, along with object-oriented programming techniques. Object-oriented programming (OOP), which is increasingly being used to develop complex applications, may be used.

[0044] Referring now to FIG. 3, a storage system 300 according to one approach is illustrated. Note that some of the elements illustrated in FIG. 3 may be implemented as hardware or software, or a combination thereof, according to various aspects. The storage system 300 may include a storage system manager 312 for communicating with multiple media or drives, or a combination thereof, on at least one higher storage tier 302 and at least one lower storage tier 306. The one or more upper storage tiers 302 may preferably include one or more random-access or direct-access media 304, or a combination thereof, such as hard disks (HDDs) in hard disk drives, non-volatile memory (NVM), solid-state memory (SSDs) in solid-state drives, flash memory, SSD arrays, flash memory arrays, or others described herein or known in the art, or a combination thereof. The one or more lower storage tiers 306 may preferably comprise one or more lower performance storage media 308, such as sequential access media, e.g., magnetic tape in tape drives and / or optical media, slower access HDDs, slower access SSDs, and / or others described herein or known in the art. The one or more additional storage tiers 316 may comprise any combination of storage memory media desired by the designer of the system 300. Also, either the upper storage tier 302 or the lower storage tier 306, or a combination thereof, may comprise a storage device or storage medium or a combination thereof.

[0045] Storage system manager 312 may communicate with drives or storage media 304 and 308, or a combination thereof, on one or more upper storage tiers 302 and one or more lower storage tiers 306 through a network 310, such as that shown in FIG. 3, e.g., a storage area network (SAN), or other suitable network type. Storage system manager 312 may also communicate with one or more host systems (not shown) through a host interface 314, which may or may not be part of storage system manager 312. Storage system manager 312 or any other component of storage system 300, or a combination thereof, may be implemented in hardware or software, or a combination thereof, and may utilize a processor (not shown) for command execution of a type known in the art, such as a central processing unit (CPU), field programmable gate array (FPGA), or application specific integrated circuit (ASIC). Of course, any arrangement of storage systems may be used, as would be apparent to one of ordinary skill in the art upon reading this specification.

[0046] In more detail, storage system 300 may include any number of data storage tiers, each of which may include the same or different storage media. For example, each data storage tier may include the same type of storage media, e.g., HDDs, SSDs, sequential access media (e.g., tapes in tape drives, optical disks in optical disk drives), direct access media (e.g., CD-ROMs, DVD-ROMs), or any combination of media storage types. In one such configuration, upper storage tier 302 may include a majority of SSD storage media for storing data in a higher performance storage environment, and the remaining storage tiers, e.g., including lower storage tier 306 and additional storage tier 316, may include any combination of SSDs, HDDs, tape drives, etc. for storing data in a lower performance storage environment. In this manner, data that is accessed more frequently, data that has a higher priority, data that needs to be accessed more quickly, etc. may be stored in the upper storage tier 302, while data that does not have any of these attributes may be stored in an additional storage tier 316, such as the additional storage tier 316 described above that encompasses the lower storage tier 306. Of course, those skilled in the art, upon reading this description, may devise many other combinations of storage media types for implementation into different storage schemes in accordance with the approaches and perspectives presented herein.

[0047] According to some approaches, a storage system (e.g., storage system 300) may include logic configured to receive a request to open a dataset; logic configured to determine whether the requested dataset is stored in multiple portions associated with a lower storage tier 306 of the hierarchical data storage system 300; logic configured to move each associated portion of the requested dataset to a higher storage tier 302 of the hierarchical data storage system 300; and logic configured to assemble the requested dataset from the associated portions on the higher storage tier 302 of the hierarchical data storage system 300.

[0048] Of course, this logic may be implemented according to a variety of approaches, as a method or as a computer program product in any device or system or combination thereof.

[0049] Key Per IO Basics

[0050] In some cases, it is desirable to allow different entities to use the same address space on a storage device. However, a simplistic implementation provides no guarantee of privacy to a first entity from a second entity that can simply read what the first entity wrote. One solution to this is for each entity (or tenant) to use a unique key, managed externally to the device, that the device needs to encrypt the data it writes and to decrypt those encrypted ciphertext. Such keys will be referred to herein as external keys, external MEKs, and Kexts. In particular, each tenant has its own Kext for encrypting its own data, and that Kext is different from the Kexts of other tenants. This scheme is commonly referred to as a key-per-IO scheme.

[0051] When a KeyPerIO-enabled device (e.g., an ECD, a computer, etc.) powers up, it does not have a Kext to perform encryption or decryption. Rather, a Kext is provided to it in any desired manner, such as in association 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) by which it will be referenced in the future, and the device stores it in volatile memory. Then, when the device receives a command (e.g., an NVMe command) that includes key tag T as part of the command header, the device retrieves the associated Kext from memory and uses it to encrypt plaintext data being written by the host before the ciphertext is stored to non-volatile memory, or to decrypt ciphertext data being read from non-volatile memory before the corresponding plaintext is sent to the host. The device may accumulate multiple Kexts associated with different key tags. In some approaches, if power is lost, Kexts stored only in volatile memory are lost and must be restored to the device after power is restored before they can be used again.

[0052] The goal of many Keeper-Per-IO schemes is to allow different tenants (users, applications, computers, etc.) to share the same address space. Prior to the inventive features presented herein, a tenant's Kext was used directly as the MEK to encrypt and decrypt that tenant's data. In theory, a first tenant's encrypted data is secure from plaintext access by a second tenant as long as each Kext is unique and secure from use by other tenants. If a first tenant, or the control infrastructure responsible for the first tenant's data, wants to erase the first tenant's data on the device, the first tenant destroys the first tenant's Kext outside the device, e.g., by erasing the Kext, overwriting the Kext, or otherwise destroying the Kext, e.g., by destroying the Kext, including not only any residual copies of the Kext but also any one or more copies stored in the device's internal volatile memory. Specifically, if there is any possibility that the first tenant's Kext has been provided to the device since the device's last power cycle or cold boot, the first tenant must instruct the device to erase the Kext used as the MEK within the device. Destroying all instances of the Kext both external and internal to the device will effectively cryptographically erase the MEK-encrypted data still stored on the device and recoverable from the device. However, if someone or something records the tenant's Kext (e.g., by hacking into an external key store, eavesdropping on communications to the device, etc.) and keeps a copy without the knowledge of the entity destroying the Kext instance, that person could still potentially access the tenant's data by decrypting those ciphertexts if they have network access to the device. Therefore, there is no guarantee that the data is secure, nor is there any guarantee that a definitive cryptographic erasure has been achieved.

[0053] Moreover, as mentioned above, all Kexts are externally managed, and if the storage device is powered off, all MEKs (i.e., Kexts used as MEKs) within the device should be lost because they are only stored in volatile memory. However, potential problems arise if the device or other data storage device fails or is deemed marginal and removed from service. With externally managed Kexts, it may be difficult, if not impossible, to verify that all Kexts associated with encrypting data written to the device have truly been externally destroyed, because not all copies of a given Kext may be online or may have been surreptitiously copied. Therefore, it cannot be guaranteed that all data encrypted with a given MEK on the device is unrecoverable.

[0054] The present invention provides a way to cryptographically erase data stored within a Key-Per-IO scheme internally by implementing an internal key (Kint) and combining it with a tenant's Kext to generate an MEK, which is then used to encrypt / decrypt the tenant's data. Since no tenant, and ideally no one, has access to the Kint, destruction of the Kint cryptographically erases the data.

[0055] The ratio of internal Kints to external Kexts may vary depending on the implementation. In some approaches, there may be one common Kint for all namespaces (e.g., the namespace for the entire drive). Thus, there may be a large number of external Kexts, but only one Kint. In that case, the entire device can be cryptographically erased by simply deleting the one common Kint.

[0056] In another approach, a unique Kint may be provided for each namespace or subset of namespaces, or a combination thereof, so that some devices may use multiple Kints.

[0057] Inventive Method for Enabling Cryptographic Erasure in KeyPerIO Enabled Devices

[0058] The following description discloses several preferred approaches for systems, methods, and computer program products that enable locally encrypted data to be cryptographically erased by internal operations in a KeyPerIO-enabled device, such as an ECD. Generally, data is encrypted, decrypted, or both encrypted and decrypted using a MEK generated from an external Kext and a Kint stored within a storage device, such as an ECD, SED, tape cartridge, or portable memory. Upon destruction of a Kint and all MEKs generated therefrom, all data that was stored only encrypted with that MEK is cryptographically erased and therefore unrecoverable. Similarly, destruction of all copies of a Kext cryptographically erases the data corresponding to that Kext.

[0059] Furthermore, because a Kint is combined with a tenant-specific Kext to generate an MEK, which is then used to write and read data for that tenant, other tenants cannot decrypt a first tenant's data without the first tenant's Kext, even if the tenants share an address space. Thus, multiple Kexts may be individually associated with unique data stored at different locations within the same logical block address range, i.e., the allowable range of a logical block of the storage medium (e.g., a logical block within the NVMe namespace), which may be millions of sectors long. This is not to be confused with the range of an individual write command, which will all be written using a key-per-IO with a single Kext identified by the key tag that arrived in the header of that write command.

[0060] Cryptographic Erasure in ECDs and SEDs

[0061] While much of the following description is presented in the context of an exemplary implementation using any type of SED or ECD, this is done merely for illustrative purposes and to provide a helpful context for the reader. Thus, the concepts and teachings presented below are equally applicable to implementations using storage media, such as magnetic recording tape, memory cards, optical media, etc., and related devices.

[0062] Referring now to Figure 4, there is shown a flowchart diagram of a method 400 according to one approach. Method 400 may be performed in accordance with the present invention in a variety of approaches, particularly in any of the environments depicted in the other figures described herein. Of course, more or fewer operations than those specifically depicted in Figure 4 may be included in method 400, as will be understood by those skilled in the art upon reading this specification.

[0063] The steps of method 400 may be performed by any suitable component of an operating environment. For example, in various approaches, method 400 may be performed partially or entirely by a device, such as a computer, drive, or other device having one or more processors therein. The processor, such as one or more processing circuits, one or more chips, or one or more modules implemented in hardware or software or a combination thereof, and preferably having at least one hardware component, may be utilized in any device to perform one or more steps of method 400. 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), or the like, or a combination thereof, or any other suitable computing device known in the art.

[0064] As shown in FIG. 4 , method 400 may begin at operation 402, where a device configured to perform data operations on a storage medium, such as reading, writing, or both reading and writing data from or to the storage medium, receives one or more unique external encryption keys (Kexts). The one or more Kexts are provided to the device from one or more external sources for use in key-per-IO operations. The external source may be any external source. For example, the external source may be an application running natively on a virtual machine, container, or host server that writes or reads data, or a control infrastructure that handles all key provisioning transparently to the application, virtual machine, container, or host server. The external source may also be a key store, a key server, or a user-entered key (e.g., via keyboard, inserting a flash drive, etc.).

[0065] The one or more Kexts are preferably stored only in volatile memory within the device and are therefore destroyed upon powering down or rebooting the device. The one or more Kexts may be received in any suitable manner, such as one at a time, as needed, in response to a request for a Kext (e.g., a Kext from a device), etc. For example, a Kext may be received in association with a request to read or write data stored or to be stored on a storage medium in encrypted form.

[0066] The storage medium may be of any type disclosed herein, such as a magnetic tape, a magnetic disk, an NVRAM, etc. Accordingly, the device may be any type of data storage device, such as a tape drive, an SSD, an HDD, an encryption-enabled USB drive, an NVRAM module, etc. Moreover, the device may be a removable data storage type encryption-capable drive (ECD), such as an encryption-enabled USB drive, an encryption-enabled tape drive, a self-encrypting drive (SED), etc.

[0067] In operation 404, the Kint stored within the device is accessed, for example, from the device's non-volatile memory. The non-volatile memory can be on a dedicated purpose IC, such as NAND flash, or can be embedded within a larger IC, such as an FPGA, ASIC, CPU, etc. In some approaches, the Kint is stored within the device in raw (unencrypted) form. In other approaches, the Kint is stored on the device in a wrapped form (e.g., encrypted, password-protected, obfuscated, etc.). If the Kint is stored in a wrapped form, another key, such as a password, can be obtained or received, or both obtained and received, and used to unwrap the Kint. For example, the lock / unlock PIN or password required to unlock the device can be used as a wrapping key to wrap the internal key. Alternatively, a Key Encryption Key (KEK) can be used as a wrapping key to wrap the internal key. Preferably, the only non-volatile storage of the internal key will typically be in wrapped form.

[0068] In a preferred aspect, the device is configured to prohibit any form of transfer of Kint outside the device, however a microprocessor or controller within the device may access Kint within the device.

[0069] In operation 406, a unique MEK is generated for at least some of the Kexts using a Kint and an associated one of one or more Kexts. In other words, the MEK associated with a given Kext used for its generation is different from any other MEK. Any known technique can be used to generate the MEK from a Kext and a Kint, for example, by XORing the Kext and Kint together, by applying another known hashing algorithm, by appending two keys together to generate a larger MEK, etc.

[0070] The MEK for a given data set can be generated at any desired time. In one approach, the MEK is generated in response to receiving a Kext. In another approach, the MEK is generated in response to receiving a request to perform a data operation for data associated with the Kext.

[0071] Regardless of when the MEK is generated, it may be stored volatilely within the device for use and / or reuse, or may be used for data manipulation and then discarded. Preferably, the MEK is stored only in volatile memory within the device and is therefore lost when the device is powered off or reset. This ensures that the MEK cannot be accessed from outside the device and also helps ensure that it cannot be accessed if the device is disabled.

[0072] In operation 408, in response to receiving a request to perform a data operation for data associated with one of a plurality of Kexts, the MEK associated with that Kext is used to encrypt and / or decrypt the data, e.g., using other conventional encryption / decryption techniques. For example, in response to receiving a read request, the ciphertext of the requested data is decrypted using the appropriate MEK in operation 408 to provide an unencrypted (i.e., plaintext) form of the requested data, which can then be output to the requestor. The ciphertext of the requested data may be copied into a buffer and then decrypted, or may be decrypted "on the fly" during a read. The decrypted data is output, e.g., via a host interface, to the requestor of the data.

[0073] In some approaches, the MEK is deleted upon completion of the associated request. In other approaches, the MEK may be retained in some form of volatile memory or register for reuse. In either case, the storage device may retain the Kext and associated MEK until it is told to forget them by an explicit command or reset, or until it forgets them by powering off.

[0074] Various operational aspects of Figure 4 are provided below. Such aspects are offered by way of example only and are not intended to be limiting. As noted above, while much of the discussion refers to ECDs, this is done by way of example only. Moreover, such aspects may be combined in any manner, in accordance with the multitude of possible aspects and approaches for implementing the present invention.

[0075] The MEK may be generated from two separate keys using any technique known in the art or that will become apparent to one of ordinary skill in the art upon reading this specification, or a combination thereof. For example, one method of generating a MEK that must be calculated using both Kint and Kext is to perform a calculation requiring both Kint and Kext, such as treating Kint and Kext as two independently generated random numbers and combining the two using a bitwise XOR or concatenation of these two values, to calculate the MEK.

[0076] Kint can be generated from any possible source. Kint is preferably generated inside the ECD, which is the most secure approach, since no copies of Kint need exist outside the ECD unless intentionally copied. For example, Kint could be generated in a known manner using the output of a random number generator inside the ECD.

[0077] In other approaches, Kint may be generated external to the ECD and provided to the ECD, for example, Kint may be programmed into the device during manufacturing build, programmed into the device by an administrator, or inserted into the device during configuration or formatting of the device.

[0078] In one aspect, a Kint may be unique to a particular dataset, and thus the device may store multiple unique Kints, where each unique Kint is associated with a unique dataset.

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

[0080] In an exemplary approach, Kint is a first value required in generating the MEK, e.g., a first random number of the same length (number of bits) as the MEK. Kext is a second value required in generating the MEK, e.g., a second random number of the same length as the MEK. Kint is processed with Kext in a predetermined manner to generate the MEK as a result. For example, Kint may be XORed (or otherwise) with Kext to generate the MEK. Alternatively, standard key derivation techniques (e.g., using hashing or encryption) can be used instead of an XOR operation (or otherwise) to calculate the MEK. Any form of key derivation that requires processing both Kint and Kext to calculate the MEK is potentially acceptable.

[0081] Those familiar with the intricacies of ECDs capable of supporting Key-Per-IO SSC will appreciate that there are numerous ways to implement this concept, and accordingly, the present invention is not limited to the exemplary descriptions presented herein.

[0082] In one approach, a unique Kint is created to be combined with each Kext. Alternatively, there may be fewer Kints than Kexts, down to a single aforementioned Kint that can be combined with all Kexts. Thus, potentially thousands of Kexts can be combined with several Kints or as few as one Kint; i.e., there is a many-to-many, many-to-few, or many-to-one relationship.

[0083] In another approach, the MEK is generated using multiple Kints and a single Kext. For example, two different Kints can be combined with a single Kext, so the end result is a combination of three different keys. Erasing any of the three keys cryptographically erases any data encrypted with the combined key. Thus, in some approaches, three or more keys are combined to generate a single MEK. That is, for example, if one of the Kints is common to the entire NVMe namespace and another Kint is unique to every Kext, one can use the functionality to cryptographically erase all data in the NVMe namespace at once (by overwriting or erasing the first Kint that is common to all Kexts) or per tenant (with finer granularity, per tenant by overwriting or erasing the second Kint, which may be unique to each resulting combined encryption key, within limits).

[0084] Note that there are other ways to create a dependency on more than one Kint in a Key-per-IO scheme, which can provide additional utility. For example, a tenant's data can be first encrypted using only the tenant's Kext. The resulting ciphertext can be encrypted a second time using Kint. In this case, if a keyless copy is to be performed, the dependency on Kint can be removed by performing a single decryption, which can be performed without the tenant's Key-per-IO Kext. This allows ciphertext to be copied to a replacement device without the need to securely transfer any keys (e.g., MEK or Kint) between devices. Rather, the two devices (e.g., a marginal device being removed and a spare device taking its place) can have completely independent Kints.

[0085] As will become apparent to those skilled in the art upon reading this disclosure, there are other ways to achieve similar functionality as discussed in the previous paragraph without requiring a full second encryption of all data. Thus, there is no absolute requirement that there be secure transfer of the MEK associated with the keyless copy. Solutions exist that eliminate the need for secure transfer of any key associated with the ciphertext read from the marginal device, as described in the previous paragraph.

[0086] In one exemplary approach, only the wrapped form of the Kint is stored in non-volatile memory in the ECD. Because the Kext is only stored in non-volatile form outside the ECD, it needs to be provided to (or accessed by) the ECD at least once after a power cycle or cold boot, or a combination thereof, to allow the MEK to be calculated. The MEK can be calculated only if the ECD has both the Kint and the Kext. Therefore, the Kext needs to be provided to (or accessed by) the ECD in some form. There are many ways this can be done, according to various aspects. One way is to wrap the Kext injected into the ECD with a Key Encrypting Key (KEK). Alternatively, if the ECD supports a Key Management Interoperability Protocol (KMIP) client, it may request and receive the Kext over a secure channel (e.g., protected by TLS or IPsec) from an external key manager of a type known in the art. Alternatively, the Kext may be provided to the ECD through the secure tunnel established for the Security Protocol In and Security Protocol Out commands, in the same manner as Personal Identification Numbers (PINs), for example, in clear text form.

[0087] The Kint is preferably stored in wrapped form within the ECD and is unwrappable until a wrapping key is provided (which may be a KEK or may depend on one or more passwords or one or more PINs provided to the ECD to authenticate one or more different roles (e.g., Admin1) supported by the ECD). Thus, any portion of a wrapper key provided from outside the ECD is provided to the ECD to allow the Kint to be unwrapped. Once all the information (including the Kext) necessary for the ECD to calculate the MEK is provided or accessed, the ECD can calculate the MEK and then decrypt existing ciphertext to generate the resulting plaintext (e.g., to respond to a host read) or encrypt newly received customer data in plaintext form (e.g., to respond to a host write).

[0088] In one approach, Kint is generated internally and wrapped with either the KEK or a PIN associated with an Administrative Security Provider (hereinafter "AdminSP") role, e.g., Admin1. Kint can be accessed once the KEK is injected into the ECD or once an entity, e.g., Admin1, is authenticated with a password or PIN.

[0089] The KEK or PIN wrapping a Kint may be allowed to change as part of a rekey operation. The Kint itself may also be rekeyed, but this will result in the crypto-erasure of data encrypted with the MEK generated from the Kint that was in use before the Kint was rekeyed.

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

[0091] Referring now to Figure 5, a flowchart diagram of an exemplary method 500 for writing cryptographically erasable data in a keeper-per-IO scheme is shown according to one approach. Method 500 may be performed in accordance with the present invention, among other approaches, in any of the environments illustrated in other figures described herein, particularly Figure 4. Of course, more or fewer operations than those specifically depicted in Figure 5 may be included in method 500, as will be understood by those skilled in the art upon reading this specification.

[0092] Each of the steps of method 500 may be performed by any suitable component of an operating environment. For example, in various approaches, method 500 may be performed, in part or in whole, by a device, such as a computer, a drive, or some other device having one or more processors therein. The processor, such as one or more processing circuits, one or more chips, or one or more modules, or a combination thereof, implemented in hardware or software or a combination thereof, preferably a processor having at least one hardware component, may be utilized in any device to perform one or more steps of method 500. Exemplary processors include, but are not limited to, a central processing device (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, or a combination thereof, or any other suitable computing device known in the art.

[0093] In operation 502, a request is received at a device configured to perform a key-per-IO data operation on a storage medium to write first data to the storage medium in encrypted form using a first Kint associated with the first data.

[0094] In operation 504, the Kint stored within the device is accessed.

[0095] In operation 506, a first MEK is generated using the internal key and the first external key.

[0096] In operation 508, the first data is encrypted using the first MEK.

[0097] In operation 510, 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 allowable range of logical blocks of the storage medium (e.g., within the NVMe namespace), which may be millions of sectors long. This should not be confused with the limited range of specific write commands all associated with a single Kext.

[0098] In operation 512, a second request is received at the device, the second request being a request to write second data to the storage medium in encrypted form using a second external key associated with the second data, where the second external key is different from the first external key.

[0099] In operation 514, the internal key stored within the device is accessed.

[0100] In operation 516, a second MEK is generated using the inner key and the second outer key.

[0101] In operation 518, the second data is encrypted using the second MEK.

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

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

[0104] Referring now to FIG. 6, a flowchart diagram of an exemplary method 600 for performing cryptographic erasure on data in a keeper-per-IO scheme is shown according to one approach. Method 600 may be performed in any of the environments illustrated in the other figures described herein, particularly FIGS. 4-5, in accordance with the present invention, among other approaches. Of course, as will be understood by those skilled in the art upon reading this specification, method 600 may include more or fewer operations than those specifically depicted in FIG. 6.

[0105] Each of the steps of method 600 may be performed by any suitable component of an operating environment. For example, in various approaches, method 600 may be performed, in part or in whole, by a device, such as a computer, a drive, or some other device having one or more processors therein. The processor, such as one or more processing circuits, one or more chips, or one or more modules, or a combination thereof, implemented in hardware or software or a combination thereof, preferably a processor having at least one hardware component, may be utilized in any device to perform one or more steps of method 600. Exemplary processors include, but are not limited to, a central processing device (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, or a combination thereof, or any other suitable computing device known in the art.

[0106] In operation 602, a request to cause a crypto-erasure of all data within at least one logical block address range of a storage medium is received at a device configured to perform data operations on the storage medium using key-per-IO operations. Each individual portion of the data within the at least one logical block address range is associated with a unique Kext, e.g., corresponding to a unique tenant. Each individual portion of the data is encrypted using a Kint and a unique MEK generated using the unique Kext associated with the portion of data.

[0107] In operation 604, the cryptographic erasure is accomplished by destroying both Kint and any one or more MEKs in the device that were generated from Kint (e.g., by erasing Kint, overwriting Kint, or physically destroying memory that stores Kint, or a combination thereof).

[0108] Cryptography

[0109] Kint and Kext may be XORed or otherwise combined together to generate the MEK.

[0110] One way to verify that the resulting MEK is correct (e.g., against a one-bit offset that occurs when the Kext is off by one bit) is to use the concept of key signing, which involves encrypting a known value using the MEK, and then storing the resulting ciphertext as a signature of that MEK.

[0111] Note that in some of the approaches mentioned above, both the Kext, the Kint, and any key used to wrap the Kext (e.g., the Key Encrypting Key (KEK)) and the Kint are called Cryptographically Sensitive Parameters (CSPs). If data passing between the ECD and the host can be recorded, the channel between them should be protected using some form of encryption. One key-per-IO option is to use a KEK known by the host and the ECD, where the host wraps the Kext with the KEK and sends the wrapped Kext to the ECD, and the ECD receives the wrapped Kext and unwraps it with the same KEK. Another option is to use Data in Flight (EDiF), e.g., Internet Protocol Security (IPsec), Fibre Channel-Security Protocol (FC-SP), or Transport Layer Security (TLS). Some data centers are not concerned about data passing to or from ECDs in their internal environments, only what happens to the ECD after it leaves the protected environment, hence the desire for absolute assurance of cryptographic erasure.

[0112] Note that for XTS mode encryption (e.g., XTS-AES-256), there are two encryption-related keys: an encryption key and a separate tweak key. In some approaches, both of these keys can be generated (via key derivation) from a single root key. Thus, a 256-bit MEK can be provided, and that 256-bit MEK can be used to generate (via key derivation) the two 256-bit keys required for XTS-AES-256.

[0113] Cryptographic erasure options in an ECD implementing various aspects of the present invention include not only the required destruction (e.g., by overwriting or erasure) of any MEK within the ECD, but also one or more of the following: 1. If a user wants to cryptographically erase all data on an operational ECD, the user simply invokes one of several different methods as proposed herein. For example, the wrapped key structure containing the Kint is overwritten, and the Kint is rendered unrecoverable. In this scenario, there is no need to erase all Kexts; the MEK is unrecoverable and cannot be regenerated, since the Kint is gone. 2. If the user wants to cryptographically erase the ECD (because of a non-working ECD that doesn't respond to commands, or because the ECD is missing) but is unable to perform step 1 above for some reason, the user can now instruct each tenant to erase their Kext separately from the ECD as an alternative. In this scenario, there is no need to erase all wrapped versions of Kint. Because the Kext is gone, the MEK is unrecoverable. In this scenario, even if someone were to crack the wrapped key structure of a failed ECD at some point in the future and gain access to Kint, the MEK would remain unavailable, rendering all of their work useless. Therefore, the destroyed Kext is necessary. Thus, we are still left with a scenario in which the only viable way to access customer data is to break the encryption algorithm (e.g., XTS-AES-256) that protects the ciphertext of the user data itself. 3. If the user is particularly concerned about the security of the cryptographic erase, they may choose to delete both the Kint and the Kext. This scenario is most likely if there is a concern that the Kext may have been stored (e.g., if it was protected by some wrapping or a secure channel during transfer to the ECD, but that security was (or may subsequently be) breached). However, if this is not the case, there is no reason to need to delete both the Kint and the Kext because of the encryption involved. A common approach is to be fairly resilient (e.g., until the ECD becomes inoperable) and always attempt to erase both the Kint and the Kext, but is satisfied as long as there is verification that one of these two erasures was successful. 4. If a tenant wants to cryptographically erase their data, they can revoke their Kext. Any copies of the tenant's Kext (and any associated MEKs) on the ECD must also be deleted by powering off the device or invoking the Clear Single MEK or Clear All MEKs command.

[0114] Cryptographic erasure for magnetic recording tape and other portable memories

[0115] As mentioned above, in some approaches, the encrypted data is stored on a non-volatile storage medium, such as a magnetic storage medium (e.g., tape, disk) or solid-state memory (e.g., NAND flash, NVRAM, etc.). Again, any of the operations, concepts, etc. presented above may be used in this approach. For example, the operations of methods 400 and 500 of FIGS. 4-5 may be performed with minor modifications as noted below.

[0116] In some approaches, Kint may be stored within a particular device that operates with the medium, such as a drive, computer, etc.

[0117] In other approaches, particularly those implementing removable media, the Kint is stored on or with the storage medium, or a combination thereof. Thus, methods similar to methods 400 and 500 of Figures 4-5 instead obtain the Kint from the medium on which the data is stored, or from memory physically connected to the medium, such as cartridge memory. If the Kint is destroyed, ideally the structure storing the Kint on the removable medium is destroyed.

[0118] Referring now to Figure 7, a flowchart diagram of a method 700 according to one approach is shown. Method 700 may be implemented in accordance with the present invention in a variety of approaches, particularly in any of the environments depicted in the other figures described herein. Of course, more or fewer operations than those specifically depicted in Figure 7 may be included in method 700, as will be understood by those skilled in the art upon reading this specification.

[0119] Each of the steps of method 700 may be performed by any suitable component of an operating environment. For example, in various approaches, method 700 may be performed, in part or in whole, by a device, such as a computer, a drive, or some other device having one or more processors therein. The processor, such as one or more processing circuits, one or more chips, or one or more modules, or a combination thereof, implemented in hardware or software or a combination thereof, preferably a processor having at least one hardware component, may be utilized in any device to perform one or more steps of method 700. Exemplary processors include, but are not limited to, a central processing device (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or the like, or a combination thereof, or any other suitable computing device known in the art.

[0120] 7, method 700 may begin at operation 702, in which a device configured to perform a data operation on a storage medium, such as reading or writing data from or to the storage medium, or a combination thereof, via a key-per-IO operation, receives a request to perform a data operation on the storage medium in encrypted form. The received request may simply be a request to write data, a request to read data, or both. Additionally, the request may include additional information, such as a Kext. As noted above, the Kext used in method 700 is preferably stored only in the device's volatile memory.

[0121] The Kint stored on or with the storage medium, or a combination thereof, is retrieved in operation 704. This procedure may include retrieving the Kint from the medium on which the data is stored, from memory physically connected to the medium, such as cartridge memory.

[0122] The storage medium can be of any type disclosed herein, such as a magnetic tape, a magnetic disk, an NVRAM, etc. Thus, the device can be any type of data storage device, such as a tape drive, an SSD, an HDD, etc.

[0123] As mentioned above, in some approaches, Kint is stored in raw (unencrypted) form on or with the storage medium, or a combination thereof. In other approaches, Kint is stored in a wrapped form (obfuscated, e.g., encrypted, password-protected, etc.) on or with the storage medium, or a combination thereof. Information for unwrapping Kint, such as another key, KEK, PIN, or password, can be received and used to unwrap Kint.

[0124] In a preferred aspect, the device is configured to prohibit any form of transfer of Kint outside of the device, although a microprocessor or controller within the device may access Kint from the storage medium or other source connected to the storage medium.

[0125] In operation 706, a Kext associated with the data is received from an external source, which may be any external source, such as a requester of the data, a key store, a key server, or key input by a user (e.g., via a keyboard).

[0126] An MEK is generated using Kint and Kext in operation 708. Any known secure technique may be used to generate the MEK from Kint and Kext.

[0127] In operation 710, the requested data manipulation is performed, for example, using the MEK and other conventional techniques.

[0128] In operation 712, in response to receiving a request to cryptographically erase data on the medium, the Kint is destroyed along with any MEKs that were generated using the Kint.

[0129] Second data is received when it is to be stored by the device on the storage medium. Another external key (Kext2) may be received from a second external source. In that case, a second MEK is generated using Kint and Kext2. The data manipulation is performed using the second MEK. The second external source may be the same as or different from the external source described above. However, Kext2 is different from Kext.

[0130] Various operational aspects of Figure 7 are provided below. Such aspects are presented by way of example only and are not intended to be limiting. Moreover, such aspects may be combined in any manner, in accordance with the multitude of possible approaches to the present invention. For example, method 700 may have or incorporate features similar to those presented above in connection with Figures 4-6, such as key generation.

[0131] Kint is stored with the storage medium, e.g., on the storage medium itself, with the storage medium, or a combination thereof, e.g., in separate memory. Kint is preferably stored in a wrapped format. For example, Kint may be stored on a portion of magnetic recording tape, in tape cartridge memory, or both, so that Kint is portable with the magnetic recording tape. Similarly, in the case of an NVRAM device, e.g., a memory stick, memory card, etc., Kint may be stored in the NVRAM of the device, in separate memory of the device, etc.

[0132] Kint is preferably generated internally within a device (e.g., a drive, a computer, etc.) that operates on a storage medium. Preferably, the device is configured to not allow external visibility of Kint or copying of Kint outside of the device, except for the storage medium or memory connected thereto, or a combination thereof. Preferably, the device transfers Kint to a storage medium or memory connected thereto, or a combination thereof, and then deletes Kint from elsewhere within the device. Thus, in some approaches, such as those associated with removable media devices, Kint resides only on the storage medium.

[0133] For devices where the storage medium is integrated into the device itself (e.g., a Self-Encrypting Drive (SED) type HDD or SSD, or an Encryption-Capable Drive (ECD)), the Kint may be stored within the device. For example, in a (possibly hermetically) sealed ECD enclosure, the Kint may be stored anywhere within its typical rectangular boundary. For SSDs, the main non-volatile memory (where user data is stored) is often NAND flash. The Kint (possibly in wrapped form) may be stored there as well. In other approaches, Kint may instead be maintained in a separate non-volatile memory (from the user data) within the housing, for example, in a different NAND flash chip or NOR flash chip, in magnetic random-access memory (MRAM), in spin-transfer torque random-access memory (STT-RAM), in ferroelectric random-access memory (FeRAM), in phase-change memory (PCM), in resistive random-access memory (RRAM), in other forms of NVRAM (terms less technically specific than those previously mentioned), etc. Note that Kint may also be stored in a form of ROM that can be erased. Thus, in various approaches, Kint may be stored in a different type of memory than the storage medium storing the user data.

[0134] In another approach, Kint is generated external to the device and provided to and stored within the device.

[0135] Kexts can be generated internally on the device, or externally on the device, or with joint contributions from both internal and external to the device.

[0136] In various approaches, the Kext is provided and / or stored in volatile memory (e.g., SRAM) within the tape drive, computer, etc. to enable the drive, computer, etc. to calculate the MEK. In one approach, the Kext may be entered into the tape drive, computer, etc. each time it is needed. In another approach, the Kext once provided to the device may be kept within the device stored in volatile memory of the tape drive, computer, etc., in which case the Kext is preferably wrapped.

[0137] It should be understood that the various approaches herein can be implemented with a wide range of memory media, including NVRAM technologies (e.g., including NAND flash memory, NOR flash memory, phase change memory (PCM), magnetoresistive RAM (MRAM), and resistive RAM (RRAM)). To provide context and merely to assist the reader, the various approaches may be described with reference to types of non-volatile memory. This is done by way of example only and should not be considered a limitation of the invention defined in the claims.

[0138] In one exemplary approach, Kint in non-volatile form is stored only on the storage medium in a wrapped format, and Kext may be stored temporarily in volatile memory but is only stored in non-volatile form outside the storage medium.

[0139] Drives, computers, etc. operating on the storage medium retrieve the Kint from the storage medium and receive or obtain the Kext so that the MEK can be calculated.

[0140] Kexts, which are preferably not stored locally on the drive, computer, etc., may be provided to the drive, computer, etc. in some form. There are many ways this may be done, according to various aspects, including any of the approaches listed in the previous sections. For example, one way is to have the Kext wrapped with a KEK before the host sends it to the ECD. Another way is to have the drive, computer, etc. support a KMIP client and receive the Kext over a secure channel from an external KMIP server (key manager) of a type known in the art.

[0141] Preferably, Kexts can be stored only in a volatile form inside the ECD. The key (e.g., KEK) to unwrap the Kint may be received from the host, an external security orchestrator, or the user, or may be received from a key manager, etc.

[0142] Kint is preferably stored on the storage medium in wrapped form and is unwrappable in response to the drive, computer, etc. being provided with a wrapper key (which may be, or may depend on, a KEK or a PIN provided to the drive, computer, etc. to authenticate different users for different roles supported by the drive, computer, etc.). Thus, any portion of a wrapper key provided from outside the drive, computer, etc. is provided to the drive, computer, etc. to enable Kint to be unwrapped. Once the drive, computer, etc. has accumulated all the information necessary to calculate the MEK (including Kext), the drive, computer, etc. calculates the MEK and then decrypts existing ciphertext to produce resulting plaintext (e.g., to respond to Host Reads) and encrypts new customer data in plaintext form into the ciphertext (e.g., to be able to honor Host Writes).

[0143] In Key Per IO, the creation of a Kext is done outside of the ECD by the host or by a key manager that the host interacts with.

[0144] In a tape drive implemented approach, it is preferred that Kint comes from the tape media and Kext comes from some interface, and that the MEK calculation is built into the encryption-capable tape drive and never leaves the tape drive.

[0145] Systems according to various approaches include a device configured to perform data operations on a storage medium, where the device includes a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic configured to cause the device to perform some or all of the operations described above, e.g., the operations of Figures 4-7.

[0146] A computer program product for enabling, performing, or both enabling and performing cryptographic erasure according to various approaches includes a computer-readable storage medium having program instructions embodied therein, the program instructions executable by a device configured to perform some or all of the operations described above, e.g., the operations of FIGS. 4-7.

[0147] Example Implementation

[0148] According to one approach, an exemplary process for protecting a Key per IO encryption-capable storage device, such as an Encryption-Capable Drive (ECD), includes the following acts: 1. Create a Kint and store it securely inside the storage device. Typically, a Kint is never stored in clear text format in non-volatile memory. Instead, a Kint will be stored in a wrapped format. 2. Kexts are generated and stored outside of the ECD: A. If a Kext is generated outside of the storage device, provide the Kext to the storage device as needed. B. If the key (e.g., KEK or PIN) used to wrap the Kext is not present on the device, then that key must also be provided to or fetched by the device and used to unwrap the Kext. C. Typically, many Kexts are used, e.g., one for each tenant storing data in the ECD. 3. The storage device calculates the MEK using Kint and Kext. 4. The MEK is used, directly or indirectly, to encrypt data to produce ciphertext and to decrypt ciphertext to produce plaintext.

[0149] According to one approach, an exemplary process for regaining access to data on a KeyPerIO encryption-enabled storage device, such as an encryption-enabled drive (ECD), after a power loss or cold boot includes the following actions: 1. Have the Kext provided to the storage device 2. Accessing a Kint within the storage device, which may involve cryptographically unwrapping the Kint, which may require one or more wrapping or access keys (e.g., one or more KEKs or one or more PINs). 3. The storage device calculates the MEK using Kint and Kext. 4. The MEK is used, directly or indirectly, to encrypt data to produce ciphertext and to decrypt ciphertext to produce plaintext.

[0150] Processes for retiring devices and securing stolen devices

[0151] When a storage device is to be retired, for example because its background error rate has become too great (which may occur, for example, due to too many write cycles), or perhaps because it has "failed" and not successfully completed some operation, an exemplary process that may be performed according to one approach includes the following actions: 1. Send a command to the storage device instructing it to destroy the Kint and all MEKs on the device that were generated using that Kint. 2. Was the destruction of Kint and MEK successfully completed? If: If yes, the MEK or data encrypted under those MEKs is successfully crypto-erased In this case, it is not necessary to destroy the Kext, but it is also possible to do so. If no, you cannot trust that cryptographic erasure was performed. Destroying a Kext external to the storage device, and therefore cryptographically erasing the data corresponding to the Kext on the storage device by external means. Power off or cold boot the storage device to ensure it does not hold a volatile image of the key.

[0152] Note that key deletion may also be done in reverse order, where Kext is destroyed first, and preferably an attempt to delete Kint occurs later. An exemplary process according to one approach includes the following operations: 1. Destroying a Kext external to the storage device, and thus cryptographically erasing the data corresponding to the Kext on the storage device by external means, or destroying all Kexts and cryptographically erasing all data on the storage device. 2. Send a command to the storage device instructing it to cryptographically erase one or more Kints associated with one or more Kexts corresponding to the data to be cryptographically erased. 3. Did the cryptographic erase of Kint complete successfully? If: If yes, then the MEK, or data encrypted under those MEKs, is successfully crypto-erased by the destruction of the Kint and Kext Cold boot the storage device by using the Power Cycle Reset Command or perform an actual power cycle (i.e., temporarily remove power and then save it) to ensure that the storage device does not hold a volatile image of the Kext or MEK. If no, the Kext outside of the storage device is destroyed, but the storage device is cryptographically erased by external means

[0153] Also, note that destroying or erasing all of the Kexts and MEKs can be accomplished by powering down the device or performing a cold boot (e.g., starting with a Power Cycle Reset), or a combination thereof. Thus, the MEKs can be destroyed last. However, that destruction must be performed before data encrypted with the MEKs is truly cryptographically erased. That is, to achieve cryptographic erasure of data encrypted with one or more MEKs, either a MEK and its associated Kint must be destroyed, or a MEK and its associated Kext must be destroyed.

[0154] Also, note that if a storage device is stolen or not cryptographically erased before being removed from the storage system and then lost, such as while being transported to another location, then cryptographic erasure of the data by destroying the Kint is no longer possible since there is no physical access to the storage device; instead, the Kext must be destroyed, which is possible even without physical access to the storage device unless it has been recorded (e.g., covertly).

[0155] FIG. 8 illustrates procedures that may be performed in a marginal device without aspects of the present invention, as compared to procedures that may be performed in a marginal device with one or more aspects of the present invention. The chart in FIG. 8 is provided at a glance and by way of example only. Note that performing cryptographic erasure according to the last row of the chart in FIG. 8, i.e., upon confirmation of destruction of Kint, is only possible in a keeper-per-IO environment when aspects of the present invention are implemented. Also note that once the destruction of Kint and any MEK currently in the device generated using Kint is confirmed, cryptographic erasure of the data is possible by confirming "Erase all Ciphertext" as shown in the top two rows of the table, and can be accomplished much faster (e.g., in less than one second) than what could take hours to accomplish (perhaps even a full read to confirm that all pages have been completely erased, possibly via page erase, can take several hours). Thus, aspects of the present invention can speed up sanitization of ECDs by several orders of magnitude.

[0156] A further example, not dependent on, and not precluded by, the use of aspects of the present invention, is the selective cryptographic erasure of an individual tenant's data by destroying all Kexts used in connection with encrypting that tenant's data and all MEKs generated using those Kexts. Note that if the Kints used in those Kexts span multiple tenants, such as those mentioned above, including tenants containing encrypted data that should be retained (i.e., not cryptographically erased), then the Kints will be retained within the device.

[0157] The present invention may be a system, method, or computer program product, or combination thereof, at any level of technical detail that may be integrated. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0158] The computer-readable storage medium can be a tangible device that can hold and store instructions for use by an instruction-execution device. The computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette (登録商標) , hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disc read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanically encoded device such as punch cards or raised structures in grooves on which instructions are recorded, or any suitable combination thereof. As used herein, the computer-readable storage medium should not be construed to be a transitory signal per se, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or an electrical signal transmitted over an electrical wire.

[0159] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computing device / processing device, or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may be comprised of copper transmission cables, fiber optic transmission cables, wireless transmission cables, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing device / processing device receives the computer-readable program instructions from the network and transmits the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing device / processing device.

[0160] The computer-readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for an integrated circuit, or source or object code written in any combination of one or more programming languages, such as object-oriented programming languages, e.g., Smalltalk, C++, etc., or conventional procedural programming languages ​​(e.g., the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, partially on the user's computer as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any kind of network, such as a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, such as programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform aspects of the invention.

[0161] Aspects of the present invention are described herein with reference to flowchart illustrations or block diagrams, or combinations thereof, of methods, apparatus (systems), and computer program products or computer programs according to embodiments of the invention. It will be understood that each block of the flowchart illustrations or block diagrams, or combinations thereof, and combinations of blocks in the flowchart illustrations or block diagrams, or combinations thereof, can be implemented by computer-readable program instructions.

[0162] These computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / acts specified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof, to produce a machine. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer-programmable data processing apparatus or other device, or a combination thereof, to function in a particular manner, such that a computer-readable storage medium having stored thereon includes an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof.

[0163] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on the computer, other programmable data processing apparatus, or other device, implement the functions / acts identified in one or more blocks of the flowchart diagrams or block diagrams, or a combination thereof, to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0164] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products or computer programs according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the figures. For example, two blocks shown in succession may actually be accomplished as a single step performed simultaneously, substantially simultaneously, partially, or fully in a time-overlapping manner, depending on the functionality involved, or the blocks may be performed in the reverse order. It should be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, and combinations of multiple blocks in the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special-purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special-purpose hardware and computer instructions.

[0165] Furthermore, systems according to various embodiments may include a processor and logic integrated into or executable by the processor, or a combination thereof, configured to perform one or more of the method steps recited herein. The processor may have any of the configurations described herein, such as a discrete processor or a processing circuit comprising multiple components, such as processing hardware, memory, and I / O interfaces. "Integrated" means that the processor has logic embedded in the processor, such as hardware logic, e.g., application specific integrated circuits (ASICs) and FPGAs. "Executable by a processor" means that the logic is accessible by the processor and configured to cause the processor to perform a function when executed by the processor, whether the logic is hardware logic; software logic, e.g., firmware, part of an operating system, part of an application program, etc.; or some combination of hardware logic or software logic. Software logic may be stored in any type of memory, local or remote, or a combination thereof, as known in the art. Any processor known in the art may be used, such as a software processor module, or a hardware processor, such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), and graphics processing unit (GPU).

[0166] It will be apparent that the various features of the above-described systems or methods or combinations thereof may be combined in any manner, creating multiple combinations from the description provided above.

[0167] It will be further appreciated that aspects of the present invention may be provided in the form of a service that is deployed on behalf of a customer to provide the service on demand.

[0168] The description of various aspects of the present invention has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used in this specification have been selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A device-implemented method comprising: receiving, in a device configured to perform data operations on a storage medium, one or more unique external keys, wherein the one or more external keys are provided to the device from one or more external sources for a Key per IO operation; accessing an internal key stored within said device; for each of the one or more external keys, generating a media encryption key unique to the external key using the external key and the internal key, wherein each media encryption key is associated with the external key used to generate it; and In response to receiving a request to perform a data operation for data associated with one of the one or more external keys, encrypting and / or decrypting the data using the media encryption key associated with that external key. The method comprising:

2. The device-implemented method of claim 1 , wherein the internal key is generated internally to the device.

3. 3. The device-implemented method of claim 2, wherein the internal key is stored in a wrapped format within non-volatile memory of the device.

4. The device-implemented method of claim 1 , wherein the one or more external keys and the media encryption key are stored only in volatile memory on the device.

5. 10. The device-implemented method of claim 1, wherein the device is configured to prohibit the internal key from being transferred in any form outside the device.

6. 10. The device-implemented method of claim 1, wherein some of the foreign keys are individually associated with unique data stored at different locations within the same logical block address range.

7. The device-implemented method of claim 1 , wherein at least one of the media encryption keys is generated using multiple internal keys.

8. 10. The device-implemented method of claim 1, comprising cryptographically erasing data written using the one or more media encryption keys generated using the internal key by destroying the internal key and all associated one or more media encryption keys in the device that were generated using that internal key.

9. A computer program for enabling cryptographic erasure, said computer program causing said device to carry out the steps of the method of any one of claims 1 to 8.

10. 1. A system comprising: a device configured to perform data operations on a storage medium, said device comprising a processor and logic integrated with said processor, said logic being executable by said processor or being integrated with and executable by said processor, said logic being configured to cause said device to perform a method according to any one of claims 1 to 8. The device.

11. 1. A device-implemented method comprising: receiving, at a device configured to perform data operations on a storage medium, a request to write first data to a storage medium in encrypted form using a first external key associated with the first data; accessing an internal key stored within said device; generating a first media encryption key using the internal key and the first external key; encrypting the first data using the first media encryption key; writing the encrypted first data to the storage medium within a first logical block address range of the storage medium; receiving, at the device, a second request to write second data to the storage medium in encrypted form using a second external key associated with the second data; accessing the internal key stored within the device; generating a second media encryption key using the internal key and the second external key; encrypting the second data using the second media encryption key; and writing the encrypted second data to the storage medium within a first logical block address range of the storage medium; The method comprising:

12. 12. The device-implemented method of claim 11, wherein the internal key is generated internally to the device.

13. The device-implemented method of claim 11 , comprising receiving the external key from one or more external sources.

14. 14. The device-implemented method of claim 13, wherein the external key and the media encryption key are stored only in volatile memory on the device.

15. 12. The device-implemented method of claim 11, wherein the device is configured to prohibit the internal key from being transferred in any form outside the device.

16. 12. The device-implemented method of claim 11, wherein the device is configured as a Key per IO device.

17. 1. A device-implemented method for cryptographic erasure, comprising: receiving, at a device configured to perform data operations on a storage medium using a Key per IO operation, a request to cause a cryptographic erasure of all data within at least one logical block address range of the storage medium, wherein each individual portion of the data within the at least one logical block address range is associated with a unique external key, and each individual portion of the data is encrypted using a unique media encryption key generated using an internal key and the unique external key associated with the portion of the data; and Achieving the cryptographic erasure by destroying the internal key and all one or more media encryption keys associated with the internal key within the device. The method comprising:

18. 20. The device-implemented method of claim 17, wherein the external key and the media encryption key are stored only in volatile memory on the device.

19. 20. The device-implemented method of claim 17, wherein the device is configured to prohibit the internal key from being transferred in any form outside the device.

20. 1. A system comprising:

20. A device configured to perform data operations on a storage medium, wherein the device has a processor and logic integrated with the processor, the logic being executable by the processor or integrated with the processor and executable by the processor, the logic being configured to cause the device to perform the method of claim 17. The system.

Images