Self-encrypting drive

Abstract

The present disclosure relates to a self-encrypting drive (SED). The self-encrypting drive (SED) receives a media encryption key (MEK) from a key management server. The MEK is stored only in a volatile memory of the SED. Data is encrypted based on the MEK for storage in a non-volatile storage medium of the SED. Further, the MEK is erased in the volatile memory to cryptographically wipe the SED by deleting all instances of the MEK stored by the SED.

Description

[0001] Cross-references to related applications

[0002] This disclosure claims the benefit of priority to U.S. Provisional Application Serial No. 62 / 934,701, filed November 13, 2019, entitled “Method and Apparatus for Decommissioning a Hard Disk Drive”, filed April 4, 2019, entitled “Self-Encryption Drive (SED) Architecture for Data Center”, and U.S. Provisional Application Serial No. 62 / 829,537, filed December 10, 2018, entitled “Blockchain Based Decommissioning HDD / SDDs in Data Center”, the contents of each of which are incorporated herein by reference in their entirety. Technical Field

[0003] This disclosure generally relates to the field of data storage, and more specifically to a self-encrypting drive (SED) that receives a media encryption key (MEK) from a key management server and stores the MEK on the SED and only in the volatile memory of the SED. Background Technology

[0004] The background description provided herein is for the purpose of presenting the contents of this disclosure. The work of the currently named inventors within the scope of work described in this background section, and aspects of this specification that are not considered prior art at the time of submission, are not expressly or implied to be prior art to this disclosure.

[0005] The Trusted Computing Group (TCG) develops, defines, and promotes vendor-agnostic global industry specifications and standards to support security and trust services on storage drives such as Self-Encrypting Drives (SEDs). An SED is a special type of storage drive that stores data in an encrypted format on the SED's non-volatile storage medium and / or decrypts data stored in an encrypted format on the SED's non-volatile storage medium. This encryption format is typically a format that hides the data by altering it to make it appear random.

[0006] The Media Encryption Key (MEK) is used to encrypt data to be stored on non-volatile storage media and to decrypt encrypted data stored on non-volatile storage media. The MEK is a string of bits, which can be 128 or 256 bits long. The MEK is stored in encrypted format on the SED's non-volatile storage media. If the host computer is authenticated, the SED decrypts the MEK stored in encrypted format on the non-volatile storage media back to plaintext format. The plaintext format is typically unencrypted. The plaintext MEK allows for the encryption of data received from the host computer for storage on non-volatile storage media, or the decryption of encrypted data stored on non-volatile storage media. If the host is not authenticated, the MEK stored in encrypted format on the non-volatile storage media will not be decrypted, and no data will be encrypted or decrypted.

[0007] Even with encryption, storing MEK on non-volatile storage media carries several risks. There is a risk that the MEK stored on non-volatile media may be corrupted, rendering the stored data inaccessible. Furthermore, if the SED is lost or stolen, there is a risk that the SED could authenticate unauthorized host computers and grant access to the data stored on the non-volatile storage media.

[0008] Furthermore, storing MEK on non-volatile storage media makes decommissioning a SED difficult. SEDs typically have a lifespan of 3 to 5 years before decommissioning. The National Institute of Standards and Technology (NIST) 800-88 guideline requires the deletion or alteration of all instances of MEK on the SED when it is decommissioned, i.e., a cryptographic erasure of the SED, to protect the security of encrypted data on the SED. Deleting or altering MEK requires deleting or erasing every instance of MEK on the non-volatile storage media. This becomes even more difficult when the non-volatile storage media takes the form of, for example, solid-state drives (SSDs), universal serial bus (USB) flash drives, or phase-change memory drives. As the non-volatile storage media ages, different physical addresses of the non-volatile storage have different levels of storage reliability. MEKs are moved to those physical addresses where MEKs are reliably stored. The storage controller uses logical addresses to reference the physical addresses where MEKs are stored, which are translated throughout the SED's lifespan to the various physical addresses on the non-volatile storage media where MEKs are stored. This means that the storage controller needs to track the physical address where MEK is stored throughout the entire lifespan of the SED so that all instances of MEK can be deleted or changed on non-volatile storage media when the SED is deactivated.

[0009] If an SED malfunctions and becomes inoperable, the MEK cannot be modified or deleted. Instead, the SED must be physically destroyed and disposed of, which is a waste of time and money. A destroyed SED also generates unnecessary waste, exacerbating environmental pollution. Furthermore, destroying SSDs, USB drives, and phase-change memory requires sufficiently fine granular damage to the semiconductor chip to ensure that the MEK stored on it is destroyed.

[0010] In summary, even with an encrypted format, storing MEK on the non-volatile storage medium of SED poses security risks and increases the additional costs and work associated with disabling SED. Summary of the Invention

[0011] This disclosure relates to the field of data storage, and more particularly to a self-encrypting drive (SED). After registration, the SED receives a media encryption key (MEK) from a key management server and stores the MEK solely in the SED's volatile memory. The MEK is used to encrypt data for storage on the SED's non-volatile media and to decrypt data stored on the SED's non-volatile media. Furthermore, when the SED is no longer powered, the MEK is automatically deleted from the volatile memory, thereby enhancing the security of encrypted data stored on the non-volatile storage media, since the SED does not possess the MEK.

[0012] This disclosure provides a method for cryptographically erasing a self-encrypting drive (SED) by deleting all instances of a media encryption key (MEK) stored by the self-encrypting drive (SED), wherein the self-encrypting drive (SED) includes (i) volatile memory and (ii) non-volatile storage medium, the method comprising: receiving a media encryption key (MEK) from a key management server; storing the media encryption key (MEK) received from the key management server only in the volatile memory of the self-encrypting drive (SED); encrypting data based on the media encryption key (MEK) for storage in the non-volatile storage medium of the self-encrypting drive (SED); and erasing the media encryption key (MEK) from the volatile memory of the self-encrypting drive (SED) to cryptographically erase the self-encrypting drive (SED).

[0013] In one example, when the SED is not powered by a host computer coupled to the SED, only the MEK stored in the SED's volatile memory is erased. In another example, receiving the MEK includes receiving a timestamp associated with the MEK from a key management server, the timestamp indicating whether the MEK has expired. In yet another example, the method further includes determining whether the difference between the timestamp associated with the MEK and another timestamp is less than a specific duration, and wherein storing the MEK only in the SED's volatile memory includes storing the MEK if the difference is less than the specific duration. In yet another example, the method further includes receiving an additional timestamp from a timestamp authorization server or a timer counter register of the SED that is remote to the SED. In yet another example, the MEK is generated by a key management server. In yet another example, the stored MEK is wrapped with a key associated with a user's password, which is associated with the SED. In yet another example, the method includes: accessing a blockchain that stores indications of whether the SED has been deactivated, and wherein storing MEK on the SED, and storing only in the volatile memory of the SED, includes: if the indication indicates that the SED has not been deactivated, then storing MEK only in the volatile memory of the SED.

