Erasing data stored in a key per IO enabled device via internal action encryption

Abstract

A device-implemented method for enabling and / or performing cryptographic wipe via internal action and / or external action in a system supporting Key per IO. In different approaches, cryptographic wipe of data stored in a Key per IO scheme is enabled by implementing an internal key that is combined with an external key to generate a media encryption key that in turn is used to encrypt / decrypt data. By limiting access to the internal key, destruction of the internal key and all media encryption keys created using the internal key causes the data to be cryptographically wiped and thus unrecoverable.

Description

Background Technology

[0001] This invention relates to crypto-erasure, and more specifically, to a technique and system for implementing crypto-erasure via internal actions in a device that supports Key perIO.

[0002] The term "encryption erasure" generally refers to disabling access to the encryption key required to decrypt data in some way. This can be achieved by erasing all copies of the encryption key, deleting a portion of the encryption key, or prohibiting access to the keys required to generate or decrypt the encryption key. By permanently disabling the encryption key, data encrypted with that key cannot be decrypted; encrypted data is effectively undecryptable.

[0003] A significant problem in today's data centers is the inability to explicitly perform cryptographic erasure on all failed or obsolete Encryptable Drives (ECDs). Regardless of whether the ECD is a Self-Encrypting Drive (SED) type or uses any storage technology such as SSD, HDD, hybrid drives combining solid-state and hard disk technologies, or alternative technology drives, it possesses encryption capabilities. For example, an ECD might fail and cease communicating with the system it resides in. In this failure state, the ECD cannot receive cryptographic erasure commands, nor can it respond to such commands with a status indicating successful completion. This poses a problem for data centers unwilling to risk forensic recovery from failed ECDs that cannot be explicitly cryptographically erased. Today, these data centers typically physically destroy these drives to prevent forensic recovery. Users cannot return these drives to manufacturers or reuse them in good faith for fear of data leakage.

[0004] Please note that the Media Encryption Key (MEK) used to encrypt and decrypt data on the ECD is not stored in plaintext in modern SED drives. Instead, the MEK is encrypted; for example, it is encrypted or obfuscated itself. There is a view that this may not be strong enough in the long run, and that the key encapsulation technique could be compromised in the foreseeable future (e.g., via quantum computing).

[0005] Regardless of the scope of the problem, and regardless of whether there should be any valid concern that the encapsulated key can be decrypted or cracked, it is quite possible that there are entities that do not want to rely on or fully trust the drive for handling the non-volatile storage and cryptographic erasure of the MEK. Such users might very well prefer to provide the MEK to the drive after each boot cycle, rather than storing the MEK on the ECD, ensuring that the MEK can be corrupted and that all ciphertext created with it can be cryptographically erased externally. This gives external entities control over the MEK and keeps it outside the ECD, and these external entities are not required to take any special measures in the event that the ECD fails and prevents the drive from performing cryptographic erasure. Because the MEK is simply stored non-volatilely outside the drive, it can be corrupted by the user, regardless of how the ECD fails. However, if the keystore where the user stores the MEK is compromised, or if the security of the communication between the MEK and the ECD is eavesdropped on (and any security of the communication surrounding the MEK and the ECD is compromised), the MEK can be easily captured or retrieved.

[0006] One approach to enabling the ability to cryptographically erase ECDs externally is to use the direct key service model employed by LTO-4 (the first generation of LTO tape drives with encryption capabilities). Note that how keys are handled outside the encryption-enabled device determines whether they can be cryptographically erased. However, it is certain that if key management is done well by the entity outside the ECD, all copies of the MEK associated with a failed ECD drive should be explicitly cryptographically erased. However, copies of the keys are typically made and stored in a distributed location to ensure that the keys can still be used to decrypt data, because without a copy of the key, the data encrypted under that key (i.e., the ciphertext) cannot be decrypted, effectively rendering it inaccessible or "cryptographically erased." Therefore, as more and more key copies are made resiliently outside the ECD, key management becomes increasingly difficult to guarantee.

[0007] Since the LTO-4 era, Self-Encrypting Drive (SED) technology has been standardized around specifications conforming to the Trusted Computing Group (TCG), such as their TCG Storage Security Subsystem Class (SSC), including Enterprise and (more recently) Opal. Both SSCs support cryptographic erasure capabilities within the SED drive (a form of ECD) in several different ways. For example, in the case of the TCG's Opal SSC, there are at least four different ways to invoke internal cryptographic erasure. However, neither of these TCG SSCs supports cryptographic erasure by an external entity independent of the SED itself; that is, the SED may not be able to execute the methods (commands) specified by the SSC. The MEK is always stored in the SED, usually in an encrypted package. If someone can somehow figure out how to crack the encrypted MEK, then that person can recover all associated ciphertext stored in a failed SED conforming to either the Enterprise or Opal SSC.

[0008] The SSC currently under development is called Key per IO. The basic concept of SSC differs from Opal or Enterprise SSC. Key per IO is expected to require external key management. It enables a large number of MEKs to be used within a single namespace, such as the Non-Volatile Memory Faster (NVMe) namespace, which corresponds to a single logical block address (LBA) range for a drive (or a subset of that drive, such as a data strip). All MEKs used in an ECD conforming to the proposed Key per IO SSC will be stored only in volatile form within the ECD, thus disappearing from the ECD once the device is powered off or reset. One problem with the Key per IO scheme is that it does not support internal cryptographic erasure. Therefore, if one of the externally managed MEKs is obtained, for example by an attacker, the ciphertext (encrypted data) encrypted with that MEK can be accessed.

[0009] In traditional ECD-based storage systems, if an ECD is considered marginalized—for example, defective or expected to fail soon—the first thing typically done is to remove this marginalized ECD from the storage system. Before returning it to the manufacturer, an attempt is usually made to perform some form of secure erasure of all data on the ECD. One way to do this is to erase all ciphertext, preferably via an erase that verifies all data on the ECD. In the case of solid-state drive (SSD) type ECDs, this is typically done by attempting to page-erase all pages of the flash memory chips in the flash drive. This may succeed or it may not. For example, it's possible that some pages are not completely erased, leaving some bits on the page unremoved, such as some residual ciphertext bits. In the worst case (e.g., if a page erase line is broken), fully readable ciphertext is left behind. To prevent this worst-case scenario, standards such as the National Institute of Standards and Technology (NIST) SP 800-88r1 regarding media sterilization require drives to verify the erasure of each page by reading the erased pages to ensure that all bits (or at least a sufficient sample of those bits) have actually been erased (minus some acceptable background error rate). Unfortunately, it is well known that any attempt to erase all pages may fail. In the case of SP 800-88r1, if all data (such as password text) cannot be securely erased, then the drive must be physically destroyed, such as by shredding and incineration. Such a drive cannot be reused and should not be returned to the manufacturer.

[0010] In version r1 of SP 800-88, one change compared to previous versions is that NIST has determined that for certain types of data stored on SSD-type ECD drives, cryptographic erasure is an acceptable and secure way to erase or sanitize SSDs (i.e., this would be sufficient to allow these SSDs to be reused or returned to the manufacturer). Therefore, for certain types of storage media, such as SSD-type ECDs, the alternative to erasing all ciphertext is to perform cryptographic erasure. The problem is that, according to current recommendations, no drive supporting Key per IO can perform cryptographic erasure independently. Therefore, in the case of standard Key per IO, the only practical option the storage system has is to transparently (to the host) erase the data on marginal drives removed from the system by attempting to erase all ciphertext on them, which may fail, as mentioned earlier. Summary of the Invention

[0011] With encrypted erasure now possible, it's possible to perform encrypted erasure instead of erasing all password text. Alternatively, encrypted erasure can be performed in addition to erasing all password text. If so, these two operations can be performed in any order.

[0012] According to one aspect of the invention, a device-implemented method 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 being provided to the device from one or more external sources for use in Key-per-IO operations. Accessing an internal key stored within the device. Using the internal key and an associated external key from the one or more external keys, generating a unique MEK for each of at least one of the one or more external keys, each MEK being associated with the external key that generated the MEK. In response to receiving a request to perform data operations on data associated with one of the one or more external keys, the MEK associated with that external key is used to encrypt and / or decrypt the data.

