DE112021005968T5 - CRYPTO DELETION OF DATA STORED IN A “KEY PER IO” ENABLED DEVICE VIA AN INTERNAL ACTION - Google Patents

Abstract

Entity-implemented methodology for enabling and/or performing crypto-erase via an internal action and/or an external action in a Key per IO enabled system. In various approaches, crypto-erasure of data stored in a "Key per IO" scheme is realized by implementing an internal key that is combined with the external key to produce a media encryption key, which in turn is used to encrypt/decrypt of data. By restricting access to the internal key, destroying the internal key and any media encryption keys generated using the internal key will result in data being crypto-erased and therefore unrecoverable.

Description

BACKGROUND

The present invention relates to crypto-erasure, and more specifically, this invention relates to techniques and systems for enabling crypto-erasure via an internal action in "Key per IO" enabled devices.

The term “crypto-wipe” generally refers to a specific manner in which access to the encryption key needed to decrypt data is disabled. This can be done by, for example, deleting all copies of the encryption key, removing a portion of the encryption key, disabling access to an associated key required to generate or unwrap the encryption key, etc. By permanently disabling the encryption key the data encrypted with this encryption key cannot be decrypted; the encrypted data is effectively placed in a non-decryptable state.

It has been discovered that a major problem with today's data centers is their inability to perform a definitive crypto wipe on all failed or decommissioned encryption-capable drives (ECDs). ECDs are capable of encryption regardless of whether it is a self-encrypting drive (SED) and regardless of the storage technology, e.g. SSDs, HDDs, hybrid data carriers consisting of both semiconductor and hard drive technology, or data carriers with alternatives Technologies. For example, it is possible for an ECD to fail in such a way that it can no longer exchange data with the system in which it resides. In such a failure condition, the ECD cannot receive a crypto-erase command or respond to such a command with a status indicating that the crypto-erase command was successfully executed. For a data center that is not willing to take the risk of having data recovered in a forensic manner from the solid state drive (SSD) or hard disk drive (HDD) of the failed ECD have to be deleted that could not be permanently crypto-deleted, this is a problem. Today, these data centers typically rely on physically destroying these disks in an effort to avoid forensic recovery. In good conscience, the user cannot return these disks to the manufacturer or use them again without fear of data disclosure.

It is important to note that the Media Encryption Key (MEK) used to encrypt and decrypt data on an ECD is not stored in plain text on modern SED disks. The MEK is instead cryptographically wrapped, e.g. self-encrypted or otherwise obfuscated. There are considerations that this may not be strong enough in the very long term, that key wrapping technology could be broken in the foreseeable future (e.g. via quantum computing).

Regardless of the scope of the problem or whether there is a valid concern that the wrapped key could be decrypted or decrypted, there may well be entities that do not want to rely on or fully trust that the disk will non-volatile storage and crypto deletion of the MEK. Such a user might very much prefer, rather than storing the MEK on the ECD, to provide the MEK to the disk each time it is turned on, to ensure that the MEK can be destroyed and all ciphertext created with it can be crypto-eraseed externally. This shifts control of the MEK to the external entity outside of the ECD, and the external entity does not have to ensure that anything extraordinary needs to be done in the event that an ECD fails in such a way that the crypto erase cannot be carried out by the disk can be carried out. Since the MEK is only stored in a non-volatile manner outside of the disk, the user has the option of deleting it regardless of how the ECD failed. A breach of the user's key store in which the MEK is stored or an eavesdropping on the data transmission (and breach of any security surrounding the data transmission) of that MEK to the ECD renders the MEK vulnerable to interception or retrieval.

One way to enable the external crypto-erase capability of an ECD is to use the direct key delivery model used in LTO-4 (the first generation of encryption-capable LTO tape drives). It should be noted that the manner in which keys are handled outside of the encryption-capable device determines whether they are crypto-erasable or not. However, if an entity's key management is properly performed outside of the ECD, it should be possible to permanently remove all copies of the MEK associated with a failed ECD volume via crypto-erase. However, copies of the key are usually created and stored in distributed locations to ensure that the key remains available for decrypting data, since if no copy remains, the data encrypted with that key, i.e. the ciphertext, cannot be decrypted and can therefore be effectively made inaccessible or “crypto-deleted”. This makes securing key management significantly more difficult as more and more copies of the key are created outside the ECD for robustness.

Following the era of LTO-4, self-encrypting disk technology (SED technology) has become the standard in the field of compliance with Trusted Computing Group (TCG) specifications such as its TCG Storage's Security Subsystem Classes (SSC) including Enterprise and (more recently) opal developed. Both of these SSCs support crypto-erase capability within the SED volumes (which is a form of ECD) in several different ways. For example, there are at least four different ways to invoke an internal crypto wipe in the case of a TCG Opal SSC. But neither of these two TCG-SSCc supports crypto-erase by an external entity independent of the SED itself, i.e. if the SED cannot process a procedure (command) specified by the SSC. The MEK is always stored in the SED, usually in a cryptographically wrapped function. If someone can somehow figure out how to break the wrapped MEK, that person can recover all of the associated ciphertext stored on a failed SED compatible with either the Enterprise or Opal SSC.

An SSC currently under development is called a “Key per IO”. The basic concept of SSC is different from both Opal and Enterprise SSCs. Key per IO is expected to require external key management instead. It allows the use of a large number of MEKs within a single namespace, such as a Non-Volatile Memory Express (NVMe) namespace, which is a logical range Block addresses (LBA range) of a disk (or a subset of that disk, such as a database). Any MEKs provided to the ECDs that are compatible with the proposed "Key per IO" SSC would only be stored on that ECD in volatile form and therefore normally disappear from this ECD as soon as the unit is switched off or reset. A problem with the "Key per IO" scheme is that it does not allow for internal crypto-wiping. For example, if one of the externally managed MEKs is obtained by an attacker, this will make the ciphertext (encrypted data) associated with that MEK accessible is encrypted.

For ECDs based on traditional storage systems, when an ECD is deemed non-essential, e.g., defective or likely to fail soon, the first action is usually to begin the process of removing that less important ECD from the storage system. Before returning it to its manufacturer, an attempt would normally be made to perform some type of secure erasure of all data on the ECD. One way to do this is to delete the entire ciphertext, preferably via a verified wipe of all data on that ECD. For an ECD in the form of a solid-state disk (SSD), this is often done by attempting to erase all of the pages in the flash memory chips in the flash disk on a page-by-page basis. This may or may not be successful. For example, it is possible that a page is not completely erased, which would leave some of the bits on the page unerased, e.g. some leftover bits of ciphertext. In the worst case (e.g. if the page delete line is interrupted), completely readable ciphertext is left behind. To protect against this worst-case scenario, standards such as National Institute of Standards and Technology (NIST) SP 800-88r1 on Media Sanitization require that media verify each page deletion by reading the pages that were deleted to ensure that all bits ( or at least a sufficient sample of these bits) have actually been cleaned (minus an acceptable background error rate). Unfortunately, it is common knowledge that attempts to perform a page delete on all pages may not be successful. In the case of SP 800-88r1, if not all data (e.g. cipher text) can be safely deleted, the data carrier must be physically destroyed, e.g. shredded and burned. Such data carriers cannot be reused nor should they be returned to the manufacturer.

One of the changes in version r1 of SP 800-88 compared to the previous version is that for certain types of data stored on SSD-type ECD disks, NIST has determined that crypto-erase is an acceptable option to securely erase or wipe the SSDs (i.e. it would then be sufficient to allow these SSDs to be reused or returned to the manufacturer). Accordingly, with certain types of storage media such as SSD type ECD an alternative to deleting the entire ciphertext is to perform a crypto wipe. The problem is that, as currently proposed, no Key per IO capable disk would be capable of independently performing a crypto erase, making the only option the storage system realistically has with the standard Key per IO is to transparently (to the host) erase the data on a non-essential disk that has been removed from a system by attempting to erase all of the ciphertext on it, which may fail, as discussed in the previous paragraph.

SHORT PRESENTATION

With crypto-wiping now possible, crypto-wiping can be performed instead of deleting the entire ciphertext. Alternatively, crypto-wiping can be done in addition to deleting the entire ciphertext. In such a case, these two operations can be performed in any order.

A method implemented by a device, according to an aspect of the present invention, includes receiving one or more unique external keys at a device configured to perform data operations on a storage medium, the one or more external keys of the device one or more external sources for a "Key per IO" operation. An internal key stored within the device is accessed. A unique MEK is created for each of at least some of the one or more external keys using the internal key and of the associated one or more external keys, each MEK being associated with the external key it is used to generate, in response to receiving a request to perform a data operation on data corresponding to one of the one or more external keys are associated, the MEK associated with this external key is used to encrypt and/or decrypt the data.

The above method enables internal crypto-erase of data stored in a "Key per IO" scheme by realizing the internal key, which is combined with the external key to generate the MEK, which in turn is used for encryption /Decryption of the user's data. Since no user and ideally no one and nothing outside the ECD has access to the internal key, destruction of the internal key results in the data being crypto-deleted and therefore unrecoverable.

In preferred approaches, the device is configured to prevent transmission of the internal key outside the device. Accordingly, since the internal key cannot leave the device, destruction of the key stored within the device and the MEKs associated with it will effectively crypto-erase all data written using the MEKs and ensure that the MEKs are not lost can be regenerated using the internal key.

In some approaches, several of the external keys are associated with individually unique data stored in different locations in a same range of logical block addresses. Such approaches advantageously allow users to share the same namespace on an ECD. Since the internal key is combined with an external key specific to a first user to create the MEK, which is subsequently used to write and read data for that user, no other user can read the first user's data without the first user's external key User's decryption, even if multiple users share an address space.