[0014] This disclosure provides a non-transitory computer-readable medium storing instructions for cryptographically erasing a self-encrypting drive (SED) by deleting all instances of a media encryption key (MEK) stored by the self-encrypting drive (SED), the instructions, when executed by one or more processors, causing the one or more processors to perform at least the following operations: receiving a media encryption key (MEK) from a key management server; storing the media encryption key (MEK) received from the key management server only in the volatile memory of the self-encrypting drive (SED); encrypting data based on the media encryption key (MEK) for storage in the non-volatile storage medium of the self-encrypting drive (SED); and erasing the media encryption key (MEK) from the volatile memory of the self-encrypting drive (SED) to cryptographically erase the self-encrypting drive (SED).

[0015] In one example, when the SED is not powered by a host coupled to the SED, only the MEK stored in the SED's volatile memory is erased. In another example, the MEK is associated with a timestamp indicating whether the MEK has expired. In yet another example, the non-transitory computer-readable medium further includes instructions for determining whether the difference between a timestamp associated with the MEK and another timestamp is less than a specific duration, and wherein the instructions for storing the MEK only in the SED's volatile memory include instructions for storing the MEK if the difference is less than the specific duration. In another example, the non-transitory computer-readable medium further includes instructions for receiving an additional timestamp from a timestamp grant server or a timer counter register of the SED that is remote to the SED. In yet another example, the MEK is associated with a range addressed by the logical block address (LBA) of the SED's non-volatile storage medium. In another example, the non-transitory computer-readable medium further includes: instructions for accessing a blockchain that stores instructions on whether the SED is deactivated, and wherein the instructions for storing MEK on the SED, stored only in the volatile memory of the SED, include: instructions for storing MEK only in the volatile memory of the SED if the instructions indicate that the SED is not deactivated.

[0016] This disclosure provides a self-encrypting drive (SED) configured to delete all instances of a media encryption key (MEK) stored in the self-encrypting drive (SED) for cryptographic erasure of the self-encrypting drive (SED). The self-encrypting drive (SED) includes: volatile memory; a non-volatile storage medium; and instructions stored in the memory of the self-encrypting drive (SED), which, when executed by one or more processors of the self-encrypting drive (SED), cause the SED to perform at least the following operations: receive a media encryption key (MEK) from a key management server; store the media encryption key (MEK) received from the key management server only in the volatile memory of the self-encrypting drive (SED); encrypt data based on the media encryption key (MEK) for storage in the non-volatile storage medium of the self-encrypting drive (SED); and erase the media encryption key (MEK) in the volatile memory of the self-encrypting drive (SED) for cryptographic erasure of the self-encrypting drive (SED).

[0017] In one example, MEK is associated with a timestamp indicating whether MEK has expired. In another example, the SED further includes instructions for determining whether the difference between a timestamp associated with MEK and another timestamp is less than a specific duration, and wherein the instructions for storing MEK only in the volatile memory of the SED include instructions for storing MEK if the difference is less than the specific duration. In yet another example, the SED further includes instructions for receiving an additional timestamp from a timestamp authorization server or a timer counter register of the SED that is remote to the SED. In yet another example, the SED further includes instructions for accessing a blockchain that stores indications about whether the SED has been deactivated, and wherein the instructions for storing MEK on the SED only in the volatile memory of the SED include instructions for storing MEK only in the volatile memory of the SED if the indication indicates that the SED has not been deactivated. Attached Figure Description

[0018] Figure 1 This is a block diagram of an exemplary self-encrypting drive (SED) deployed in a data center.

[0019] Figure 2 The illustration shows an exemplary initialization process between the host computer and the SED.

[0020] Figure 3 The illustration shows an example registration process for associating a Media Encryption Key (MEK) with a range allocated during initialization to facilitate the encryption of data stored within that range and the decryption of data stored within that range.

[0021] Figure 4 The illustration shows a sample detail of the registration process when SED registers using a key management server.

[0022] Figure 5 The illustration shows example details of providing MEK from SED to the key management server for storage in the range key database.

[0023] Figure 6 The illustration shows example details related to providing MEK from a range key database to the SED to facilitate encryption and decryption operations on the SED.

[0024] Figure 7 The illustration shows an example process that reflects the deactivation of SED.

[0025] Figure 8 This is an example flowchart of the function associated with SED storing MEK in SED's volatile memory.

[0026] Figure 9This is an example system diagram of SED.

[0027] The accompanying drawings are for illustrative purposes only, but it should be understood that the embodiments are not limited to the arrangements and means shown in the drawings. Detailed Implementation

[0028] This disclosure provides examples and details relating to a self-encrypting drive (SED). The SED receives a protected media encryption key (MEK) from a key management server via a host computer connection and stores the MEK on the SED and only in volatile memory. For example, the MEK is not stored on the non-volatile storage medium of the SED. Encrypted data on the non-volatile storage medium is secure because the MEK in the volatile memory is deleted when the SED is no longer powered on and the SED no longer has the MEK to decrypt the encrypted data. In some examples, the SED may take the form of a hard disk drive (HDD), a solid-state drive (SSD), or a Universal Serial Bus (USB) flash drive. The principles described herein are applicable to these different types of storage devices.

[0029] Example Architecture

[0030] Figure 1 This is a block diagram 100 of an exemplary self-encrypting drive (SED) 102 deployed in a data center. Block diagram 100 includes a host computer 104, SED 102, key management server 106, and range key database 108 coupled together via a communication network 110, such as a local area network (LAN) or a wide area network (WAN). In this example, one or more of the SED 102, host computer 104, key management server 106, and range key database 108 deployed in the data center provide on-demand computer system resources, particularly data storage.

[0031] Host computer 104 can be a computer, server, smartphone, tablet, computer, laptop, etc., located in a data center. Host computer 104 can be coupled to SED 102 to facilitate data storage to SED 102 via connection 105, such as Serial Advanced Technology Attachment (SATA), Peripheral Component Interconnect Fast (PCIe), Small Computer System Interface (SCSI), and a network switch that routes to SED 102 via Storage Area Network (SAN). In some examples, host computer 104 can also power SED 102.

[0032] The key management server 106 facilitates the sending and receiving of protected medium encryption keys (MEKs), such as encryption keys, used to encrypt and decrypt data stored on the SED 102. The MEK can be a string of bits, for example, 128 bits or 256 bits long, used as a code to convert encrypted data into plaintext format and vice versa. The key management server 106 can operate according to the Key Management Interoperability Protocol (KMIP), which defines the message formats for sending MEKs to and from the SED 102, and manipulating the MEKs.

