Encryption mode conversion method and electronic device

Abstract

The present application discloses an encryption mode conversion method and electronic device, which relates to the field of computer technology and the technical field, including receiving authentication information and a key configuration table sent by a verified data processing device; obtaining current key information according to the authentication information, and obtaining source storage block and target key information according to the key configuration table; ensuring that only trusted devices can initiate conversion operations; allocating target storage blocks to source storage blocks, and generating conversion records corresponding to the source storage blocks and target storage blocks; decrypting the source storage blocks according to the current key information, and re-encrypting them with the target key and writing them to the target storage blocks; based on the plaintext data having been stored in the target storage block, mapping the logical address of the source storage block to the target storage block, and updating the conversion record, thereby realizing the atomicity, traceability, and conversion consistency of the conversion operation; solving the problem of poor data security during the conversion process, and achieving the technical effect of improving data security and reliability.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an encryption mode conversion method and electronic device. Background Art

[0002] With the continuous advancement of cloud computing and increasing enterprise data requirements, encryption on solid-state drives (SSDs) has become a critical link in the end-to-end data protection chain. The currently widely used self-encrypting drive (SED) mode uses a single built-in media key to encrypt data entirely. However, when an SSD is shared by multiple hosts or multiple tenants (virtual machines, containers, function instances, etc.) on a single host, a single key cannot distinguish the access boundaries between different tenants, allowing any authorized party to decrypt all data. To increase isolation granularity, the self-encrypting mode is being gradually migrated to a key-per-I / O mode, where a separate key is selected for each I / O operation.

[0003] In the encryption mode conversion method of related technologies, the host usually initiates a read / write command, reads the entire disk ciphertext into the host memory, decrypts it using the original encryption mode key to obtain the plaintext, then re-encrypts it one by one according to the key-per-I / O key pool before writing it back to the solid-state drive. Although simple to implement, the plaintext remains in the host memory for a long time during the entire process, making data security difficult to ensure. Therefore, an encryption mode conversion method is urgently needed to address the technical problem of poor data security during the encryption mode conversion process. Summary of the Invention

[0004] The present application provides an encryption mode conversion method and an electronic device to at least solve the problem of poor data security in encryption mode conversion in the related art.

[0005] In a first aspect, the present application provides an encryption mode conversion method, comprising:

[0006] Receiving an encryption mode conversion instruction sent by a verified data processing device, and obtaining authentication information and a key configuration table carried in the encryption mode conversion instruction;

[0007] Obtaining current key information according to the authentication information, and obtaining at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table;

[0008] Allocating a target storage block to the source storage block and generating a conversion record corresponding to the source storage block and the target storage block;

[0009] Decrypt the data in the source storage block according to the current key information to obtain the plaintext data, and then encrypt the plaintext data using the target key information and write it into the target storage block;

[0010] Based on the plaintext data having been stored in the target storage block, the logical address of the source storage block is mapped to point to the target storage block, and the conversion record is updated.

[0011] In a second aspect, the present application provides an encryption mode conversion method, comprising:

[0012] Obtaining address information of at least one namespace to be converted, and determining a second key corresponding to the namespace to be converted according to a target encryption mode;

[0013] Generate a key configuration table according to address information of at least one namespace to be converted and a second key corresponding to at least one target encryption mode;

[0014] Obtain preset authentication information, and generate and send an encryption mode conversion instruction carrying the authentication information and the key configuration table to the storage device, so that the storage device receives the encryption mode conversion instruction sent by the verified data processing device and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction; obtain current key information based on the authentication information, and obtain at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block based on the key configuration table; allocate a target storage block to the source storage block, and generate a conversion record corresponding to the source storage block and the target storage block; decrypt the data of the source storage block based on the current key information to obtain plaintext data, and use the target key information to encrypt the plaintext data and write it to the target storage block; based on the plaintext data having been stored in the target storage block, map the logical address of the source storage block to point to the target storage block, and update the conversion record.

[0015] In a third aspect, the present application further provides a storage device, comprising:

[0016] An information receiving module is used to receive an encryption mode conversion instruction sent by a verified data processing device and obtain the authentication information and key configuration table carried in the encryption mode conversion instruction;

[0017] A key acquisition module is used to obtain current key information according to the authentication information, and obtain at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table;

[0018] A transaction processing module, configured to allocate a target storage block to a source storage block and generate a conversion record corresponding to the source storage block and the target storage block;

[0019] The encryption processing module is used to decrypt the data of the source storage block according to the current key information to obtain the plaintext data, and use the target key information to encrypt the plaintext data and write it into the target storage block;

[0020] The transaction update module is used to map the logical address of the source storage block to the target storage block based on the plaintext data having been stored in the target storage block, and to update the conversion record.

[0021] In a fourth aspect, the present application provides a data processing device, comprising:

[0022] An information acquisition module, configured to acquire address information of at least one namespace to be converted, and determine a second key corresponding to the namespace to be converted according to a target encryption mode;

[0023] An information configuration module, configured to generate a key configuration table based on address information of at least one namespace to be converted and a second key corresponding to at least one target encryption mode;

[0024] An instruction sending module is used to obtain preset authentication information, and generate and send an encryption mode conversion instruction carrying the authentication information and a key configuration table to a storage device, so that the storage device receives the encryption mode conversion instruction sent by the verified data processing device and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction; obtains current key information based on the authentication information, and obtains at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block based on the key configuration table; allocates a target storage block to the source storage block, and generates a conversion record corresponding to the source storage block and the target storage block; decrypts the data of the source storage block based on the current key information to obtain plaintext data, and uses the target key information to encrypt the plaintext data and write it to the target storage block; based on the plaintext data having been stored in the target storage block, maps the logical address of the source storage block to point to the target storage block, and updates the conversion record.

[0025] In a fifth aspect, the present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of the encryption mode conversion method of any one of the first or second aspects mentioned above when executing the computer program.

[0026] In a sixth aspect, the present application also provides a computer-readable storage medium, in which a computer program is stored, wherein when the computer program is executed by a processor, the steps of the encryption mode conversion method of any one of the first or second aspects mentioned above are implemented.

[0027] In the seventh aspect, the present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the encryption mode conversion method in any one of the first or second aspects above.

[0028] This application ensures that only trusted devices can initiate conversion operations by receiving encryption mode conversion instructions sent by verified data processing devices and parsing authentication information and key configuration tables; obtains current key information and target key information based on authentication information and key configuration tables, and only performs conversion on data blocks that pass integrity verification, thereby ensuring the integrity and credibility of the data to be converted. A new target storage block is allocated to each source storage block, and a conversion record is generated to achieve the atomicity and traceability of the conversion operation. By decrypting the data in the source storage block and re-encrypting it with the target key and writing it to the new storage location, the encryption reconstruction of the data is effectively completed. After the plaintext data is successfully stored in the target storage block, the logical address mapping relationship is updated, and the conversion record is updated to ensure that subsequent accesses accurately point to the new location and maintain conversion consistency. Therefore, it can solve the poor security problems such as plaintext leakage during the conversion process in related technologies, and achieve the technical effect of improving data security and reliability during the conversion process. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0030] Figure 1 Schematic diagram of the encryption mode conversion method provided in this embodiment Figure 1 ;

[0031] Figure 2 A schematic diagram of a method flow of a recovery mechanism provided in an embodiment of the present application;

[0032] Figure 3 Schematic diagram of the encryption mode conversion method provided in this embodiment Figure 2 ;

[0033] Figure 4 An interactive timing diagram of encryption mode conversion provided in an embodiment of the present application;

[0034] Figure 5 An interactive timing diagram of device verification provided in an embodiment of the present application;

[0035] Figure 6 A schematic diagram of the structure of a storage device provided in an embodiment of the present application;

[0036] Figure 7 A schematic diagram of the structure of a data processing device provided in an embodiment of the present application;

[0037] Figure 8 This is a schematic diagram of the structure of the electronic device provided in this application. DETAILED DESCRIPTION