[0013] The method described above achieves internal encrypted erasure of data stored in the Key per IO scheme by implementing an internal key. The internal key is combined with an external key to generate the MEK, which is then used to encrypt / decrypt tenant data. Since there are no tenants, ideally nothing outside of people and ECDs can access the internal key. Damage to the internal key will result in encrypted erasure of the data, making it unrecoverable.

[0014] In a preferred approach, the device is configured to prevent the internal key from being transferred outside the device. Therefore, since the internal key cannot leave the device, destroying the internal key stored within the device and its associated MEK can effectively encrypt and erase all data written using the MEK, and ensure that the MEK cannot be regenerated using the internal key.

[0015] In some approaches, several external keys are associated with unique data stored at different locations within the same logical block address range. The advantage of this approach is that it allows tenants to share the same namespace on the ECD. Because the internal key is combined with the first tenant's specific external key to create the MEK for writing and reading data for that tenant, even if multiple tenants share the address space, other tenants cannot decrypt the first tenant's data without the first tenant's external key.

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

[0017] The method described above enables internal cryptographic erasure of data stored in a Key per IO scheme. Furthermore, it preserves the functionality of Key per IO, allowing two or more tenants to share the same namespace on the ECD without one tenant being allowed to access another tenant's data within that shared namespace.

[0018] According to another aspect of the invention, a method for implementing encrypted erasure in a device includes receiving, at a device configured to perform data operations on a storage medium using Key-per-IO operations, a request to perform encrypted erasure on all data within at least one logical block address range of the storage medium. Each portion of the data within the at least one logical block address range is associated with a unique external key, and each portion of the data is encrypted using a unique MEK, which is created using an internal key and a unique external key associated with that portion of the data. The internal encrypted erasure of the logical block range can be achieved by destroying a common internal key associated with the logical block range and all media encryption keys associated with the internal key.

[0019] The above method enables internal encrypted erasure of data stored in encrypted form in the Key per IO scheme.

[0020] In a preferred approach, the device is configured to prevent the internal key from being transferred outside the device. Therefore, since the internal key cannot leave the device, corrupting the internal key stored within the device, along with all MEKs generated from it, effectively encrypts and erases all data written using these MEKs, and ensures that MEKs cannot be regenerated using the now-corrupted internal key.

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

[0022] A computer program product for implementing encrypted erasure includes a computer-readable storage medium having program instructions embodied therein, which can be executed by a device configured to perform data operations on the storage medium to cause the device to perform any of the methods described herein.

[0023] According to various aspects of the invention, the system includes a device configured to perform data operations on a storage medium. Such a device has a processor and logic integrated with, executable by, or integrated with and executable by the processor, the logic being configured to cause the device to perform any of the methods presented herein.

[0024] The various approaches described in this article are applicable to many types of storage media, including non-volatile memory and magnetic recording tape.

[0025] Other aspects and approaches of the invention will become apparent from the following detailed description, which is consistent with the appendix. Figure 1 The principles of the present invention will be illustrated by examples. Attached Figure Description

[0026] Figure 1 This is a diagram of a network structure according to one aspect of the present invention.

[0027] Figure 2 It is possible according to one aspect of the invention and Figure 1 A diagram of the representative hardware environment associated with the server and / or customer.

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

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

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

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

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

[0033] Figure 8 This is a chart comparing the current state of technology for phasing out and securing storage products that support Key per IO with the procedures implemented by various aspects of this invention. Detailed Implementation

[0034] The following description is intended to illustrate the general principles of the invention and not to limit the inventive concepts claimed herein. Furthermore, the specific features described herein can be used in a variety of possible combinations and permutations with other described features.

[0035] Unless otherwise specifically defined herein, all terms should be interpreted as broadly as possible, including their implied meaning from the specification, their meaning as understood by those skilled in the art, and / or their meaning as defined in dictionaries, papers, etc.

[0036] It must also be noted that the singular forms “a,” “an,” and “the” used in this specification and the appended claims include plural references unless otherwise stated. It should also be understood that when the terms “comprising” and / or “including” are used in this specification, they indicate the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0037] This document describes several preferred approaches to encrypting and erasing locally encrypted data via internal actions in Key-per-IO devices. In various approaches, instead of directly using an externally provided "encryption" key Kext, an internal key Kint is combined with Kext. This combination of two keys is used as the actual media encryption key (MEK).

[0038] In a general approach, a device implementation method 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 being provided to the device from one or more external sources for use in Key-per-IO operations. Accessing an internal key stored within the device. Using the internal key and an associated external key from the one or more external keys, generating a unique MEK for each of at least some of the at least one or more external keys, each MEK being associated with the external key used to generate the MEK. In response to receiving a request to perform data operations on data associated with one of the external keys, the MEK associated with that external key is used to encrypt and / or decrypt the data.

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

[0040] In another general approach, a method for implementing encrypted erasure includes receiving, at a device configured to perform data operations on a storage medium using Key-per-IO operations, a request to encryptedly erase all data within at least one logical block address range of the storage medium. Each portion of the data within the at least one logical block address range is associated with a unique external key, and each portion of the data is encrypted using a unique MEK created using an internal key and a unique external key associated with that portion of the data. Encrypted erasure is achieved by destroying the internal key and any or more MEKs generated from that internal key.

[0041] Descriptive computing environment

[0042] Figure 1 This illustrates an architecture 100 based on one approach. For example... Figure 1 As shown, multiple remote networks 102 are provided, including a first remote network 104 and a second remote network 106. A gateway 101 can couple between the remote networks 102 and the near-end network 108. Within the context of this architecture 100, networks 104 and 106 can each take any form, including but not limited to local area networks (LANs), wide area networks (WANs), such as the Internet, the Public Switched Telephone Network (PSTN), and internal telephone networks.

[0043] In use, gateway 101 serves as the entry point from remote network 102 to near-end network 108. Therefore, gateway 101 can act as a router capable of routing a given packet of data arriving at gateway 101 and as a switch providing the actual path for a given packet to and from gateway 101.

[0044] It also includes at least one data server 114 coupled to the near-end network 108 and accessible from the remote network 102 via gateway 101. It should be noted that the data server 114 may include any type of computing device / groupware. Coupled to each data server 114 are multiple user devices 116. User devices 116 may also be directly connected via one of networks 104, 106, and 108. Such user devices 116 may include desktop computers, laptops, handheld computers, printers, or any other type of logical device. It should be noted that, in one approach, user devices 111 may also be directly connected to any one of the networks.

[0045] Peripheral device 120, or a series of peripheral devices 120, such as fax machines, printers, networked and / or local storage units or systems, may be coupled to one or more of networks 104, 106, and 108. It should be noted that databases and / or other components may be used with or integrated into any type of network element coupled to networks 104, 106, and 108. In the context of this description, network element can refer to any component of the network.

[0046] According to several approaches, the methods and systems described in this paper can be implemented through virtual systems and / or systems that simulate one or more other systems, such as simulation systems. Environment System, virtual hosting Environment System, simulation Environment Systems, etc. In some ways, this virtualization and / or emulation can be achieved by using... Software can be used to enhance this.

[0047] In many other contexts, one or more networks 104, 106, 108 can represent a cluster of systems commonly referred to as a "cloud." In cloud computing, shared resources such as processing power, peripherals, software, data, and servers are provided to any system in the cloud on an on-demand basis, allowing services to be accessed and distributed across many computing systems. Cloud computing typically involves internet connectivity between systems operating in the cloud, but other technologies for connecting systems can also be used.

[0048] Figure 2 It shows the relationship based on one approach. Figure 1 The diagram illustrates a representative hardware environment associated with user equipment 116 and / or server 114. It shows a typical hardware configuration for a workstation, featuring a central processing unit 210 (such as a microprocessor) and several other units interconnected via a system bus 212.

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