[0033] The range key database 108 may have storage devices for storing MEKs. In the example, a key management server 106 may be coupled to the range key database 108 to facilitate the storage of MEKs in the range key database 108. The range key database 108 is illustrated as a system separate from the key management server 106, but in some examples, the functionality of both may be integrated into a single system.

[0034] SED 102 can be a special type of storage drive that stores data in an encrypted format on the non-volatile storage medium 112 of SED 102 and / or decrypts data stored in an encrypted format on the non-volatile storage medium 112 of SED 102. This encryption format is typically a format that hides the data by altering it to make it appear random. The non-volatile storage medium 112 can be a storage medium on SED 102 that persistently stores data, such as encrypted data, even when power is lost from SED 102. The non-volatile storage medium 112 can take many forms. For example, if SED 102 is a hard disk drive (HDD), then the non-volatile storage medium 112 can be a disk. As another example, if SED 102 is a solid-state drive (SSD) or Universal Serial Bus (USB), then the non-volatile storage medium 112 can be a non-volatile memory such as NAND memory, NOR memory, or phase-change memory.

[0035] Non-volatile storage medium 112 may include multiple partitions 114-118, including a boot partition 114, a user data partition 118, and a metadata partition 116. Boot partition 114 may include an operating system (OS) associated with the boot host computer 104. User data partition 118 may store data associated with one or more users of SED 102. Multiple ranges may be assigned to each user, addressed by a logical block address (LBA) or some other identifier of a storage location in non-volatile storage medium 112, in which the user can store data (referred to as a range). User data partition 118 is shown with ranges associated with two users (User 1 and User 2), but user data partition 118 may include more or fewer ranges. In the example, multiple users may be assigned the same range or unique ranges. Metadata partition 116 may include an administrator service provider (SP) table and a lockout service provider (SP) table. The administrator service provider table may store passwords in an encrypted format for the administrator of the SED (who controls which users can access SED 102). The lock service provider table can identify the range of non-volatile storage media 112 associated with each user of SED 102.

[0036] SED 102 may also include an encryption / decryption engine 122, an embedded hardware security module (eHSM) 124, volatile memory 130, one-time programmable memory (OTP) 120, and flash memory 134. One or more of the decryption engine 122, the embedded hardware security module (eHSM) 124, the volatile memory 130, the one-time programmable memory 120, and / or flash memory 134 may be implemented by a processor that executes computer instructions (e.g., firmware) stored in flash memory 134 or any other suitable type of hardware and / or software to perform the functions described herein.

[0037] The encryption / decryption engine 122 can perform encryption and decryption functions. Encryption is generally the process of converting plaintext data into encrypted data. Encrypted data hides the data by altering it, making the data appear random, while the plaintext format remains unencrypted. Decryption is the process of converting encrypted data back into plaintext data. The encryption / decryption engine 122 can encrypt plaintext data for storage on the non-volatile storage medium 112 and decrypt the encrypted data stored on the non-volatile storage medium 112. In this example, the encryption / decryption engine 122 may conform to the Advanced Encryption Standard (AES), which defines a symmetric key algorithm for handling data encryption and decryption in blocks of 128 bits, 192 bits, or 256 bits.

[0038] eHSM 124 can control the security of encrypted data on the non-volatile storage medium 112 of SED 102. In one example, eHSM 124 can generate a MEK to encrypt data for storage on the non-volatile storage medium 112 and decrypt data stored on the non-volatile storage medium 112. In another example, eHSM 124 can securely provide the MEK to the key management server 106 for storage in the range key database 108. In yet another example, eHSM 124 can securely receive a MEK stored in the range key database 108 from the key management server 106. In yet another example, eHSM 124 can securely provide a MEK to the encryption / decryption engine 122 to encrypt data on the non-volatile storage medium 112 and decrypt data stored on the non-volatile storage medium 112. In some examples, the eHSM 124 can securely provide the MEK to the encryption / decryption engine 122 via a dedicated communication path 128 between the eHSM 124 and the encryption / decryption engine 122.

[0039] MEK can be stored on SED 102 and only on the volatile memory 130 on SED 102, instead of being stored on the non-volatile storage medium 112 in a conventional manner. The volatile memory 130 can be a storage device (such as random access memory) that requires power to maintain the stored information, and the volatile memory 130 can be read, written, and erased multiple times; the volatile memory 130 retains the stored information while powered on, but the stored data is lost when the power is interrupted. In this example, the volatile memory 130 can store MEK for the encryption / decryption engine 122 to encrypt plaintext data into encrypted data and decrypt the encrypted data into plaintext data. Even though the volatile memory 130 is shown as separate from the encryption / decryption engine 122, such as a system buffer, the volatile memory 130 can be accessed by the encryption / decryption engine 122 and the eHSM 124. In other examples, at least a portion of the volatile memory 130 can be located within the encryption / decryption engine 122 and the eHSM 124.

[0040] In this example, a MEK may be associated with a range of non-volatile storage medium 112, and is also referred to herein as a range key. The range key can be used to encrypt and / or decrypt data within a range on the non-volatile storage medium 112. In this case, multiple MEKs may be associated with SED 102, each MEK associated with encrypting and / or decrypting data within a given range. The MEK used to encrypt data within a range is stored in the volatile memory 130 of SED 102. The MEK is not stored on the non-volatile storage medium 112, and in particular, is not stored in the lock service provider table in the metadata partition 116 on the non-volatile storage medium 112.

[0041] The OTP 120 is a semiconductor memory that can only be written to once (e.g., by blowing a fuse), and the stored information can be retrieved even after power-on. In this example, the OTP 120 can store the identifier and unique device secret (UDS) of the SED 102. This identifier can be a physical security ID pin (Personal Identification Number) (C_PIN_PSID) used to uniquely identify the SED, and can be stored in the OTP 120 during the manufacturing process of the SED 102. In this example, the C_PIN_PSID can match the C_PIN_PSID affixed to the label on the SED. The UDS can be an encryption key, and may have been stored in the OTP 120 during the manufacturing process of the SED 102.

[0042] Flash memory 134 may be in the form of non-volatile memory such as NAND or NOR memory, used to store firmware (FW) associated with SED 102. The firmware may include bootloader firmware 136 associated with operating one or more encryption / decryption engines 122 and eHSM 124. Flash memory 134 may include other firmware, but MEK will not be stored in flash memory 134.

[0043] In some examples, one or more of the encryption / decryption engine 122, volatile memory 130, eHSM 124, OTP 120, and flash memory 134 may define the storage controller 132 of SED 102. The storage controller 132 may include other components associated with the storage of data on the non-volatile storage medium 112, which are not shown for clarity.

[0044] Example Operation