[0038] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0039] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0040] In response to the problems in the related art, the inventive concept of this application is to provide an encryption mode conversion method to complete the data encryption mode conversion on the storage device side. The storage device receives the encryption mode conversion instruction sent by the verified data processing device, and based on the authentication information and key configuration table carried in the instruction, securely obtains the first key from the current encryption mode, and further obtains the source storage block that has passed the integrity check and the second key required in the target encryption mode. The conversion process is completed entirely within the device: first, the data of the source storage block is decrypted, and after obtaining the plaintext data, the second key is used directly in the device to complete the re-encryption and write it to the target storage block, and then the logical address mapping is updated and the conversion operation is recorded. In this way, the problem of plaintext data being exposed on the host side is avoided, and at the same time, the atomicity of the conversion is guaranteed through transaction control, thereby constructing an encryption mode conversion mechanism for environments with high security requirements.

[0041] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0042] Figure 1 Schematic diagram of the encryption mode conversion method provided in this embodiment Figure 1 ,like Figure 1 Shown, including:

[0043] S11, receiving an encryption mode conversion instruction sent by a verified data processing device, and obtaining authentication information and a key configuration table carried in the encryption mode conversion instruction.

[0044] In this embodiment, an encryption mode switch instruction is received from a verified data processing device. This instruction serves as a trigger signal for initiating the encryption mode switch process. It is important to ensure that the source of the encryption mode switch instruction is trustworthy to prevent unauthorized devices from triggering data encryption operations. Specifically, the data processing device sending the encryption mode switch instruction is confirmed to be a verified device. After confirming the identity of the device sending the encryption mode switch instruction, the information carried in the encryption mode switch instruction is retrieved, specifically including authentication information and a key configuration table. The authentication information is used to confirm the authenticity of the relevant information for this switch operation and the integrity of the data. For example, the authentication information may include the device identification or security credentials used for subsequent verification. The key configuration table defines the keys required for the encryption mode switch process and the applicable scope of the encryption mode switch. While ensuring the trustworthiness of the data processing device, this embodiment establishes the basic context information required for this encryption mode switch task. This provides the data foundation and guarantee for subsequent operations such as key acquisition, data decryption and encryption, and address mapping updates. This ensures the reliable initiation of the entire switch process and enhances security during encryption policy changes.

[0045] S12: Obtain current key information according to the authentication information, and obtain at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table.

[0046] In this embodiment, after receiving an encryption mode switch instruction, the current key information is extracted based on the authentication information. This current key information identifies the data decryption credentials for the currently used encryption mode and is a fundamental component of the subsequent data parsing process. Authentication information, as an input parameter for key access control, ensures that the obtained key information is used only in authorized contexts. During the authentication information parsing process, access rights verification is typically performed in conjunction with security policies to ensure the security of key acquisition. After extracting the current key information, the key configuration table is further parsed. This key configuration table stores the mapping between source data blocks and target keys and identifies source storage blocks that have passed integrity checks. This table is used to confirm that the data in the source storage blocks has not been tampered with and is stable. Based on the key configuration table, the device selects one or more source storage blocks that have passed integrity checks and further determines the target key information corresponding to each source storage block. The target key information represents the key credentials used to encrypt data in the target encryption mode. This embodiment effectively binds source data blocks to the target encryption policy and completes preparations for switching key resources to the new encryption mode while maintaining the integrity of the original data. Through the authentication-driven key identification mechanism and the analysis of the structured configuration table, the certainty of key analysis and the accuracy of target matching are improved, ensuring the consistency of data encryption policies before and after conversion, and improving the accuracy of key mapping and conversion security.

[0047] S13, allocating a target storage block to the source storage block, and generating a conversion record corresponding to the source storage block and the target storage block.

[0048] In this embodiment, to ensure that source data has independent storage space in the target encryption mode, an unused target storage block is allocated to each source storage block from the currently available storage resources. It is important to note that the target storage block must be consistent with the source storage block in terms of parameters such as capacity and alignment, and its physical address must not overlap with the source storage block to ensure that data is not overwritten or interfered with when written. The allocation process can be completed through a block mapping table or storage pool management to ensure the uniqueness and writability of the target storage block. After the target block is allocated, a conversion record is constructed to record status information during the data migration process. Exemplarily, the conversion record may include an association between the source storage block and the corresponding target storage block, and may further include a target encryption mode identifier, a target key identifier for data encryption, transaction execution status, and timestamp information. The conversion record is preferably generated using atomic operations and written to a non-volatile log area to ensure recoverability and consistency in the event of a device power outage or fault recovery. This embodiment implements metadata preparation for data encryption mode switching operations by allocating independent target storage blocks to source storage blocks and establishing conversion records. Separate block allocation ensures the logical independence of source and target data, supporting subsequent data decryption, encryption, and address remapping. Furthermore, conversion records, serving as metadata for the encryption mode conversion process, ensure transaction integrity verification, exception recovery, and state reconstruction. This overcomes the lack of transaction tracking and fault tolerance in traditional data migration, improving the security and stability of the encryption mode conversion process.

[0049] S14, decrypting the data in the source storage block according to the current key information to obtain the plaintext data, and using the target key information to encrypt the plaintext data and write it into the target storage block.

[0050] In this embodiment, the ciphertext data in the source storage block is decrypted based on the current key information. The key corresponding to the current key information should be consistent with the key used by the source storage block in the current encryption mode, ensuring that the decryption operation can restore accurate and uncorrupted plaintext data. The decryption operation is typically performed in a secure execution environment within the device, reducing the exposure of plaintext in external system buffers and improving data security. After obtaining the plaintext data, the target key information is called to re-encrypt the plaintext data. The key strength, encryption algorithm, and key derivation rules of the target key information may differ from the current encryption mode. When performing encryption, the format and encryption parameters specified by the target encryption policy must be adapted. To prevent intermediate plaintext from being accessed by external processes, this encryption process is also preferably performed in a hardware encryption engine. The encrypted ciphertext data is then written to the pre-allocated target storage block. This embodiment achieves encryption policy migration from the old encryption mode to the new encryption mode by decrypting the source data based on the current key information and re-encrypting it based on the target key information. Throughout the entire process, a closed data processing path ensures full ciphertext protection during data conversion, improving data processing security and encryption conversion consistency.

[0051] S15, based on the plaintext data having been stored in the target storage block, the logical address of the source storage block is mapped to point to the target storage block, and the conversion record is updated.

[0052] In this embodiment, after the plaintext data has been successfully encrypted and written to the target storage block, the storage mapping relationship and related records need to be updated to ensure the consistency of the data access path and the traceability of the status. First, based on a predefined address mapping mechanism, the logical address originally pointing to the source storage block is redirected to the target storage block. The logical address is an abstract index used by the upper-level file system or storage management module to access data, and the mapping between it and the physical storage location is maintained by the storage control module. During the encryption mode conversion, the logical address remains unchanged, while the physical address is switched from the source storage block to the target storage block, thereby achieving the update of the underlying data encryption policy without affecting the upper-level application access logic. Subsequently, the conversion record is updated. This update operation must meet atomicity, that is, the record update must be performed only after the mapping relationship is successfully modified, ensuring that the conversion status of each data block can be accurately traced back in the event of an abnormal interruption or fault recovery. In this embodiment, by remapping the logical address, all subsequent read and write requests automatically access data encrypted using the target encryption mode, ensuring the consistency of the data access path and encryption status. At the same time, by updating the conversion records, the status tracking and error recovery of each conversion can be achieved, which improves the controllability and security of the encryption mode conversion task.

[0053] Figure 2A schematic diagram of the recovery mechanism provided by the embodiment of the present application. Figure 2 As shown, the encryption mode conversion method also includes:

[0054] S21, based on the plaintext data not being stored in the target storage block, obtaining multiple conversion records and reading transaction statuses in the multiple conversion records;

[0055] S22, filtering out conversion records in a suspended state according to the transaction state; wherein, when the plaintext data is not stored in the target storage block, the transaction state in the conversion record is a suspended state;

[0056] S23: Obtain at least one conversion record in a suspended state, and mark the target storage block in the conversion record in the suspended state as invalid.

[0057] In this embodiment, in order to ensure the integrity and abnormal fault tolerance of the conversion operation, it is also necessary to have the ability to handle unfinished conversion tasks. Under the premise that the plaintext data has not been successfully written to the target storage block, a suspended state identification and recovery mechanism based on the conversion record is provided to ensure the consistency and accuracy of subsequent operations. First, when there is an unfinished write operation during the encryption mode conversion process, that is, when the plaintext data has not been successfully written to the corresponding target storage block, the abnormal state processing process will be triggered. This process reads multiple conversion records from a preset non-volatile log area or metadata management unit. Each conversion record contains the source storage block, the target storage block, key information and the corresponding transaction status field.