[0050] Workstations can have an operating system residing on them, such as Microsoft... Operating System (OS) Etc. It is understood that the preferred approach can also be implemented on platforms and operating systems other than those mentioned above. The preferred approach can be written using Extensible Markup Language (XML), C and / or C++, or other programming languages, and object-oriented programming methodologies. Object-oriented programming (OOP), which has been increasingly used to develop complex applications, can be employed.

[0051] Now for reference Figure 3 This illustrates a storage system 300 according to one approach. Note that, depending on the aspect, Figure 3 Some of the components shown can be implemented as hardware and / or software. Storage system 300 may include a storage system manager 312 for communicating with multiple media and / or drives on at least one higher storage layer 302 and at least one lower storage layer 306. Higher storage layer 302 may preferably include one or more random access and / or direct access media 304, such as hard disks in hard disk drives (HDDs), non-volatile memory (NVM), solid-state memory in solid-state drives (SSDs), flash memory, SSD arrays, flash memory arrays, etc., and / or other media pointed out herein or known in the art. Lower storage layer 306 may preferably include one or more lower-performance storage media 308, including sequential access media, such as magnetic tape and / or optical media in tape drives, slower-access HDDs, slower-access SSDs, etc., and / or other media pointed out herein or known in the art. One or more additional storage layers 316 may include any combination of storage media required by the designer of system 300. Additionally, any higher storage layer 302 and / or lower storage layer 306 may include some combination of storage devices and / or storage media.

[0052] Storage system manager 312 can communicate via network 310 with drives and / or storage media 304, 308 on higher storage tier 302 and lower storage tier 306, such as network 310. Figure 3 The storage area network (SAN) or other suitable network type shown may be used. The storage system manager 312 may also communicate with one or more host systems (not shown) via 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 commands of types 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 storage system may be used, as those skilled in the art will discover upon reading this description.

[0053] In many other ways, storage system 300 may include any number of data storage layers, and may include the same or different storage media within each storage layer. For example, each data storage layer may include the same type of storage media, such as HDD, SSD, sequential access media (tape in a tape drive, optical disc in an optical disc drive, etc.), direct access media (CD-ROM, DVD-ROM, etc.), or any combination of media storage types. In one such configuration, higher storage layer 302 may include most of the SSD storage media for storing data in a higher-performance storage environment, while the remaining storage layers, including lower storage layer 306 and additional storage layer 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 higher priority, data that needs to be accessed more quickly, etc., can be stored in higher storage layer 302, while data that does not have one of these attributes can be stored in additional storage layer 316, including lower storage layer 306. Of course, those skilled in the art, after reading this description, can design many other combinations of storage media types to achieve different storage schemes based on the approaches and aspects presented herein.

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

[0055] Of course, this logic can be implemented in various ways as a method on any device and / or system or as a computer program product.

[0056] Key per IO basic principle

[0057] In some cases, it is desirable to allow different entities to use the same address space on a storage device. However, a simple implementation does not provide any privacy guarantees for the first entity, as a second entity can easily read what the first entity writes. One solution to this is to have each entity (or tenant) use a unique key, which they can manage externally. The device needs this key to encrypt their written data and decrypt their encrypted ciphertext. This key will be referred to herein as the external key, external MEK, and Kext. In particular, each tenant has a unique Kext used to encrypt their data, and this Kext is different from the Kexts of other tenants. This scheme is often referred to as the Keyper IO scheme.

[0058] When a device supporting Key per IO (such as an ECD, computer, etc.) powers on, it does not have a Kext to perform encryption or decryption. Instead, the Kext is provided to the device in any way needed, such as along with requests for read or write operations, as required. For example, a tenant might send the Kext and a key tag (e.g., T) together, which will be used to reference the Kext in the future; the device stores the Kext in volatile memory. Then, when the device receives a command (e.g., an NVMe command) that includes the key tag T as part of a command header, it retrieves the associated Kext from memory and uses it to encrypt plaintext data being written by the host or to decrypt ciphertext data being read from non-volatile memory before the corresponding plaintext is stored in non-volatile memory. The device can accumulate multiple Kexts associated with different key tags. In some methods, if power is cut off, only the Kext stored in volatile memory will be lost and therefore needs to be provided to the device again after power is restored for reuse.

[0059] Many Key-per-IO schemes aim to allow different tenants (users, applications, computers, etc.) to share the same address space. Prior to the functionality of this invention, a tenant's Kext was directly used as the MEK to encrypt and decrypt that tenant's data. Theoretically, the encrypted data of the first tenant is secure to plaintext access by the second tenant, as long as their respective Kexts are unique to each other and secure to other tenants. When the first tenant or the control infrastructure responsible for the first tenant's data wants to erase the first tenant's data on the device, the first tenant destroys the first tenant's Kext outside the device, for example, by deleting the Kext, overwriting the Kext, or otherwise destroying the Kext, including not only any remaining copies of the Kext outside the device, but also any copies stored in the volatile memory inside the device. Specifically, if there is any possibility that the first tenant's Kext is provided to the device after the device's last power cycle or cold start, the first tenant must almost certainly instruct the device to erase the Kext that serves as the device's internal MEK. By destroying all instances of the Kext, both outside and inside the device, the MEK-encrypted data still stored on the device and recoverable from the device is effectively encrypted and erased. However, if the entity that compromises the Kext instance is unaware that someone or something has already logged into the tenant's Kext (e.g., by compromising an external key store or eavesdropping on its communications with the device) and retains a copy, that person could still potentially access the tenant's data by decrypting their ciphertext, provided they have internet access to the device. Therefore, there is no guarantee that the data is secure, nor is there any guarantee that explicit cryptographic erasure has been performed.

[0060] Furthermore, as mentioned above, Kexts are externally managed, and when the storage device loses power, all MEKs (i.e., Kexts used as MEKs) inside the device should be lost, as they are only stored in volatile memory. However, potential problems arise when the device or other data storage devices fail or are deemed marginalized and removed from service. Since not all copies of a given Kext are online, or they may have been secretly copied, it is difficult, if not impossible, to ensure that all Kexts associated with encrypted data written to the device have actually been corrupted externally for externally managed Kexts. Therefore, it is impossible to guarantee that all data encrypted with a particular MEK on the device is unrecoverable.

[0061] This invention provides a method for internally encrypting and erasing data stored using a Key-per-IO scheme by implementing an internal key (Kint). The internal key Kint is combined with the tenant's Kext to generate the MEK, and the internal key is then used to encrypt / decrypt the tenant's data. Since there are no tenants, ideally no one can access the Kint, and corruption of the Kint will result in the encrypted erasure of the data.

[0062] The ratio of internal Kint to external Kexts can vary depending on the implementation. In some approaches, all namespaces (e.g., the entire drive's namespace) may share a common Kint. Therefore, there may be a large number of external Kexts, but only one Kint. In this case, the entire device can be cryptographically erased by simply deleting a single common Kint.

[0063] In other ways, a unique Kint can be provided for each namespace and / or subset of namespaces. Therefore, some devices can use multiple Kints.

[0064] Invention method for enabling encrypted erasure in devices that support Key per IO

[0065] The following description discloses several preferred approaches for systems, methods, and computer program products to enable locally encrypted data to be encrypted and erased via internal actions in devices supporting Key per IO (such as ECDs). Generally, data is encrypted and / or decrypted using MEKs created from an external Kext and a Kint stored within a storage device (e.g., ECD, SED, tape cartridge, portable memory, etc.). Upon destruction of the Kint and all MEKs created from the Kint, all data stored solely with MEKs is encrypted and erased, becoming unrecoverable. Similarly, destroying all copies of the Kext also encrypts and erases the data corresponding to the Kext.

[0066] Furthermore, because the Kint is combined with a tenant-specific Kext to create the MEK, which is then used to write and read data for that tenant, even if tenants share the address space, other tenants cannot decrypt the first tenant's data without the first tenant's Kext. Therefore, several Kexts can be individually associated with unique data stored at different locations within the same logical block address range (the range of allowed logical blocks in the storage medium, such as the NVMe namespace), which can be millions of sectors long. This should not be confused with the range of a single write command; in the case of Key per IO, all write commands are written by a single Kext specified by the key tag arriving at the write command header.

[0067] Encryption erasure in ECD and SED

[0068] While much of the following description relates to exemplary implementations of any type of SED or ECD, it is done by way of example only and merely to provide background for the reader to aid understanding. Therefore, the concepts and teachings presented below are equally applicable to implementations of storage media such as magnetic recording tapes, memory cards, optical media, and related devices.

[0069] Now for reference Figure 4 A flowchart of method 400 according to one approach is shown. Method 400 can be performed in various ways in any environment depicted in the other figures of the invention described herein. Of course, method 400 may include more than Figure 4 The more or fewer operations described in detail herein will be understood by those skilled in the art upon reading this description.

[0070] Each step of method 400 can be performed by any suitable component of the operating environment. For example, in various ways, method 400 can be performed in part or in whole by a device such as a computer, a drive, or some other device having one or more processors. One or more steps of method 400 can be performed in any device using a processor (e.g., processing circuitry, chips, and / or modules implemented in hardware and / or software, and preferably having at least one hardware component). Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), the like, combinations thereof, or any other suitable computing device known in the art.