[0045] Figure 2An example initialization process 200 for configuring SED 102 between host computer 104 and SED 102 is illustrated. Initialization process 200 is based on the Trusted Computing Group (TCG) protocol executed between eHSM 124 and host computer 104. Initialization process 200 can be implemented by one or more of hardware, software, or a combination of hardware and software. Furthermore, Figure 2 The initialization process 200 shown includes... Figure 1 These are some components similar to those described above. Descriptions of these components have already been provided above, and for clarity, they will be omitted here.

[0046] At point 202, the host computer 104 is powered on. Powering on the host computer also powers on the storage controller 132 to load the bootloader firmware 136 into one or more of the eHSM 124 and the encryption / decryption engine 122.

[0047] At position 204, ownership of SED 102 is acquired. The administrator of SED 102 can store the administrator password in the Management Service Provider table (AdminSP table) of the metadata partition 116 on non-volatile storage medium 112 to control access to SED 102 by one or more users. In the example, the administrator can set the password if no administrator has previously accessed SED 102 or if the password has been reset. Additionally, acquiring ownership may include exporting the public and private keys used for SED 102. The private and public keys can be encryption keys associated with SED 102, where the public key can be shared outside of SED 102, and the private key may not be shared outside of SED 102.

[0048] eHSM 124 can derive public and private keys based on data stored in OTP 120 (such as C_PIN_PSID and UDS) to generate public and private keys for SED 102. For example, the UDS and C_PIN_PSID stored in OTP 120 can be applied to functions such as the Device Identifier Synthesis Engine (DICE) in eHSM 124 to generate a Composite Device Indicator (CDI). The Cryptographic Key Derivation Function (PBKDF) in eHSM 124 determines the private key for SED based on the CDI: PBKDF(CDI) = SED_PrivKey for Elliptic Curve (EC) cryptography. The private key is then used to derive the public key for SED based on PubKey_Derivation: PubKey_Derivation(SED_PrivKey) = SED_PubKey for EC cryptography. The private and public keys of the SED can be used to encrypt / decrypt the administrator password in the management service provider table of the metadata partition 116 stored in the non-volatile storage medium 112. In other examples, instead of eHSM 124 or other methods that generate the public and / or private keys using eHSM 124, one or more of SED_PrivKey and SED_PubKey can be generated by the key management server 106 or other systems and provided to the SED 102. In this example, SED_PrivKey and SED_PubKey can be stored in OTP 120.

[0049] At position 204, a range access is assigned to a user of SED 102. A range access can identify an LBA or some other identifier of the storage device at which the user can store data into non-volatile storage medium 112. In some examples, SED 102 can support 32 to 128 unique ranges, and one or more ranges can be assigned to each user.

[0050] At point 206, a login is established for the user. For example, an administrator can assign a default password to the user, which is stored in the management service provider's metadata partition 116 of non-volatile storage medium 112. The user can then provide this default password to the SED to access the scope associated with the user. The private key and / or public key of SED 102 can be used to encrypt / decrypt the default password, similar to the administrator's password, in the management service provider.

[0051] SED 102 can support multiple users. In the example, initialization process 200 and steps 202-206 can be repeated once or multiple times to associate each user with a range in non-volatile storage medium 112. Each range can store encrypted data for the corresponding user on the non-volatile storage medium 112 of SED 102.

[0052] Figure 3 An example registration process 300 is illustrated, which associates the MEK with a range allocated during the initialization process to encrypt user data for storage and decryption within that range. Furthermore, the MEK can be stored on the SED 102 and only in the volatile memory 130. By storing the MEK on the SED 102 only in the volatile memory 130, the encrypted data on the non-volatile storage medium 112 is secure because the MEK in the volatile memory 130 is deleted when the SED 102 is no longer powered on. The SED 102 does not have a MEK for decrypting the encrypted data on the non-volatile storage medium 112.

[0053] The registration process 300 may include communication between the key management server 106 and the eHSM 124 of the SED 102, and is implemented by one or more of hardware, software, or a combination of hardware and software. For ease of illustration, the communication is directly shown as steps 302-308 between the key management server 106 and the eHSM 124; however, in this example, the communication may occur via the host computer 104. Furthermore, Figure 3 The registration process 300 shown may include, but is not limited to, the registration process with respect to, information about Figure 1 This describes components similar to those in the description. Descriptions of these components have already been provided above and will be omitted here for clarity.

[0054] At point 302, host computer 104 is powered on, causing it to boot. Host computer 104 can boot via an OS in boot partition 114 on non-volatile storage medium 112 of SED 102. Powering on also powers on storage controller 132 to load bootloader firmware 136 into one or more of eHSM 124 and encryption / decryption engines 122. Host computer 104 can facilitate communication between SED 102 and key management server 106.

[0055] At 304, SED 102 registers using key management server 106. Registration may include key management server 106 allocating data structures in range key database 108 to store one or more range keys associated with one or more users of SED 102.

[0056] At point 306, the MEK is sent from eHSM 124 to key management server 106 for storage in range key database 108. The MEK can be wrapped for transmission using one or more encryption keys derived from the encryption keys associated with the user's password and the range key (e.g., PBKDF) and UDS. The wrapped MEK can also be encrypted using a shared session key held by both SED 102 and key management server 106, which is associated with the communication session between SED and key management server 106.

[0057] At 308, the MEK from the range key database 108 is loaded into volatile memory 130. If the MEK was previously sent to the key management server 106 for storage in the range key database 108, it can be loaded from the range key database 108 into volatile memory 130 after power-off and upon startup of SED 102. The loaded MEK allows SED 102 to encrypt data for storage within the range associated with the MEK and decrypt data stored within the range associated with the MEK. The loading of the MEK involves the MEK on SED 102 and storage only in volatile memory 130 so that if SED 102 is no longer powered, the MEK is erased from SED 102, resulting in an encrypted erasure of SED 102, meaning no MEK is stored on SED 102 in plaintext or encrypted form. Because MEK is not stored on non-volatile storage medium 112, the encrypted data stored on non-volatile storage medium 112 is secure when SED 102 is powered off.

[0058] Figure 4 Example details of the registration process when SED 102 registers using key management server 106 are shown. This process may include communication between key management server 106 and eHSM 124, which is at least related to… Figure 3 It relates to step 304 and is implemented by one or more of hardware, software, or a combination of hardware and software.

[0059] At 402, a request is sent from SED 102 to Key Management Server 106 to open a secure communication session via the communication network 110 between SED 102 and Key Management Server 106. This request identifies various information associated with the data structure allocated in Range Key Database 108 to store one or more range keys for SED 102. This information may include the C_PIN_PSID of SED 102 for identifying SED 102, an indication that a MEK in the form of a RangeKey will be used to encrypt and decrypt data on SED 102, and / or multiple ranges supported by SED 102 as indicated by Range_num. The communication session is then opened.