[0058] Subsequently, the transaction status fields in the aforementioned conversion records are traversed and filtered to identify conversion records currently in a pending state. The pending state typically identifies tasks that failed to complete the conversion due to a system interruption, power outage, or operational anomaly during the previous encryption mode conversion process. This state is set when the target data has not yet been written. When the data is successfully written, the pending state is no longer in effect due to the conversion record being updated. For one or more conversion records in a pending state that have been filtered out, the associated target storage block identifiers are further extracted, and these target storage blocks are re-marked as invalid. This invalidation marking of the target storage blocks not only prevents subsequent read and write operations from accessing incomplete or erroneous data but also allows them to be reallocated as reusable resources within the space reclamation mechanism. This invalidation marking operation is typically accompanied by flag bit updates, space reclamation registration, and log record synchronization to ensure data consistency and traceability. By promptly identifying and processing conversion records in a pending state, this embodiment enables the clearing of abnormal conversion tasks and resource recovery, effectively improving the fault tolerance and storage space utilization of the encryption mode conversion method. At the same time, it also provides a clear starting point and judgment basis for subsequent recovery retry or alternative conversion operations.

[0059] In one embodiment, based on the above embodiment, before obtaining the authentication information and key configuration table carried by the encryption mode conversion instruction, the method further includes:

[0060] S101, obtaining signature information in the encryption mode conversion instruction and obtaining a stored data processing device certificate;

[0061] S102, verifying the signature information according to the data processing device public key in the data processing device certificate;

[0062] S103: If the signature information verification is successful, the authentication information and key configuration table carried by the encryption mode conversion instruction are obtained.

[0063] In one embodiment, after receiving an encryption mode switch instruction, the instruction is first parsed and signature information is extracted. This signature information is a digital digest generated by encrypting the instruction content using the data processing device's private key. It is tamper-resistant and anti-forgery. Subsequently, a pre-registered and authenticated data processing device certificate is obtained. This certificate contains the identification information of the data processing device and the data processing device's public key used to verify the signature. The signature information is then verified based on the extracted data processing device public key. This verification process typically uses a preset signature algorithm, such as the Rivest–Shamir–Adleman algorithm (RSA), to compare the decrypted signature to determine its validity. If verification fails, it indicates that the instruction content may have been tampered with or the device identity is unauthorized, and subsequent execution is terminated and a security alert is issued. If the signature information verification passes, it confirms that the content of the current encryption mode switch instruction has not been tampered with and originates from a trusted data processing device. Furthermore, the authentication information and key configuration table carried in the encryption mode switch instruction are retrieved. Through the above-mentioned verification steps based on the signature mechanism, this embodiment ensures the instruction integrity and device credibility of the encryption mode conversion operation, builds reliable end-to-end authentication, effectively reduces the occurrence of data leakage problems, and ensures the security and controllability of the entire encryption mode conversion process.

[0064] Next, a specific implementation method for obtaining the authentication information and key configuration table carried by the encryption mode conversion instruction in step S11 is provided, including:

[0065] S111, obtaining a stored storage device private key, and decrypting the encrypted information carried in the encryption mode conversion instruction according to the storage device private key to obtain authentication information and a key configuration table.

[0066] In this embodiment, the pre-stored storage device private key is first read from the non-volatile storage area. This private key is typically isolated and protected using a hardware security module (HSM) or a trusted execution environment (TEE) to prevent unauthorized access or extraction. After reading the private key, a decryption operation is performed using the private key based on the encrypted information carried in the encryption mode switch instruction. The encrypted information is typically encrypted using a public-private key system such as RSA or ECDSA. The decryption process ensures that only authorized devices can restore its content. Through this decryption process, the authentication information and key configuration table carried by the encryption mode switch instruction are obtained. By storing the private key in a secure environment and using it to decrypt the information carried in the external instruction, the integrity and confidentiality of the key configuration table and authentication information are protected, thereby improving the security and reliability of the encryption mode switch process.

[0067] In one embodiment, a specific implementation of step S13 is provided herein. Based on the above embodiment, the implementation includes:

[0068] S131, selecting an unused storage block from a spare storage block pool as a target storage block;

[0069] S132, write a conversion record in a preset non-volatile log area according to the source storage block and the target storage block; wherein the conversion record includes at least one of the source storage block identifier, the target storage block identifier, the key identifier corresponding to the target encryption mode, or setting the transaction status to a suspended state.

[0070] In this embodiment, a currently unused physical storage block is selected from a spare storage block pool as the target storage block. The spare storage block pool is a set of alternative blocks reserved within the current storage device (such as a solid-state drive) to provide available space in the event that the original block becomes damaged, worn, or migrated, ensuring redundancy and sustainable write capabilities. The selected target storage block must be in an idle state and have write permissions and structural integrity to reduce the probability of subsequent migration failure or data loss. After the target storage block is selected, a conversion record is written to a pre-set non-volatile log area. The non-volatile log area is typically located in a specific reserved area of ​​the flash memory and has power-loss retention capabilities. It is used to record critical metadata information to support breakpoint recovery and transaction consistency. The writing of this log record provides atomicity guarantees for the encryption mode conversion process. Even if a power outage or failure occurs during the migration process, the operation can be accurately rolled back or retried based on the information in the log record, preventing data mapping confusion or status abnormalities.

[0071] The conversion record contains at least one or more of the following key fields: First, the source storage block identifier (such as the source storage block address), which is used to uniquely identify the original data block currently undergoing encryption mode migration; second, the target storage block identifier (such as the target storage block address), which is used to identify the new data block currently allocated for writing encrypted data; third, the key identifier corresponding to the target encryption mode, which is used to represent the encryption key index or number that should be used for the target storage block to ensure that the data encryption operation is consistent with the key configuration; fourth, the transaction status field, which can be set to a suspended state at the initial stage of writing the record, indicating that the data migration is not yet complete and needs to be submitted or rolled back through the status confirmation process. By recording these fields, the migration process status can be accurately located in subsequent operations, achieving closed-loop management of data block mapping relationships and key application policies, and effectively improving the controllability and fault tolerance of the overall conversion process.

[0072] In a specific embodiment, in step S12, current key information is obtained based on the authentication information. A specific embodiment is provided below. Based on the above embodiment, the following steps are included:

[0073] S1211, determining the current encryption mode based on the current key information;

[0074] S1212, based on the current encryption mode and the authentication information, obtaining a key encryption key using a preset key derivation algorithm, and calculating a current hash value corresponding to the key encryption key;

[0075] S1213: If the current hash value is the same as the preset reference hash value, the key encryption key is used to decrypt the medium encryption key encrypted and stored in the non-volatile storage area to obtain a first key corresponding to the current encryption mode.

[0076] In this embodiment, the encryption mode currently used by the storage device is determined based on the current key information. The current key information typically includes the current encryption algorithm identifier, key length information, and configuration fields related to the current encryption policy. By parsing these fields, the current encryption mode can be determined, such as whether it is in self-encrypting drive (SED) mode or one of several encryption policies. This ensures that subsequent key processing operations are performed according to the correct encryption mode, reducing key mismatches or data decryption failures caused by mode confusion. After identifying the current encryption mode, a key encryption key (KEK) is derived using a preset key derivation algorithm based on authorization parameters in the authentication information, such as the device identifier, permission token, and user password. The key derivation algorithm is typically a structured algorithm based on a cryptographic hash function, such as HKDF (HMAC-based Key Derivation Function). The authentication information serves as one of the inputs to the derivation algorithm, ensuring that the generated KEK is device-bound and consistent with the authentication context. The derived KEK is used to further protect the actual stored encryption key, preventing the direct exposure of the Media Encryption Key (MEK). A hash algorithm (such as SHA-256) is then used to calculate the key encryption key to generate the current hash value, which is used for key integrity verification.

[0077] Next, the calculated current hash value is compared with a reference hash value pre-stored in the secure storage area. If the current hash value matches the reference hash value, this indicates that the key encryption key has not been tampered with or replaced, and its derivation process is trustworthy. Based on this, the key encryption key is used to decrypt the media encryption key stored in the non-volatile storage area, recovering the first key corresponding to the current encryption mode. This process ensures that the acquisition of the first key has the basis for authentication and integrity verification, improving the security and robustness of key management during the conversion process.

[0078] Furthermore, in a specific embodiment, step S12 obtains at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table, including:

[0079] S1221, read and parse the key configuration table, extract the address start value and address end value of at least one namespace to be converted, and obtain target key information corresponding to the namespace to be converted;

[0080] S1222, according to the address start value and the address end value of the namespace to be converted, obtain source storage blocks from the namespace to be converted according to a preset acquisition order; wherein the namespace to be converted includes one or more source storage blocks;

[0081] S1223: Based on the source storage block, use the first key to decrypt and obtain the plaintext data in the source storage block, and store the plaintext data in a preset secure buffer;

[0082] S1224, using a preset cyclic redundancy check algorithm, calculate the current check value of the plaintext data, obtain a preset reference check value corresponding to the plaintext data, and obtain the current check count corresponding to the source storage block;

[0083] S1225: If the number of checksums corresponding to the source storage block is less than a preset number threshold, and the current checksum value is consistent with the reference checksum value, then the source storage block is recorded as having passed the integrity check. Based on the correspondence between the source storage block and the namespace to be converted and the target key information corresponding to the namespace to be converted, the target encryption mode corresponding to the source storage block is determined, and a second key corresponding to the target encryption mode is obtained.

[0084] S1226: If the number of checksums corresponding to the source storage block is less than a preset number threshold, and the current checksum value is inconsistent with the reference checksum value, the first key is used to re-decrypt and obtain the plaintext data in the source storage block, and the current checksum value of the plaintext data is calculated. The current checksum number corresponding to the source storage block is updated, and the current checksum value and the reference checksum value are re-verified.

[0085] S1227, if the number of verifications corresponding to the source storage block is equal to or greater than a preset number threshold, and the current verification value is inconsistent with the reference verification value, the source storage block is marked as damaged, and the source storage block is added to a preset damaged block list.

[0086] In this embodiment, to ensure that conversion operations are performed only on valid data blocks, the key configuration table must first be read and parsed. The key configuration table records the boundary information of multiple namespaces to be converted, including the starting and ending address values ​​of each namespace, as well as the corresponding target key information. A namespace is a continuous area in the logical address space, typically used for partitioning storage resources. Each namespace contains one or more source storage blocks to be converted. By extracting the boundary addresses of the namespace, the range of data blocks to be processed can be determined, achieving accurate positioning of the conversion target. Subsequently, the source storage blocks are extracted from the specified namespace according to a preset acquisition order. The acquisition order can be set based on address sorting, conversion priority, or other scheduling strategies to ensure that block-level data processing can be carried out in an orderly manner during the encryption mode conversion process. Through a structured reading order, data processing consistency and efficiency are achieved.

[0087] The obtained source storage block is decrypted using the first key to obtain the plaintext data. The first key is the key used in the current encryption mode. Its decryption operation can be completed by an embedded security module or a hardware encryption engine to improve processing speed and enhance security. The decrypted plaintext data is temporarily stored in a secure buffer located in a controlled memory area to prevent the leakage of intermediate plaintext data in the memory. To ensure that the decrypted data has not been tampered with, an integrity check is performed on the plaintext data in the buffer. This integrity check uses a preset cyclic redundancy check (CRC) algorithm to calculate a check value on the data and compare it with a pre-saved reference check value. The current check count for each source storage block is also recorded to control the number of retries and reduce resource waste.

[0088] If the checksums match, indicating the data is valid, the integrity check is recorded for the source storage block. Based on the mapping between the namespace and the source storage block, the corresponding target key information is searched. This target key information is used to derive the target encryption mode, from which the second key is derived for subsequent re-encryption. If the checksums do not match, and the number of checksum attempts has not reached the preset threshold, the source storage block is decrypted again using the first key, and the checksum is recalculated and compared. The checksum attempt count for that block is also updated, implementing a fault-tolerant data verification mechanism.

[0089] Furthermore, if the integrity verification still fails after the number of checks reaches or exceeds the threshold, the source storage block is marked as damaged and added to the damaged block list. The damaged block list is used to record storage units with abnormal data so that they will no longer be converted or written to, thereby ensuring the reliability and data consistency of the overall encryption mode conversion process. This embodiment implements a data integrity judgment mechanism on the device side by introducing a cyclic redundancy check mechanism and multiple check retry logic, ensuring the consistency and credibility of data during the key switching process, and improving the robustness of the encryption mode conversion operation and the data security level.

[0090] In a specific embodiment, the above steps are performed according to a preset acquisition order to obtain the source storage block; a specific implementation method is provided herein. Based on the above embodiment, it includes:

[0091] According to multiple source storage blocks in the namespace to be converted, the access frequency of each source storage block is obtained, and the multiple source storage blocks are sorted in descending order according to the access frequency, and the encryption mode conversion of the source storage blocks is performed in sequence from high to low.

[0092] In this embodiment, historical access frequency information for each source storage block in the namespace to be converted is obtained. Access frequency can be obtained by recording the number of read and write operations on each storage block within a preset time window, or by extracting it based on auxiliary information such as I / O counters, access timestamps, and popularity indicators maintained by the underlying storage device. This information reflects the activity level of each storage block, thereby indicating its importance in the current environment. After obtaining the access frequency, the multiple source storage blocks are sorted in descending order of access frequency. After the sorting is complete, encryption mode conversion is prioritized for source storage blocks with higher access frequencies, i.e., data migration and encryption reconstruction are performed sequentially in descending order of access popularity. This prioritization mechanism allows for the conversion of critical, hot data to be completed as quickly as possible in the early stages, allowing frequently accessed areas to be released from the old encryption mode as quickly as possible and benefit from the higher-granularity key isolation and security guarantees of the new encryption mode. Furthermore, the conversion process reduces the security exposure window of hot data caused by delayed conversion. Therefore, this strategy ensures data security while balancing operational efficiency and resource scheduling priorities.

[0093] In a specific embodiment, a specific implementation of step S14 is provided herein. Based on the above embodiment, the data of the source storage block is decrypted according to the current key information to obtain the plaintext data, and the plaintext data is encrypted using the target key information and then written into the target storage block, including:

[0094] S141, reading the data content in the source storage block, and decrypting the data using a first key through a preset hardware encryption engine according to the current encryption mode to obtain the plaintext data in the source storage block;

[0095] S142 , based on the target encryption mode, according to the second key, using a preset encryption algorithm to encrypt the plaintext data, and write the encrypted plaintext data into the target storage block.

[0096] In this embodiment, to ensure complete data migration and confidentiality protection across different encryption modes, the ciphertext data in the source storage block must be read and re-encrypted. First, the data content in the source storage block is read and transferred to the hardware encryption engine via Direct Memory Access (DMA). During the read process, parameters such as the block address and offset are combined to determine the required data range, ensuring that the retrieved ciphertext data is completely consistent with the data corresponding to the logical address, minimizing data misalignment or omissions. Based on the current encryption mode (such as self-encryption mode), the read data is decrypted by the hardware encryption engine. The hardware encryption engine is a dedicated circuit module integrated into the storage device, offering high decryption speed and security. It prevents plaintext data from being exposed to the external environment via host memory, thereby reducing the risk of unauthorized access. The hardware engine decrypts the data using a first key to obtain the plaintext data in the source storage block. Alternatively, the plaintext data, decrypted using the first key, can be retrieved from the secure buffer. The specific acquisition method can be flexibly configured based on actual needs to achieve the purpose of obtaining plaintext data.

[0097] Next, the plaintext data is re-encrypted based on the target encryption mode. The target encryption mode can be a key-per-I / O mode, which requires that each input and output operation use an independent key to ensure data isolation. To this end, the plaintext data is encrypted using a preset encryption algorithm (e.g., a symmetric encryption algorithm such as AES or SM4) based on a second key that matches the target encryption mode. After encryption is complete, the generated encrypted data is written to a pre-allocated target storage block, completing the secure migration of the data under the new encryption mode. This embodiment maintains data integrity and confidentiality during the encryption mode transition by encapsulating the read, decryption, re-encryption, and write operations into a single, inseparable logical process. This solves the low data security issue caused by plaintext transit on the host side in traditional solutions and enables encryption mode transitions with higher security. It should be further noted that after the second key is used, its corresponding target key information in the key configuration table is marked as associated, indicating that the current key has been used, thereby reducing the misuse of keys that have not yet been used in transactions.

[0098] In a specific embodiment, updating the conversion record in step S15 includes:

[0099] S151: Mark the transaction status in the conversion record as committed, and add the source storage block to a queue to be recycled.

[0100] In this embodiment, after confirming that the plaintext data has been successfully written to the target storage block and the logical address mapping has been switched to the target storage block, the relevant conversion record and storage block status are updated. First, the transaction status field in the corresponding conversion record recorded in the non-volatile log area is updated from the suspended state to the committed state. The transaction status field is a control field used to identify the current stage of the conversion process. The change of its value must comply with the preset atomic transaction rules, that is, it will be marked as committed only after the data is successfully written and the address mapping switch is completed. The update of this status allows the completed transaction record to be skipped when the restart recovery process is subsequently executed, thereby improving recovery efficiency and reducing repeated encryption or erroneous rollback.

[0101] Subsequently, the source storage block corresponding to the conversion record is added to the queue to be recycled. The queue to be recycled is a logical collection used to manage data source blocks that have completed re-encryption. Its goal is to free up physical space while ensuring that the data no longer depends on the old blocks. By moving the source block into this queue, the resource recovery mechanism can be uniformly scheduled, such as asynchronous erasure, erase and write leveling, or recycling operations, thereby improving overall performance. This embodiment realizes the resource closure and state consistency maintenance in the encryption mode conversion process by clarifying the update of the conversion status and the triggering of source block recycling. Through this mechanism, the residual source block data is removed to ensure that the old data cannot be reread after the key is updated.

[0102] In one embodiment, before the above step S11, the encryption mode conversion method further includes:

[0103] S1001, receiving a startup authentication instruction sent by a data processing device, and obtaining a data processing device certificate carried in the startup authentication instruction;

[0104] S1002, obtaining the stored public key of the organization and using the public key to verify the data processing device certificate;

[0105] S1003, if the data processing device certificate is verified, the data processing device certificate is stored and a random number of a preset length is generated; wherein the current random number is different from the random numbers corresponding to the previous multiple authentication instructions;

[0106] S1004, sending the storage device certificate and the random number to the data processing device, so that the data processing device verifies the storage device certificate according to the storage device certificate and the random number;

[0107] S1005, receiving a storage device certificate verification pass instruction sent by the data processing device, and obtaining signature information carried in the storage device certificate verification pass instruction;

[0108] S1006, obtaining the data processing device public key based on the stored data processing device certificate, and verifying the signature information using the data processing device public key;

[0109] S1007, if the signature information verification fails, a verification failure message is sent to the data processing device;

[0110] S1008: If the signature information verification is successful, the data processing device is marked as a verified data processing device.

[0111] In this embodiment, in order to ensure that the communication with the data processing device is established on the basis of a trusted identity, a startup authentication process is first executed. The startup authentication process is initiated by the storage device side actively responding to the authentication request initiated by the data processing device, and establishing a trust relationship through a two-way certificate verification mechanism. Specifically, the storage device first receives the startup authentication instruction sent from the data processing device, and parses and obtains the data processing device certificate carried in the instruction. The data processing device certificate contains attribute information such as the data processing device public key, issuing agency information, and validity period for identity authentication. The storage device then obtains the locally preset agency public key and uses the agency public key to verify the data processing device certificate. Certificate verification includes integrity verification and validity period check of the signature field to ensure that the certificate is issued by a trusted agency and is still within the validity period.

[0112] If verification succeeds, the data processing device certificate is stored in a pre-set certificate cache, and a random number corresponding to the current session is generated. This random number has a fixed length and is guaranteed to be different from the random numbers used in previous startup authentication instructions. This reduces data security issues caused by random number reuse. Subsequently, the storage device certificate containing its own identification information and the currently generated random number are sent to the data processing device for verification of the storage device's identity and establishment of the session context.

[0113] After receiving a storage device certificate verification success instruction from the data processing device, the storage device further obtains the signature information contained in the instruction. The signature information is a response digest generated by the data processing device using its private key based on the received random number and the storage device certificate, and is intended to prove that it possesses the corresponding private key capabilities. Based on the stored data processing device certificate, the public key is extracted and used to verify the signature information. If the verification fails, the storage device immediately sends a verification failure message to the data processing device and no further interaction is carried out.

[0114] If the signature information is verified successfully, it is confirmed that the data processing device has a private key that matches its certificate, indicating that the device's identity is trustworthy, and the device status is marked as verified. Subsequent operations such as encryption mode conversion instructions and key distribution requests for this device will be judged based on this marked status. This embodiment implements the identity authentication process during the startup phase by introducing a bidirectional certificate verification and non-repeating random number mechanism, effectively reducing the security issues of certificate forgery, replay attacks, and key inconsistencies, and improving the security of encryption mode conversion operations in the overall data link.

[0115] Figure 3 Schematic diagram of the encryption mode conversion method provided in this embodiment Figure 2 ,like Figure 3 Shown, including:

[0116] S31, obtaining address information of at least one namespace to be converted, and obtaining a second key corresponding to the namespace to be converted according to a target encryption mode;

[0117] S32: Generate a key configuration table based on the address information of at least one namespace to be converted and the second key corresponding to at least one target encryption mode;

[0118] S33, obtain preset authentication information, and generate and send an encryption mode conversion instruction carrying the authentication information and the key configuration table to the storage device, so that the storage device receives the encryption mode conversion instruction sent by the verified data processing device, and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction; according to the authentication information, obtain the first key corresponding to the current encryption mode, and according to the key configuration table, obtain at least one source storage block that passes the integrity check and at least one second key corresponding to the target encryption mode; allocate a target storage block to the source storage block, and generate a conversion record corresponding to the source storage block and the target storage block; according to the first key, decrypt the data of the source storage block to obtain the plaintext data, and use the second key to encrypt the plaintext data and write it to the target storage block; based on the plaintext data having been stored in the target storage block, according to the preset atomic transaction operation rules, map the logical address of the source storage block to point to the target storage block, and update the conversion record.

[0119] In this embodiment, the data processing device first obtains the address information of at least one namespace to be converted. The address information is used to identify the data area in the storage device that needs to switch the encryption mode, usually including the start address and end address of each namespace to define its physical or logical range. Subsequently, according to the set target encryption mode, the corresponding encryption key, that is, the second key, is set or obtained. The target encryption mode may include different types such as Key-per-I / O, partition key, tenant key, etc., and the second key is a key instance that matches it and has usage permissions and validity period control. The obtained address information and the second key are used together to generate a key configuration table. The key configuration table records the mapping relationship between each storage block in the namespace to be converted and the target encryption mode, and associates the key label, encryption algorithm identifier and necessary key attribute information.

[0120] After generating the key configuration table, the data processing device retrieves authentication information from the local key protection mechanism. This authentication information includes parameters such as the user password, device identification, and timestamp. Specifically, based on the authentication information and the key configuration table, the data processing device uses the stored storage device public key to encrypt the authentication information and key configuration information, obtaining encrypted information. The encrypted information is then signed using the data processing device's private key to obtain the corresponding signature information. The device then generates an encryption mode switch instruction carrying the encrypted information and sends this instruction to the storage device. After receiving the encryption mode conversion instruction, the storage device obtains the authentication information and key configuration table carried by the encryption mode conversion instruction; according to the authentication information, obtains the first key corresponding to the current encryption mode, and according to the key configuration table, obtains at least one source storage block that has passed the integrity check and at least one second key corresponding to the target encryption mode; allocates the target storage block to the source storage block, and generates a conversion record corresponding to the source storage block and the target storage block; according to the first key, decrypts the data of the source storage block to obtain the plaintext data, and uses the second key to encrypt the plaintext data and write it to the target storage block; based on the plaintext data being stored in the target storage block, according to the preset atomic transaction operation rules, maps the logical address of the source storage block to the target storage block, and updates the conversion record. The corresponding implementation method of the storage device has been described in the previous embodiment and will not be repeated here. In summary, through this embodiment, the encryption mode conversion method realizes the orderly transition from the self-encryption mode to the higher security level encryption mode such as Key-per-I / O under the premise of ensuring data security, and has atomicity, rollback and key isolation, effectively meeting the data protection requirements in a multi-host, multi-tenant environment.

[0121] In one embodiment, the encryption mode conversion method further includes:

[0122] S301, obtaining at least one conversion record of a non-volatile log area in a storage device;

[0123] S302, acquiring address information of at least one unconverted namespace based on address information of at least one namespace to be converted recorded in the key configuration table and based on at least one conversion record;

