Disc device and storage device

Abstract

The present disclosure provides a disk device and a storage device capable of appropriately confirming whether a key at the time of encryption of data is identical to a key acquired from a host in a case where an encryption key is generated on the host side. The disk device includes a volatile memory, a nonvolatile memory, and a controller. The controller generates generation information of an encryption / decryption key, records first information obtained by associating the generation information of the encryption / decryption key, tag information of the encryption / decryption key, and the encryption / decryption key to the volatile memory, and records second information obtained by associating an encryption / decryption key identifier and the generation information of the encryption / decryption key to the nonvolatile memory, in a case where the encryption / decryption key, the encryption / decryption key identifier, and the tag information of the encryption / decryption key are received from the host and a setting request of the encryption / decryption key is accepted from the host.

Description

[0001] This application enjoys priority based on Japanese Patent Application No. 2021-153621 (filed on September 21, 2021). This application incorporates the entire contents of the basic application by reference to that basic application. Technical Field

[0002] Embodiments of the present invention relate to disk devices and storage devices. Background Technology

[0003] The storage device has a technology that verifies whether the key used for encryption matches the current key by comparing it with historical encryption key information. Furthermore, it is desirable to be able to properly verify whether the key used to encrypt data matches the key obtained from the host, even when the encryption key is generated on the host side instead of in the storage device. Summary of the Invention

[0004] One embodiment aims to provide a disk device and storage device capable of appropriately verifying whether the key used to encrypt data is consistent with the key obtained from the host when the encryption key is generated on the host side.

[0005] According to one embodiment, the disk device includes volatile memory, non-volatile memory, and a controller. Upon receiving an encryption / decryption key, an encryption / decryption key identifier, and encryption / decryption key tag information from a host, and upon receiving a setting request for the encryption / decryption key from the host, the controller generates encryption / decryption key generation information, records first information (associated with the encryption / decryption key generation information, encryption / decryption key tag information, and encryption / decryption key) in the volatile memory, and records second information (associated with the encryption / decryption key identifier and encryption / decryption key generation information) in the non-volatile memory. Attached Figure Description

[0006] Figure 1 This is a schematic diagram illustrating an example of the configuration of the disk device according to the first embodiment.

[0007] Figure 2 This is an example of the KeyID table involved in the first embodiment.

[0008] Figure 3 This is an example of the Key table involved in the first embodiment.

[0009] Figure 4 This is a flowchart illustrating the command execution order according to the first embodiment.

[0010] Figure 5A This is a data example of the KeyID table involved in the first embodiment.

[0011] Figure 5B This is a data example of the KeyID table involved in the first embodiment.

[0012] Figure 6A This is a data example of the Key table involved in the first embodiment.

[0013] Figure 6B This is a data example of the Key table involved in the first embodiment.

[0014] Figure 6C This is a data example of the Key table involved in the first embodiment.

[0015] Figure 7A This is a data example of the Key table involved in the first embodiment.

[0016] Figure 7B This is a data example of user data involved in the first embodiment.

[0017] Figure 7C This is a data example of user data involved in the first embodiment.

[0018] Figure 8 This is a flowchart illustrating the process of receiving an encryption key setting command according to the first embodiment.

[0019] Figure 9 This is a flowchart illustrating the process of receiving a write command according to the first embodiment.

[0020] Figure 10 This is a flowchart illustrating the process of receiving a read command according to the first embodiment.

[0021] Figure 11A This is a data example of the KeyID table involved in the second embodiment.

[0022] Figure 11B This is a data example of the KeyID table involved in the second embodiment.

[0023] Figure 11C This is a data example of the KeyID table involved in the second embodiment.

[0024] Figure 11D This is a data example of the Key table involved in the second implementation.

[0025] Figure 12 This is a flowchart illustrating the process of receiving a read command according to the second embodiment.

[0026] Label Explanation

[0027] 1 Disk drive, 2 Host, 11 Disk, 12 Spindle motor, 13 Ramp, 15 Actuator arm, 21 Motor driver IC, 22 Magnetic head, 22r Read element, 22w Write element, 23 HDC, 24 Head IC, 25 RWC, 26 Processor, 27 RAM, 28 FROM, 29 Buffer memory, 30 Controller. Detailed Implementation

[0028] Hereinafter, the disk device according to the embodiments will be described in detail with reference to the accompanying drawings. However, the invention is not limited to these embodiments.