[0060] At 404, the C_PIN_PSID, SED_PubKey, OEM-CAVerifyKey, and DigitalSignature are sent from eHSM 124 to Key Management Server 106. C_PIN_PSID and SED_PubKey have been described above. OEM-CAVerifyKey can be a public key associated with: the Certificate Authority (CA) server of the Original Equipment Manufacturer (OEM) of SED 102, and a digital certificate of the OEM maintained by the CA that issued the digital certificate and proves ownership of the OEM-CAVerifyKey. The sent C_PIN_PSID and SED_PubKey can be signed with the OEM CA signing key to generate a digital signature. DigitalSignature can be used to verify the C_PIN_PSID and SED_PubKey of SED 102 associated with the received OEM-CAVerifyKey. OEM-CAVerifyKey can be checked by Key Management Server 106 by directly querying from a trusted OEM CA server in the network, or it can be checked relative to a pre-supplied value. Based on this verification, the key management server 106 can confirm that SED 102 sent C_PIN_PSID and SED_PubKey. The key management server 106 can allocate data structure 410 in the range key database 108, which is uniquely identified by the C_PIN_PSID in the range key database 108. Data structure 410, also referred to as a range key storage device, includes one or more timestamp slots 412, a certain number of range key slots 414 that may be equal to or greater than Range_num, a public key slot 416, and a digital signature slot 418. In this example, a timestamp can be stored in the timestamp slot 412, indicating the time when data structure 410 was allocated, such as a counter value. The timestamp can be provided by SED 102 during a communication session, based on a timer counter register associated with storage controller 132, or obtained from a trusted third party, such as a Timestamp Authority (TSA) server, as specified in RFC 3161 published by the Internet Society. In some examples, the timer counter register may be a register in volatile memory 130, and the TSA server may be located remotely from SED 102 and / or key management server 106. Range key slot 414 may store range keys for each user range and may initially be assigned undefined range keys such as 0xFF. In this regard, timestamps, described in further detail below, may be used to determine the validity of the range keys stored in range key slot 414. Public key slot 416 may store the SED_PubKey verified by key management server 106.Digital signature slot 418 may include a digital signature of key management server 106, which is signed based on information in slots 412-416 using a key management server signature key associated with key management server 106.

[0061] At 406, the key management server 106 sends an indication that the data structure 410 on the range key database 108 has been successfully allocated.

[0062] At 408, SED 102 uses a key to close the communication session with management server 106. SED 102 can close the communication session after data structure 410 has been successfully allocated or if the DigitalSignature has not been verified. The communication session can also be closed for other reasons.

[0063] Figure 5 The illustration shows example details of providing the MEK from SED 102 to the key management server 106 for storage in the range key database 108. This process may include at least... Figure 3 The communication between the key management server 106 and the SED 102 related to step 306 is implemented by one or more of hardware, software, or a combination of hardware and software.

[0064] At 502, a request is sent from SED 102 to Key Management Server 106 to open a secure communication session on the communication network 110 between SED 102 and Key Management Server 106. This request may include SED 102's C_PIN_PSID to identify SED 102. The communication session is then opened.

[0065] At 504, a shared key generation request is sent from SED 102 to key management server 106 with a random salt. The random salt can be a random number generated for a communication session and can be changed for another communication session. By using elliptic curve Diffie-Hellman (ECDH) or some other shared key generation algorithm, key management server 106 can generate a shared key based on key management server private key and SED_PubKey for secure communication over the communication session. Key management server public key, key management server private key, and C_PIN_PSID used for SED 102 may already be available to key management server 106 in range key database 108, and data structure 410 in range key database 108 can store SED_PubKey used for SED 102. Key management server 106 can use the received C_PIN_PSID to access data structure 410 and obtain the SED_PubKey used to generate the shared key. By using a Key Derivation Function (KDF) with a received random salt, the generated shared key can be further transformed into a session shared key for communication sessions. As an example, the KDF can be a Key Hash (HMAC) operation for message authentication, using a random salt as the HMAC key to process the shared key.

[0066] At 506, the key management server 106 can send an acknowledgment back to SED 102. This acknowledgment may include the key management server public key, the key management server CA verification key, and a digital signature of the key management server public key signed by the key management server CA signing key. eHSM 124 can verify that the key management server 106 sent the management server public key by verifying the digital signature using the received key management server CA verification key and calculating its hash digest, comparing it with a pre-supplied digest value stored in the SED non-volatile storage medium 112 or OTP 120. Using the elliptic curve Diffie-Hellman (ECDH) algorithm 514 or some other key generation algorithm of eHSM 124 on a random salt sent by SED 102, eHSM 124 can generate a shared session key identical to the shared session key generated by the key management server 106 for the communication session. The shared session key may be based on the key management server public key, SED_PrivKey, and the random salt. The shared session key can be the same as the shared session key generated by the key management server 106 to support secure communication over the communication session.

[0067] The eHSM 124 can generate a MEK to encrypt or decrypt a range. This MEK associated with the range can also be referred to as the range key. The MEK can be generated by a random number generator such as the deterministic random bit generator (DRBG) 512 of the eHSM 124 and seeded by hardware real entropy bit generation (EBG). The MEK can be wrapped, for example, encrypted, using the user's password associated with the range key and a key generated by PDKDF to produce a wrapped MEK, i.e., the wrapped range key. In some cases, it can be further wrapped, for example, encrypted, by the UDS. The eHSM 124 can have a wrap / unwrap function 518 to support wrapping. In the example, the Key Hash (HMAC) 516 for message authentication of the eHSM 124 can calculate a hash against the wrapped MEK to check the integrity of the wrapped MEK, for example, the absence of error bits. A shared session key associated with the communication session can be used to encrypt the wrapped MEK along with the hash.

[0068] At 508, the MEK of the package, along with its hash and the identifier of the range associated with the MEK, can be sent from SED 102 to Key Management Server 106. Key Management Server 106 can decrypt the MEK of the package based on a shared session key generated by Key Management Server 106. Furthermore, Key Management Server 106 can use the HMAC associated with Key Management Server 106 to verify that the MEK of the package matches the received hash. If the received hash is verified, the MEK of the package is stored in the range key database 108. The timestamp in timestamp slot 412 can be updated to indicate when the MEK of the package was stored. The updated timestamp can be provided by SED 102 during the communication session or obtained by Key Management Server 106 from a trusted third party such as a TSA server. The contents of slots 412-418 of data structure 410 are then re-signed using the Key Management Server signing key and a new signature stored in digital signature slot 418.