A device-implemented method according to a further aspect of the present invention includes, at a device configured to perform data operations on a storage medium, receiving a request to write first data to the storage medium in encrypted form using a first external key that is associated with the first data. An internal key stored within the unit 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 in a first range of logical block addresses of the storage medium. A second request is received, the second request being to write data in encrypted form to the storage medium 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 in the first range of logical block addresses of the storage medium is written to the storage medium.

The above method enables internal crypto-erasure of the data stored in a "Key per IO" scheme. Furthermore, this aspect allows the "Key per IO" to be maintained by two or more users who are capable of one share the same namespace on an ECD without allowing a user to access another user's data within this shared namespace.

A device-implemented crypto-erase method according to yet another aspect of the present invention includes receiving a request at a device configured to perform data operations on a storage medium using a "key per IO" operation to effect a crypto-erasure of all data in at least one range of logical block addresses of the storage medium. Individual sections of the data in the at least one range of logical block addresses are each associated with a unique external key, with the individual sections of the data each using a unique MEK created using an internal key and the unique external key associated with the section of data. Internal crypto-erase of this range of logical blocks can be achieved by using the common internal key associated with this range of logical blocks, and all media encryption keys associated with the internal key are destroyed.

The above method enables internal crypto-erasure of the data stored in encrypted form in a "Key per IO" scheme.

In preferred approaches, the device is configured to prevent transmission of the internal key outside the device. Accordingly, since the internal key cannot leave the device, destruction of the key stored within the device and any MEKs generated therefrom will effectively crypto-erase all data written using those MEKs and ensures that the MEKs are not lost Using this now destroyed internal key can be regenerated.

In some approaches, several of the external keys are associated with individually unique data stored in different locations in a same range of logical block addresses. Such approaches advantageously allow users to share the same namespace on an ECD. Because the internal key is combined with an external key specific to a user to create the MEK, which is subsequently used to write and read data for that user, no other user can read the first user's data without the first user's external key decrypt even if users share an address space.

A computer program product for enabling crypto-erasing includes a computer-readable storage medium having program instructions embodied thereon, the program instructions being executable by a device configured to perform data operations on a storage medium to cause the device to: performs any methodology presented herein.

Systems according to various aspects of the present invention include a device configured to perform data operations on a storage medium. Such a device includes a processor and logic integrated into the processor and executable by the processor, or logic integrated into the processor and executable by the processor, the logic being configured to cause the device to perform any of the methodology presented herein .

Various approaches described herein are applicable to many types of storage media, including non-volatile memory and magnetic recording tape.

Other aspects and approaches of the present invention will become apparent from the following detailed description, which, when taken in conjunction with the drawings, illustrates the principles of the invention by way of example.

BRIEF DESCRIPTION OF DRAWINGS

• 1 is a representation of a network architecture according to an aspect of the present invention.
• 2 is a representation of a representative hardware environment in accordance with an aspect of the present invention associated with the servers and/or clients of 1 can stand.
• 3 is an illustration of a tiered data storage system in accordance with one aspect of the present invention.
• 4 is a flowchart of a method according to an aspect of the present invention.
• 5 is a flowchart of a method according to an aspect of the present invention.
• 6 is a flowchart of a method according to an aspect of the present invention.
• 7 is a flowchart of a method according to an aspect of the present invention.
• 8th is a table comparing the current state of the art for decommissioning and securing "Key per IO" enabled storage products and operations enabled by aspects of the present invention.

DETAILED DESCRIPTION

The following description is intended to illustrate the general principles of the present invention and is not intended to limit the inventive concepts claimed herein. Further, certain features described herein may be used in combination with other features described in any of various possible combinations and substitutions.

Unless otherwise expressly defined herein, all terms are to be interpreted in the broadest possible sense, including meanings implied in the description, as well as meanings understandable to those skilled in the art and/or as set forth in dictionaries, treatises, etc.

It should also be noted that the singular forms “a” and “the” used in the description and the appended claims also include the plural forms unless otherwise stated. It is further understood that the terms "comprises" and "comprising/comprising" when used in this specification mean the presence of specified features, integers, steps, operations, elements and/or components, but the presence or addition of one or one or more other features, integers, steps, operations, elements, components and/or groups thereof.

The description herein discloses several preferred approaches to systems, methods, and computer program products for enabling locally encrypted data to be crypto-erased by an internal action in "Key per IO" enabled devices. In various approaches, the externally provided "encryption" -Key Kext is not used directly, but instead an internal key Kint is combined with the Kext. The combination of these two keys is used as the actual media encryption key (MEK).

In a general approach, a device implemented method includes, at a device configured to perform data operations on a storage medium, receiving one or more unique external keys, the one or more external keys of the device being one or more multiple external sources for a "key per IO" operation. An internal key stored within the device is accessed. A unique MEK is created for each of at least some of the one or more external keys using the internal key and the associated of the one or more external keys, each MEK associated with the external key it is used to generate, in response to receiving a request to perform a data operation on data associated with one of the external key(s). , the MEK associated with this external key is used to encrypt and/or decrypt the data.

In another general approach, a device implemented method includes, at a device configured to perform data operations on a storage medium, receiving a request to write first data to the storage medium in encrypted form using a first external key , which is associated with the first data. An internal key stored within the unit 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 at a specific first logical block address in a first range of logical block addresses of the storage medium. A second request is received, the second request being to write data in encrypted form to the storage medium 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 who which is encrypted using the second MEK. The encrypted second data is written to the storage medium at a specific second logical block address in the first range of logical block addresses of the storage medium.

In yet another general approach, a device-implemented crypto-erase method includes receiving a request to perform data operations on a storage medium using a key per IO operation at a device configured to perform data operations on a storage medium to effect a crypto-erasure of all data in at least one area of logical block addresses of the storage medium. Individual sections of the data in the at least one area of logical block addresses are each associated with a unique external key, the individual sections of the data each using a unique MEK encrypted using an internal key and the unique external key associated with the section of data. Crypto-erasure is achieved by destroying the internal key and any MEK or MEKs that was generated from this internal key.

Illustrative data processing environment

1 illustrates an architecture 100 according to one approach. As in 1 As shown, a plurality of 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 networks 102 and an adjacent network 108. In the context of the present network architecture 100, the networks 104, 106 may each take any form, including, but not limited to, a local area network (LAN), a wide area network (WAN), such as the Internet, the public switched telephone network (PSTN), an internal telephone network, etc.

During use, the gateway 101 serves as an entry point from the remote networks 102 into the neighboring network 108. Essentially, the gateway 101 can act as a router that can forward a specific data packet arriving at the gateway 101, and as a switch, which provides the actual path into and out of the gateway 101 for a particular packet.

Furthermore, at least one data server 114 is included, which is connected to the neighboring network 108 and is accessible from the remote networks 102 via the gateway 101. It should be noted that the data server(s) 114 may include any type of computing device/groupware. A plurality of user devices 116 are connected to each of the data servers 114. User units 116 may also be directly connected via one of the networks 104, 106, 108. Such user devices 116 may include a desktop computer, a notebook computer, a handheld computer, a printer, or any other type of logic. It should be noted that in one approach, a user device 111 may also be directly connected to any of the networks.

A peripheral device 120 or a series of peripheral devices 120, e.g., facsimile machines, printers, networked and/or local storage devices or systems, etc., may be connected to one or more of the networks 104, 106, 108. It should be noted that databases and/or other components may be used in conjunction with or integrated into any types of network elements that are connected to the networks 104, 106, 108. In the context of this description, a network element can be any component of a network.

In some approaches, methods and systems described herein may be implemented with and/or on virtual systems and/or systems that emulate one or more other systems, such as a ^UNIX® system that emulates an ^IBM® z/ ^OS® environment , a UNIX ^® system that virtually hosts a Microsoft ^® Windows ^® environment, a Microsoft ^® Windows ^® system that emulates an IBM ^® z/OS ^® environment, etc. This virtualization and/or emulation can be accomplished in some approaches the use of the Vmware ^® software can be extended.

In other approaches, one or more networks 104, 106, 108 may form 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 to any system in the cloud on an as-needed basis, allowing access and distribution of services across many computing systems is possible. Cloud computing usually requires an Internet connection between the systems operated in the cloud, but other techniques can also be used to connect systems.

2 shows a representative hardware environment associated with one approach to a user device 116 and/or the server 114 of 1 can belong. This figure illustrates a typical hardware configuration of a workstation that includes a central processing unit 210, such as a microprocessor, and a number of other units interconnected via a system bus 212.

In the 2 The workstation shown includes a random access memory (RAM) 214, a read only memory (ROM) 216, an I/O adapter 218 for connecting peripheral devices such as disk storage devices 220 to the bus 212, a User interface adapter 222 for connecting a keyboard 224, a mouse 226, a speaker 228, a microphone 232 and/or other user interface devices such as a touch screen, a digital camera (not shown), etc. to the bus 212, a data exchange adapter 234 for connecting the workstation a data exchange network 235 (eg a data processing network) and a display adapter 236 for connecting the bus 212 to a display unit 238.