[0029] (First Embodiment)

[0030] Figure 1 This is a schematic diagram illustrating an example of the configuration of the disk device 1 according to the first embodiment.

[0031] Disk device 1 is connected to host 2. Disk device 1 can receive access commands such as set, write, and read commands for encryption keys from host 2.

[0032] The disk drive 1 includes a disk 11 with a recording surface formed on its surface. The disk drive 1 writes data to and reads data from the disk 11 (more precisely, the recording surface of the disk 11) according to access commands. In addition, the disk drive 1 may have multiple disks 11, but in this embodiment, for the sake of clarification and illustration, the disk drive 1 is shown to have only one disk 11.

[0033] Data writing and reading are performed via the read / write head 22. More specifically, in addition to the disk 11, the disk device 1 also includes a spindle motor 12, a motor driver IC (Integrated Circuit) 21, a read / write head 22, an actuator arm 15, a voice coil motor (VCM) 16, a ramp 13, a head IC 24, a read / write channel (RWC) 25, RAM 27, FROM (Flash Read-Only Memory) 28, a buffer memory 29, a hard disk controller (HDC) 23, and a processor 26.

[0034] The disk 11 is rotated at a predetermined speed by a spindle motor 12 mounted on the rotation axis of the disk 11. The spindle motor 12 is driven by a motor driver IC 21. The disk 11 is an example of a non-volatile memory.

[0035] The motor driver IC21 controls the rotation of the spindle motor 12 and the VCM16.

[0036] The read / write head 22 writes and reads data from the disk 11 using its write element 22w and read element 22r. The read / write head 22 is mounted on the front end of the actuator arm 15. The read / write head 22 moves radially along the disk 11 via the VCM 16, which is driven by the motor driver IC 21.

[0037] When the disk 11 stops rotating, the read / write head 22 moves onto the ramp 13. The ramp 13 is configured to hold the read / write head 22 in a position away from the disk 11.

[0038] During reading, head IC24 amplifies and outputs the signal read by head 22 from disk 11 to RWC25. Additionally, head IC24 amplifies the signal corresponding to the data to be written from RWC25 and provides it to head 22.

[0039] HDC23 controls data transmission and reception between the HDC23 and the host 2 via the I / F bus, controls the buffer memory 29, and performs error correction processing on the read data.

[0040] The buffer memory 29 is used as a cache for data transmitted and received between the host 2 and the host 2. For example, the buffer memory 29 is used to temporarily store data to be written to or read from the disk 11.

[0041] The buffer memory 29 is, for example, composed of a volatile memory capable of high-speed operation. The type of memory constituting the buffer memory 29 is not limited to a specific type. The buffer memory 29 may be composed of, for example, DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), or a combination thereof.

[0042] RWC25 modulates the data to be written from HDC23 and provides it to head IC24. Additionally, RWC25 demodulates the signals read from disk 11 and provided by head IC24, outputting them as digital data to HDC23.

[0043] The processor 26 is, for example, a CPU (Central Processing Unit). RAM 27, FROM (Flash Read Only Memory) 28, and buffer memory 29 are connected to the processor 26.

[0044] FROM28 is a non-volatile memory. Firmware (program data) and various operational parameters are stored in FROM28. Additionally, the firmware can also be stored on disk 11.

[0045] RAM 27 is composed of, for example, DRAM, SRAM, or a combination thereof. RAM 27 is used by the processor 26 as its working memory. RAM 27 is used as an area for loading firmware and as an area for storing various management data.

[0046] The processor 26 performs overall control of the disk device 1 according to the firmware stored in the FROM 28 or the disk 11. For example, the processor 26 loads the firmware from the FROM 28 or the disk 11 into the RAM 27, and executes the control of the motor driver IC 21, head IC 24, RWC 25, HDC 23, etc. according to the loaded firmware.

[0047] Furthermore, the configuration including RWC25, processor 26, and HDC23 can also be considered as controller 30. Controller 30 may also include other elements besides these (such as RAM27, FROM28, buffer memory 29, or RWC25, etc.).

[0048] When disk device 1 receives a write command from host 2, it encrypts the user data to be written and records it on disk 11. One method involves the host 2 generating the encryption key, not disk device 1; receiving this encryption key from host 2; and using it to encrypt the user data, without recording the encryption key on disk 11. Since the encryption key is not stored on disk 11, it is desirable to be able to properly determine whether the encryption key received from host 2 is the same one used to encrypt the user data. Therefore, disk device 1 manages the generation information of the encryption key received from host 2 using table information to properly determine whether the encryption key received from host 2 is an appropriate encryption key.