[0069] At 510, SED 102 uses the key manager to close the communication session with server 106. The communication session may be closed for various reasons. The communication session may be closed after the package's MEK has been stored in the range key database 108. Furthermore, if one or more of the hashes or digital signatures received from the key management server 106 are not verified, the package's MEK is not stored in the range key database 108 because it may be erroneous and the communication session is closed. If storage is unsuccessful, the communication session may also be closed for other reasons, and steps 502-510 may need to be performed again to store the MEK in the range key database 108. One or more additional steps in steps 502-510 may be performed to store multiple MEKs associated with different ranges in data structure 410 in non-volatile storage medium 112.

[0070] The example above describes how SED 102's eHSM 124 generates a MEK, which is then provided to the key management server 106. In other examples, the MEK may not be generated by SED 102's eHSM 124. Instead, the key management server 106, or another system located away from SED 102, may have one or more of EBG and DRBG to generate the MEK, which is then stored on the key management server 106. In this respect, one or more of steps 306 or 508 may be omitted, which also reduces the complexity of SED 102. Other variations are also possible regarding the manner in which the MEK is generated and then stored in data structure 410.

[0071] Figure 6 The illustration illustrates example details related to the following: providing the MEK from the range key database 108 to the SED 102 to facilitate encryption and decryption operations on the SED 102. The MEK can be loaded onto the SED 102 only in its volatile memory 130 after the SED 102 is powered on, and not stored on the non-volatile storage medium 112, to preserve the security of the encrypted data on the non-volatile storage medium of the SED 102. Loading may include communication between the key management server 106 and the eHSM 124 of the SED 102, which is at least related to... Figure 3 The process relates to step 308, and loading can be implemented by one or more of hardware, software, or a combination of hardware and software.

[0072] At 602, a request is sent from SED 102 to Key Management Server 106 to open a secure communication session on the communication network 110 between SED 102 and Key Management Server 106. This request may include SED 102's C_PIN_PSID to identify SED 102. The communication session is then opened.

[0073] At 604, SED 102 sends a request to receive the MEK stored in the range key database associated with the C_PIN_PSID. This request may include an indication to receive the MEK (i.e., the range key), a random salt, and a pointer to where the MEK should be delivered (i.e., pRangeKeyStore). Key management server 106 can use the random salt to generate a shared session key for the communication session. The shared session key may also be based on the key management server's private key and the SED_PubKey. Key management server 106 can use the received C_PIN_PSID to access data structure 410 and obtain the SED_PubKey used to generate the shared session key. The shared session key allows secure communication over the communication session. The timestamp in timestamp slot 412 can be updated to indicate when the MEK was sent. The updated timestamp may be provided by SED 102 during the communication session or obtained by key management server 106 from a trusted third party such as a TSA server. Then, the contents of data structure 410 are re-signed using the key management server's signing key and the new signature stored in digital signature slot 418. Then, key management server 106 transmits data structure 410 to SED 102 by encrypting it with a shared session key and delivering the data structure 410 with MEK to SED 102 based on pRangeKeyStore.

[0074] At point 606, the key management server 106 can send an acknowledgment to the SED 102 confirming the delivery of the MEK. This acknowledgment may include: the key management server's public key, the key management server's CA verification key, and a digital signature on the key management server's public key, signed by the key management server's CA signing key. The eHSM 124 can verify the key management server's public key by using the received key management server's CA verification key and the digital signature verified by the key management server's digital certificate maintained by the CA, to confirm that the key management server's public key originates from the key management server 106. Further, the eHSM 124 can use the ECDH algorithm 514, the key management server's public key, SED_PrivKey, and a random salt to generate a shared session key for the communication session. The eHSM 124 can use the shared session key to decrypt the data structure 410. Then, the eHSM 124 can use the key management server's public key to verify the digital signature in the data structure 410. The MEK received from the key management server 106 and stored in the data structure 410 can be protected by one or more encryption keys. If the digital signature is verified, the packaged MEK is unpacked using the UDS and the package / unpacking function 518 of the eHSM 124, for example, decrypted, and loaded into volatile memory 130. Further, when a user associated with the range key provides a password such as USER_PIN, or an administrator provides a password such as ADMIN_PIN, the eHSM 124 can use PBKDF to derive the unpacking key from the password, unpack the packaged MEK, for example, decrypt it, and load the MEK into the encryption / decryption engine 122 via dedicated communication path 128. The encryption / decryption engine 122 can now be configured to decrypt data for storage on non-volatile storage medium 112, and decrypt data stored on non-volatile storage medium 112 for use by the user.

[0075] In the example, eHSM 124 can also check the timestamp in data structure 410 before storing the MEK in volatile memory 130. eHSM 124 can determine the current timestamp from a trusted TSA server or a timer counter register associated with storage controller 132, indicating the timestamp currently being issued by the TSA server or the timestamp currently being issued by the timer counter register. If the timestamp in data structure 410 is within a specific duration of the current timestamp, such as 24 hours, the wrapped MEK is stored in non-volatile memory 130. If the timestamp in data structure 410 is not within a specific duration of the current timestamp, such as 24 hours, the wrapped MEK is not stored in volatile memory 130 because the MEK has expired. This specific duration can be related to the physical distance between key management server 106 and SED 102, and in some instances, can be negotiated during SED registration 304. Because data structure 410 is sent to volatile memory 130 via communication network 110 between key management server 106 and eHSM 124 during MEK loading at step 308, an unauthorized third party on communication network 110 could potentially make a copy of data structure 410 and later attempt to load it into non-volatile memory 130 to decrypt data stored in SED 102. Once the timestamp is outside a specific duration, the eHSM 124's check of the timestamp prevents MEK loading, thus protecting the encrypted data on non-volatile storage medium 112 from unauthorized third parties.

[0076] At 608, SED 102 closes the communication session with the key management server 106. This communication session may be closed for various reasons. The communication session is closed at 608 when the range key is stored in volatile memory 130. Also, the communication session is closed at 608 if the timestamp associated with the MEK and the current timestamp are outside a specific duration, or if the digital signature from the key management server 106 is not verified. The communication session may also be closed for other reasons, and steps 602-608 may need to be repeated to store the MEK in volatile memory 130.

[0077] Because MEK is stored only on SED 102 in volatile memory 130 and not on non-volatile media, each time SED 102 is powered off, all instances of MEK on SED 102 are removed, resulting in cryptographic erasure of SED 102 and protecting the encrypted data on non-volatile storage medium 112. Deactivating SED 102 is also simplified. Deactivating SED 102 according to the National Institute of Standards and Technology (NIST) 800-88 guideline involves deleting or altering all MEK instances on SED 102 when SED 102 is deactivated to protect the security of the encrypted data on SED 102. In the example, SED 102 can be deactivated by removing power to SED 102, which deletes the MEK in SED 102 and also deletes the MEK stored in data structure 410 in range key database 108.

[0078] Figure 7 The illustration shows an example process for memorizing the deactivation of SED 102. This memorization may include communication between the key management server 106 and the host computer 104 (associated with SED 102), and may be implemented by one or more of the following: hardware, software, or a combination of hardware and software.