The workstation may contain a resident operating system such as the Microsoft Windows® operating system (OS ⁾ , a ^macOS® , an OS ^UNIX®, etc. It will be clear that a preferred approach can also be implemented on platforms and operating systems other than those mentioned. A preferred approach may be written using the eXtensible Markup Language (XML), C and/or C++ or other programming languages in conjunction with an object-oriented programming methodology. Object Oriented Programming (OOP), which is increasingly used to develop complex applications, can be used.

Now with reference to 3 a storage system 300 is shown there according to one approach. It should be noted that some of the in 3 Elements shown can be implemented as hardware and/or software according to various aspects. The storage system 300 may include a storage system manager 312 for exchanging data with a plurality of media and/or volumes at at least one higher storage level 302 and at least one lower storage level 306. The higher storage tier(s) 302 may include one or more random access media and/or random access media 304 such as hard drives in hard disk drives (HDDs), non-volatile memory (NVM), semiconductor memory in solid state disks (SSDs), Flash memory, SSD devices, flash memory devices, etc. and/or others listed herein or known in the art. The lower storage tier(s) 306 may preferably include one or more lower performance storage media 308, including, but not limited to, sequential access media such as magnetic tape in magnetic tape drives and/or optical media, slower access HDDs, slower access SSDs, etc. and/or others listed herein or known in the art. One or more additional storage tiers 316 may include any combination of storage media desired by a designer of the system 300. Additionally, any of the higher storage levels 302 and/or the lower storage levels 306 may include a particular combination of storage devices and/or storage media.

The storage system manager 312 may communicate with the volumes and/or storage media 304, 308 at the higher storage tier(s) 302 and the lower storage tier(s) 306 via a network 310 such as a storage area network (SAN), as in 3 shown, or any other suitable network type to exchange data. The storage system manager 312 may also communicate with one or more host systems (not shown) via a host interface 314, which may or may not be part of the storage system manager 312. The storage system manager 312 and/or any other component of the storage system 300 may be implemented in hardware and/or software and may utilize a processor (not shown) to execute instructions of a type known in the art, such as a central processing unit , CPU), a field programmable gate array (FPGA), an application specific integrated circuit (ASIC), etc. Of course, any arrangement of a memory system can be used, as will be apparent to those skilled in the art after reading this Description will be apparent.

In several approaches, storage system 300 may include any number of data storage tiers and may include the same or different storage media within each storage tier. For example, each data storage tier may have the same type of storage media such as HDDs, SSDs, sequential access media (tape in tape drives, optical disk in optical disk drives, etc.), random access media (CD-ROM, DVD-ROM, etc.) or any combination of media storage types. In such a configuration, a higher storage tier 302 may include a majority of SSD storage media for storing data in a higher performance storage environment, and remaining storage media, including, but not limited to, the lower storage tier 306 and additional storage tiers 316 may include any combination of SSDs, HDDs, Tape drives, etc. for storing data in a lower performance storage environment. In this way, data that is accessed more frequently, data with a higher priority, data that needs to be accessed more quickly, etc. can be stored on the higher storage level 302, while data that has none of these attributes can be stored on the additional storage levels 316 may be stored, including at the lower storage level 306. Of course, after reading the present descriptions, those skilled in the art may devise other combinations of storage media types to implement different storage strategies in accordance with the approaches and aspects presented herein.

According to some approaches, the storage system (such as 300) may include logic configured to receive a request to open a record, logic configured to determine whether the requested record is at a lower storage level 306 one tiered data storage system 300 is stored in multiple associated sections, logic configured to move each associated section of the requested data set to a higher storage level 302 of the tiered data storage system 300, and logic configured to move the requested data set to the higher storage level 302 of the tiered data storage system 300 is composed of the associated sections.

Of course, this logic can be implemented according to various approaches as a method on any unit and/or system or as a computer program product.

"Key per IO" basics

In some cases, it is desirable to allow different entities to use the same address space in a storage unit. However, a simplistic implementation of this does not provide a first entity with any privacy assurance over a second entity that could simply read what the first entity wrote. One solution to this is to require each entity (or user) to use a unique key that it can maintain outside of the entity, where the entity must encrypt its write data and decrypt its encrypted ciphertext. This key is referred to herein as external key, external MEK and Kext. In particular, each user has a unique kext with which to encrypt that user's data, and this kext is different from the other users' kexts. This scheme is commonly referred to as the "Key per IO" scheme.

When a "Key per IO" enabled device (e.g. ECD, computer, etc.) is powered on, it does not contain kexts to perform encryption and decryption. Rather, it is provided with kexts in any desired manner, e.g. on demand, in conjunction with a Request provided for a read or write operation, etc. For example, a user may send a kext along with a key tag (e.g. T) for future reference, which the device stores in volatile memory When the device receives a command (e.g. NVMe command) that contains the key tag T as part of the command header, it retrieves the associated kext from memory and uses it to encrypt plaintext data written by the host, before the ciphertext is stored in non-volatile memory, or to decrypt ciphertext data read from non-volatile memory before the corresponding plaintext is sent to the host. This unit can accumulate multiple kexts associated with different key tags. In some approaches, in the event of a power outage, the kexts that were only stored in volatile memory are lost and therefore must be redeployed to the device after power is restored before they can be used again.

A goal of many "Key per IO" schemes is to allow different users (users, applications, computers, etc.) to share the same address space. Prior to the inventive features presented herein, a user's kext was used directly as a MEK to encrypt and decrypt the user's data. In theory, the encrypted data of a first user is safe from plaintext access by a second user as long as their respective kexts are unique to each other, and remains safe from use by the other user. If a first user or a control infrastructure that is responsible for first user data wants to delete first user data on the unit, Zer the first user interferes with the first user's kext outside the unit, for example, by deleting the kext, overwriting the kext, or otherwise destroying the kext, including, without limitation, any remaining copies of the kext not only outside the unit, but any copy or copies that stored in volatile memory within the unit. If there is a possibility that the first user's kext has been deployed to the device since the last power cycle or cold boot, the first user must instruct the first device to delete the kext used as the MEK within the device. Destroying all instances of the kext outside and inside the device will effectively crypto-delete the data encrypted with that MEK that is still stored on and can be removed from that device. However, if someone or something is able to record that user's kext unbeknownst to the entity deleting kext instances (e.g., by attempting to access (hack) the external key's storage or by eavesdropping on the key while it is to the device, etc.) and retain a copy of it, that person may still be able to access the user's data by decrypting their ciphertext if the person can connect to the device. Therefore, there can be no assurance that the data is secure nor that definitive crypto deletion has been achieved.

Furthermore, as mentioned above, all kexts are managed externally, and when the storage device is powered down, all MEKs present within the device (i.e., kexts used as MEKs) should be lost since they are only stored in volatile memory. However, a potential problem arises if the device or another data storage device fails or is deemed non-essential and should be taken out of service. Because of the possibility that not all copies of a kext are online or that this key may have been secretly copied, for kexts that are managed externally, it may be difficult, if not impossible, to ensure that all kexts that are in connection with it have actually been deleted externally involved in encrypting data written to this device. Therefore, there is no guarantee that all data encrypted with a particular MEK on the device will be unrecoverable.

The present invention provides a way to internally crypto-erase the data stored in a "Key per IO" scheme by implementing an internal key (Kint) that is combined with a user's kext to generate a MEK, which in turn is used to encrypt/decrypt the user's data. Since no user, and ideally no one, has access to the Kint, destroying the Kint will result in the data being crypto-deleted.

The ratio of internal kints to external kexts can vary from implementation form to implementation form. In some approaches, there may be a common kint for all namespaces (e.g. for the entire disk). Accordingly, there can be an enormous number of external kexts, but only one kint. In this case, the entire entity can be crypto-deleted by simply deleting the one common kint.

In other approaches, a unique kint may be provided for each namespace and/or for a subset of a namespace. Accordingly, some units may use multiple kints.

Method according to the invention for enabling crypto deletion in "Key per IO" capable units

The following description discloses several preferred approaches of systems, methods and computer program products to enable locally encrypted data to be crypto-erased by an internal action in "Key per IO" enabled devices such as ECDs. In general, data is crypto-erased using a MEK encrypted and/or decrypted created from an external kext and a kint stored within the storage device, e.g. ECD, SED, tape cartridge, portable storage, etc. Upon destruction of the kint and all MEKs created from it, All data that was stored encrypted only with this MEK will be crypto-deleted and therefore unrecoverable. Likewise, destroying all copies of a kext will crypto-delete the data that corresponds to this kext.

Furthermore, since the Kint is combined with a kext specific to a user to create the MEK, which is then used to write and read data for that user, no other user can decrypt data of the first user without the external kext of the first user , even if users share an address space. Accordingly, multiple kexts may be associated with individually unique data stored in different locations in a same range of logical block addresses, where the permitted range of logical block addresses (e.g. in the NVMe namespace) of the storage medium may be millions of sectors long. This should not be confused with the area of a single write command, which would be written with a single kext in "Key per IO", which is indicated by the key identifier that arrived in the header data of this write command.

Crypto deletion in ECD and SED

While much of the following description is presented in the context of an exemplary implementation with an SED or ECD of any type, this is provided by way of example only and solely for the purpose of providing context to assist the reader. Accordingly, the concepts and teachings presented below are equally applicable to implementations with storage media such as magnetic recording tapes, memory cards, optical media and related devices.

Now with reference to 4 a method 400 is shown there according to one approach. The method 400 may be performed in various approaches according to the present invention in any of the environments depicted in the other FIGURES described herein, among other things. Of course, the method 400 can be more or less than that in 4 include the operations specifically described, as will be clear to those skilled in the art after reading the present descriptions.

Each of the steps of method 400 may be performed by any suitable components of the operating environment. For example, in various approaches, method 400 may be performed in part or entirely by a device such as a computer, a disk, or some other device that includes one or more processors. The processor, e.g. processing circuit(s), chip(s) and/or module(s), which are implemented in hardware and/or software and preferably contain at least one hardware component, can be used in any unit to carry out one or more steps to carry out procedure 400. Illustrative processors include, but are not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., combinations thereof, and any other suitable data processing unit known in the art is known.