[0049] Upon receiving from the host 2 a Key (as encryption / decryption key), a KeyID (as encryption / decryption key identifier), and a KeyTag (as encryption / decryption key tag information), and upon receiving a setting command for the encryption key from the host 2, the controller 30 of the disk device 1 generates Key table information and KeyID table information. Furthermore, the encryption / decryption key tag information refers to information indicating the scope of application of the encryption / decryption key.

[0050] Figure 2This is a diagram representing the data structure of KeyID table 60. The information in KeyID table 60 is stored on disk 11. KeyID table 60 is a table storing record information 61 including KeyID and KeyGen. KeyIDs received from host 2 are entered into the KeyID field of record information 61. Encryption / decryption key generation information is entered into the KeyGen field of record information 61. Encryption / decryption key generation information refers, for example, information indicating the input order of KeyIDs entered into KeyID table 60, and numbering information used to identify KeyIDs. Furthermore, the information in KeyID table 60 can also be stored in a non-volatile storage area outside of disk 11.

[0051] When the controller 30 receives a setting command for the encryption key from the host 2, it searches the KeyID table. If no record 61 with the KeyID received from the host 2 exists, the controller 30 generates a new KeyGen and registers the record 61 with the KeyID received from the host 2 and the new KeyGen in the KeyID table 60.

[0052] Figure 3 This is a diagram representing the data structure of Key table 70. Information in Key table 70 is stored, for example, in buffer memory 29 and RAM 27. Key table 70 is a table storing record information 71 including KeyTag, Key, and KeyGen. KeyTag received from host 2 is input into the KeyTag field of record information 71. Key received from host 2 is input into the Key field of record information 71. Newly generated KeyGen by controller 30 is input into the KeyGen field of record information 71.

[0053] When the controller 30 receives a setting command for the encryption key from the host 2, it registers record information 71 containing the KeyTag received from the host 2, the Key received from the host 2, and the new KeyGen in the Key table 70. Alternatively, if the Key table 70 already contains record information 71 containing the same Key and KeyTag as the Key received from the host 2, the controller 30 may not generate new record information 71 based on the information received from the host 2.

[0054] In addition, when the controller 30 receives the KeyTag and the user data of the write object from the host 2, and receives the write command from the host 2, it retrieves the record information 71 corresponding to the KeyTag received from the host 2, uses the Key of the retrieved record information to encrypt the user data received from the host 2, and records the information obtained by associating the KeyGen of the retrieved record information 71 and the encrypted user data to the disk 11.

[0055] Furthermore, when the controller 30 receives a KeyTag for the data to be read from the host 2 and a read command for user data from the host 2, it retrieves the record information 71 corresponding to the KeyTag received from the host 2. The controller 30 uses the Key of the retrieved record information 71 to decrypt the user data to be read, and determines whether the KeyGen corresponding to the user data matches the KeyGen of the retrieved record information 71. If they match, the controller 30 sends the decrypted user data to the host 2. Otherwise, if they do not match, the controller 30 sends an error notification to the host 2.

[0056] Next, use Figure 4 , Figures 5A-5B as well as Figures 6A to 6C The update status of the information stored in KeyID table 60 and Key table 70 is explained when the controller 30 receives setting commands, writing commands and reading commands for the encryption key.

[0057] Figure 4 This is a flowchart illustrating the command processing steps received from host 2. Figures 5A-5B This is a diagram representing the information stored in KeyID table 60. Figures 6A to 6C This is a diagram representing the information stored in Key table 70. Furthermore, it is assumed that no record information 61 of KeyID table 60 and no record information 71 of Key table 70 are stored.

[0058] First of all, Figure 4 In process 1, the controller 30 receives information from the host 2 indicating that the KeyTag is 3, the KeyID is KeyID0, and the Key is Key0, and accepts the encryption key setting command (process 1).

[0059] Controller 30 refers to KeyID table 60 and retrieves record information 61 with Key0. Initially, there is no record information 61; therefore, controller 30 generates 1 as the value of KenGen. Furthermore, controller 30 will... Figure 5A Record information 61a, as shown, with KeyID as KeyID0 and KenGen as 1, is registered in KeyID table 60. Additionally, controller 30 will... Figure 6A Record information 71a, as shown, with KeyTag as 3, Key as Key0, and KenGen as 1, is stored in Key table 70.