[0071] like Figure 4 As shown, method 400 may begin with operation 402, wherein a device configured to perform data operations on the storage medium (e.g., reading data from and / or writing data to the storage medium) receives one or more unique external cryptographic keys (Kexts). These one or more Kexts are provided to the device from one or more external sources for use in Key-per-IO operations. The external source can be any external source. For example, the external source can be an application running in a virtual machine or container, or natively on a host server that is writing or reading data, or a control infrastructure that transparently handles all keys supplied to these applications, virtual machines, containers, or host servers. The external source can also be a keystore, a key server, or a key entered by the user (e.g., via keyboard, by inserting a flash drive, etc.).

[0072] Kext is preferably stored only in the device's volatile memory so that it can be destroyed when the device is powered off or restarted. Kext can be received in any suitable manner, such as receiving it as needed, receiving it all at once, receiving it in response to a request for Kext (e.g., from the device), etc. For example, Kext can be received along with a request to read or write data stored or to be stored on a storage medium in encrypted form.

[0073] The storage medium can be any type disclosed herein, such as magnetic tape, disk, NVRAM, etc. Correspondingly, the device can be any type of data storage device, such as a tape drive, SSD, HDD, encrypted USB drive, NVRAM module, etc. Furthermore, the device can be an encrypted drive (ECD) of the removable data storage type, such as an encrypted USB drive, an encrypted tape drive, a self-encrypting drive (SED), etc.

[0074] In operation 404, the Kint stored within the device is accessed, for example, from the device's non-volatile memory. This non-volatile memory may be on an application-specific integrated circuit (ASIC) such as NAND flash memory or embedded in a larger IC such as an FPGA, ASIC, or CPU. In some cases, the Kint is stored in the device in its raw (unencrypted) form. In other cases, the Kint is stored in the device in a packaged form (e.g., encrypted, password-protected, obfuscated, etc.). When the Kint is stored in a packaged form, information for decapsulating the Kint (such as another key, password, etc.) can be retrieved and / or received and used to decapsulate the Kint. For example, a lock / unlock PIN or password required to unlock the device can serve as a package key for encapsulating the internal key. Alternatively, a Key Encryption Key (KEK) can also serve as a package key for encapsulating the internal key. Preferably, the unique non-volatile storage of the internal key is typically in a packaged form.

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

[0076] In Operation 406, a unique MEK is generated for each of at least some of the Kexts using a Kint and an associated Kext from one or more Kexts. In other words, the MEK associated with a given Kext (used to generate that MEK) is different from any other MEK. Any known technique can be used to create a MEK from Kexts and Kints, such as by XORing the Kexts and Kints together, by applying another known hash algorithm, by appending the two keys together to create a larger MEK, and so on.

[0077] The MEK for a given dataset can be created whenever needed. In one approach, the MEK is generated upon receiving the Kext. In another approach, the MEK is created in response to a request to perform data operations on the data associated with the Kext.

[0078] Regardless of when the MEK is created, it can be volatilely stored within the device for use and / or reuse, or used for data manipulation and discarded. Preferably, the MEK is stored only in volatile memory within the device, so that it is lost when the device is powered off or reset. This helps ensure that the MEK cannot be accessed from outside the device or when the device is disabled.

[0079] 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 the 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, in operation 408, the ciphertext of the requested data is decrypted using the appropriate MEK to give the unencrypted (i.e., plaintext) form of the requested data, which can then be output to the requester. The ciphertext of the requested data can be copied to a buffer and then decrypted, or it can be decrypted "on the fly" during the reading process, etc. The decrypted data is output, for example, via a host interface to the data requester, etc.

[0080] In some cases, the MEK is deleted after the associated request is completed. In others, the MEK may be retained in some form in volatile memory or registers for reuse. In any case, the storage device may retain the Kext and its associated MEK until they are explicitly forgotten by command or reset, or until a power outage causes them to be forgotten.

[0081] The following provides Figure 4 Various aspects of its operation. These aspects are presented by way of example only and are not intended to be limiting. As mentioned above, most of this discussion refers to the ECD, and this is only by way of example. Furthermore, these aspects can be combined in any way according to the numerous possible aspects and approaches of practicing the invention.

[0082] MEK can be created from two separate keys using any techniques known in the art and / or discovered by those skilled in the art upon reading this description. For example, one way to create a MEK that requires both Kint and Kext for computation is to have Kint and Kext be two independently generated random numbers, and then perform computations that require both Kint and Kext, such as bitwise XORing them together or concatenating the two values ​​to compute MEK.

[0083] Kints can originate from any conceivable source. Kints are preferably created within the ECD, which is the safest approach because a copy of the Kint never needs to exist outside the ECD unless intentionally copied. For example, a Kint can be generated in a known manner using the output of a random number generator within the ECD.

[0084] In other methods, a Kint can be created outside the ECD and provided to the ECD. For example, a Kint can be programmed into the device during manufacturing, programmed into the device by an administrator, or inserted into the device during configuration or formatting.

[0085] In one respect, a Kint can be a specific dataset, so a device can store multiple unique Kints, each associated with a unique dataset.

[0086] Preferably, the ECD is configured to disallow any external visibility of Kint or to move or copy Kint out of the ECD.

[0087] In one illustrative approach, Kint is the first value required to create MEK, for example, a first random number of the same length as MEK (same bit length). Kext is the second value required to create MEK, for example, a second random number of the same length as MEK. Kint and Kext are processed in a predetermined manner to generate the resulting MEK. For example, Kint can be XORed (or similar) with Kext to generate MEK. Alternatively, standard key derivation techniques (e.g., using hashing or encryption) can be used instead of the XOR operation (or similar) to compute MEK. Any form of key derivation that requires processing both Kint and Kext to compute MEK is acceptable.

[0088] Anyone familiar with the complexities of an ECD capable of supporting Key per IO SSC will understand that there are many, many ways to implement this concept, and therefore, the present invention is not limited to the exemplary description herein.

[0089] In one approach, a unique Kint is created to be combined with each Kext. Alternatively, the number of Kints can be less than the number of Kexts, up to the single Kint that can be combined with all Kexts. Therefore, there could be thousands of Kexts that can be combined with a few or as few as one Kint, i.e., many-to-many, many-to-few, or many-to-one relationships exist.

[0090] In another approach, the MEK is created using more than one Kint and Kext. For example, two different Kints can be combined with Kexts, resulting in a net result of three different keys. Erasing any one of these three keys will cryptographically erase any data encrypted with the combined keys. Therefore, in some approaches, more than two keys are combined to create the MEK. Thus, for example, if one Kint is common across the entire NVMe namespace, while another Kint is unique to each Kext, it is possible to cryptographically erase all data in the NVMe namespace at once (by overwriting or erasing the first Kint shared by all Kexts) or to cryptographically erase all data in the NVMe namespace per tenant (by overwriting or erasing a second Kint, which is more granular, and in extreme cases, the encryption key for each resulting combination may be unique).