[0079] At point 702, a request is sent from host computer 104 to key management server 106 to open a communication session between host computer 104 and key management server 106. This request may include an identifier of SED 102 to disable features such as C_PIN_PSID. The communication session is then opened.

[0080] At 704, a transaction request 750 is sent from host computer 104 to key management server 106. The transaction request 750 may include multiple fields 752-762, including one or more of the following: a timestamp field 752, having a timestamp of the request; an SED field 754, having the C_PIN_PSID of SED 102 to identify the SED 102 to be deactivated; and an encrypted erasure range key field 756, indicating the SED 102 to be deactivated. The multiple fields 752-762 may also include: an administrator ID field 758, having an administrator ID to identify the administrator making the deactivation request; a public key field 760, having a public key associated with the administrator, and a digital signature of the administrator's signing key in digital signature key 762, which signs the contents of fields 752-760. The transaction request 750 may also include a digital certificate field 764, having a digital certificate of the administrator that identifies the public key associated with the administrator, and that the administrator has the authority to deactivate SED 102.

[0081] At point 706, the key management server 106 sends an indication that transaction request 708 has been verified. This verification is based on the digital signature in the digital signature field 762, the administrator public key in the public key field 760, and the administrator public key in the administrator public certificate managed by the CA.

[0082] The verified transaction request 750 is then stored in block 766 of the storage device for subsequent access via C_PIN_PSID. Block 766 can be 4 kilobytes (KB), allowing 128 transaction requests to be populated within it. Once block 766 is populated (indicated by shaded areas), it can be signed with the key management server's signing key and / or hashed, and then chained into blockchain 768. Blockchain 768 is decentralized, distributed, and used to record transactions across many computers, ensuring that any involved records cannot be retroactively altered. Blockchain 768 can store block 766 in a deactivated blockchain accessible only to the identified party. Furthermore, key management server 106 can remove data structure 410 stored in range key database 108, preventing MEK from being loaded into SED 102 to decrypt encrypted data stored on non-volatile storage medium 112.

[0083] At 708, host computer 104 closes its communication session with key management server 106. This communication session can be closed for various reasons. The communication session is closed at 708 when a transaction request is stored in blockchain 768. Furthermore, if a transaction request is not stored in blockchain 768 (23), the communication session is closed at 708 because the transaction request 708 cannot be verified. The communication session can also be closed for other reasons, and steps 702-708 may need to be repeated to store the transaction request in blockchain 768.

[0084] In the example, Figures 4-6 The key management server 106 can use blockchain 768 to verify that any request including the C_PIN_PSID is not associated with a deactivated SED 102. For example, if the key management server 106 receives a request to open a communication session with the C_PIN_PSID, it can check blockchain 768 to see if the SED 102 is associated with a deactivated C_PIN_PSID. If the SED 102 is deactivated, the key management server 106 terminates the communication session, ensuring that no MEK is loaded onto the volatile memory 130 of the SED 102 because the SED 102 is deactivated. In this way, the encrypted data in the deactivated SED 102 is secure.

[0085] Furthermore, SED 102 can use blockchain 768 to determine whether to load MEK into volatile memory 130.

[0086] Figure 8 This is an example flowchart of function 800 associated with the storage controller 132 of SED 102, which stores one or more MEKs in the volatile memory 130 of SED 102 based on blockchain 768. Function 800 can be executed by SED 102 via host controller 104, and in this example, the storage controller 132 of SED 102 is executed by software, hardware, or a combination of software and hardware.

[0087] At 802, one or more MEKs and the timestamps associated with them are received. The MEKs within the MEKs can be associated with the encryption and decryption of data within a range on the non-volatile storage medium 112 of SED 102. Data structure 410 may include timestamps indicating the correctness of one or more MEKs. Each MEK within the MEKs can still be wrapped using a wrapping key based on the password of the user associated with it.

[0088] At position 804, the current timestamp is determined. The current timestamp can be provided from the same source as the timestamp in data structure 410. For example, if SED 102 provides a timestamp in data structure 410, eHSM 124 can obtain the current timestamp from the timer counter register associated with storage controller 132. Alternatively, if a TSA server provides a timestamp, eHSM 124 can obtain the current timestamp from the TSA server.

[0089] At point 806, the following determination is made: whether the difference between the current timestamp and the timestamp associated with one or more MEKs is less than or greater than a specific duration. This specific duration can be a period after which one or more MEKs are valid and no longer valid. By defining this specific duration, a third party obtaining an unauthorized copy of a MEK cannot load the MEK into the volatile memory 130 of SED102 after this specific duration, because the MEK expiration ensures the security of the encrypted data stored in the non-volatile storage medium 112.

[0090] At point 808, if the difference exceeds a certain duration, one or more MEKs are not loaded into the volatile memory 130 of SED 102. These one or more MEKs are not loaded because they are not valid and could potentially be provided by a third party who has obtained an unauthorized copy of the MEK.

[0091] At 810, the following determination is made: whether SED 102 has been deactivated if the difference is less than or equal to a specific duration. One or more MEKs may be valid, but if SED 102 is deactivated, the MEKs may still not be loaded into volatile memory 130. SED 102 may send a request to key management server 106 with an identifier of SED 102 (such as SED 102's C_PIN_PSID) to determine whether SED 102 has been deactivated. Key management server 106 may access blockchain 768 with that identifier to see if transaction requests associated with SED 102 are stored in blockchain 768. If transaction requests associated with the identifier exist, SED 102 is deactivated. Otherwise, SED 102 is not deactivated. Key management server 106 can provide an indication of whether SED 102 has been deactivated for eHSM 124.

[0092] At 812, if SED 102 is not disabled, MEK is loaded into volatile memory 130. Furthermore, when the user enters their password, eHSM 124 can unwrap MEK to support encryption and decryption of data within the range associated with the user.

[0093] At point 808, if SED 102 has been deactivated, MEK is not loaded into volatile memory 130. A third party may have obtained an unauthorized copy of MEK and may be attempting to load MEK into the deactivated SED 102. The fact that MEK is not loaded ensures the security of encrypted data stored in non-volatile storage medium 112.

[0094] Example SED

[0095] Figure 9 This is an example system diagram 900 for SED 102. Example system diagram 900 includes a storage controller 130, which has volatile memory 130 for storing MEK and OTP 120 for storing encryption keys. Additionally, storage controller 132 may include an encryption / decryption engine 122, flash memory 134, and eHSM 124. SED 102 may have a non-volatile storage medium 112 for storing encrypted data received from encryption / decryption engine 122, and providing encrypted data stored on non-volatile storage medium 112 for decryption by encryption / decryption engine 122. Non-volatile storage medium 112 or flash memory 134 may not store MEK.

[0096] SED 102 also includes bus 902 (e.g., Peripheral Component Interconnect (PCI), Industry Standard Architecture (ISA), PCI-Express, NuBus, etc.). Coupled to bus 802 may be storage controller 132 and non-volatile storage medium 112.

[0097] SED 102 may partially (or entirely) implement any of the foregoing functions in hardware and / or software (e.g., computer code, program instructions, program code, computer instructions) stored on a non-transient machine-readable medium / media (such as non-volatile storage medium 112 for MEK storage on SED 102 in volatile memory 130 for SED 102 alone).

[0098] Some implementations have been described in detail above, and various modifications are possible. The disclosed subject matter can be implemented in electronic circuit systems, computer hardware, firmware, software, or combinations thereof, including the functional operations described herein, such as the structural components and their structural equivalents disclosed herein, including programs that may be operable to cause one or more data processing devices (e.g., processors) to perform the described operations (e.g., programs encoded in non-transient computer-readable media, which may be storage devices, machine-readable storage substrates, or other physical, machine-readable media, or combinations thereof).

[0099] A program (also known as a computer program, software, software application, script, or code) can be written in any form of grammatical language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. A program does not necessarily correspond to a file in a file system. A program can be stored as a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., a file storing one or more modules, subroutines, or portions of code). A program can be deployed to execute on a single computer, or on multiple computers located at a single site or distributed across multiple sites and interconnected via a communication network.