[0060] return Figure 4 The controller 30 receives information with KeyTag 3 from the host 2 and accepts the write command (processing 2). The controller 30 refers to the Key table 70 and retrieves the record information 71a with KeyTag 3. Furthermore, the controller 30 uses Key0 of the record information 71a to encrypt the user data and records the encrypted user data and the data with KenGen 1 to the disk 11.

[0061] return Figure 4 The controller 30 receives information with KeyTag 3 from the host 2 and accepts the read command (processing 3). The controller 30 refers to the Key table 70 and searches for record information 71a with KeyTag 3. Furthermore, the controller 30 uses Key0 of record information 71a to decrypt the user data. If the KenGen value in the data to be decrypted is inconsistent with the KenGen value of record information 71a, it is determined that the encryption keys are different. Therefore, the controller 30 can determine whether the area read has not yet been written to, or whether the data area read was encrypted with a different encryption key.

[0062] return Figure 4 The controller 30 receives information from the host 2 indicating that the KeyTag is 2, the KeyID is KeyID1, and the Key is Key1, and accepts the encryption key setting command (processing 4).

[0063] The controller 30 refers to the KeyID table 60 and retrieves the record information 61 with Key1. For example... Figure 5A As shown, there is no record information 61 with Key1, therefore, controller 30 generates 2 as the value of KenGen. Furthermore, controller 30 will... Figure 5B Record information 61b, as shown, with KeyID as KeyID1 and KenGen as 2, is registered in KeyID table 60. Additionally, controller 30 will... Figure 6B Record information 71b, as shown, with KeyTag as 2, Key as Key1, and KenGen as 2, is stored in Key table 70.

[0064] return Figure 4The controller 30 receives information with KeyTag 2 from the host 2 and accepts the write command (processing 5). The controller 30 refers to the key table 70 and retrieves the record information 71b with KeyTag 2. Furthermore, the controller 30 uses Key1 of the record information 71b to encrypt the user data and records the encrypted user data and the data with KenGen 2 to the disk 11.

[0065] return Figure 4 The controller 30 receives information with KeyTag 2 from the host 2 and accepts the read command (processing 6). The controller 30 refers to the Key table 70 and searches for record information 71b with KeyTag 2. Furthermore, the controller 30 uses Key2 of record information 71b to decrypt the user data. If the KenGen value in the data to be decrypted is inconsistent with the KenGen value of record information 71b, it is determined that the encryption keys are different.

[0066] return Figure 4 The controller 30 receives information from the host 2 indicating that KeyTag is 1, KeyID is KeyID1, and Key is Key1, and accepts the encryption key setting command (processing 7).

[0067] The controller 30 refers to the KeyID table 60 and retrieves the record information 61 with Key1. For example... Figure 5B As shown, record information 61b has a key of Key1; therefore, controller 30 does not register record information 61b in the KeyID table 60. Furthermore, since controller 30 does not have record information 71 with a key tag of 1 and a key of Key1, it will... Figure 6C Record information 71c, as shown, with KeyTag as 1, Key as Key1, and KenGen as 2, is stored in Key table 70.

[0068] Next, use Figures 7A to 7C The control during reading is explained. Figure 7A This represents an example of Key table 70. Key table 70 has record information 71a with KeyTag 1, Key 2, and KeyGen 3. Additionally, Key table 70 has record information 71b with KeyTag 2, Key 1, and KeyGen 2. Furthermore, Key table 70 has record information 71c with KeyTag 3, Key 0, and KeyGen 1.

[0069] Figure 7B This is an example of data written. KeyGen is set to 1 and encrypted using Key0. Figure 7C These are examples of data that have been identified as erroneous. For example... Figure 7CAs shown, KenGen is 1, but when encryption is performed using Key1, the Key corresponding to KenGen1 is Key0. Therefore, the reason lies in the encryption and decryption key.

[0070] Figure 8 This is a flowchart of the process when an encryption key setting command is received. Controller 30 receives KeyTag, KeyID, and Key from host 2, and accepts the encryption key setting command (step S1). Controller 30 searches the KeyID table 60 for record information 61 corresponding to the KeyID received from host 2 (step S2). If no record information 61 with a matching KeyID is found (step S3: No), controller 30 generates a KenGen value and appends a new record information 61 to the KeyID table 60 (step S4), proceeding to step S5. Alternatively, if controller 30 has a record information 61 with a matching KeyID in step S3 (step S3: Yes), proceeding to step S5. In step S5, record information 71 containing the KenGen generated in step S4 is registered in the Key table 70 (step S5).