[0091] Note that in Key-per-IO schemes, there are other forms of creation that create dependencies on one or more Kints, which can provide additional utility. For example, a tenant's data might initially be encrypted using only the tenant's Kext. The resulting ciphertext can then be encrypted a second time using a Kint. In this case, if a keyless copy is to be performed, the dependency on the Kint can be removed by performing a single decryption, which can be done without the tenant's Key-per-IO Kext. This allows the ciphertext to be copied to a replacement device without needing to securely transfer any keys (such as MEK or Kint) from one device to another. Conversely, two devices (e.g., the removed edge device, and the standby device that replaces it) can have completely independent Kints.

[0092] There are other ways to achieve similar capabilities as discussed earlier without requiring comprehensive secondary encryption of all data, which will become apparent to those skilled in the art after reading this disclosure. Therefore, there is no absolute requirement for secure transfer of MEK associated with keyless copying. Several solutions, such as those discussed earlier, eliminate the need for secure transfer of any keys associated with the ciphertext read from the edge device.

[0093] In one illustrative approach, only the encapsulated Kint is stored in the ECD's non-volatile memory. The Kext is stored only in non-volatile form outside the ECD and therefore must be provided to (or accessed by) the ECD at least once after a power cycle and / or cold start to allow MEK computation. MEK can only be computed when the ECD possesses both the Kint and the Kext. Therefore, the Kext must be provided to (or accessed by) the ECD in some form. Depending on the approach, there are several ways to do this. One way is to inject the Kext into the ECD and encapsulate it with a key encryption (KEK). Alternatively, if the ECD supports a Key Management Interoperability Protocol (KMIP) client, it can request and receive the Kext from an external key manager of a type known in the art via a secure channel, such as a secure channel protected by TLS or IPsec. Alternatively, the Kext can be provided to the ECD in a manner similar to a Personal Identifier (PIN), for example, in plaintext, through a secure tunnel established for secure protocol input and output commands, etc.

[0094] Kint is preferably stored in an encapsulated form in the ECD and can be uncapsulated before the encapsulation key (which may be a KEK, or may depend on one or more passwords or PINs, provided to the ECD to verify one or more different roles supported by the ECD (e.g., Admin1)) is provided. Therefore, any part of the encapsulation key provided from outside the ECD is provided to the ECD to allow the Kint to be uncapsulated. Once the ECD is provided with or has access to all the information (including the Kext) required to compute the MEK, the ECD computes the MEK and is then able to decrypt existing ciphertext to produce the plaintext result (e.g., in response to a host readout), or encrypt newly received client data in plaintext to ciphertext (e.g., to fulfill a host write).

[0095] In one approach, the Kint is internally generated and packaged with a KEK or a PIN associated with a certain Administrative Security Provider (hereinafter referred to as "AdminSP") role (such as Admin1). Therefore, once the KEK is injected into an ECD or entity, such as Admin1, which has already authenticated with its password or PIN, access to the Kint is granted.

[0096] The KEK or PIN code encapsulating the Kint can be changed as part of a (encapsulating key) rekey operation. The Kint itself can also be rekeyed, but this will result in the data encrypted with MEK created from the Kint in use being encrypted and erased before the Kint is rekeyed.

[0097] One implementation involves having the ECD use the same type of internal random number generation capability, such as that invoked via a random command, as the source for generating Kint in some or all cases.

[0098] Now for reference Figure 5 The flowchart illustrates, in one manner, an exemplary method 500 for writing cryptographically erasable data in a Key per IO scheme. Method 500 can be adapted from other diagrams described herein (especially...). Figure 4 It can be executed in various ways in any environment described in ( ). Of course, method 500 can include more than Figure 5 The more or fewer operations described in detail herein will be understood by those skilled in the art upon reading this description.

[0099] Each step of method 500 can be performed by any suitable component of the operating environment. For example, in various ways, method 500 can be performed in part or in whole by a device such as a computer, a drive, or some other device having one or more processors. One or more steps of method 500 can be performed in any device using a processor (e.g., processing circuitry, chips, and / or modules implemented in hardware and / or software, and preferably having at least one hardware component). Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), the like, combinations thereof, or any other suitable computing device known in the art.

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

[0101] In Operation 504, access was made to Kint stored in the device.

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

[0103] In operation 508, the first MEK is used to encrypt the first data.

[0104] In operation 510, encrypted first data is written to the storage medium within a first logical block address range. The first logical block address range is preferably an allowed range of logical blocks in the storage medium (e.g., in an NVMe namespace), which may be the length of millions of sectors. This should not be confused with the limited range of a particular write command, which is associated with a single Kext.

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

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

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

[0108] In operation 518, the second MEK is used to encrypt the second data.

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

[0110] Additional operations can be performed in method 500, and any of the features described herein can be implemented in method 500.

[0111] Now for reference Figure 6 A flowchart of an exemplary method 600 for performing cryptographic erasure on data in a Key per IO scheme is shown according to one approach. This method 600 can be adapted from other diagrams described herein (especially...). Figures 4-5 It can be executed in various ways in any environment described in the document. Of course, method 600 can include methods that are more advanced than those described in the document. Figure 6 The more or fewer operations described in detail herein will be understood by those skilled in the art upon reading this description.

[0112] Each step of method 600 can be performed by any suitable component of the operating environment. For example, in various ways, method 600 can be performed in part or in whole by a device such as a computer, a drive, or some other device having one or more processors. One or more steps of method 600 can be performed in any device using a processor (e.g., processing circuitry, chips, and / or modules implemented in hardware and / or software, and preferably having at least one hardware component). Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), the like, combinations thereof, or any other suitable computing device known in the art.

[0113] In operation 602, a request is received at a device configured to perform data operations on the storage medium using Key-per-IO operations, causing all data within at least one logical block address range of the storage medium to be encrypted and erased. Each portion of the data within the at least one logical block address range is associated with a unique Kext, for example, corresponding to a unique tenant. Each portion of the data is encrypted using a unique MEK, which is created using a Kint and a unique Kext associated with that portion of the data.

[0114] In operation 604, cryptographic erasure is achieved by corrupting the Kint (e.g., by erasing the Kint, overwriting the Kint, and / or physically destroying the memory storing the Kint) and any MEK created from the Kint in the device.

[0115] cryptography

[0116] Kint and Kext can be XORed together or otherwise combined to create MEK.

[0117] One way to verify the correctness of a generated MEK (e.g., compared to a single off when the Kext has one off bit) is to use the concept of key signing. The concept of key signing involves encrypting a known value using the MEK and then storing the resulting ciphertext as a signature of the MEK.

[0118] Please note that in some of the approaches described above, the Kext, Kint, and any keys used to encapsulate the Kext (such as the Key Encryption Key (KEK) and Kint) become so-called Cryptographic Sensitive Parameters (CSPs). If there is any possibility that the data transmitted between the ECD and the host could be logged, then the channel between them should be protected with some form of encryption. One option detailed in Key per IO is to use a KEK known to both the host and the ECD. The host encapsulates the Kext with the KEK before sending it to the ECD, and the ECD decapsulates it with the same KEK after receiving it. Another option is to use Data in Flight (EDiF), such as Internet Protocol Security (IPsec), Fibre Channel Security Protocol (FC-SP), or Transport Layer Security (TLS). In some data centers, the focus is not on the data passing back and forth within the ECD's internal environment, but on what happens after the ECD leaves the protected environment. This is why absolute cryptographic erasure is necessary.

[0119] Please note that in XTS encryption mode (e.g., XTS-AES-256), there are two encryption-related keys: an encryption key and a separate fine-tuning key. In some methods, these two keys can be generated from a single root key (via key derivation). Therefore, a 256-bit MEK can be provided and used to generate (via key derivation) the two 256-bit keys required for XTS-AES-256.