[0124] S303: Obtain the second key corresponding to the untranslated namespace according to the key configuration table, and generate a new key configuration table according to the address information of at least one untranslated namespace and its corresponding second key;

[0125] S304: Obtain preset authentication information, generate and send an encryption mode conversion instruction carrying the authentication information and a new key configuration table to the storage device.

[0126] In this embodiment, if a restart or other situation occurs, the data processing device reads at least one conversion record from the non-volatile log area preset in the storage device. This conversion record is used to track the intermediate and historical states of the encryption mode conversion operation. By parsing this record, it is possible to determine which namespaces have completed the conversion during the conversion process and which are still in a pending or unprocessed state. Next, combined with the address information of at least one namespace to be converted recorded in the key configuration table, and compared with at least one conversion record extracted from the non-volatile log area, the address information of the namespace that has not yet completed the encryption mode conversion is identified. Based on the mapping logic of the address range and the parsing of the conversion status field, accurate identification of the unconverted namespace is ensured.

[0127] After determining the address information of at least one unconverted namespace, the corresponding second key is obtained based on the mapping between namespaces and keys maintained in the key configuration table. The second key is a parameter used to encrypt data in the new encryption mode (such as Key-per-I / O mode). A new key configuration table is reconstructed based on the identified address information of the unconverted namespaces and their corresponding second keys. This new key configuration table contains only relevant information that has not been converted, and is used to guide the processing of the unconverted namespaces in subsequent encryption mode conversion tasks. After generating the new key configuration table, pre-set authentication information is used to sign, bind identities, or encrypt the new encryption mode conversion instruction to ensure tamper resistance during communication. Subsequently, an encryption mode conversion instruction carrying the authentication information and the new key configuration table is generated and sent to the storage device. This instruction triggers the conversion process for the remaining unconverted namespaces, achieving phased advancement of the encryption mode conversion process. This allows the storage device to continue processing data for the remaining unconverted areas, achieving a smooth encryption mode transition and closed-loop conversion process for the entire namespace.

[0128] It should be noted that after all source storage blocks requiring encryption mode conversion in a namespace to be converted have been converted, the encryption mode of the namespace is set to the target encryption mode (e.g., Key Per I / O mode) instead of the current encryption mode (e.g., self-encryption mode). At this point, the original self-encryption key is deleted from the non-volatile memory. The non-volatile log area is cleared, and the corresponding namespace is marked as completed (e.g., the value is changed to 0xFFFFFFFF), indicating that the current conversion is complete and there are no pending conversions. If the value of the namespace identifier is not 0xFFFFFFFF, it indicates that the conversion of the specified namespace has not yet been completed, that is, the namespace has not been converted.

[0129] Furthermore, in one embodiment, before sending the encryption mode conversion instruction carrying the authentication information and the new key configuration table to the storage device, the encryption mode conversion method further includes:

[0130] S3301, sending a start authentication instruction carrying a data processing device certificate to a storage device, so that the storage device verifies the data processing device certificate;

[0131] S3302, receiving a storage device certificate and a random number sent by the storage device;

[0132] S3303: Verify the storage device certificate based on the organization public key in the stored organization public key certificate.

[0133] S3304: If the storage device certificate verification passes, the random number is signed using the data processing device private key to obtain signature information, and a storage device certificate verification pass instruction carrying the signature information is sent to the storage device;

[0134] S3305: If the storage device certificate verification fails, resend the start authentication instruction carrying the data processing device certificate to the storage device.

[0135] In this embodiment, the data processing device generates and sends a startup authentication instruction carrying a data processing device certificate to the storage device. The startup authentication instruction is used to initiate a two-way authentication process between the storage device and the data processing device, and the data processing device certificate contained therein is used to prove the legal identity of the current host. The certificate is usually issued by a trusted organization and contains device identification, public key information, and other content. Then, after the data processing device receives the storage device certificate and the random number, it first verifies the authenticity of the storage device certificate based on the institution public key in the locally pre-stored institution public key certificate. The verification process includes checking whether the signature is valid, whether the certificate is within the validity period, and whether the certificate chain is complete, etc., to ensure that the current communication peer is a trusted storage device.

[0136] If the verification result is passed, the data processing device will use the data processing device private key through the local encryption module to sign the received random number, thereby generating signature information. This can be verified by the other party to confirm the authenticity of the identity. Subsequently, the data processing device constructs a storage device certificate verification pass instruction and sends the instruction containing the signature information to the storage device, marking the completion of the second half of the authentication process. If the verification result is failed, it means that the received storage device certificate cannot be trusted, and the data processing device should not continue the authentication process. To this end, the authentication retry logic can be automatically triggered to resend the start authentication instruction carrying the data processing device certificate to the storage device to wait for its response again and enter a new round of authentication judgment process. By introducing this authentication mechanism, the interactive security between devices can be effectively guaranteed, and a trusted foundation can be laid for subsequent key transmission and instruction issuance.

[0137] Figure 4 The interactive sequence diagram of the encryption mode conversion provided by the embodiment of this application. Figure 4 Shown, including:

[0138] S41, the data processing device obtains address information of at least one namespace to be converted, and obtains a second key corresponding to the namespace to be converted according to a target encryption mode;

[0139] S42, the data processing device generates a key configuration table according to the address information of at least one namespace to be converted and the second key corresponding to at least one target encryption mode;

[0140] S43, the data processing device obtains preset authentication information, generates and sends an encryption mode conversion instruction carrying the authentication information and the key configuration table to the storage device;

[0141] S44, the storage device receives the encryption mode conversion instruction sent by the authenticated data processing device, and obtains the authentication information and key configuration table carried in the encryption mode conversion instruction;

[0142] S45: The storage device obtains a first key corresponding to the current encryption mode based on the authentication information, and obtains at least one source storage block that passes the integrity check and at least one second key corresponding to the target encryption mode based on the key configuration table.

[0143] S46, the storage device allocates a target storage block to the source storage block and generates a conversion record corresponding to the source storage block and the target storage block;

[0144] S47, the storage device decrypts the data of the source storage block using the first key to obtain plaintext data, and encrypts the plaintext data using the second key and writes the encrypted data into the target storage block;

[0145] S48, based on the plaintext data having been stored in the target storage block, the storage device maps the logical address of the source storage block to point to the target storage block according to the preset atomic transaction operation rules, and updates the conversion record.

[0146] It should be noted that the data processing device in this embodiment adopts a host, the storage device adopts a solid-state hard disk, and the implementation process of converting from the self-encryption mode (current encryption mode) to the Key Per I / O mode (target encryption mode) has been explained in the above embodiment and will not be repeated here.

[0147] Figure 5 This is an interactive timing diagram of the device verification provided in the embodiment of this application. In a specific embodiment, the data processing device is a host and the storage device is a solid state drive. On this basis, the bidirectional verification of the two devices is further explained here. Figure 5 Shown, including:

[0148] In step S501 , the host sends a start authentication command and carries the host's digital certificate (host certificate) to the solid state drive.

[0149] In step S502 , the solid state drive receives the start authentication command, extracts the host certificate therein, and verifies the host certificate using the pre-stored public key of the certificate authority.

[0150] Step S503: If the host certificate verification fails, the solid-state drive returns an authentication failure message and the authentication process terminates;

[0151] Step S504: If the verification is successful, the SSD saves the host certificate, generates a new random number (e.g., 128 bits in length), and returns the random number and its own digital certificate (SSD certificate) to the host;

[0152] Step S505 , the host receives the SSD certificate and random number returned by the SSD, and verifies the SSD certificate using the locally stored public key of the certificate authority;

[0153] Step S506: If the host fails to verify the SSD certificate, it re-executes the start-up authentication command (it should be noted that the authentication process is terminated after a total of three verification failures);

[0154] Step S507: If the SSD certificate is successfully verified, the host uses its own private key to sign the obtained random number to generate signature information;

[0155] Step S508: The host sends an authentication command carrying signature information to the solid state drive;

[0156] Step S509: The solid state drive receives the authentication command, extracts the signature information, and verifies the signature information using the host public key in the stored host certificate.

[0157] Step S510: If the signature verification fails, the solid-state drive returns an authentication failure message;

[0158] Step S511: If the signature verification is successful, the solid-state drive sets a verification success flag and marks the host as a trusted device;