[0071] Figure 9 This is a flowchart of the process when a write command is received. Controller 30 receives a KeyTag from host 2 and accepts the write command (step S11). Controller 30 searches the Key table 70 for record information 71 corresponding to the KeyTag received from host 2 (step S12). If no record information 71 with a matching KeyTag is found (step S13: No), controller 30 encrypts the record using a KeyTag other than the one received from host 2 (step S14) and proceeds to step S16. Alternatively, if controller 30 finds a record information 71 with a matching KeyTag in step S13 (step S13: Yes), it encrypts the record information 71 using its Key (step S14) and proceeds to step S16. In step S16, the record information 71 containing the encrypted user data and KenGen is registered on disk 11 (step S16).

[0072] In this way, the controller 30 will register KenGen, which is smaller than KeyID, and encrypted user data together, thus avoiding unnecessary use of disk space.

[0073] Figure 10This is a flowchart of the process when a read command is received. Controller 30 receives the KeyTag from host 2 and accepts the read command (step S21). Controller 30 searches the Key table 70 and searches for the record information 71 corresponding to the KeyTag received from host 2 (step S22). If no record information 71 with a matching KeyTag is found (step S23: No), controller 30 uses the Key of a KeyTag other than the one received from host 2 to decrypt the record (step S25), and proceeds to step S26. Alternatively, if controller 30 finds a record information 71 with a matching KeyTag in step S23 (step S23: Yes), it uses the Key of record information 71 to decrypt the record (step S24), and proceeds to step S26. In step S26, controller 30 reads information containing the decrypted user data and KenGen (step S26). If the KenGen corresponding to the user data matches the KenGen of the retrieved record information 71 (step S27: Yes), the controller 30 outputs the read data to the host 2 (step S28). Alternatively, if the KenGen corresponding to the user data does not match the KenGen of the retrieved record information 71 in step S27 (step S27: No), the controller 30 sends an error notification to the host 2 (step S29).

[0074] In this case, the controller 30 can determine whether the key used for encryption is the same as the key used for decryption by judging whether the KenGen corresponding to the user data is consistent with the KenGen of the retrieved record information 71.

[0075] In the above description, upon receiving a setting command for the encryption key from host 2, controller 30 generates a new KeyGen and registers record information 61 containing the KeyID received from host 2 and the new KeyGen in KeyID table 60 on disk 11. Additionally, record information 71 containing the KeyTag received from host 2, the Key received from host 2, and the new KeyGen is registered in Key table 70 of buffer memory 29 and / or RAM 27.

[0076] In this way, by storing KeyGen in disk 11, buffer memory 29, and / or RAM 27, and storing Key in buffer memory 29 and / or RAM 27, disk device 1 can manage key generation information without storing Key in disk 11. Therefore, it is possible to appropriately determine whether the encryption key received from host 2 is an older encryption key.

[0077] Furthermore, if there is no record information 61 corresponding to the KeyID received from the host 2, the controller 30 records the record information 61 based on the information received from the host 2 to the disk 11, and records the record information 71 based on the information received from the host 2 to the buffer memory 29 and / or RAM 27. In this way, the controller 30 only records the record information 61 and the record information 71 when a new KeyID is received, thus avoiding the recording of unnecessary records.

[0078] (Second Implementation)

[0079] In the second embodiment, the disk device 1 outputs control on the result of determining whether the encryption key is appropriate when the encrypted encryption key becomes unrecoverable after the data recorded on the disk 11 is encrypted.

[0080] The main purpose of host 2 sending KeyID along with Key to disk device 1 is to detect the situation where the encryption key used for encryption and the decryption key used for decryption are inconsistent.

[0081] In the disk device 1 according to the first embodiment, if the encryption key used for encryption and the decryption key used for decryption are inconsistent, the disk device 1 notifies the host 2 of the encryption key mismatch.

[0082] On the other hand, when disk device 1 performs the Secure Instance Erase function, it renders the encryption key used to encrypt data on disk 11 in an unrecoverable state. In this case, it is not actually necessary to erase the data on disk 11. After the Secure Instance Erase function is performed, when data written before the Secure Instance Erase function on disk 11 is read, it is expected that the read data will be transmitted to host 2 without detecting inconsistencies between the encryption and decryption keys.