[0120] In ECDs in which various aspects of the present invention have been implemented, the encryption erasure option includes not only the required destruction of any MEK within the ECD (e.g., by overwriting or erasing), but also one or more of the following:

[0121] 1. If a user wants to encrypt and erase all data on an ECD in operation, they only need to invoke one of the various methods suggested in this article. For example, if the encapsulated key structure containing the Kint is overwritten, the Kint is now unrecoverable. In this case, it is not necessary to erase every Kext simultaneously; the MEK is unrecoverable and cannot be regenerated because the Kint has been lost.

[0122] 2. If a user wants to encrypt and erase the ECD (perhaps because the ECD is not working, not responding to commands, or the ECD is lost), but cannot execute "1." for some reason, the user now has another option—to instruct each tenant to erase their Kext, regardless of the ECD. In this case, it is unnecessary to erase all the wrapped Kint versions; the MEK is unrecoverable because the Kext is gone. In this situation, even if someone were to crack the wrapped key structure of the invalid ECD at some point in the future to obtain the Kint, everything they did would be in vain because the MEK remains unavailable. For this, they would need the corrupted Kext. Therefore, they are still in a situation where the only feasible path to access customer data is to crack the encryption algorithm protecting the ciphertext of the user data itself (e.g., XTS-AES-256).

[0123] 3. If the user is particularly concerned about the security of cryptographic erasure, they can choose to delete both Kint and Kext. This is most likely if there are concerns that Kext may have been logged (e.g., its security was compromised en route to the ECD, even with some encapsulation or secure channel protection (or may be subsequently compromised)). However, due to cryptographic considerations, there should be no reason to require the deletion of both Kint and Kext. A general approach is quite flexible (e.g., if the ECD becomes inoperable), namely, always attempt to delete both Kint and Kext, but be satisfied as long as the deletion of one of them is verified to be successful.

[0124] 4. If a tenant wants to perform encrypted erasure of its data, it can destroy the tenant's Kext. Any copies of the tenant's Kext on the ECD (and any associated MEKs) should also be deleted, for example, by power cycling the device or by invoking a command to clear a single MEK or clear all MEKs.

[0125] Encryption erasure for magnetic recording tapes and other portable storage devices

[0126] As mentioned above, in some approaches, encrypted data is stored on non-volatile storage media, such as magnetic recording media (e.g., magnetic tape, disk) or solid-state storage (e.g., NAND flash memory, NVRAM, etc.). Similarly, any operations, concepts, etc., described above can be used in this method. For example, Figures 4-5 When performing operations 400 and 500, please note the following minor modifications.

[0127] In some approaches, Kint can be stored in a specific device that operates along with the medium, such as a drive, computer, etc.

[0128] In other approaches, particularly those implementing removable media, Kint is stored on and / or along with the storage medium. Therefore, similar to... Figures 4-5 Methods like 400 and 500 would instead retrieve the Kint from the storage medium or from a memory physically coupled to the medium (such as a cassette memory). Ideally, in the event that the Kint is to be destroyed, the structure storing the Kint on the removable medium would be destroyed.

[0129] Now for reference Figure 7 A flowchart of method 700 is shown according to one approach. Method 700 can be performed in various ways in any environment depicted in the other figures described herein, according to the invention. Of course, method 700 may include more than Figure 7 The more or fewer operations described in detail herein will be understood by those skilled in the art upon reading this description.

[0130] Each step of method 700 can be performed by any suitable component of the operating environment. For example, in various ways, method 700 can be performed in part or in whole by a device such as a computer, a drive, or some other device having one or more processors. One or more steps of method 700 can be performed in any device using a processor (e.g., processing circuitry, chips, and / or modules implemented in hardware and / or software, and preferably having at least one hardware component). Exemplary processors include, but are not limited to, a central processing unit (CPU), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), the like, combinations thereof, or any other suitable computing device known in the art.

[0131] like Figure 7 As shown, method 700 may begin at operation 702, wherein a device configured to perform Key-per-IO data operations (e.g., reading from and / or writing data to the storage medium) receives a request to perform data operations 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 include additional information, such as a Kext. As mentioned above, the Kext used in method 700 is preferably stored only in the device's volatile memory.

[0132] In operation 704, a Kint stored on and / or stored with the storage medium is retrieved. This procedure may include retrieving a Kint from a medium storing data, or retrieving a Kint from a memory physically coupled to the medium (such as a cassette memory).

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

[0134] As described above, in some methods, the Kint is stored on and / or along with the storage medium in its raw (unencrypted) form. In other methods, the Kint is stored on and / or along with the storage medium in an encapsulated form (such as encrypted form, password-protected form, etc.). Information such as another key, KEK, PIN, or a password used to encapsulate the Kint can be received and used to decapsulate the Kint.

[0135] In a preferred aspect, the device is configured to prevent the Kint from being moved outside the device in any form. However, the microprocessor or controller inside the device can access the Kint from the storage medium or other sources coupled to the storage medium.

[0136] In operation 706, the Kext associated with the data is received from an external source. This external source can be any external source. For example, the external source can be the requester of the data, a key store, a key server, or a key entered by a user (e.g., via a keyboard).

[0137] In Operation 708, a MEK is generated using Kint and Kext. Any known security techniques can be used to create a MEK from Kint and Kext.

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

[0139] In operation 712, in response to receiving a request to encrypt and erase data on the medium, the Kint and any MEK created using that Kint are destroyed.

[0140] If the second data is to be stored on the storage medium by the device, then the second data is received. Another external key (Kext2) can be received from a second external source. If so, a second MEK is generated using Kint and Kext2. Data operations are performed using the second MEK. Note that the second external source can be the same as or different from the external source mentioned above. However, Kext2 is different from Kext.

[0141] The following provides Figure 7 Various aspects of the operation. These aspects are presented by way of example only and are not intended to be limiting. Moreover, these aspects can be combined in any way according to the numerous possible approaches of the invention. For example, method 700 may have or be combined with the above-mentioned aspects. Figures 4-6 Similar features have been proposed, such as key generation.

[0142] Kint is stored along with a storage medium, such as on the storage medium itself and / or together with the storage medium in a separate memory. Kint is preferably stored in an encapsulated form. For example, Kint can be stored on a portion of a magnetic tape, or in a magnetic tape cassette, or both. This allows Kint to be carried along with the magnetic recording tape. Similarly, for NVRAM devices such as Memory Sticks, Memory Cards, etc., Kint can be stored in the device's NVRAM, or in the device's separate memory, and so on.

[0143] Kints are preferably created internally within a device (such as a drive, computer, etc.) and operate on a storage medium. Preferably, the device is configured to disallow any external visibility of the Kint or to copy the Kint outside the device, except to the storage medium and / or the memory coupled thereto. Preferably, the device transfers the Kint to the storage medium and / or the memory coupled thereto and removes the Kint from other parts of the device. Thus, in some ways, the Kint resides only on the storage medium, such as those associated with removable media devices.

[0144] When the storage medium is integrated into the device itself (e.g., a self-encrypting drive (SED) or an encrypted drive (ECD) of the HDD or SSD type), the Kint can be stored within the device. For example, within a (potentially airtight) sealed ECD casing, the Kint can be stored anywhere within this typically rectangular boundary. In the case of an SSD, the primary non-volatile memory (where user data is stored) is typically NAND flash memory. The Kint (potentially in encapsulated form) may also be stored there. In other ways, the Kint can be stored in separate (different from user data) non-volatile memory within the casing, such as in different NAND or NOR flash memory chips, in magnetic random access memory (MRAM), in spin-transfer torque random access memory (STT-RAM), in ferroelectric random access memory (FeRAM), in phase-change memory (PCM), in resistive random access memory (RRAM), in other forms of NVRAM (which are less technologically advanced than the aforementioned terms), and so on. Note that the Kint can also be stored in the form of ROM (such as EEPROM), which can be erased. Therefore, in various ways, Kint can be stored in a memory that is different from the storage medium used to store user data.

[0145] In other ways, Kint is created outside the device and provided to the device, and stored within the device.

[0146] Kexts can be created inside or outside the device, or contributed by both inside and outside the device.