As in 4 As shown, method 400 may start with operation 402, in which a device configured to perform data operations on a storage medium, such as reading and/or writing data from/to the storage medium, provides one or more unique external encryption keys (Kexts) receives. The one or more kexts are provided to the device from one or more external sources for use in "Key per IO" operations. An external source can be any external source. For example, the external source can be an application running on a virtual machine, in a container, or natively on a host server that writes or reads data, or a control infrastructure that handles all provisioning of keys transparently to those applications, virtual machines, containers, or host servers. The external source could also be a key store, a key server, key entry by a user (e.g. via a keyboard, by connecting a flash drive, etc.).

The kext(s) are preferably stored in the device only in volatile memory so that they are destroyed after the device is turned off or restarted. The kext(s) may be received in any manner, e.g. on demand, all at once, in response to a request for a kext (e.g. from the device), etc. For example, a kext may be received in conjunction with a request for Reading or writing data is received that is stored in encrypted form on the storage medium or is to be stored on it.

The storage medium may be any type disclosed herein, e.g., magnetic tape, magnetic disk, NVRAM, etc. Accordingly, the device may be any type of data storage device, e.g., tape drive, SSD, HDD, encryptable USB disk, NVRAM modules, etc. In addition, the device may be an encryption-capable data carrier (ECD) in the form of a removable data storage device, e.g. an encryption-capable USB disk, an encryption-capable tape drive, a self-encrypting disk (SED), etc.

In operation 404, a Kint stored within the device is accessed, for example from non-volatile memory on the device. The non-volatile memory could be a dedicated IC such as a NAND flash, or it could be embedded in a larger IC such as an FPGA, ASIC, CPU. In some approaches, the kint is stored in the device in raw (unencrypted) form. In other approaches, the Kint is stored on the device in a wrapped form (e.g., encrypted form, password-protected form, obfuscated form, etc.). In the case where the Kint is stored in wrapped form, information such as another Key, password, etc. to unwrap the Kint can be accessed and/or received and used to unwrap the Kint. For example, a lock/unlock PIN or lock/unlock password required to unlock the device could be used as the overwrap key used to overwrap the internal key. Alternatively, a Key Encryption Key (KEK) could be used as a wrapping key to wrap the internal key. Preferably, only the non-volatile memory of the internal key would normally be in wrapped form.

In preferred aspects, the unit is configured to prevent transmission of the Kint in any form outside of the unit. However, an internal microprocessor or control unit of the unit can access the kint within the unit.

In operation 406, for each of at least some of the kexts, a unique MEK is generated using the kint and the associated one or more kexts. In other words, the MEK associated with a particular kext used to create it is different from any other MEK. Any known technique can be used to create the MEK from the kext and the kint, for example, by XORing the kext and the kint, by applying another known hashing algorithm, by joining the two keys together to create a larger MEK to create, etc.

The MEK for a specific data set can be created at any desired time. In one approach, the MEK is generated in response to receiving the kext. In another approach, the MEK is created in response to receiving a request to perform a data operation on data associated with the kext.

Regardless of when the MEK is created, it can be stored volatile within the device for use and/or reuse, can be used for a data operation and discarded, etc. Preferably, the MEK is stored only in volatile memory within the device, so that it is lost goes when the unit is powered off or reset. This helps ensure that the MEK cannot be accessed from outside nor is the unit disabled.

In operation 408, in response to receiving a request to perform a data operation on data associated with one of the kexts, the MEK associated with that kext is used to encrypt and/or decrypt the data, for example, 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, resulting in the unencrypted form (i.e., plaintext form) of the requested data, which can then be output to the requester. The ciphertext of the requested data may be copied into a buffer and then decrypted, may be decrypted during the read operation, etc. The decrypted data is output, e.g. to a requestor of the data via a host interface, etc.

In some approaches, the MEK is deleted after the associated request is executed. In other approaches, the MEK may be retained in some form of volatile memory or register for reuse. In either case, the storage unit may retain the kexts and associated MEKs until an explicit command or reset tells it to forget them, or a power down causes them to be forgotten.

Aspects of the various operations of 4 are provided below. Such aspects are provided by way of example only and are not intended to be limiting. As noted above, much of the present discussion relates to an ECD; this is merely an example. Furthermore, such aspects may be combined in any manner according to the plethora of possible aspects and approaches to practice the present invention.

A MEK may be created from two separate keys using any method known in the art and/or apparent to those skilled in the art upon reading this specification. For example, one way to create a MEK that requires using both the Kint and Kext to calculate is to require Kint and Kext to be two independently generated random numbers, and then perform a calculation using both Kint and Kext Kext such as requires a bitwise XOR of the two or a concatenation of these two values to calculate the MEK.

Kint can come from any conceivable source. Kint is preferably created internally in the ECD, which is the safest approach is because copies of Kint do not have to exist outside the ECD unless they were intentionally copied from it. For example, Kint is generated in a known manner using output from a random number generator within the ECD.

In other approaches, Kint can be created outside the ECD and deployed in the ECD. For example, Kint can be programmed into the device during build, can be programmed into the device by an administrator, can be inserted during device configuration or formatting, etc.

In one aspect, Kint may be specific to a particular set of data, and thus the entity may store multiple unique Kints, each associated with a unique data set.

Preferably, the ECD is programmed so that it does not allow visibility of the Kint from outside or transfer or copying of Kint from the ECD.

In an illustrative approach, Kint is the first value required when creating the MEK, for example a first random number with the same length (in bits) as the MEK. Kext is the second value required when creating the MEK, e.g. a second random number with the same length as the MEK. Kint is processed with Kext in a predefined manner to produce the resulting MEK. For example, Kint can be XORed (or similar) with Kext to produce the MEK. Alternatively, standard key derivation techniques (using hashing or encryption) can be used instead of the XOR operation (or the like) to calculate the MEK. Any form of key derivation that requires processing both Kint and Kext to calculate the MEK is potentially acceptable.

Anyone familiar with the complexity of an ECD capable of supporting the "Key per IO" SSC will realize that there are many, many ways to realize this concept, and this invention does not limited to the exemplary description presented herein.

A deployment creates a unique kint to combine with each of the kexts. Alternatively, there could be fewer Kints than Kexts, down to the single Kint mentioned above that can be combined with all Kexts. Accordingly, there could potentially be thousands of kexts that can be combined with several or just one kext, i.e. there is a many-to-many, many-to-fewer, or many-to-one relationship.

In another approach, the MEK is created using more than just a kint and the kext. For example, two different kints could be combined with a kext so that the net result is the combination of three different keys. Deleting any of the three keys crypto-erases any data encrypted with the combined key. Accordingly, some approaches combine more than two keys to create the MEK. For example, if one of the kints is common to the entire NVMe namespace and the other kint is unique to each kext, there is thus the ability to crypto-erase all data in the NVMe namespace at once (by overwriting or deleting the first kint, which is common to all kexts) or by a user (by overwriting or deleting the second kext, which is more fine-grained and may ultimately be unique per resulting combined encryption key).

Note that there are other forms of creating a dependency on one or more kints in a "Key per IO" scheme that may provide certain additional benefits. For example, data from a first user could initially be created using only the user's kext The resulting ciphertext can be encrypted a second time using Kint. If keyless copying is to be performed, in this case the dependency on Kint can be reversed (removed) by performing a single encryption without the user's "Key per IO" kexts can be carried out. This allows the ciphertext to be copied to a replacement device without having to securely transfer an arbitrary key (such as the MEK or Kint) from one device to another. Rather, the two units (e.g. a non-essential unit being taken out and a replacement unit taking its place) can have completely independent kints.

Other ways exist to achieve a similar capability to that discussed in the previous paragraph without requiring full secondary encryption of all data, as will become apparent to those skilled in the art after reading the present disclosure. Accordingly, there is no absolute requirement for secure transmission of a MEK associated with keyless copying. There are solutions, such as the one discussed in the previous paragraph, that... eliminate the need to perform a secure transmission of any key associated with the ciphertext read from a non-essential device.

In an illustrative approach, only a wrapped form of the Kint is stored in non-volatile memory in the ECD. The kext is only stored outside the ECD in non-volatile form and thus must be provided to the ECD (or the EDC must access it) at least once after a power cycle and/or after a cold start in order to be able to calculate the MEK. The MEK can only be calculated if the ECD has both Kint and Kext. Thus, Kext must be provided to the ECD in a specific form (or the EDC must access it). According to various aspects, there are many ways in which this can be done. One option is to inject the kext wrapped with an encryption key (KEK) into the ECD. Alternatively, if the ECD supports a Key Management Interoperability Protocol (KMIP) client, it may retrieve 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 in a manner similar to personal identification numbers (PINs), e.g. in plain text form, over a secure tunnel set up for "Security Protocol In and Security Protocol Out" commands, etc.

Kint is preferably stored in the ECD in wrapped form, which may be unwrapped until the wrapping key is provided (which may be a KEK or may instead depend on one or more passwords or one or more PIN(s). which can be provided to the ECD to check the authorization of one or more different roles that the ECD supports (e.g. Admin1)). Accordingly, any portion of the wrapping function key is provided to the ECD from outside the ECD to enable unwrapping of the kint. Once the ECD has been provided or accessed all the necessary information (including kext) necessary to calculate the MEK, the ECD calculates the MEK and is then able to decrypt existing ciphertext to the resulting plaintext (e.g. to respond to a host read operation), or to encrypt newly received customer data in plaintext form into ciphertext (e.g. to serve a host write operation).

In one approach, the Kint is generated internally and wrapped with either a KEK or the PIN associated with a specific Administrative Security Provider role (hereinafter AdminSP role), e.g. Admin1. The Kint can therefore be accessed once the KEK has been initiated into the ECD or the authorization of the entity such as Admin1 has been checked using its password or PIN.