[0083] Here, use Figures 11A to 11D The update status of the information stored in KeyID table 60 or Key table 70 before and after the execution of the security instance erasure function is explained.

[0084] First, the KeyID table 60 before the security instance erasure function is executed is represented in... Figure 11A .like Figure 11AAs shown, the KeyID table 60 stores record information 61 (record information 61a, record information 61b, etc.) with KeyIDs such as KeyID-0 and KeyID1000. Additionally, in this case, the Key table 70 also contains record information 71 of KeyGen that shares the record information 61.

[0085] When controller 30 performs the secure instance erasure function, it invalidates the encryption key, therefore, as Figure 11B As shown, all records 61 in KeyID table 60 are deleted. Additionally, controller 30 deletes all records 71 ​​in Key table 70.

[0086] After the security instance erasure function deletes record information 61 in KeyID table 60, and upon receiving an encryption key setting command from host 2, record information 61 in KeyID table 60 is appended according to the encryption key setting command. An example of appended record information 61 is shown below. Figure 11C .like Figure 11C As shown, KeyID table 60 contains record information 61 with KeyID=KeyID-1001 and record information 61d with KeyID=KeyID-1002. Additionally, Key table 70 in this state is as follows: Figure 11D The record information shown is 71, which has KeyTag of 00, Key of Key-1001, and KeyGen of 1002.

[0087] In this state, it is determined whether the data of the read object was encrypted before the secure instance erasure function was executed, and based on the determination result, it is sent to host 2.

[0088] Next, use Figure 12 The processing involved in receiving a read command according to the second embodiment will be described. Figure 12 This is a flowchart illustrating the processing steps in the case of receiving a read command according to the second embodiment.

[0089] As a premise, such as Figures 11A to 11D The data in KeyID table 60 and Key table 70 is shown to be updated. That is, before executing the secure instance erase function, controller 30 appends record information 61 to KeyID table 60 and record information 71 to Key table 70. Furthermore, controller 30 executes the secure instance erase function and then appends record information to KeyID table 60 and Key table 70.

[0090] Controller 30 receives the KeyTag from host 2 and accepts the read command (step S51). Controller 30 searches the Key table 70 and retrieves the record information 71 corresponding to the KeyTag received from host 2. Controller 30 reads the information containing the decrypted user data and KenGen (step S52).

[0091] The controller 30 determines whether the KenGen corresponding to the user data is managed by the KeyID table 60 by judging whether the KenGen is consistent with the KenGen of any record information 61 in the KeyID table 60 (step S53).

[0092] If the KeyID table 60 is not managed (step S53: No), it means that the user data read was encrypted before the security instance erasure function was executed. Therefore, the consistency judgment of the encryption key is skipped (step S54), and the process proceeds to step S57.

[0093] When managed by KeyID table 60 (step S53: Yes), if the KenGen corresponding to the user data matches the KenGen of the retrieved record information 71 (step S55: Yes), the controller 30 outputs the read data to the host 2 (step S57). Alternatively, if the KenGen corresponding to the user data does not match the KenGen of the retrieved record information 71 in step S55 (step S55: No), the controller 30 sends an error notification to the host 2 (step S56).

[0094] In the second embodiment, when disk 1 performs a secure instance erase function and then receives a read command, it does not issue an error notification if there is no KenGen record 61 containing Key tag information based on the data to be read. In this way, disk 1 can avoid checking the consistency of the encryption and decryption keys, such as when examining user data prior to performing the secure instance erase function, without needing to verify the consistency of the encryption and decryption keys.

[0095] (Modified Example)

[0096] In the above embodiment, the case of receiving KeyID from host 2 and storing the received KeyID in KeyID table 60 has been described. However, it is also possible to organize KeyIDs that have not been used for a long time. For example, when controller 30 sends record information 61 to host 2 according to a request from host 2 and receives the KeyID of the object to be deleted from host 2, it deletes the record information 61 corresponding to the KeyID. In addition, controller 30 deletes the record information 71 of KeyGen that contains the record information 61 of the object to be deleted.

[0097] In this way, disk 1 can avoid continuously maintaining unnecessary KeyID, Key, and other information.