[0147] In various approaches, the Kext is provided and / or stored in volatile memory (e.g., SRAM) of a tape drive, computer, etc., to allow the tape drive, computer, etc., to compute MEK. In one approach, the Kext can be input to the tape drive, computer, etc., whenever needed. In another approach, once provided to the device, the Kext can remain inside the device, stored in volatile memory of the tape drive, computer, etc., in which case the Kext is preferably encapsulated.

[0148] It should be understood that the various approaches described herein can be implemented using a wide range of storage media, including, for example, NVRAM technologies such as NAND flash memory, NOR flash memory, phase-change memory (PCM), magnetoresistive RAM (MRAM), and resistive RAM (RRAM). For background purposes, and merely to assist the reader, the various approaches can be described with reference to types of non-volatile memory. This is done by way of example only and should not be construed as limiting the invention as defined in the claims.

[0149] In one illustrative approach, the non-volatile form of Kint is stored only in an encapsulated form along with the storage medium. Kext, while it can be temporarily stored in volatile memory, is stored only in a non-volatile form outside the storage medium.

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

[0151] Kexts are preferably not stored locally on drives, computers, etc., but can be provided to drives, computers, etc. in some form. Depending on the aspect, there are many ways to do this, including any of the methods listed in the previous section. For example, one way is to have the host encapsulate the Kext with a KEK before transmitting it to the ECD. Another way is to have the drive, computer, etc., support a KMIP client and receive the Kext from an external KMIP server (key manager) of a type known in the art via a secure channel.

[0152] Preferably, the Kext can only be stored in volatile form within the ECD. The key used to unpack the Kint (e.g., KEK) can be received from the host, an external security coordinator, the user, or a key manager, etc.

[0153] Kint is preferably stored encapsulated along with the storage medium and can be uncapsulated after the hard drive, computer, etc., is provided with an encapsulated key (which may be or depends on a KEK or PIN code provided to the hard drive, computer, etc. to verify different user roles supported by the hard drive, computer, etc.). Therefore, any part of the encapsulated key provided from outside the drive, computer, etc., is provided to the drive, computer, etc., to allow the Kint to be uncapsulated. Once the drive, computer, etc., has accumulated all the information (including Kext) required to compute the MEK, it computes the MEK and is then able to decrypt existing ciphertext to produce the plaintext result (e.g., responding to a host read), or encrypt new client data in plaintext form into ciphertext (e.g., performing a host write).

[0154] In Key per IO, the generation of Kexts is done outside the ECD by the host or a key manager that interacts with the host.

[0155] In the tape drive implementation method, preferably Kint comes from the tape medium, Kext comes from an interface, and the calculation of MEK is performed inside the encrypted tape drive and never leaves the tape drive.

[0156] Systems of various types include devices configured to perform data operations on storage media, the devices having a processor and logic integrated with the processor, executable by the processor, or integrated with and executable by the processor, the logic being configured to cause the device to perform some or all of the aforementioned operations, for example... Figures 4-7 The operation.

[0157] According to various methods, computer program products for enabling and / or performing encrypted erasure according to various means include a computer-readable storage medium having program instructions embodied therein, which can be executed by a device configured to perform some or all of the aforementioned operations, for example... Figures 4-7 The operation.

[0158] Exemplary Implementation

[0159] According to one approach, an illustrative process for protecting storage devices with Key per IO encryption capabilities (such as Encryptable Drives (ECDs)) includes the following operations:

[0160] 1. Generate a Kint and store it securely inside a storage device. Typically, a Kint is never stored in plaintext in non-volatile memory. Instead, it is stored in a wrapped form.

[0161] 2. Kexts are generated and stored outside of the ECD:

[0162] A. If the Kext is created outside the storage device, then the Kext is provided to the storage device when needed.

[0163] B. If the key used to encapsulate the Kext (e.g., KEK or PIN) is not already in the device, it must also be provided to the device or obtained by the device and used to uncapture the Kext.

[0164] C. Typically, many Kexts are used; for example, each tenant storing data on an ECD has one Kext.

[0165] 3. Storage devices use Kint and Kext to calculate MEK.

[0166] 4. MEK is used directly or indirectly to encrypt data to create ciphertext and to decrypt ciphertext to create plaintext.

[0167] An illustrative process for regaining access to a storage device with Key per IO encryption (e.g., an encrypted drive (ECD)) after a power outage or cold boot, according to one approach, includes the following operations:

[0168] 1. Provide Kext to storage devices

[0169] 2. Accessing the Kint inside the storage device may involve cryptographically unpacking the Kint, which may require one or more unpacking or access keys (such as KEK or PIN).

[0170] 3. Storage devices use Kint and Kext to calculate MEK.

[0171] 4. MEK is used directly or indirectly to encrypt data to create ciphertext and to decrypt ciphertext to create plaintext.

[0172] The process of replacing equipment or securing stolen equipment

[0173] According to one approach, when a storage device is to be phased out, for example, because its background error rate becomes too high (e.g., this might be due to too many write cycles) or perhaps because it "failed" without successfully completing some operations, the illustrative procedures that can be performed include the following:

[0174] 1. Send a command to the storage device instructing it to destroy its Kint and all MEK currently stored on the device that were generated using that Kint.

[0175] 2. Were the destructions of Kint and MEK successful? If:

[0176] If yes, then the data encrypted under MEK or those MEKs has been successfully encrypted and erased.

[0177] In this case, while it's not necessary to destroy Kext, it's possible to do so.

[0178] No, in this case, it cannot be assumed that any encryption erasure has occurred:

[0179] • Damage the external Kext of the storage device and use external means to encrypt and erase the data corresponding to that Kext on the storage device.

[0180] • Power off the storage device or perform a cold start to ensure that the storage device does not retain a volatile image of the key.

[0181] Note that key deletion can also be performed in reverse order, where Kext is destroyed first, preferably followed by an attempt to delete Kint. According to one approach, the illustrative process includes the following operations:

[0182] 1. Damage the external Kext of the storage device to encrypt and erase the data corresponding to the Kext on the storage device through external means, or destroy all Kexts to encrypt and erase all data on the storage device.

[0183] 2. Send a command to the storage device that instructs the storage device to encrypt and erase the Kint associated with the Kext corresponding to the data to be encrypted and erased.

[0184] 3. Was Kint's encryption and erasure process successful? If:

[0185] If yes, then the data encrypted under MEK or those under MEK has been successfully encrypted and erased by the destruction of Kint and Kext.

[0186] • Perform a cold boot of the storage device using the Power Cycle Reset command, or execute an actual power cycle (i.e., remove power for a period of time before storing) to ensure that the storage device does not retain any volatile images of Kext or MEK.

[0187] No, but the Kext outside the storage device has been corrupted, so the encrypted erasure of the storage device is achieved through external means.

[0188] It's also important to note that the destruction or erasure of all Kexts and MEKs can be accomplished by disconnecting the device from power and / or performing a cold boot (e.g., via a Power Cycle Reset call). Therefore, these MEKs can be destroyed last. However, this destruction must occur before the data encrypted with these MEKs is actually encrypted and erased. In short, to achieve the encrypted erasure of data encrypted with one or more MEKs, either the MEK and its associated Kint must be destroyed, or the MEK and its associated Kext must be destroyed.

[0189] It is also important to note that if the storage device is stolen, or lost without being encrypted and erased before being removed from the storage system, such as during transport to another location, it is no longer possible to encrypt and erase the data by destroying the Kint since people do not have physical access to the storage device. Instead, people must destroy the Kext, which is possible even without physical access to the storage device, as long as the Kext has not been (e.g., secretly) logged.