[0100] Although this specification contains numerous details, these details should not be construed as limiting the scope of the claims, but rather as a description of the specific features that a particular implementation may have. Certain functions described in individual implementations of this specification may also be implemented in combination within a single implementation. Conversely, various features described in the context of a single implementation may be implemented separately in multiple implementations or in any suitable sub-combination. Moreover, although features may be described above as acting in a particular combination, or even initially claimed in this way, in some cases one or more features may be removed from the claimed combination, and the claimed combination may be for sub-combinations or variations thereof.

[0101] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring such operations to be performed in the specific order shown or in a sequential order, or to perform all the operations shown to achieve the desired result. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of the various system components in the above embodiments should not be interpreted as requiring such separation in all implementations.

[0102] Unless otherwise expressly stated, the use of the phrase "at least one" preceding a list with the conjunction "and" should not be considered an exclusive list, nor should it be interpreted as a list of categories having one item in each category. A clause citing "at least one of A, B, and C" may only violate one item listed, multiple items listed, one or more items in the list, and another item not listed.

[0103] Other implementations fall within the scope of the appended claims.

Claims

1. A method for cryptographically erasing a self-encrypting drive (SED) by deleting all instances of a media encryption key MEK stored by the SED, wherein the SED comprises (i) a volatile memory and (ii) a non-volatile storage medium, the method comprising: Receive the MEK from the key management server and receive a timestamp associated with the MEK from the key management server, the timestamp indicating whether the MEK has expired; Determine whether the difference between the timestamp associated with the MEK and another timestamp is less than the duration, wherein the other timestamp is received from a timestamp authorization server that is remote to the SED or from the timer counter register of the SED; If the difference is less than the duration, the MEK received from the key management server will be stored only in the volatile memory of the SED; Based on the MEK stored only in the volatile memory of the SED, the data is encrypted for storage in the non-volatile storage medium of the SED; as well as The MEK stored only in the volatile memory of the SED is erased to perform an encrypted erase of the SED.

2. The method of claim 1, wherein when the SED is not powered by a host computer coupled to the SED, only the MEK stored in the volatile memory of the SED is erased.

3. The method according to claim 1, wherein the MEK is generated by the key management server.

4. The method of claim 3, wherein the stored MEK is wrapped with a key associated with a user's password, which is associated with the SED.

5. The method of claim 1, further comprising: Accessing a blockchain that stores indications about whether the SED is deactivated, and wherein storing the MEK on the SED, and storing it only in the volatile memory of the SED, includes: if the indication indicates that the SED is not deactivated, then storing the MEK only in the volatile memory of the SED.

6. A non-transitory computer-readable medium storing instructions for cryptographically erasing the SED by deleting all instances of a media encryption key MEK stored by a self-encryption driver SED, the instructions causing the one or more processors, when executed, to perform at least the following operations: Receive the MEK from the key management server, wherein the MEK is associated with a timestamp indicating whether the MEK has expired; Receive another timestamp from either a remote timestamp authorization server or a timer counter register of the SED; Determine whether the difference between the timestamp associated with the MEK and the other timestamp is less than the duration; If the difference is less than the duration, the MEK received from the key management server will be stored only in the volatile memory of the SED; Based on the MEK stored only in the volatile memory of the SED, the data is encrypted for storage in the non-volatile storage medium of the SED; as well as The MEK stored only in the volatile memory of the self-encryption driver SED is erased to perform encrypted erasure of the self-encryption driver SED.

7. The non-transitory computer-readable medium of claim 6, wherein when the SED is not powered by a host coupled to the SED, only the MEK stored in the volatile memory of the SED is erased.

8. The non-transitory computer-readable medium of claim 6, wherein the MEK is associated with a range addressed by the logical block address (LBA) of the non-volatile storage medium of the SED.

9. The non-transitory computer readable medium of claim 6, further comprising: Instructions for accessing a blockchain that stores indications about whether the SED is deactivated, and wherein the instructions for storing the MEK on the SED, stored only in the volatile memory of the SED, include: instructions for storing the MEK only in the volatile memory of the SED if the indication indicates that the SED is not deactivated.

10. A self-encrypting drive SED, configured to delete all instances of a media encryption key MEK stored by the SED to perform encrypted erasure of the SED, the SED comprising: Volatile memory; Non-volatile storage media; Instructions stored in the memory of the SED, when executed by one or more processors of the SED, cause the SED to perform at least the following operations: Receive the medium encryption key MEK from the key management server, wherein the MEK is associated with a timestamp indicating whether the MEK has expired; Receive another timestamp from either a remote timestamp authorization server or a timer counter register of the SED; Determine whether the difference between the timestamp associated with the MEK and the other timestamp is less than the duration; If the difference is less than the duration, the MEK received from the key management server will be stored only in the volatile memory of the SED; Based on the MEK stored only in the volatile memory of the SED, the data is encrypted for storage in the non-volatile storage medium of the SED; as well as The MEK stored only in the volatile memory of the SED is erased to perform an encrypted erase of the SED.

11. The SED of claim 10, further comprising: Instructions for accessing a blockchain that stores indications about whether the SED is deactivated, and wherein the instructions for storing the MEK on the SED, stored only in the volatile memory of the SED, include: instructions for storing the MEK only in the volatile memory of the SED if the indication indicates that the SED is not deactivated.

Images