It may be permissible for the KEK or PIN that wraps the Kint to change as part of a re-encryption operation (the wrapping key). The Kint itself can also be re-encrypted, but this would result in crypto-erasure of data encrypted by the MEKs generated from the Kint in use before the Kint was re-encrypted.

One form of implementation includes the ECD being, in some or all cases, the source of generating the kints using the same type of internal random number generation capability that is invoked, for example, by the random command.

Now with reference to 5 There is shown a flowchart of an exemplary method 500 for writing crypto-erasable data in a "Key per IO" scheme according to one approach. The method 500 can be used, among other things, in various approaches according to the present invention in any of those shown in the other FIGURES, in particular 4 , illustrated environments described herein. Of course, the method 500 can be more or less than that in 5 include the operations specifically described, as will be clear to those skilled in the art after reading the present descriptions.

Each of the steps of method 500 may be performed by any suitable components of the operating environment. For example, in various approaches, method 500 may be performed in part or entirely by a device such as a computer, a disk, or some other device that includes one or more processors. The processor, eg processing circuit(s), chip(s) and/or module(s), which are implemented in hardware and/or software and preferably contain at least one hardware component, can be used in any unit to carry out one or more steps to carry out procedure 500. Illustrative processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., combinations thereof, and any other suitable data processing unit known in the art.

In operation 502, a request is received at a device configured to perform key per IO data operations on a storage medium. The request is to write first data to the storage medium in encrypted form using a first Kint, the belongs to the first data.

In operation 504, a Kint stored within the device is accessed.

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

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

In operation 510, the encrypted first data is written to the storage medium in a first range of logical block addresses of the storage medium. The first range of logical block addresses is preferably an allowable range of logical blocks (e.g. in the NVMe namespace) of the storage medium, which may be millions of sectors long. This should not be confused with the restricted scope of the specific write command, which is all associated with a single kext.

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

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

In operation 516, a second MEK is generated using the internal key and the second external key.

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

In operation 520, the encrypted second data in the first range of logical block addresses of the storage medium is written to the storage medium. The second write operation could be to any range of logical block addresses in the permitted range of logical block addresses (e.g. in the NVMe namespace), which may or may not overlap with the range of logical block addresses written to by the first write command became.

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

Now with reference to 6 There is shown a flowchart of an exemplary method 600 for performing crypto-erase on data in a "Key per IO" scheme according to one approach. The method 600 can be used, among other things, in various approaches according to the present invention in any of those shown in the other FIGURES , especially that 4 until 5 , illustrated environments described herein. Of course, the method 600 can be more or less than that in 6 include the operations specifically described, as will be clear to those skilled in the art after reading the present descriptions.

Each of the steps of method 600 may be performed by any suitable components of the operating environment. For example, in various approaches, method 600 may be performed in part or entirely by a device such as a computer, a disk, or some other device that includes one or more processors. The processor, e.g. processing circuit(s), chip(s) and/or module(s), which are implemented in hardware and/or software and preferably contain at least one hardware component, can be used in any unit to carry out one or more steps to carry out procedure 600. Illustrative processors include, but are not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., combinations thereof, and any other suitable data processing unit known in the art is known.

In operation 602, a device configured to perform data operations on a storage medium using a "key per IO" operation is received a request to perform a crypto-erase of all data in at least a range of logical block addresses storage medium Sections of the data in the at least one range of logical block addresses are each associated with a unique kext, which corresponds, for example, to unique users. Each section of data is encrypted using a unique MEK created using a Kint and the unique Kext associated with the section of data.

In operation 604, crypto-erase is accomplished by both destroying the Kint (e.g., by deleting the Kint, overwriting the Kint, and/or physically destroying a memory that stores the Kint) and destroying any MEK(s) in the device created from this kint.

Cryptography

Kint and Kext can be XORed or otherwise combined to create the MEK.

One way to verify that the resulting MEK is correct (e.g., compared to a one-bit shift, which would occur if the kext was one-bit shifted) is to use a key signature concept. The key signature concept involves using the MEK to encrypt a known value, and the resulting ciphertext is then stored as the signature of that MEK.

Note that in some of the above approaches, both Kext, Kint, and any keys used to wrap Kext (e.g., the Key Encryption Key (KEK) and Kint have become what are known as Cryptographically Sensitive Parameters, CSPs). If there is a likelihood that the data transmitted between the ECD and the host could be recorded, the channel between them should be protected with some form of encryption. An option addressed by "Key per IO" consists of using a KEK that is known to the host and the ECD, where the host wraps the kext with the KEK before sending the wrapped KEX to the ECD, and the ECD receives this wrapped kext and unwraps it with the same KEK Another option is to use data in flight (EDiF) such as Internet Protocol Security (IPsec), Fiber Channel Security Protocol (FC-SP) or Transport Layer Security (TLS). Some data centers have no concerns about transferring data to and from an ECD in their internal environment; the concerns relate only to what happens to that ECD after it leaves this protected environment, which is why absolute certainty about crypto deletion is desirable.

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

1. 1. Wenn ein Benutzer alle Daten auf einem funktionsfähigen ECD krypto-löschen möchte, aktiviert der Benutzer hierzu einfach eine oder mehrere der hierin vorgeschlagenen Möglichkeiten. Zum Beispiel werden die umhüllten Schlüsselstrukturen überschrieben, die den Kint enthalten, sodass der Kint nun nicht mehr wiederherstellbar ist. Bei diesem Szenario besteht keine Notwendigkeit, auch jeden Kext zu löschen, die MEKs sind nicht wiederherstellbar und können nicht regeneriert werden, da der Kint nicht mehr vorhanden ist.
2. 2. Wenn ein Benutzer einen ECD krypto-löschen möchte (da es sich möglicherweise um einen nicht funktionsfähigen ECD, der nicht auf Befehle reagiert, oder um einen fehlenden ECD handelt), aber aus irgendeinem Grund den Punkt „1“ nicht durchführen kann, hat der Benutzer nun eine weitere Option, anstatt jeden Nutzer anzuweisen, seinen Kext unabhängig von dem ECD zu löschen. Bei diesem Szenario besteht keine Notwendigkeit, alle umhüllten Versionen des Kint zu löschen; der MEK ist nicht wiederherstellbar, da der Kint nicht mehr vorhanden ist. Wenn bei diesem Szenario jemand zu einem Zeitpunkt in der Zukunft die umhüllten Schlüsselstrukturen eines ausgefallenen ECD aufbricht und auf diese Weise Zugang zu dem Kint erhalten würde, wäre sein gesamtes Bemühen vergeblich, da der MEK nicht erreichbar bleibt. Deswegen benötigt er den Kext, der zerstört wurde. Dementsprechend befindet er sich nach wie vor in dem Szenario, bei dem der einzig gangbare Weg zum Zugreifen auf Kundendaten darin besteht, den Verschlüsselungsalgorithmus (z.B. XTS-AES-256) aufzubrechen, der den Chiffriertext der Benutzerdaten selbst schützt.
3. 3. Wenn ein Benutzer besonders besorgt hinsichtlich der Sicherheit des Krypto-Löschens ist, kann sich der Benutzer zum Löschen sowohl von Kint als auch Kext entscheiden. Dieses Szenario ist möglicherweise das wahrscheinlichste, wenn Bedenken bestehen, dass der Kext aufgezeichnet worden sein könnte (z.B. während der Übertragung zu dem ECD, selbst wenn er durch eine bestimmte Umhüllung oder einen sicheren Kanal geschützt ist, dessen Sicherheit aufgebrochen wurde (oder vielleicht anschließend aufgebrochen werden könnte)). Ansonsten sollte jedoch kein Grund bestehen, aus dem sowohl Kint als auch Kext gelöscht werden müssen, da die Kryptografie beteiligt ist. Ein allgemeiner Ansatz, der ziemlich widerstandsfähig ist (z.B. in Bezug darauf, dass der ECD funktionsunfähig wird), besteht darin, stets zu versuchen, sowohl den Kint als auch den Kext zu löschen, aber sich damit zu begnügen, solange eine Bestätigung dafür vorliegt, dass eine der beiden Löschungen erfolgreich war.
4. 4. Wenn ein Nutzer die Daten des Nutzers krypto-löschen möchte, kann der Nutzer den Kext des Benutzers zerstören. Eine beliebige Kopie des Kext des Nutzers auf dem ECD (und ein beliebiger zugehöriger MEK) sollten ebenfalls gelöscht werden, z.B. durch Ein- und Ausschalten der Einheit oder durch Aufruf des Befehls „Einzigen MEK löschen“ oder „Alle MEKs löschen“.

Crypto-erase options for ECDs implementing various aspects of the present invention include not only the required destruction (e.g., by overwriting or erasing) of any MEKs within the ECD, but also one or more of the following:

1. 1. If a user wishes to crypto-erase all data on a functional ECD, the user can do so by simply enabling one or more of the options suggested herein. For example, the wrapped key structures containing the kint are overwritten, making the kint unrecoverable. In this scenario there is no need to delete every kext as well, the MEKs are unrecoverable and cannot be regenerated since the kint is no longer present.
2. 2. If a user wants to crypto-erase an ECD (as it may be a non-functional ECD that does not respond to commands or a missing ECD) but for some reason cannot perform point "1". the user now has another option instead of instructing each user to delete their kext independently of the ECD. In this scenario, there is no need to delete all wrapped versions of the kint; the MEK is not recoverable because the kint is no longer present. In this scenario, if at some point in the future someone were to break open the encased key structures of a failed ECD and thus gain access to the Kint, their entire effort would be in vain as the MEK would remain inaccessible. That's why he needs the kext that was destroyed. Accordingly, it is still in the scenario where the only viable way to access customer data is through the encryption algo rithm (e.g. XTS-AES-256) that protects the ciphertext of the user data itself.
3. 3. If a user is particularly concerned about the security of crypto deletion, the user can choose to delete both Kint and Kext. This scenario is perhaps the most likely if there is concern that the kext may have been recorded (e.g. during transmission to the ECD, even if protected by a specific enclosure or secure channel, whose security was breached (or perhaps subsequently breached). could be)). Otherwise, however, there should be no reason for both Kint and Kext to need to be deleted since cryptography is involved. A general approach that is fairly resilient (e.g. in terms of the ECD becoming inoperable) is to always try to delete both the kint and the kext, but be content with doing so as long as there is confirmation of this, that one of the two deletions was successful.
4. 4. If a user wants to crypto-delete the user's data, the user can destroy the user's kext. Any copy of the user's kext on the ECD (and any associated MEK) should also be deleted, for example by power cycling the unit or by invoking the Delete Single MEK or Delete All MEKs command.

Crypto-erasing magnetic recording tape and other portable storage

As noted above, in some approaches, encrypted data is stored on a non-volatile storage medium such as a magnetic recording medium (e.g., tape, disk) or semiconductor memory (e.g., NAND flash, NVRAM, etc.). To reiterate, any of the operations, concepts, etc. set forth above may be used in the present approaches. For example, the operations of methods 400, 500 of 4 until 5 carried out with minor modifications listed below.

In some approaches, Kint can be stored in a specific device, e.g. disk, computer, etc., that works with the medium.

In other approaches, particularly those in which removable media are implemented, Kint is stored on and/or at the storage medium. Accordingly, a method similar to method 400, 500 of the 4 until 5 instead retrieve the kint from the medium on which the data is stored, from a storage such as a cartridge memory that is physically connected to the medium, and the like. In cases where the Kint is to be destroyed, the structures that store the Kint on the removable media are ideally destroyed.

Now with reference to 7 a method 700 is shown there according to one approach. The method 700 may be performed in various approaches according to the present invention in any of the environments depicted in the other FIGURES described herein, among other things. Of course, the method 700 can be more or less than that in 7 include the operations specifically described, as will be clear to those skilled in the art after reading the present descriptions.

Each of the steps of method 700 may be performed by any suitable components of the operating environment. For example, in various approaches, the method 700 may be performed in part or entirely by a device such as a computer, a disk, or some other device that includes one or more processors. The processor, e.g. processing circuit(s), chip(s) and/or module(s), which are implemented in hardware and/or software and preferably contain at least one hardware component, can be used in any unit to carry out one or more steps to carry out procedure 700. Illustrative processors include, but are not limited to, a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc., combinations thereof, and any other suitable data processing unit known in the art is known.

As in 7 As shown, method 700 may start with operation 702, in which a device configured to perform "key per IO operation" data operations on a storage medium, such as reading and/or writing data from/to the performs the storage medium, 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. Furthermore, the request may be contain additional information such as the kext. As listed above, the kexts used in method 700 are in the Unit preferably stored only in volatile memory.

In operation 704, a Kint stored on and/or at the storage medium is retrieved. This process may include retrieving the Kint from the medium on which the data is stored, from a storage such as a cartridge memory that is physically connected to the medium, and the like.

The storage medium may be any type disclosed herein, e.g., magnetic tape, magnetic disk, NVRAM, etc. Accordingly, the device may be any type of data storage device, e.g., tape drive, SSD, HDD, etc.

As noted above, in some approaches the Kint is stored on and/or at the storage medium in raw (unencrypted) form. In other approaches, the kint is stored on and/or at the storage medium in wrapped form (e.g., obfuscated form, encrypted form, password-protected form, etc.). Information such as another key, KEK, PIN, or password to unwrap the kint can be received and used to unwrap the kint.

In preferred aspects, the unit is configured to prevent transmission of the Kint in any form outside of the unit. However, an internal microprocessor or controller of the device may access the Kint from the storage medium or from another source connected to the storage medium.

In operation 706, a kext associated with the data is received from an external source. The external source can be any external source. For example, the external source may be a requestor of the data, a key store, a key server, a key input by a user (e.g. via a keyboard, etc.).

In operation 708, a MEK is created using Kint and Kext. Any known secure technique can be used to create a MEK from Kint and Kext.

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

In operation 712, in response to receiving a request to crypto-erase data on the medium, Kint is destroyed along with any MEKs created using that Kint.

When second data is to be stored on the storage medium by the device, the second data is received. Another external key (Kext2) can be received from a second external source. If this is the case, a second MEK is generated using Kint and Kext2. The data operation is performed using the second MEK. Note that the second external source may be the same as the above-mentioned external source or a different source. However, Kext2 is different from Kext.

Aspects of the various operations of 7 are provided below. Such aspects are provided by way of example only and are not intended to be limiting. Furthermore, such aspects may be combined in any manner according to the plethora of possible approaches to the present invention. For example, the method 700 may have similar features to those above in relation to 4 until 6 contain or include those set out, e.g. key generation, etc.

Kint is stored on the storage medium, e.g. on the medium itself and/or on the storage medium, e.g. in a separate memory. Kint is preferably stored in encased form. For example, Kint may be stored on a section of magnetic recording tape, in a tape cartridge memory, or both. In this way, Kint is transportable with the magnetic recording tape. Likewise, for an NVRAM device such as a memory stick, memory card, etc., Kint can be stored in the device's NVRAM, in a separate device memory, etc.

Kint is preferably created internally in the device (e.g. disk, computer, etc.) that works with the storage medium. Preferably, the device is configured to not allow visibility of the Kint from outside or copying of the Kint outside the device, except for the storage medium/or memory connected to the device. Preferably, the device transfers the Kint to the storage medium and/or memory associated with the device and deletes the Kint from other locations in the device. Thus, in some approaches, such as those associated with removable media units, the kint is located with the storage medium.

In the case of a device where the storage medium is integrated into the device itself (e.g. a self-encrypting disk (SED) of an HDD or SSD or an encryption-enabled disk (ECD)), Kint may be stored within the device. For example, Kint could be stored in a (possibly hermetically) sealed enclosure anywhere within this normally rectangular enclosure. In the case of an SSD, the bulk of the non-volatile memory (where user data is stored) is often NAND flash. Kint (possibly in enveloped form) can also be stored there. In other approaches, Kint may instead be stored in non-volatile memory separate (from user data) within the package, for example: in another NAND flash or NOR flash chip; in a magnetic random access memory (MRAM); in a spin transfer torque random access memory (STT-RAM); in a ferroelectric random access memory (FeRAM); in a phase-change memory (PCM); in a resistive random-access memory (RRAM); in other forms of NVRAM (which is less technology-specific than the previous terms); etc. It should be noted that Kint can also be stored in a form of ROM such as EEPROM, which can be erased. Thus, in different approaches, Kint can be stored in a different form of memory than the memory that stores the user data.

In other approaches, Kint can be created outside of the device and deployed to and stored in the device.

Kext can be created within the unit or outside the unit, or through shared contributions from inside and outside the unit.

In various approaches, Kext is provided and/or stored in the volatile memory (e.g. SRAM) in the tape drive, computer, etc. to enable the disk, computer, etc. to calculate the MEK. In one approach, Kext can be entered into the tape drive, computer, etc. every time it is needed. In another approach, Kext, once provided to the device, may be stored internally within the device in volatile storage on the tape drive, computer, etc., in which case Kext is preferably wrapped.

It should be understood that various approaches listed herein can be implemented with a wide range of storage media, including, for example, NVRAM technologies such as NAND flash memory, NOR flash memory, phase change memory (PCM), magneto-restrictive RAM ( MRAM) and resistive RAM (RRAM). In order to provide context solely for the convenience of the reader, various approaches may be described with reference to some type of non-volatile memory. This is by way of example only and should not be construed as limiting the invention, which is defined in the claims.

In an illustrative approach, Kint is stored in non-volatile form only on the storage medium in wrapped form. And Kext, although it can be temporarily stored in volatile memory, is only stored in non-volatile form outside the storage medium.

The disk, computer, etc. that works with the storage medium retrieves Kint from the storage medium and receives or receives Kext so that the MEK can be calculated.

Kext, which is preferably not stored locally on the disk, computer, etc., can be delivered to the disk, computer, etc. in a specific form. There are many ways in which this can be done, according to various aspects, including any of the approaches listed in the previous section. For example, one possibility is for the host to wrap the kext with a KEK before transmitting it to the ECD. Another possibility is that the disk, computer, etc. supports a KMIP client and receives the kext over a secure channel from an external KMIP server (key manager) of a type known in the art.

Preferably, Kext can only be stored in volatile form within the ECD. A Kint unwrap key (e.g. the KEK) can be received from the host, an external security orchestrator, a user, a key manager, etc.

Kint is preferably stored with the storage medium in wrapped form and can be unwrapped after the key of the wrapping function (which may be or depends on the KEK or PINs) is provided to the disk, computer, etc provided to the disk, computer, etc. to check the authorization of different users to different roles that the disk, computer, etc. supports). Accordingly, any parts of the key of the wrapping function of provided outside the disk, computer, etc. to the disk, computer, etc. to enable unwrapping of the Kint. Once the disk, computer, etc. has collected all the necessary information (including kext) necessary to calculate the MEK, the disk, computer, etc. calculates the MEK and is then able to decrypt existing ciphertext to to generate the resulting plaintext (e.g. to respond to a host read operation), or to encrypt new customer data in plaintext form into ciphertext (e.g. to serve a host write operation).