[0159] In step S512, the solid state drive returns a success status to the host.

[0160] It should be noted that if the authentication command is sent directly without executing the startup authentication command first, the solid-state drive will directly return failure; and the random number used for each authentication is only valid once, and will be discarded after the process is completed regardless of whether the authentication is successful.

[0161] In one embodiment, a key generation and certificate configuration process for a solid-state drive and a host is provided to establish a trust foundation for subsequent authentication and encrypted communication. This is performed before performing bidirectional authentication between the host and the solid-state drive.

[0162] First, before a solid-state drive (SSD) leaves the factory, the SSD controller calls a pre-installed key generation module to generate a pair of public and private keys based on the Elliptic Curve Digital Signature Algorithm (ECDSA). These keys are referred to as the SSD public key (SSD_pubkey) and the SSD private key (SSD_prikey). The SSD private key is configured through hardware logic and stored only in the SSD's internal non-volatile secure memory. It is also set to a non-exportable attribute, making it inaccessible even through the debug port or software commands. The SSD public key is then sent to a trusted certificate authority (CA) via a private command channel.

[0163] After receiving the SSD public key, the certificate authority uses its own certificate authority private key (CA_prikey) to sign the SSD public key and organize it into a digital certificate format that complies with the X509 standard, obtaining the SSD device certificate (SSD_cert). This certificate includes fields such as the SSD public key, public key usage, signature algorithm identifier, validity period, and digital signature information signed by the certificate authority's private key. The certificate authority further sends this SSD certificate back to the SSD device along with its own root certificate (CA_cert). After receiving the above certificate, the SSD securely writes it to the internal non-volatile area for subsequent two-way authentication with the external host.

[0164] At the same time, the host side also needs to complete its own certificate application process in advance. When the host is first configured, a pair of key pairs is generated through the local key generation module, which are recorded as the host public key (host_pubkey) and the host private key (host_prikey). The host private key is stored only in a protected storage area within the host (such as the Trusted Execution Environment or Trusted Platform Module) through the security policy to ensure its security during operation. The host sends the host public key to the same certificate authority for authentication. The certificate authority uses the certificate authority private key to sign the host public key, generate a host certificate (host_cert) in X509 format, and return the host certificate and root certificate to the host. The host securely stores the host certificate and root certificate for subsequent identity authentication before establishing a secure connection with the SSD.

[0165] In this embodiment, both the SSD and host certificates are issued by a unified and trusted certificate authority, ensuring that the trust relationship established between the host and SSD is based on the same trust chain. Furthermore, the private keys of both the host and SSD are confined to the local device and cannot be exported, effectively preventing the risk of key leakage. This pre-configuration process enables subsequent authentication of storage commands and execution of encryption mode conversion commands based on a two-way certificate verification mechanism.

[0166] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0167] Figure 6 This is a schematic diagram of the structure of the storage device provided in the embodiment of the present application. Figure 6 As shown, the storage device 6 includes:

[0168] An information receiving module 61 is configured to receive an encryption mode switching instruction sent by a verified data processing device and obtain authentication information and a key configuration table carried in the encryption mode switching instruction;

[0169] A key acquisition module 62 is configured to acquire current key information based on the authentication information, and acquire at least one source storage block that has passed the integrity check and at least one target key information corresponding to the source storage block based on the key configuration table;

[0170] The transaction processing module 63 is used to allocate a target storage block to a source storage block and generate a conversion record corresponding to the source storage block and the target storage block;

[0171] The encryption processing module 64 is used to decrypt the data of the source storage block according to the current key information to obtain the plaintext data, and encrypt the plaintext data using the target key information and write it into the target storage block;

[0172] The transaction update module 65 is configured to map the logical address of the source storage block to the target storage block based on the plaintext data having been stored in the target storage block, and to update the conversion record.

[0173] The storage device 6 may be a solid-state hard disk. For descriptions of features in the corresponding embodiment, please refer to the relevant descriptions of the embodiment corresponding to the encryption mode conversion method, which will not be repeated here.

[0174] Figure 7 This is a schematic diagram of the structure of the data processing device provided in the embodiment of the present application. Figure 7 As shown, the data processing device 7 includes:

[0175] An information acquisition module 71 is configured to acquire address information of at least one namespace to be converted and determine a second key corresponding to the namespace to be converted based on a target encryption mode;

[0176] An information configuration module 72 is configured to generate a key configuration table based on the address information of at least one namespace to be converted and a second key corresponding to at least one target encryption mode;

[0177] The instruction sending module 73 is used to obtain preset authentication information, and generate and send an encryption mode conversion instruction carrying the authentication information and the key configuration table to the storage device, so that the storage device receives the encryption mode conversion instruction sent by the verified data processing device, and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction; obtains the current key information according to the authentication information, and obtains at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table; allocates a target storage block to the source storage block, and generates a conversion record corresponding to the source storage block and the target storage block; decrypts the data of the source storage block according to the current key information to obtain plaintext data, and uses the target key information to encrypt the plaintext data and write it to the target storage block; based on the plaintext data having been stored in the target storage block, maps the logical address of the source storage block to point to the target storage block, and updates the conversion record.

[0178] The data processing device 7 may be a host. For descriptions of features in the corresponding embodiments, reference may be made to the relevant descriptions of the embodiments corresponding to the encryption mode conversion method, which will not be described in detail here.

[0179] Figure 8 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 8 As shown, the electronic device 8 provided in this embodiment includes: at least one processor 81 and a memory 82. Optionally, the electronic device 8 also includes a communication component 83. The processor 81, the memory 82 and the communication component 83 are connected via a bus 84.

[0180] During the specific implementation process, at least one processor 81 executes the computer-executable instructions stored in the memory 82, so that the at least one processor 81 executes the above-mentioned encryption mode conversion method embodiment.

[0181] The specific implementation process of the processor 81 can be found in the above-mentioned method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0182] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the application may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0183] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0184] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0185] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored, wherein the computer program is configured to execute the steps of any of the above-mentioned encryption mode conversion method embodiments when running.

[0186] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0187] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any one of the above encryption mode conversion method embodiments are implemented.

[0188] An embodiment of the present application also provides another computer program product, including a non-volatile computer-readable storage medium, the non-volatile computer-readable storage medium storing a computer program, and when the computer program is executed by a processor, implementing the steps in any of the above-mentioned encryption mode conversion method embodiments.

[0189] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0190] The above describes in detail the encryption mode conversion method provided by this application. This document uses specific examples to illustrate the principles and implementation methods of this application. The description of the above embodiments is intended only to facilitate understanding of the method and core concepts of this application. It should be noted that those skilled in the art may make various improvements and modifications to this application without departing from the principles of this application, and such improvements and modifications also fall within the scope of protection of the claims of this application.

Claims

1. A method for converting an encryption mode, characterized in that: The encryption mode conversion is completed inside the storage device, including: Receiving an encryption mode conversion instruction sent by a verified data processing device, and obtaining authentication information and a key configuration table carried in the encryption mode conversion instruction; Obtaining current key information according to the authentication information, and obtaining at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table; Allocating a target storage block to the source storage block from currently available storage resources, and generating a conversion record corresponding to the source storage block and the target storage block; Decrypting the data of the source storage block according to the current key information to obtain plaintext data, and encrypting the plaintext data using the target key information and writing the encrypted data into the target storage block; Based on the fact that the plaintext data has been stored in the target storage block, the logical address of the source storage block is mapped to point to the target storage block, and the conversion record is updated.

2. The encryption mode conversion method according to claim 1, wherein: The encryption mode conversion method further includes: Based on the fact that the plaintext data is not stored in the target storage block, obtaining a plurality of conversion records, and reading transaction statuses in the plurality of conversion records; According to the transaction state, filtering out conversion records in a suspended state; wherein, when the plaintext data is not stored in the target storage block, the transaction state in the conversion record is a suspended state; At least one transition record of the suspended state is obtained, and a target storage block in the transition record of the suspended state is marked as invalid.

3. The encryption mode conversion method according to claim 1, wherein: Before obtaining the authentication information and key configuration table carried by the encryption mode conversion instruction, the method further includes: Obtaining signature information in the encryption mode conversion instruction and obtaining a stored data processing device certificate; verifying the signature information according to the data processing device public key in the data processing device certificate; If the signature information is verified successfully, the authentication information and key configuration table carried by the encryption mode conversion instruction are obtained.