[0098] Alternatively, the controller 30 can be configured to maintain the KenGen corresponding to the KeyID of the deleted object from the host 2, and perform a full read of the disk 11 at predetermined intervals to update the KenGen of the user data corresponding to the KenFGen to a value indicating that there is no KeyID.

[0099] Alternatively, disk 1 can be configured to be managed virtually as multiple drives, such as namespaces or logical unit numbers (LUNs). In this case, disk 1 can also be configured to store KeyID table 60 and Key table 70 on separate drives (virtual areas).

[0100] In this case, by storing KeyID table 60 and Key table 70 in a way that matches the virtual region, disk 1 can narrow the scope of searching KeyID table 60 and Key table 70, thereby reducing the processing load.

[0101] Furthermore, while the above embodiment describes the case applied to disk 1, it can also be applied to various other storage devices such as SSD (Solid State Drive).

[0102] Several embodiments of the present invention have been described above, but these embodiments are merely illustrative and not intended to limit the scope of the invention. These new embodiments can be implemented in a variety of other ways, and various omissions, substitutions, and modifications can be made without departing from the spirit of the invention. These embodiments and their variations are included within the scope and spirit of the invention, and are included within the scope of the invention as described in the claims and its equivalents.

Claims

1. A disk device comprising: Volatile memory; Non-volatile memory; as well as Controller When the controller receives the encryption / decryption key, the encryption / decryption key identifier, and the tag information of the encryption / decryption key from the host, and receives a setting request for the encryption / decryption key from the host, Generate generation information for the encryption / decryption key. The first information, which is associated with the generation information of the encryption and decryption keys, the tag information of the encryption and decryption keys, and the encryption and decryption keys, is recorded in the volatile memory. The second information, which is obtained by associating the encryption / decryption key identifier and the generation information of the encryption / decryption key, is recorded in the non-volatile memory.

2. The disk device according to claim 1, If the controller does not have second information corresponding to the received encryption / decryption key identifier, it will record the first information into the volatile memory and the second information into the non-volatile memory.

3. The disk device according to claim 1, When the controller receives user data and tag information of the encryption / decryption key corresponding to the user data from the host, and accepts a write request for the user data from the host, it encrypts the user data using the encryption / decryption key of the first information based on the tag information of the encryption / decryption key corresponding to the user data, and records the encrypted data into the non-volatile memory. The encrypted data is data obtained by associating the encrypted user data with the generation information of the encryption / decryption key of the first information.

4. The disc device according to claim 3, The controller Upon receiving tag information of the encryption / decryption key of the data to be read from the host, and upon receiving a read request for user data from the host, the system obtains the first information based on the tag information of the encryption / decryption key of the data to be read, and the encrypted data of the data to be read. If the generation information of the encryption / decryption key of the encrypted data of the read object is consistent with the generation information of the encryption / decryption key of the first information, the decrypted user data is sent to the host. If the generation information of the encryption / decryption key of the encrypted data of the read object is inconsistent with the generation information of the encryption / decryption key of the first information, an error notification is sent to the host.

5. The disk device according to claim 1, The controller As requested by the host, the encryption / decryption key identifier of the second information is sent to the host. Upon receiving the encryption / decryption key identifier of the object to be deleted from the host and accepting the data deletion request from the host, delete the second information containing the encryption / decryption key identifier of the object to be deleted and the first information containing the generation information of the encryption / decryption key containing the second information containing the encryption / decryption key identifier of the object to be deleted.

6. The disk device according to claim 1, The first information and the second information are recorded according to each virtual region of the non-volatile memory.

7. The disc device according to claim 4, The controller If an irrecoverable process is performed on the non-volatile memory, the first and second information are deleted. When the host receives the tag information of the encryption / decryption key of the data to be read and accepts the user's data read request, if the second information containing the tag information of the encryption / decryption key based on the data to be read cannot be obtained, the error notification will not be made.

8. A storage device comprising: Volatile memory; Non-volatile memory; as well as Controller When the controller receives the encryption / decryption key, the encryption / decryption key identifier, and the tag information of the encryption / decryption key from the host, and receives a setting request for the encryption / decryption key from the host, Generate generation information for the encryption / decryption key. The first information, which is associated with the generation information of the encryption and decryption keys, the tag information of the encryption and decryption keys, and the encryption and decryption keys, is recorded in the volatile memory. The second information, which is obtained by associating the encryption / decryption key identifier and the generation information of the encryption / decryption key, is recorded in the non-volatile memory.

Images