[0190] Figure 8A program that can be executed on an edge device without any aspects of the present invention is described, in contrast to a program that can be executed on an edge device having one or more aspects of the present invention. Figure 8 The diagrams in the figures are self-evident and are presented only by way of example. It should be noted that all aspects of this invention are only implemented in a Key per IO environment, according to... Figure 8 The last row of the diagram shows that cryptographic erasure is only possible after confirming the corruption of the Kint. It's also important to note that if the corruption of the Kint and any MEKs currently present in the device generated using the Kint is confirmed, cryptographic erasure of the data is achievable much faster than confirming "erase all password text" as described in the previous two rows, which can take up to several hours (thoroughly confirming that all pages have been completely erased by reading (possibly by page erasure) can also take several hours). Therefore, certain aspects of this invention can increase the speed of ECD disinfection by several orders of magnitude.

[0191] Another approach, independent of and not limited by the use of any aspect of this invention, is to selectively and cryptographically erase individual tenant data by destroying all Kexts and all MEKs created using those Kexts, the MEKs being cryptographically associated with the tenant's data. Note that when a Kint used with these Kexts spans multiple tenants, including those with encrypted data that needs to be retained (i.e., not cryptographically erased), the Kint will remain internal to the device.

[0192] This invention can be a system, method, and / or computer program product integrated at any possible level of technical detail. The computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to execute aspects of the invention.

[0193] Computer-readable storage media can be tangible devices capable of retaining and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer floppy disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, mechanical encoding devices, such as punch cards or raised structures in recesses, on which instructions are recorded, and any suitable combination of the foregoing. The computer-readable storage media used herein should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through optical fibers), or electrical signals transmitted through wires.

[0194] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to their respective computing / processing devices, or downloaded via a network to an external computer or external storage device, such as the Internet, a local area network (LAN), a wide area network (WAN), and / or a wireless network. This network may include copper transmission cables, optical fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the respective computing / processing device for storage.

[0195] Computer-readable program instructions used to perform the operations of this invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or similar languages, and 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, partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or wide area network (WAN), or connected to an external computer (e.g., using an Internet service provider via the Internet). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, a field-programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuitry and thereby perform various aspects of the invention.

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

[0197] These computer-readable program instructions may be provided to a computer processor or other programmable data processing apparatus to produce a machine, such instructions, which, when executed by the processor of a computer or other programmable data processing apparatus, create means for implementing the functions / behaviors specified in the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, and / or other apparatus to operate in a particular manner. Thus, a computer-readable storage medium having instructions stored therein includes an article of writing comprising instructions for implementing aspects of the functions / behaviors specified in the blocks of the flowcharts and / or block diagrams.

[0198] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device, thereby producing a computer-implemented process, in which the instructions that execute on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the flowchart and / or block diagram.

[0199] The flowcharts and block diagrams in the figures illustrate the structure, function, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the blocks may not appear in the order shown in the figures. For example, two blocks shown consecutively may actually be completed as a single step, executed simultaneously, executed substantially simultaneously, executed in a manner with partial or complete time overlap, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagram and / or flowchart illustrations, and combinations of blocks in the block diagram and / or flowchart illustrations, may be implemented by special-purpose hardware systems that perform the specified functions or behaviors, or by combinations of special-purpose hardware and computer instructions.

[0200] Furthermore, systems according to various embodiments may include a processor and logic integrated with and / or executable by the processor, the logic being configured to perform one or more processing steps described herein. The processor may be any configuration described herein, such as a discrete processor or including numerous components of processing hardware such as processing hardware, memory, I / O interfaces, etc. "Integrated" means that the processor has logic embedded therein as hardware logic such as application-specific integrated circuits (ASICs), FPGAs, etc. "Executable by a processor" means that the logic is hardware logic, such as software logic as firmware, part of an operating system, part of an application, or a combination of hardware and software logic accessible to the processor and configured to cause the processor to perform certain functions when executed by the processor. The software logic may be stored on local and / or remote memory of any memory type, as known in the art. Any processor known in the art may be used, such as a software processor module and / or a hardware processor such as an ASIC, FPGA, central processing unit (CPU), integrated circuit (IC), graphics processing unit (GPU), etc.

[0201] It is clear that the various features of the above systems and / or methods can be combined in any way, creating a variety of combinations from the description above.

[0202] It will be further understood that aspects of the present invention can be provided in the form of services deployed on behalf of customers, to provide services on demand.

[0203] The description of various aspects of the invention is provided for illustrative purposes and is not intended to be exhaustive or limiting. Many modifications and variations will be apparent to those skilled in the art without departing from the scope of the described aspects. The terminology used herein is intended to best explain the principles of the various methods, practical applications or improvements to techniques found in the market, or to enable others skilled in the art to understand the methods disclosed herein.

Claims

1. A method implemented by a device, comprising: One or more unique external keys are received at a device configured to perform data operations on a storage medium, the one or more external keys being provided to the device from one or more external sources for use in Key perIO operations; Access the internal key stored within the device; Using the internal key and an associated external key from the one or more external keys, a unique media encryption key is generated for each of at least some of the one or more external keys, each media encryption key being associated with the external key used to generate the media encryption key; as well as In response to receiving a request to perform a data operation on first data associated with a first external key among the one or more external keys, the first data is encrypted and / or decrypted using the media encryption key associated with the first external key.

2. The method implemented by the device according to claim 1, wherein the internal key is generated internally within the device.

3. The method implemented by the device according to claim 2, wherein the internal key is stored in the non-volatile memory of the device in an encapsulated form.

4. The method implemented by the device according to claim 1, wherein the one or more external keys and the medium encryption key are stored only in the volatile memory within the device.

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

6. The method implemented by the device according to claim 1, wherein the plurality of external keys are respectively associated with unique data stored at different locations within the same logical block address range.

7. The method implemented by the device according to claim 1, wherein at least one of the media encryption keys is created using more than one internal key.

8. The method implemented in the device according to claim 1, comprising encrypting and erasing data written using one or more media encryption keys created with the internal key by destroying the internal key and all associated media encryption keys in the device created using the internal key.

9. A computer program product for implementing encrypted erasure, 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 the storage medium to cause the device to perform the method according to claim 1.

10. A system for implementing encrypted erasure, comprising: The device is configured to perform the data operation on the storage medium, the device having a processor and logic, the logic being integrated with the processor, executable by the processor, or integrated with and executable by the processor, the logic being configured to cause the device to perform the method according to claim 1.

11. A method implemented by a device, comprising: A request is received at a device configured to perform data operations on a storage medium to write the first data in encrypted form using a first external key associated with the first data; Access the internal key stored within the device; A first medium encryption key is generated using the internal key and the first external key; The first data is encrypted using the first medium encryption key; The encrypted first data is written into the storage medium within the address range of the first logical block of the storage medium; The device receives a second request to write the second data into the storage medium in encrypted form using a second external key associated with the second data. Access the internal key stored in the device; A second medium encryption key is generated using the internal key and the second external key; The second data is encrypted using the second medium encryption key; as well as The encrypted second data is written to the storage medium within the address range of the first logical block of the storage medium.

12. The method implemented by the device according to claim 11, wherein the internal key is generated internally within the device.

13. The method implemented by the device according to claim 11, comprising receiving the external key from one or more external sources.

14. The method implemented by the device according to claim 13, wherein the external key and the medium encryption key are stored only in the volatile memory within the device.

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

16. The method implemented by the device according to claim 11, wherein the device is configured as a Key per IO device.

17. A method for encrypted erasure implemented in a device, the method comprising: A request is received at a device configured to perform data operations on a storage medium using Key per IO operations, causing encrypted erasure of all data within at least one logical block address range of the storage medium. Each portion of the data within the at least one logical block address range is associated with a unique external key, and each portion of the data is encrypted using a unique media encryption key, which is created using an internal key stored within the device and the unique external key associated with the portion of the data received at the device. as well as Encryption erasure is achieved by destroying the internal key in the device and all media encryption keys associated with the internal key.

18. The method implemented by the device according to claim 17, wherein the external key and the medium encryption key are stored only in the volatile memory within the device.

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

20. A system for implementing encrypted erasure, comprising: A device configured to perform data operations on a storage medium, the device having a processor and logic, the logic being integrated with the processor, executable by the processor, or integrated with and executable by the processor, the logic being configured to cause the device to perform the method according to claim 17.

Images