With "Key per IO" the generation of Kext takes place outside the ECD by a host or by a key manager with which the host interacts.

In approaches implemented using tape drives, it is preferred that the Kint comes from the tape media and the Kext comes from a specific interface and that the calculation of the MEK occurs internally in the encryption-capable tape drive and never leaves the tape drive.

Systems according to various approaches include a device configured to perform data operations on a storage medium, the device having a processor and logic integrated into the processor, executable by the processor, or integrated into the processor and contains logic executable by it, the logic being configured to cause the unit to perform some or all of the operations listed above, for example the operations of 4 until 7 .

Computer program products for enabling and/or performing crypto-erase in accordance with various approaches include a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a device configured to perform some or all of the operations listed above carries out, for example, the operations of the 4 until 7 .

Exemplary forms of implementation

1. 1. Erzeugen eines Kint und Speichern dieses Kint intern in der Speichereinheit in einer sicheren Weise intern in der Speichereinheit. Normalerweise würde Kint keinesfalls in Klartextform im nichtflüchtigen Speicher gespeichert werden. Stattdessen würde Kint in umhüllter Form gespeichert.
2. 2. Kext wird außerhalb des ECD erzeugt und gespeichert:
   1. A. Wenn Kext außerhalb der Speichereinheit erstellt wurde, muss dieser Kext bei Bedarf der Speichereinheit bereitgestellt werden.
   2. B. Wenn sich ein Schlüssel, der zum Umhüllen des Kext verwendet wurde (z.B. der KEK oder die PIN), nicht bereits in der Einheit befindet, muss er ebenfalls der Einheit bereitgestellt oder durch diese abgerufen und zum Aufheben der Umhüllung des Kext verwendet werden.
   3. C. Normalerweise werden viele Kexts verwendet, z.B. einer für jeden Nutzer, der Daten auf dem Datenträger speichert.
3. 3. Die Speichereinheit verwendet Kint und Kext zum Berechnen des MEK.
4. 4. Der MEK wird direkt oder indirekt verwendet, um Daten zu verschlüsseln, um Chiffriertext zu erstellen, und Chiffriertext zu entschlüsseln, um Klartext zu erstellen.

An illustrative process for protecting a key-per-IO encryptable storage device, such as an encryptable data carrier (ECD), according to one approach includes the following operations:

1. 1. Create a Kint and store this Kint internally in the storage device in a secure manner internally in the storage device. Normally Kint would not be stored in plain text form in non-volatile memory under any circumstances. Instead, Kint would be stored in sheathed form.
2. 2. Kext is created and stored outside the ECD:
   1. A. If kext was created outside the storage device, then this kext must be provided to the storage device when needed.
   2. B. If a key used to wrap the kext (e.g., the KEK or PIN) is not already in the device, it must also be provided to or retrieved by the device and used to unwrap the kext.
   3. C. Typically many kexts are used, for example one for each user storing data on the disk.
3. 3. The storage unit uses Kint and Kext to calculate the MEK.
4. 4. The MEK is used directly or indirectly to encrypt data to create ciphertext and to decrypt ciphertext to create plaintext.

1. 1. Veranlassen, dass Kext der Speichereinheit bereitgestellt wird.
2. 2. Zugreifen auf Kint intern in der Speichereinheit, was ein kryptografisches Aufheben der Umhüllung von Kint einschließen kann, was eine oder mehrere Umhüllungs- oder Zugriffsschlüssel (z.B. KEK(s) oder PIN(s)) erfordern kann.
3. 3. Die Speichereinheit verwendet Kint und Kext zum Berechnen des MEK.
4. 4. Der MEK wird direkt oder indirekt verwendet, um Daten zu verschlüsseln, um Chiffriertext zu erstellen, und Chiffriertext zu entschlüsseln, um Klartext zu erstellen.

An illustrative process after a power outage or cold boot to regain access to data on a "Key per IO" encryptable storage device, such as an encryption-capable data carrier (ECD), includes the following operations, according to one approach:

1. 1. Cause Kext to be provided to the storage device.
2. 2. Access Kint internally in the storage device, which may include cryptographically unwrapping Kint, which may require one or more wrapping or access keys (e.g., KEK(s) or PIN(s)).
3. 3. The storage unit uses Kint and Kext to calculate the MEK.
4. 4. The MEK is used directly or indirectly to encrypt data to create ciphertext and to decrypt ciphertext to create plaintext.

Process for decommissioning a unit or securing a stolen unit

1. 1. Senden eines Befehls an die Speichereinheit, der sie anweist, ihren Kint und alle MEKs zu zerstören, die sich gegenwärtig innerhalb der Einheit befinden, die durch Verwendung dieses Kint erzeugt wurden.
2. 2. Wurde das Zerstören von Kint und der MEKs erfolgreich beendet? Wenn:
   • • ja, wurden die unter diesem/diesen MEK/s verschlüsselten Daten erfolgreich krypto-gelöscht.
     • • In diesem Fall kann, obwohl keine Notwendigkeit zum Zerstören von Kext besteht, dies ebenfalls vorgenommen werden.
   • • nein, in diesem Fall, indem nicht darauf vertraut werden kann, dass ein beliebiges Krypto-Löschen stattgefunden hat:
     • • Zerstören von Kext außerhalb der Speichereinheit und somit Krypto-Löschen der Daten, die diesem Kext entsprechen, auf der Speichereinheit durch externe Mittel.
     • • Abschalten oder Kaltstarten der Speichereinheit, um sich zu vergewissern, dass die Speichereinheit kein flüchtiges Abbild eines Schlüssels aufbewahrt.