4. The encryption mode conversion method according to claim 1 or 3, characterized in that: The obtaining of the authentication information and key configuration table carried by the encryption mode conversion instruction includes: The stored storage device private key is obtained, and the encrypted information carried by the encryption mode conversion instruction is decrypted according to the storage device private key to obtain the authentication information and the key configuration table.

5. The encryption mode conversion method according to claim 1, wherein: The allocating a target storage block to the source storage block and generating a conversion record corresponding to the source storage block and the target storage block includes: Select an unused storage block from the spare storage block pool as a target storage block; Writing a conversion record in a preset non-volatile log area according to the source storage block and the target storage block; The conversion record includes at least one of a source storage block identifier, a target storage block identifier, a key identifier corresponding to a target encryption mode, or setting a transaction state to a suspended state.

6. The encryption mode conversion method according to claim 1, wherein: The obtaining of current key information according to the authentication information includes: Determining a current encryption mode according to the current key information; Based on the current encryption mode and the authentication information, obtaining a key encryption key through a preset key derivation algorithm, and calculating a current hash value corresponding to the key encryption key; If the current hash value is the same as the preset reference hash value, the key encryption key is used to decrypt the medium encryption key encrypted and stored in the non-volatile storage area to obtain a first key corresponding to the current encryption mode.

7. The encryption mode conversion method according to claim 6, characterized in that: The step of obtaining, according to the key configuration table, at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block includes: Reading and parsing the key configuration table, extracting the address start value and address end value of at least one namespace to be converted, and obtaining target key information corresponding to the namespace to be converted; According to the address start value and the address end value of the namespace to be converted, the source storage block is obtained from the namespace to be converted according to a preset acquisition order; Wherein, the namespace to be converted includes one or more source storage blocks; Decrypting and acquiring plaintext data in the source storage block using a first key based on the source storage block, and storing the plaintext data in a preset secure buffer; Using a preset cyclic redundancy check algorithm, calculate the current check value of the plaintext data, obtain a preset reference check value corresponding to the plaintext data, and obtain the current check count corresponding to the source storage block; If the number of verifications corresponding to the source storage block is less than a preset number threshold, and the current verification value is consistent with the reference verification value, then the source storage block is recorded as having passed the integrity check, and based on the correspondence between the source storage block and the namespace to be converted and according to the target key information corresponding to the namespace to be converted, the target encryption mode corresponding to the source storage block is determined, and a second key corresponding to the target encryption mode is obtained; or, If the number of verification times corresponding to the source storage block is less than a preset number threshold, and the current verification value is inconsistent with the reference verification value, the first key is used to re-decrypt and obtain the plaintext data in the source storage block, and the current verification value of the plaintext data is calculated, and the current number of verification times corresponding to the source storage block is updated, and the current verification value and the reference verification value are re-verified; or If the number of verifications corresponding to the source storage block is equal to or greater than a preset number threshold, and the current verification value is inconsistent with the reference verification value, the source storage block is marked as damaged and added to a preset damaged block list.

8. The encryption mode conversion method according to claim 7, characterized in that: The step of decrypting the data of the source storage block according to the current key information to obtain plaintext data, and encrypting the plaintext data using the target key information and then writing the encrypted data into the target storage block includes: Reading data content in the source storage block, and decrypting the data using the first key through a preset hardware encryption engine according to a current encryption mode to obtain plaintext data in the source storage block; Based on the target encryption mode, according to the second key, a preset encryption algorithm is used to encrypt the plaintext data, and the encrypted plaintext data is written into the target storage block.

9. The encryption mode conversion method according to any one of claims 1 to 3, characterized in that: The updating of the conversion record includes: The transaction status in the conversion record is marked as submitted, and the source storage block is added to a queue to be recycled.

10. The encryption mode conversion method according to any one of claims 1 to 3, characterized in that: The encryption mode conversion method further includes: Receiving a startup authentication instruction sent by a data processing device, and obtaining a data processing device certificate carried in the startup authentication instruction; Obtaining a stored public key of the organization, and using the public key of the organization to verify the data processing device certificate; If the data processing device certificate is verified, the data processing device certificate is stored and a random number of a preset length is generated; The current random number is different from the random numbers corresponding to the previous authentication instructions. Sending the storage device certificate and the random number to the data processing device, so that the data processing device performs storage device certificate verification according to the storage device certificate and the random number; Receiving a storage device certificate verification pass instruction sent by the data processing device, and obtaining signature information carried in the storage device certificate verification pass instruction; Obtaining a public key of the data processing device according to the stored data processing device certificate, and verifying the signature information using the public key of the data processing device; If the signature information verification fails, a verification failure message is sent to the data processing device; or, If the signature information is verified successfully, the data processing device is marked as a verified data processing device.

11. A method for converting an encryption mode, characterized in that: The encryption mode conversion is completed inside the storage device, including: Obtaining address information of at least one namespace to be converted, and determining a second key corresponding to the namespace to be converted according to a target encryption mode; Generate a key configuration table according to address information of at least one namespace to be converted and a second key corresponding to at least one target encryption mode; Obtain preset authentication information, and generate and send an encryption mode conversion instruction carrying the authentication information and the key configuration table to a storage device, so that the storage device receives the encryption mode conversion instruction sent by the verified data processing device and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction; obtain current key information based on the authentication information, and obtain at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block based on the key configuration table; allocate a target storage block to the source storage block from currently available storage resources, and generate a conversion record corresponding to the source storage block and the target storage block; decrypt the data of the source storage block based on the current key information to obtain plaintext data, and use the target key information to encrypt the plaintext data and write it to the target storage block; based on the fact that the plaintext data has been stored in the target storage block, map the logical address of the source storage block to point to the target storage block, and update the conversion record.

12. The encryption mode conversion method according to claim 11, characterized in that: The encryption mode conversion method further includes: Obtaining at least one conversion record of a non-volatile log area in the storage device; Acquire address information of at least one unconverted namespace based on address information of at least one namespace to be converted recorded in the key configuration table and based on the at least one conversion record; According to the key configuration table, obtaining the second key corresponding to the untranslated namespace, and generating a new key configuration table according to the address information of the at least one untranslated namespace and the second key corresponding thereto; Preset authentication information is obtained, and an encryption mode conversion instruction carrying the authentication information and a new key configuration table is generated and sent to the storage device.

13. The encryption mode conversion method according to claim 11, characterized in that: Before sending the encryption mode conversion instruction carrying the authentication information and the new key configuration table to the storage device, the encryption mode conversion method further includes: Sending a startup authentication instruction carrying the data processing device certificate to the storage device, so that the storage device verifies the data processing device certificate; Receiving a storage device certificate and a random number sent by the storage device; Verifying the storage device certificate according to the organization public key in the stored organization public key certificate; If the storage device certificate is verified successfully, the random number is signed by the data processing device private key to obtain signature information, and a storage device certificate verification successful instruction carrying the signature information is sent to the storage device; or If the storage device certificate fails to be verified, a start authentication instruction carrying the data processing device certificate is resent to the storage device.

14. A method for converting an encryption mode, characterized in that: The encryption mode conversion is completed inside the storage device, including: The data processing device obtains address information of at least one namespace to be converted, and obtains a second key corresponding to the namespace to be converted according to a target encryption mode; The data processing device generates a key configuration table according to address information of at least one namespace to be converted and a second key corresponding to at least one target encryption mode; The data processing device obtains preset authentication information, generates and sends an encryption mode conversion instruction carrying the authentication information and the key configuration table to the storage device; The storage device receives the encryption mode conversion instruction sent by the authenticated data processing device, and obtains the authentication information and key configuration table carried in the encryption mode conversion instruction; The storage device obtains current key information according to the authentication information, and obtains at least one source storage block that passes the integrity check and at least one target key information corresponding to the source storage block according to the key configuration table; The storage device allocates a target storage block to the source storage block from currently available storage resources, and generates a conversion record corresponding to the source storage block and the target storage block; The storage device decrypts the data of the source storage block according to the current key information to obtain plaintext data, and uses the target key information to encrypt the plaintext data and write the encrypted data into the target storage block; Based on the fact that the plaintext data has been stored in the target storage block, the storage device maps the logical address of the source storage block to point to the target storage block, and updates the conversion record.

15. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the encryption mode conversion method according to any one of claims 1 to 10 or claims 11 to 13 when executing the computer program.

Images