An illustrative process that can be performed when a storage device is about to be decommissioned, for example because its background error rate has become too high (which, for example, one approach includes the following operations:

1. 1. Send a command to the storage unit instructing it to destroy its Kint and any MEKs currently within the unit that were created using that Kint.
2. 2. Was the destruction of Kint and the MEKs successfully completed? If:
   • • Yes, the data encrypted under this MEK/s has been successfully crypto-deleted.
     • • In this case, although there is no need to destroy kext, this can also be done.
   • • no, in this case, by not being able to trust that any crypto deletion has taken place:
     • • Destroying kext outside the storage device and thus crypto-deleting the data corresponding to that kext on the storage device by external means.
     • • Shut down or cold boot the storage device to ensure that the storage device does not retain a volatile image of a key.

1. 1. Zerstören von Kext außerhalb der Speichereinheit und somit Krypto-Löschen der Daten auf der Speichereinheit, die diesem Kext entsprechen, durch externe Mittel, oder Zerstören aller Kexts zum Krypto-Löschen aller Daten auf der Speichereinheit.
2. 2. Senden eines Befehls an die Speichereinheit, der sie zum Krypto-Löschen ihres/ihrer Kint(s) anweist, die dem/den Kext(s) zugehörig sind, der/die den Daten entspricht/entsprechen, die krypto-gelöscht werden sollen.
3. 3. Wurde das Krypto-Löschen von Kint erfolgreich beendet? Wenn:
   • • ja, wurden die unter diesem/diesen MEK/s verschlüsselten Daten durch Zerstörung von Kint und Kext erfolgreich krypto-gelöscht.
     • • Kaltstarten der Speichereinheit durch Verwendung des Einschalten-Ausschalten-Rücksetzbefehls oder Durchführen eines tatsächlichen Ein- und Ausschaltens (d.h. Trennen der Stromversorgung während eines Zeitraums und anschließendes Wiederherstellen der Stromversorgung), um sicherzustellen, dass die Speichereinheit kein flüchtiges Abbild eines beliebigen Kext oder MEK aufbewahrt.
   • • nein, aber der Kext außerhalb der Speichereinheit wurde zerstört, und somit wird ein Krypto-Löschen der Speichereinheit durch externe Mittel herbeigeführt.

Note that a key deletion can also be done in reverse order, destroying Kext first, preferably with a subsequent attempt to delete Kint. An illustrative process according to one approach includes the following operations:

1. 1. Destroying kext outside the storage unit and thus crypto-wiping the data on the storage unit corresponding to that kext by external means, or destroying all kexts to crypto-erase all data on the storage unit.
2. 2. Sending a command to the storage device instructing it to crypto-erase its kint(s) associated with the kext(s) corresponding to the data to be crypto-erase .
3. 3. Was the Kint crypto wipe completed successfully? If:
   • • yes, the data encrypted under this MEK/s has been successfully crypto-deleted by destroying Kint and Kext.
     • • Cold booting the storage device by using the power-on-power-off reset command or performing an actual power cycle (i.e., removing power for a period of time and then restoring power) to ensure that the storage device does not retain a volatile image of any Kext or MEK .
   • • no, but the kext outside the storage unit has been destroyed, and thus a crypto-erase of the storage unit is caused by external means.

It should also be noted that destruction or deletion of all Kexts and MEKs can be accomplished by powering off the unit and/or performing a cold boot (e.g., invoked by invoking a power cycle reset). These MEKs can be destroyed last. But this destruction must be carried out before the data encrypted with these MEKs is truly crypto-deleted. In short, to achieve crypto-wiping of data encrypted with one or more MEKs, either the MEKs and the associated kint must be destroyed, or the MEKs and the associated kexts must be destroyed.

It should also be noted that if a storage unit is stolen or has not been crypto-erased before being removed from the storage system and is then lost, for example when being moved to another location, this is a crypto-erase of data through destruction of Kint is no longer possible because there is no physical access to the storage unit, instead Kext must be deleted, which is possible even without physical access to the storage unit as long as Kext has not been recorded (e.g. secretly).

8th depicts operations that can be performed on a non-essential device without aspects of the present invention contrasted with operations that can be performed on a non-essential device with one or more aspects of the present invention. The table in 8th is self-explanatory and only presented as an example. It should be noted that the execution of crypto delete according to the last row of the table in 8th , that is, by confirmed destruction of the Kint, is only possible in a "Key per IO" environment when aspects of the present invention are implemented. It should also be noted that if confirmed destruction of Kint and any MEKs is achieved, which are currently in of the unit generated by using Kint, the crypto-erase of the data is achievable much faster (e.g. in less than a second) than is possible by confirming "erase all ciphertext", such as two lines above it, which could take many hours to achieve (just fully confirming through reads that all pages have been thoroughly deleted, possibly through page deletion, can take hours). Accordingly, aspects of the present invention can speed up the cleanup of an ECD by several orders of magnitude.

Another case that neither relies on nor is prevented from using aspects of the present invention is the selective crypto-wiping of an individual user's data by destroying all kexts and all MEKs created by using the kexts were created that were used in connection with the encryption of that user's data. Note that if the kint used with these kexts extends to multiple users, including those with encrypted data that is not intended to be retained (i.e. not crypto-deleted), that kint will be kept internal to the unit.

The present invention may be a system, a method and/or a computer program product with any possible level of integration of technical details. The computer program product may include a computer-readable storage medium (or media) on which computer-readable program instructions are stored to cause a processor to carry out aspects of the present invention.

The computer-readable storage medium may be a tangible device on which instructions may be retained and stored for use by an instruction-executing device. The computer-readable storage medium may 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 of the foregoing. A non-exhaustive list of more specific examples of the computer-readable storage medium includes the following: a portable computer diskette, a hard drive, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable read-only memory in the form of a compact disc (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically coded unit such as punch cards or raised structures in a groove with instructions recorded thereon, or any suitable combination of the foregoing. A computer-readable storage medium as used herein shall not be construed as being transient signals per se, such as radio waves or freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media ( e.g. light pulses passing through an optical fiber cable) or electrical signals that are transmitted via a cable.

Computer-readable program instructions described herein may be transmitted via a network, for example the Internet, a local network, a wide area network and/or a wireless network, from a computer-readable storage medium to relevant data processing/processing units or to an external computer or an external storage unit can be downloaded. The network may include copper transmission cables, fiber optic transmission conductors, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or a network interface in the data processing/processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective data processing/processing unit.

Computer-readable program instructions for performing operations of the present invention may be assembler instructions, instruction-set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including, but not limited to, object-oriented programming languages such as Smalltalk, C++ or the like, as well as procedural programming languages such as 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, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the Compu The user's device may be connected over any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (for example, via the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLA), that execute computer-readable program instructions by reading state information from those read by a computer Readable program instructions can be used to personalize the electronic circuit to carry out aspects of the present invention.

Aspects of the present invention are described herein with reference to flowchart illustrations and/or block diagrams of methods, devices (systems) and computer program products according to embodiments of the invention. It will be understood that each block of the flowcharts and/or the block diagrams and combinations of blocks in the flowcharts and/or block diagrams may be implemented using computer-readable program instructions.

These computer program instructions may be provided to a processor of a computer or other programmable data processing device to create a machine, such that the instructions executed via the processor of the computer or other programmable data processing device provide a means for the processing in a block or blocks to implement the functions/actions specified in the flow diagram or flow diagrams and/or the block diagram or block diagrams. These computer-readable program instructions may also be stored in a computer-readable medium that can instruct a computer, other programmable data processing device, or other device to function in a particular manner, such that the computer-readable medium has instructions stored thereon Product that contains instructions that implement the function/action specified in a block or blocks of the flowcharts and / or the block diagrams.

The computer readable program instructions may also be loaded into a computer, other programmable data processing devices, or other devices to cause the computer, other programmable devices, or other devices to perform a series of operations to perform a computer realized process so that the instructions executed on the computer, on other programmable devices or units, implement the functions/actions specified in a block or blocks of the flowcharts and / or the block diagrams.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present invention. In this context, each block in the flowcharts or block diagrams may represent a module, segment, or section of instructions that includes one or more executable instructions for implementing the specified logic function or functions. In some alternative implementations, the functions specified in the block may be performed in a different order than that specified in the figures. For example, two blocks shown one after the other may actually be executed as one step, executed simultaneously, substantially simultaneously, in a partially or completely overlapping time manner, or the blocks may sometimes be executed in reverse order depending on the functionality associated with the blocks. In addition, it should be noted that each block of the block diagrams and/or flowchart representations, as well as combinations of blocks in the block diagrams and/or flowchart representations, are implemented using dedicated hardware-based systems for carrying out the specified functions or actions, or using combinations of dedicated hardware and dedicated computer instructions can or can be.

Additionally, according to various embodiments, a system may include a processor and logic integrated into or executable by the processor, the logic configured to perform one or more of the process steps listed herein. The processor may be of any configuration as described herein, such as a discrete processor or a processing circuit that includes many components such as processing hardware, memory, I/O interfaces, etc. By "integrated in" it is meant that the processor contains logic that is embedded within it as hardware logic, such as an application-specific integrated circuit (ASIC), an FPGA, etc. By “executable by the processor” it is meant that the logic is hardware logic; Software logic such as firmware, part of an operating system, part of an application program; etc. or a combination of hardware and software logic accessible to the processor and configured to cause the professor to perform a specific functionality when executed by the processor. Software logic may be stored on local and/or remote memory of any type of memory known in the art. Any processor known in the art, such as a software processor module and/or a hardware processor such as an ASIC, an FPGA, a central processing unit (CPU), an integrated circuit (IC), a graphics processing unit , GPU) etc. can be used.

It will be appreciated that various features of the aforementioned systems and/or methodologies may be combined in any manner, thereby creating a variety of combinations from the descriptions set forth above.

It will be further understood that aspects of the present invention may be provided in the form of a service provided on behalf of a customer to provide an on-demand service.

The descriptions of the various aspects of the present invention are intended to be illustrative, but are not intended to be exhaustive or limited to the approaches disclosed. Many modifications and variations are conceivable for those skilled in the art without these representing a deviation from the scope of the aspects described. The terminology used herein was chosen to explain the basic ideas of the various approaches, the practical application and/or the technical improvement over the technologies found on the market, or to enable others with appropriate expertise to understand the approaches disclosed herein.

Claims (20)

Method implemented by means of a unit, which has: Receive, for a device configured to perform data operations on a storage medium, one or more unique external keys, the one or more external keys of the device from one or more external sources for a "Key per IO" surgery will be provided; accessing an internal key stored within the device; Generating a unique media encryption key for each of at least some of the one or more external keys using the internal key and the associated one or more external keys, each media encryption key being associated with the external key it is used to generate; and in response to receiving a request to perform a data operation on data associated with one of the one or more external keys, using the media encryption key associated with that external key to encrypt and/or decrypt the data. Method implemented using a unit Claim 1 , where the internal key is generated internally in the unit. Method implemented using a unit Claim 2 , where the internal key is stored in the device's non-volatile memory in wrapped form. Method implemented using a unit Claim 1 , where one or more external keys and the media encryption keys are stored in volatile memory only on the device. Method implemented using a unit Claim 1 , where the unit is configured to prevent transmission of the internal key in any form outside the unit. Method implemented using a unit Claim 1 , where several of the external keys are associated with individually unique data stored in different locations in a same range of logical block addresses. Method implemented using a unit Claim 1 , wherein at least one of the media encryption keys is generated using more than one internal key. Method implemented using a unit Claim 1 which involves performing crypto-erase of data written using the one or more media encryption keys created using the internal key, by destroying the internal key and any associated media encryption keys in the device that were created using that internal key. A computer program product for enabling crypto-erasing, the computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a device configured to perform data operations on a storage medium to cause the unit follows the procedure Claim 1 carries out. System comprising: the device configured to perform data operations on a storage medium, the device having a processor and logic integrated into the processor, executable by the processor, or integrated into the processor and through contains executable logic, the logic being configured to cause the unit to carry out the method Claim 1 carries out. Method implemented by means of a unit, which has: Receiving, at a device, a request to write first data to the storage medium in encrypted form using a first external key associated with the first data; accessing an internal key stored within the 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 in a first range of logical block addresses of the storage medium; receiving, at the unit, a second request to write second data in encrypted form to the storage medium 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 in the first range of logical block addresses of the storage medium. Method implemented using a unit Claim 11 , where the internal key is generated internally in the unit. Method implemented using a unit Claim 11 , which includes receiving the external keys from one or more external sources. Method implemented using a unit Claim 13 , where the external keys and the media encryption keys are stored in volatile memory only within the device. Method implemented using a unit Claim 11 , where the unit is configured to prevent transmission of the internal key in any form outside the unit. Method implemented using a unit Claim 11 , where the unit is configured as a "Key per IO" unit. Method for crypto deletion implemented by means of a unit, the method comprising: Receive, at a device configured to perform data operations on a storage medium using a "Key per IO" operation, a request to effect a crypto-erase of all data in at least a range of logical block addresses of the storage medium , individual portions of the data in the at least one range of logical block addresses, each associated with a unique external key, the individual portions of the data each being encrypted using a unique media encryption key created using an internal key and the unique external key , which is associated with the section of data; and Achieving crypto-erase by destroying the internal key and any media encryption keys associated with it in the device. Method implemented using a unit Claim 17 , where the external keys and the media encryption keys are stored in volatile memory only within the device. Method implemented using a unit Claim 17 , where the unit is configured to prevent transmission of the internal key in any form outside the unit. System comprising: the device configured to perform data operations on a storage medium, the device having a processor and logic integrated into the processor, executable by the processor, or integrated into the processor and through contains executable logic, the logic being configured to cause the unit to carry out the method Claim 17 carries out.

Images