Encryption mode conversion method and electronic equipment

By receiving encryption mode conversion instructions on the storage device side, acquiring and updating key information, decrypting and reencrypting data, and updating logical address mapping, the problem of poor data security in encryption mode conversion is solved, and the full ciphertext protection of data and the reliability of the conversion process is realized.

CN120372667AActive Publication Date: 2025-07-25INSPUR SUZHOU INTELLIGENT TECH CO LTD
View PDF 8 Cites 0 Cited by

Patent Information

Application Number
CN202510855559.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-06-24
Publication Date
2025-07-25
Estimated Expiration
2045-06-24

AI Technical Summary

Technical Problem

During the encryption mode conversion process, data security is poor, especially the security risks caused by long-term residency in the host memory are difficult to solve.

Method used

Receive encryption mode conversion instructions on the storage device side, obtain the current key and target key through authentication information, decrypt and re-encrypt the data, and update the logical address map to ensure the atomicity and traceability of the conversion operation.

Benefits of technology

It realizes the full ciphertext protection of data during the conversion process, improves data security and reliability, and avoids the exposure of plaintext data in the host memory.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120372667A_ABST
    Figure CN120372667A_ABST
Patent Text Reader

Abstract

The invention discloses an encryption mode conversion method and electronic equipment, and relates to the technical field of computers, and the method comprises the following steps: receiving authentication information and a key configuration table sent by verified data processing equipment; obtaining current key information according to the authentication information, and obtaining a source storage block and target key information according to a key configuration table; it is ensured that only the trusted device can initiate the conversion operation; 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; decrypting the source storage block according to the current key information, re-encrypting the source storage block by using a target key, and writing the re-encrypted source storage block into a target storage block; on the basis that the plaintext data is stored in the target storage block, mapping the logic address of the source storage block to the target storage block, and updating the conversion record, so that the atomicity, traceability and conversion consistency of the conversion operation are realized; the problem that the data security is poor in the conversion process is solved, and the technical effect of improving the data security and reliability is achieved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

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

[0002] With the continuous improvement of cloud computing and enterprise data requirements, the encryption mode on solid-state drives has become a key link in the end-to-end data protection chain. The currently widely used self-encrypting mode (Self-Encrypting Drive, abbreviated as SED) encrypts data as a whole through a built-in single media key. However, when a solid-state drive is shared by multiple hosts or multiple tenants (virtual machines, containers, function instances, etc.) on a single host, the single key cannot distinguish the access boundaries of different tenants, and any authorized party may decrypt all data. To improve the isolation granularity, the self-encrypting mode is gradually being migrated to the independent key mode for input / output operations (i.e., Key-per-I / O mode), that is, an independent key is selected for each input / output.

[0003] In the encryption mode conversion method of the related art, usually, the host side initiates a read / write command, reads the entire disk ciphertext into the host memory, decrypts it with the original encryption mode key to obtain the plaintext, and then re-encrypts it one by one according to the Key-per-I / O key pool and writes it back to the solid-state drive. Although it is simple to implement, the plaintext stays in the host memory for a long time during the whole process, and the data security is difficult to guarantee. Based on this, there is an urgent need for an encryption mode conversion method to solve the technical problem of poor data security during the encryption mode conversion. Summary of the Invention

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

[0005] In a first aspect, this application provides an encryption mode conversion method, including:

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

[0007] Obtaining the 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 for the source storage block, and generating a conversion record corresponding to the source storage block and the target storage block;

[0009] Decrypting the data of the source storage block according to the current key information to obtain plaintext data, and encrypting the plaintext data with the target key information and writing it into the target storage block;

[0010] 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.

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

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

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

[0014] Obtain the 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 current key information, and according to the key configuration table, 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; allocate a target storage block for the source storage block, and generate a conversion record corresponding to the source storage block and the target storage block; according to the current key information, decrypt the data of the source storage block to obtain the plaintext data, and use the target key information to encrypt the plaintext data and write it into 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.

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

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

[0017] A key acquisition module, configured to obtain the 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 for the source storage block, and generate a conversion record corresponding to the source storage block and the target storage block;

[0019] An encryption processing module, configured 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] A transaction update module, configured to map the logical address of the source storage block to the target storage block based on that the plaintext data has been stored in the target storage block, and update the conversion record.

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

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

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

[0024] An instruction sending module, configured to acquire 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 acquires the authentication information and the key configuration table carried by the encryption mode conversion instruction; acquire the current key information according to the authentication information, and acquire 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; allocate a target storage block for 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 according to the current key information to obtain plaintext data, and encrypt the plaintext data with the target key information and write it into the target storage block; map the logical address of the source storage block to the target storage block based on that the plaintext data has been stored in the target storage block, and update the conversion record.

[0025] In a fifth aspect, the present application further provides an electronic device, including: a memory, configured to store a computer program; a processor, configured to implement the steps of the encryption mode conversion method according to any one of the first aspect or the second aspect when executing the computer program.

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

[0027] In a seventh aspect, the present application further provides a computer program product, including a computer program, and when the computer program is executed by a processor, the steps of the encryption mode conversion method according to any one of the first aspect or the second aspect are implemented.

[0028] This application ensures that only trusted devices can initiate the conversion operation by receiving the encryption mode conversion instruction sent by the verified data processing device and parsing the authentication information and key configuration table; obtains the current key information and target key information according to the authentication information and key configuration table, and only performs the conversion on the data blocks that pass the integrity check, ensuring the integrity and credibility of the data to be converted. Assigns a new target storage block to each source storage block and generates a conversion record, realizing the atomicity and traceability of the conversion operation. Effectively completes the encryption reconstruction of the data by decrypting the data of the source storage block and re-encrypting it with the target key and writing it to the new storage location. After the plaintext data is successfully stored in the target storage block, updates the logical address mapping relationship and updates the conversion record to ensure that subsequent accesses accurately point to the new location and maintain conversion consistency. Therefore, it can solve the problem of poor security such as plaintext leakage during the conversion process in the related art, and achieve the technical effect of improving the security and reliability of the data during the conversion process. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] To more clearly illustrate the embodiments of the present application, the following will briefly introduce the drawings required for use in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0030] Figure 1 Flow schematic of the encryption mode conversion method provided by the embodiment of the present application Figure 1 ;

[0031] Figure 2 Flow schematic diagram of the method of the recovery mechanism provided by the embodiment of the present application;

[0032] Figure 3 Flow schematic of the encryption mode conversion method provided by the embodiment of the present application Figure 2 ;

[0033] Figure 4 Interaction timing diagram of the encryption mode conversion provided by the embodiment of the present application;

[0034] Figure 5 Interaction timing diagram of the device verification provided by the embodiment of the present application;

[0035] Figure 6 Structural schematic diagram of the storage device provided by the embodiment of the present application;

[0036] Figure 7 Structural schematic diagram of the data processing device provided by the embodiment of the present application;

[0037] Figure 8 Structural schematic diagram of the electronic device provided by the present application. Detailed implementation manners

[0038] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application.

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

[0040] In view of the problems in the related art, the inventive concept of the present 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 the 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 completely completed inside the device: first, decrypt the data of the source storage block to obtain the plaintext data, then directly use the second key in the device to complete re-encryption and write it into the target storage block, and then update the logical address mapping and record the conversion operation. In this way, the problem of the exposure of plaintext data on the host side is avoided, and at the same time, the atomicity of the conversion is ensured through transaction control, and an encryption mode conversion mechanism for a high-security requirement environment is constructed.

[0041] In order to enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific implementation manners.

[0042] Figure 1 Flow schematic of the encryption mode conversion method provided for the embodiments of the present application Figure 1 , as Figure 1 shown, includes:

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

[0044] In this embodiment, an encryption mode conversion instruction sent by a verified data processing device is received. The encryption mode conversion instruction is a trigger signal for initiating an encryption mode switching process. It should be noted that it is necessary to ensure the credibility of the source of the encryption mode conversion instruction to prevent unauthorized devices from triggering data encryption operations. That is, it is confirmed that the data processing device sending the encryption mode conversion instruction is a verified device. After confirming the identity of the device sending the encryption mode conversion instruction, the information carried in the encryption mode conversion instruction is obtained, specifically including authentication information and a key configuration table. The authentication information is used to confirm the credibility of the relevant information of this conversion operation and the integrity of the data, etc. For example, the authentication information may include a device identifier or a security credential for subsequent verification. The key configuration table is used to define the keys required during the encryption mode conversion process and the applicable scope of the encryption mode conversion. On the premise of ensuring the credibility of the data processing device source, this embodiment establishes the basic context information required for this encryption mode conversion task, provides a data basis and guarantee for subsequent key acquisition, data decryption and encryption, address mapping update, etc., realizes the reliable start of the entire conversion process, and improves the security during the encryption policy change process.

[0045] S12. According to the authentication information, obtain the current key information, and according to the key configuration table, 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.

[0046] In this embodiment, after receiving the encryption mode conversion instruction, the current key information is extracted based on the authentication information. The current key information is used to identify the data decryption credentials in the currently adopted encryption mode and is a fundamental component in the subsequent data parsing process. The authentication information, as an input parameter for key access control, ensures that the obtained key information is only used within the authorized context. During the process of parsing the authentication information, access permission verification is usually performed in combination with security policies to ensure the security of key acquisition. After the extraction of the current key information is completed, the key configuration table is further parsed. The key configuration table stores the mapping relationship between the source data blocks and the target keys and marks the source storage blocks that pass the verification in the integrity check. It is used to confirm that the data of the source storage blocks has not been tampered with and is in a stable state. Based on the key configuration table, the device filters out one or more source storage blocks that have passed the integrity check and further determines the target key information corresponding to each source storage block. The target key information refers to the key credentials for encrypting data in the target encryption mode. Through this embodiment, an effective binding between the source data blocks and the target encryption policy is achieved, and on the basis of maintaining the original data integrity, the preparation work for switching the key resources to the new encryption mode is completed. Through the authentication-driven key identification mechanism and the parsing of the structured configuration table, the certainty of key parsing and the accuracy of target matching are improved, ensuring the consistency of the encryption policies before and after data conversion, and enhancing the accuracy of key mapping and the security of conversion.

[0047] S13, allocate a target storage block for the source storage block and generate a conversion record corresponding to the source storage block and the target storage block.

[0048] In this embodiment, in order to ensure that the source data has an independent storage space in the target encryption mode, an unused target storage block is allocated for each source storage block from the currently available storage resources. It should be noted that the target storage block should meet the consistency with the source storage block in terms of parameters such as capacity and alignment method, and its physical address does not overlap with the source storage block to ensure that the source data will not be overwritten or interfered when data is 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 allocation is completed, a conversion record will be constructed to record the status information during the data migration process. Exemplarily, the conversion record may include the association relationship between the source storage block and the corresponding target storage block, and may further include the target encryption mode identifier, the target key identifier for data encryption, the transaction execution status, and the timestamp information. The generation of the conversion record preferably uses an atomic operation to write to the non-volatile log area, and has recoverability and consistency in the scenarios of device power-off or fault recovery. This embodiment realizes the metadata preparation work in the data encryption mode switching operation by allocating independent target storage blocks for the source storage blocks and establishing conversion records. The separate block allocation method ensures the logical independence of the source data and the target data, and provides support for subsequent data decryption, encryption, and address remapping. At the same time, as the meta-information of the encryption mode conversion process, the conversion record provides guarantee for transaction integrity verification, exception recovery, and status reconstruction. Therefore, the problem of lack of transaction tracking and fault tolerance in traditional data migration can be solved, and the security and stability of the encryption mode conversion process can be improved.

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

[0050] In this embodiment, according to the current key information, the ciphertext data in the source storage block is decrypted. 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, so as to ensure that the decryption operation can restore accurate and undamaged plaintext data. The decryption operation is usually completed in a secure execution environment inside the device, reducing the occurrence of the problem of plaintext exposure in the external buffer of the system 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 rule of the target key information are different from the current encryption mode, and the format and encryption parameters specified by the target encryption policy need to be adapted during encryption. To prevent the intermediate plaintext from being accessed by external processes, this encryption process is also preferably performed in a hardware encryption engine. The ciphertext data after encryption is then written into the pre-allocated target storage block. This embodiment realizes the migration of the encryption policy of data from the old encryption mode to the new encryption mode through the decryption of source data based on the current key information and the re-encryption process based on the target key information. Throughout the process, through a closed data processing path, the whole-process ciphertext protection during data conversion is ensured, improving the data processing security and encryption conversion consistency.

[0051] S15. Based on 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.

[0052] In this embodiment, after the plaintext data has been successfully encrypted and written into the target storage block, to ensure the consistency of the data access path and the traceability of the state, it is necessary to update the storage mapping relationship and related records. First, based on the 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-layer 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. In the encryption mode conversion, the logical address remains unchanged, while the physical address switches from the source storage block to the target storage block, thus realizing the update of the underlying data encryption policy without affecting the access logic of the upper-layer application. Subsequently, an update operation is performed on the conversion record. This update operation needs to meet atomicity, that is, the record update must be performed only after the mapping relationship is successfully modified, ensuring that the conversion state of each data block can be accurately traced back in case of abnormal interruption or fault recovery. This embodiment makes all subsequent read and write requests automatically access the data encrypted with the target encryption mode through the remapping of the logical address, ensuring the consistency of the data access path and the encryption state. At the same time, by updating the conversion record, the status tracking and error recovery of each conversion can be realized, improving the controllability and security during the encryption mode conversion task.

[0053] Figure 2Schematic flowchart of the recovery mechanism provided by the embodiments of the present application. On the basis of the above embodiments, as Figure 2 shown, the encryption mode conversion method further includes:

[0054] S21, based on that the plaintext data is not stored in the target storage block, obtain multiple conversion records, and read the transaction status in the multiple conversion records;

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

[0056] S23, obtain at least one conversion record in the pending state, and mark the target storage block in the conversion record in the pending state as invalid.

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

[0058] Subsequently, traverse and filter the transaction status fields in the above conversion records to identify the conversion records currently in the pending state. The pending state is usually used to identify tasks that were not fully completed due to system interruption, power failure, or abnormal operations during the previous encryption mode conversion. This state is set when the target data has not been written, and when the write is successful, it is no longer in the pending state because the conversion record is updated. For one or more conversion records in the pending state that are filtered out, further extract the associated target storage block identifiers, and re-mark these target storage blocks as invalid states. The invalid marking of the target storage block can not only prevent subsequent read and write operations from accessing incomplete or incorrect data, but also be reused as a reusable resource in the space recycling mechanism. This invalid marking operation is usually accompanied by processes such as flag bit update, space recycling registration, and log record synchronization to ensure data consistency and the traceability of operations. Through the timely identification and processing of the conversion records in the pending state in this embodiment, the cleaning of abnormal conversion tasks and resource recycling are realized, effectively improving the fault tolerance ability and storage space utilization rate of the encryption mode conversion method. At the same time, it also provides a clear starting point and judgment basis for subsequent execution of recovery retry or alternative conversion operations.

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

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

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

[0062] S103, if the signature information is verified to be passed, obtain the authentication information and the key configuration table carried in the encryption mode conversion instruction.

[0063] In one embodiment, after receiving the encryption mode conversion instruction, the signature information is first parsed and extracted from the instruction. This signature information is a digital digest generated by the data processing device using its private key to encrypt the instruction content, and has the characteristics of anti-tampering and anti-forgery. Subsequently, the pre-registered and authenticated data processing device certificate is obtained, which contains the identification information of the data processing device and the data processing device public key for verifying the signature. Based on the extracted data processing device public key, the above signature information is verified. This verification process usually uses a preset signature algorithm, such as the public key encryption algorithm (Rivest–Shamir–Adleman algorithm, abbreviated as: RSA), etc., to compare the decrypted signature to determine whether the signature is valid. If the verification fails, it indicates that the instruction content may be tampered with or the device identity is not authorized, and the subsequent execution process is aborted and a security warning is issued. If the signature information is verified to be passed, it is confirmed that the content of the current encryption mode conversion instruction has not been tampered with and comes from a trusted data processing device. On this basis, the authentication information and the key configuration table carried in the encryption mode conversion instruction are obtained. Through the above verification steps based on the signature mechanism, this embodiment ensures the integrity of the instruction and the trustworthiness of the device for the encryption mode conversion operation, constructs a 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, for the above step S11 of obtaining the authentication information and the key configuration table carried in the encryption mode conversion instruction, a specific implementation manner is provided as follows:

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

[0066] In this embodiment, first, the pre-stored private key of the storage device is read from the non-volatile storage area. This private key is usually isolated and protected by a Hardware Security Module (HSM) or a Trusted Execution Environment (TEE) to prevent unauthorized access or extraction. After reading, according to the encryption information carried in the encryption mode conversion instruction, the private key is used to perform a decryption operation. The encryption information is generally encrypted using a public-private key system such as RSA or ECDSA, and the decryption process can ensure that only authorized devices can restore its content. Through this decryption process, the authentication information and the key configuration table carried by the encryption mode conversion instruction are obtained. By storing the private key in a secure environment and decrypting the information carried by external instructions with this private key, the integrity and confidentiality of the key configuration table and the authentication information are guaranteed, thus enhancing the security and reliability of the encryption mode conversion process.

[0067] In one embodiment, a specific implementation manner is provided for the above step S13. On the basis of the above embodiment, it includes:

[0068] S131, select an unused storage block from the spare storage block pool as the target storage block;

[0069] S132, write a conversion record in the pre-set non-volatile log area according to the source storage block and the target storage block; wherein, the conversion record at least includes 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 the pending state.

[0070] In this embodiment, a currently unused physical storage block is selected from the spare storage block pool as the target storage block. The spare storage block pool is a set of replaceable blocks reserved inside the current storage device (such as a solid-state drive) for providing available space when the original block is damaged, worn, or migrated, ensuring that the device has redundancy and sustainable write capabilities. The selected target storage block needs to meet the idle state and have write permission and structural integrity to reduce the probability of subsequent migration failure or data loss. After selecting the target storage block, a conversion record is written in the pre-set non-volatile log area. The non-volatile log area is usually located in a specific reserved area in the flash memory and has the power-off retention ability to record key metadata information to support breakpoint recovery and transaction consistency. The writing of this log record provides atomicity guarantee for the encryption mode conversion process. Even if a power-off or failure occurs during the migration process, the operation can be accurately rolled back or retried according to the information in the log record, preventing data mapping chaos or state anomalies.

[0071] The conversion record should contain 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 undergoing the 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 the encrypted data; Third, the key identifier corresponding to the target encryption mode, which is used to represent the encryption key index or number that the target storage block should use to ensure the consistency of data encryption operations and key configurations; Fourth, the transaction status field, which can be set to the pending 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 a status confirmation process in the future. By recording these fields, the status of the migration process can be accurately located in subsequent operations, realizing the closed-loop management of the data block mapping relationship and the key application strategy, and effectively improving the controllability and fault tolerance of the overall conversion process.

[0072] In a specific embodiment, for step S12 above, according to the authentication information, the current key information is obtained, and a specific embodiment is provided again. Based on the above embodiment, it includes:

[0073] S1211, determine the current encryption mode according to the current key information;

[0074] S1212, based on the current encryption mode, according to the authentication information, through a preset key derivation algorithm, obtain the key encryption key and calculate the 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, then use the key encryption key to decrypt the medium encryption key encrypted and stored in the non-volatile storage area to obtain the first key corresponding to the current encryption mode.

[0076] In this embodiment, the encryption mode currently adopted by the storage device is determined according to the current key information. The current key information usually includes the identifier of the currently used encryption algorithm, the key length information, and the configuration fields related to the current encryption policy. By parsing these fields, the current encryption mode can be determined, such as being in one of different encryption policies like the Self-Encrypting Drive (SED) mode. This ensures that subsequent key processing operations can be carried out according to the correct encryption mode, reducing problems such as key mismatches or data decryption failures caused by mode confusion. After identifying the current encryption mode, according to the authorization parameters in the authentication information, such as the device identifier, permission token, user password, etc., a Key Encryption Key (KEK) is derived through a preset key derivation algorithm. The key derivation algorithm is usually a structured algorithm based on a cryptographic hash function, such as HKDF (HMAC-based Key Derivation Function). The authentication information, as one of the inputs of the derivation algorithm, ensures that the generated KEK has device binding and authentication context consistency. The derived KEK is used to further protect the actually stored encryption key, preventing the Media Encryption Key (MEK) from being directly exposed. Subsequently, a hash algorithm (such as SHA-256) is used to operate on this key encryption key to generate the current hash value for key integrity verification.

[0077] Next, the calculated current hash value is compared with the reference hash value pre-stored in the secure storage area. If the current hash value is the same as the reference hash value, it indicates that the key encryption key has not been tampered with or replaced, and its derivation process is trustworthy. On this basis, the key encryption key is used to decrypt the media encryption key encrypted and stored in the non-volatile storage area to recover the first key corresponding to the current encryption mode. Through the above processing process, it is ensured that the acquisition of the first key has the basis of authentication guarantee 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 start value and end value of the address of at least one namespace to be converted, and obtain the target key information corresponding to the namespace to be converted;

[0080] S1222. Obtain a source storage block from the namespace to be converted according to the preset acquisition order based on the start address value and the end address value of the namespace to be converted; 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. Use a preset cyclic redundancy check algorithm to calculate the current check value of the plaintext data, obtain the 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 check count corresponding to the source storage block is less than the preset count threshold and the current check value is the same as the reference check value, record that the source storage block passes the integrity check, and based on the corresponding relationship between the source storage block and the namespace to be converted, determine the target encryption mode corresponding to the source storage block according to the target key information corresponding to the namespace to be converted, and obtain the second key corresponding to the target encryption mode.

[0084] S1226. If the check count corresponding to the source storage block is less than the preset count threshold and the current check value is not the same as the reference check value, use the first key to decrypt and obtain the plaintext data in the source storage block again, calculate the current check value of the plaintext data, update the current check count corresponding to the source storage block, and re-verify the current check value and the reference check value.

[0085] S1227. If the check count corresponding to the source storage block is equal to or greater than the preset count threshold and the current check value is not the same as the reference check value, mark the source storage block as damaged and add the source storage block to the preset damaged block list.

[0086] In this embodiment, to ensure that only valid data blocks are subjected to the conversion operation, it is necessary to first read and parse the key configuration table. The key configuration table records the boundary information of multiple namespaces to be converted, including the start address value and the end address value of each namespace, as well as the corresponding target key information. A namespace is a continuous region in the logical address space, usually used for partitioning and managing 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, source storage blocks are extracted from the specified namespace according to the preset acquisition order. The acquisition order can be set according to address sorting, conversion priority, or other scheduling strategies to ensure orderly block-level data processing during the encryption mode conversion. Through the structured reading order, the coherence and efficiency of data processing are achieved.

[0087] For the obtained source storage block, use the first key to decrypt it to obtain the plaintext data. The first key is the key used in the current encryption mode, and its decryption operation can be completed by an embedded security module or a hardware encryption engine to improve the processing speed and enhance security. The decrypted plaintext data is temporarily stored in a secure buffer, which is 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. The integrity check uses a preset Cyclic Redundancy Check (CRC) algorithm to generate a check value by calculating the data and compares it with the pre-saved reference check value. The current check count of each source storage block is also recorded to control the retry count and reduce resource waste.

[0088] If the check values are consistent, indicating that the data is valid, record that the source storage block has passed the integrity check, and based on the mapping relationship between the namespace and the source storage block, find the corresponding target key information. The target key information is used to deduce the target encryption mode and obtain the second key accordingly, preparing for subsequent re-encryption. If the check values are inconsistent and the check count has not reached the preset threshold, decrypt the source storage block again using the first key, recalculate and compare the check values, and update the check attempt count for this block, implementing a fault tolerance mechanism for data verification.

[0089] Furthermore, when the integrity verification still cannot be passed after the check count reaches or exceeds the threshold, mark the source storage block as damaged and add it to the damaged block list. The damaged block list is used to record the storage units with data anomalies, so as not to perform conversion processing or data writing on them, thereby ensuring the reliability and data consistency of the overall encryption mode conversion process. This embodiment realizes a data integrity judgment mechanism on the device side by introducing a cyclic redundancy check mechanism and a 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, obtain the source storage block according to the preset acquisition order for the above steps; here is a specific implementation method. Based on the above embodiment, it includes:

[0091] According to multiple source storage blocks in the namespace to be converted, obtain the access frequency of each source storage block, and sort the multiple source storage blocks in descending order according to the access frequency, and perform the encryption mode conversion of the source storage blocks in descending order.

[0092] In this embodiment, according to multiple source storage blocks in the namespace to be converted, historical access frequency information of each source storage block is obtained. The access frequency can be obtained by recording the number of read and write operations of each storage block within a preset time window, or extracted based on auxiliary information such as I / O counters, access timestamps, and heat flags maintained by the underlying storage device. This information reflects the activity level of each storage block, thus 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 completed, according to the determined order, the encryption mode conversion operation is preferentially performed on the source storage blocks with higher access frequencies, that is, data migration and encryption reconstruction are sequentially performed in descending order of access heat. Through this priority processing mechanism, the conversion of critical hot data can be completed as soon as possible in the initial stage, enabling the high-frequency access area to be released from the old encryption mode as early as possible and benefiting from higher-granularity key isolation and security guarantee under the new encryption mode. At the same time, the security exposure window of hot data due to delayed conversion is also reduced during the conversion process. Therefore, this strategy takes into account both data security, operating efficiency, and resource scheduling priority.

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

[0094] S141, read the data content in the source storage block, and according to the current encryption mode, use a preset hardware encryption engine to decrypt with a first key to obtain the plaintext data in the source storage block;

[0095] S142, based on the target encryption mode, according to a second key, use 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 the complete migration and confidentiality protection of data under different encryption modes, it is necessary to read and re-encrypt the ciphertext data in the source storage block. First, read the data content in the source storage block and transfer it to the hardware encryption engine through direct memory access (DMA). During the reading process, parameters such as block address and offset can be combined to determine the required data range, ensuring that the obtained ciphertext data is exactly the same as the data corresponding to the logical address, and reducing data misalignment or omission. According to the current encryption mode (such as self-encryption mode), decrypt the read data through the hardware encryption engine. The hardware encryption engine is a dedicated circuit module integrated in the storage device, with high decryption speed and security, which can prevent the plaintext data from being exposed to the external environment via the host memory, thus reducing the risk of being unreasonably read. Decrypt the data through the hardware engine in combination with the first key to obtain the plaintext data in the source storage block. Or, read and obtain the plaintext data that has been decrypted by the first key from the security buffer. The specific acquisition method can be flexibly set according to actual needs to achieve the purpose of obtaining the plaintext data.

[0097] Next, based on the target encryption mode, re-encrypt the plaintext data. Among them, the target encryption mode can be the Key-per-I / O mode, that is, it is required that each input / output operation uses an independent key to ensure data isolation. For this reason, according to the second key matching the target encryption mode, use a preset encryption algorithm (such as symmetric encryption algorithms like AES, SM4, etc.) to perform an encryption operation on the plaintext data. After encryption, write the generated encrypted data into the pre-allocated target storage block to complete the secure migration of data under the new encryption mode. This embodiment encapsulates the reading, decryption, re-encryption, and writing operations into an inseparable logical process, achieving the maintenance of data integrity and confidentiality guarantee during the encryption mode conversion. Therefore, it can solve the problem of low data security caused by the transfer of plaintext at the host end in the traditional solution, and achieve the encryption mode conversion under high security. And it should be further noted that after the second key is used, mark the corresponding target key information in the key configuration table as associated, so that the current key has been used, reducing the misuse of keys without transactions.

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

[0099] S151, mark the transaction status in the conversion record as the committed status, and add the source storage block to the pending recovery queue.

[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, update operations are performed on the relevant conversion records and storage block status. First, update the transaction status field in the corresponding conversion record recorded in the non-volatile log area from the pending state to the committed state. The transaction status field is a control field used to identify the current conversion process stage, and the change of its value needs to conform to the preset atomic transaction rules, that is, it is marked as the committed state only after the data is successfully written and the address mapping is switched. The update of this status enables the skipped of the completed transaction records when the restart recovery process is executed subsequently, improving the recovery efficiency and reducing duplicate encryption or incorrect rollback.

[0101] Subsequently, add the source storage block corresponding to the conversion record to the queue to be recycled. The queue to be recycled is a logical set used to manage the data source blocks that have completed re-encryption. Its goal is to release physical space on the premise of ensuring that the data no longer depends on the old blocks. By moving the source block into this queue, the resource recycling mechanism can be uniformly scheduled, such as asynchronous erasure, write-erase balance or recycling operations, thereby improving the overall performance. This embodiment realizes the resource closed-loop and state consistency maintenance in the encryption mode conversion process by clarifying the update of the conversion state and the trigger 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, receive the start authentication instruction sent by the data processing device, and obtain the data processing device certificate carried by the start authentication instruction;

[0104] S1002, obtain the stored institutional public key, and use the institutional public key to verify the data processing device certificate;

[0105] S1003, if the data processing device certificate is verified to be passed, store the data processing device certificate, and generate a random number with a preset length; wherein, the current random number is different from the random numbers corresponding to the previous multiple start authentication instructions;

[0106] S1004, send 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, receive the storage device certificate verification passed instruction sent by the data processing device, and obtain the signature information carried in the storage device certificate verification passed instruction;

[0108] S1006. Obtain the public key of the data processing device according to the stored data processing device certificate, and use the public key of the data processing device to verify the signature information;

[0109] S1007. If the signature information verification fails, send a verification failure message to the data processing device;

[0110] S1008. If the signature information verification passes, mark the data processing device as a verified data processing device.

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

[0112] If the verification passes, store the data processing device certificate in the preset certificate buffer area and generate a random number corresponding to the current session. The random number has a fixed length and ensures that the currently generated random number is different from the random numbers used in the previous multiple startup authentication instructions. Reduce the data security problems caused by random number reuse. Subsequently, send the storage device certificate containing its own identification information and the currently generated random number to the data processing device together for it to verify the identity of the storage device and construct the session context.

[0113] After receiving the instruction that the storage device certificate verification passed returned by the data processing device, further obtain the signature information carried in the instruction. The signature information is the response digest generated by the data processing device based on the received random number and the storage device certificate using its private key, aiming to prove that it has the corresponding private key capability. Extract the public key according to the stored data processing device certificate and use it to verify the signature information. If the verification fails, the storage device immediately sends a verification failure message to the data processing device and does not perform subsequent interactions.

[0114] If the signature information verification passes, it is confirmed that the data processing device has a private key that matches its certificate, indicating that the device identity is trustworthy. Then, 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. In this embodiment, by introducing a two-way certificate verification and non-repetitive random number mechanism, the identity authentication process in the startup phase is realized, effectively reducing the security problems of certificate forgery, replay attacks, and key mismatch, and improving the security of the encryption mode conversion operation in the overall data link.

[0115] Figure 3 Schematic flow of the encryption mode conversion method provided by the embodiment of the present application Figure 2 , such as Figure 3 shown, including:

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

[0117] S32, generate 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;

[0118] S33, obtain the 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 for 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 according to the first key to obtain the plaintext data, and use the second key to encrypt the plaintext data and write it into the target storage block; based on the fact that the plaintext data has 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. This address information is used to identify the data area in the storage device where the encryption mode needs to be switched, and usually includes 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 can 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 permission and validity period control. The obtained address information and the second key are jointly used to generate a key configuration table. This key configuration table records the mapping relationship between each storage block in the namespace to be converted and the target encryption mode, and associates key tags, encryption algorithm identifiers, and necessary key attribute information.

[0120] After generating the key configuration table, the data processing device calls the authentication information from the local key protection mechanism. This authentication information includes parameters such as user password, device identifier, timestamp, etc. Specifically, based on the authentication information and the key configuration table, the data processing device uses the stored public key of the storage device to encrypt the authentication information and the key configuration information to obtain encrypted information, then signs the encrypted information with the private key of the data processing device to obtain the corresponding signature information, and generates an encryption mode conversion 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 the 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 passing the integrity check and at least one second key corresponding to the target encryption mode; allocates a target storage block for 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 first key to obtain plaintext data, and encrypts the plaintext data with the second key and writes it into the target storage block; based on the fact that the plaintext data has been stored in the target storage block, according to the preset atomic transaction operation rules, maps the logical address of the source storage block to point to the target storage block, and updates the conversion record. The corresponding implementation manner of the storage device has been described in the previous embodiment and will not be elaborated here one by one. In summary, through this embodiment, the encryption mode conversion method realizes an orderly transition from the self-encryption mode to a higher security level encryption mode such as Key-per-I / O while ensuring data security, and has atomicity, rollbackability, and key isolation, effectively meeting the data protection requirements in a multi-host and multi-tenant environment.

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

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

[0123] S302. Obtain the address information of at least one namespace to be converted recorded in the key configuration table, and obtain the address information of at least one unconverted namespace according to at least one conversion record.

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

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

[0126] In this embodiment, if a restart or the like occurs, at this time, the data processing device reads at least one conversion record from the non-volatile log area preset in the storage device. The conversion record is used to track the intermediate state and historical state of the encryption mode conversion operation. By parsing this record, it can be judged which namespaces have been converted during the conversion process and which are still in a pending or unprocessed state. Next, in combination with the address information of at least one namespace to be converted recorded in the key configuration table, and in contrast with at least one conversion record extracted from the non-volatile log area, identify the address information of the namespaces that have not yet completed the encryption mode conversion. According to the mapping logic of the address range and the parsing of the conversion status field, ensure the accurate identification of the unconverted namespaces.

[0127] After determining the address information of at least one unconverted namespace, continue to obtain the corresponding second key according to the mapping relationship between the namespace and the key maintained in the key configuration table. The second key is a parameter used for data encryption in the new encryption mode (such as Key-per-I / O mode). According to the identified address information of the unconverted namespaces and their respective corresponding second keys, reconstruct a new key configuration table. The new key configuration table only contains the relevant information that has not been converted before, and is used to guide the processing of the unconverted namespaces in the subsequent encryption mode conversion tasks. After generating the new key configuration table, call the preset authentication information to sign, bind the identity or encrypt and package the new encryption mode conversion instruction to ensure that the instruction has anti-tampering ability during the communication process. Subsequently, generate and send an encryption mode conversion instruction carrying the authentication information and the new key configuration table to the storage device. This instruction is used to trigger the conversion process of the remaining unconverted namespaces, and realize the phased promotion of the encryption mode conversion process. So that the storage device can continue to complete the data processing task of the remaining unconverted area accordingly, and realize the smooth transition of the encryption mode and the closed-loop of the conversion process within the entire namespace range.

[0128] It should be noted here that after all the source storage blocks that require encryption mode conversion in a namespace to be converted are converted, the encryption mode of the namespace is set to be converted from the current encryption mode (such as the self-encryption mode) to the target encryption mode (such as the Key Per I / O mode). At this time, the relevant keys of the original self-encryption are deleted from the non-volatile memory. The non-volatile log area is cleared, and the corresponding namespace is marked as completed (for example, the value is changed to 0xFFFFFFFF), indicating that the current conversion is completed and there is no conversion to be completed. If the value of the namespace identifier is not 0xFFFFFFFF, it means that the specified namespace has not been converted yet, that is, the unconverted namespace.

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

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

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

[0132] S3303, verifying the storage device certificate according to the institutional public key in the stored institutional public key certificate;

[0133] S3304, if the storage device certificate verification passes, signing the random number with the data processing device private key to obtain signature information, and sending a storage device certificate verification passed instruction carrying the signature information to the storage device;

[0134] S3305, if the storage device certificate verification fails, resending 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 start authentication instruction carrying the data processing device certificate to the storage device. This start 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 legitimate identity of the current host. This certificate is usually issued by a trusted institution and contains content such as device identification and public key information. 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 according to the institutional public key in the locally pre-stored institutional public key certificate. This 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 uses the private key of the data processing device through the local encryption module to sign the received random number, thereby generating signature information for the other party to verify and then confirm the authenticity of the identity. Subsequently, the data processing device constructs a storage device certificate verification passed 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 not passed, it means that the received storage device certificate cannot be trusted, and the data processing device should not continue the current authentication process. Therefore, 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 re-response and enter a new round of authentication judgment process. By introducing this authentication mechanism, the security of the interaction between devices can be effectively guaranteed, and a trusted foundation can be laid for subsequent key transmission and instruction issuance.

[0137] Figure 4 This is the interaction timing diagram of the encryption mode conversion provided by the embodiment of the present application. On the basis of the above embodiment, as Figure 4 shown, it includes:

[0138] S41, the data processing device obtains the address information of at least one namespace to be converted, and obtains the second key corresponding to the namespace to be converted according to the 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 the 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 verified data processing device, and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction;

[0142] S45, the storage device obtains the first key corresponding to the current encryption mode according to 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 according to the key configuration table;

[0143] S46, the storage device allocates a target storage block for 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 according to the first key to obtain the plaintext data, and encrypts the plaintext data with the second key and writes it into the target storage block;

[0145] S48. The storage device, based on the fact that the plaintext data has been stored in the target storage block, 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 here that in this implementation, the data processing device uses a host, and the storage device uses a solid-state drive. 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 described in the above embodiments and will not be elaborated here one by one.

[0147] Figure 5 This is the interaction timing diagram for device verification provided by the embodiments 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 two-way verification of the two devices is further described as follows. Figure 5 As shown in the figure, it includes:

[0148] Step S501. The host sends a start authentication command and sends it to the solid-state drive together with the digital certificate of the host (host certificate).

[0149] Step S502. The solid-state drive receives the start authentication command, extracts the host certificate therein, and verifies the host certificate using the public key of the pre-stored 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 solid-state drive saves the host certificate, generates a new random number (for example, 128-bit length), and returns the random number and its own digital certificate (solid-state drive certificate) to the host together.

[0152] Step S505. The host receives the solid-state drive certificate and the random number returned by the solid-state drive, and verifies the solid-state drive certificate using the public key of the certificate authority saved locally.

[0153] Step S506. If the host fails to verify the solid-state drive certificate, it re-executes the start authentication command (it should be noted that the authentication process terminates after three consecutive verification failures).

[0154] Step S507. If the host successfully verifies the solid-state drive certificate, it signs the obtained random number using its own private key to generate signature information.

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

[0156] Step S509: The solid-state drive receives an authentication command, extracts the signature information, and verifies the signature information using the host public key in the saved 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] Step S512, the solid-state drive returns a success status to the host.

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

[0161] In one embodiment, a key generation and certificate configuration process for the solid-state drive side and the host side is provided, which is used to build the trust basis for subsequent authentication and encrypted communication. It is carried out before the two-way verification between the host and the solid-state drive.

[0162] First, before the solid-state drive (SSD) leaves the factory, the built-in solid-state drive controller calls a preset key generation module to generate a pair of public and private keys based on the Elliptic Curve Digital Signature Algorithm (ECDSA), denoted as the SSD public key (SSD_pubkey) and the SSD private key (SSD_prikey) respectively. Among them, the SSD private key is configured through hardware logic and is only stored in the non-volatile secure memory inside the SSD, and is set to the non-exportable attribute, and cannot be accessed even through the debug port or software instructions. The SSD public key is sent to the Trusted Certificate Authority (CA) through the private command channel.

[0163] After receiving the SSD public key, the certificate authority uses the private key of the certificate authority (CA_prikey) it holds to sign the SSD public key, and organizes it into a digital certificate format compliant with the X509 standard to obtain the device certificate of the SSD (SSD_cert). This certificate includes fields such as the SSD public key, the purpose of using the public key, the signature algorithm identifier, the validity period, etc., as well as the digital signature information signed by the private key of the certificate authority. The certificate authority further sends the SSD certificate together with its own root certificate (CA_cert) back to the SSD device. After receiving the above certificates, the SSD securely writes them into the internal non-volatile area for subsequent two-way authentication processes with external hosts.

[0164] Meanwhile, the host side also needs to complete its own certificate application process in advance. When the host is first configured, it generates a pair of key pairs through the local key generation module, denoted as the host public key (host_pubkey) and the host private key (host_prikey) respectively, and only stores the host private key in the protected storage area inside the host (such as a trusted execution environment or a trusted platform module) through security policies to ensure its security during operation. The host sends the host public key to the same certificate authority for authentication. The certificate authority signs the host public key with the private key of the certificate authority to generate a host certificate (host_cert) compliant with the X509 format, and returns the host certificate and the root certificate to the host. The host securely stores the host certificate and the root certificate for subsequent identity authentication before establishing a secure connection with the SSD.

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

[0166] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus a 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 structural diagram of the storage device provided by the embodiment of the present application. As Figure 6 shown, the storage device 6 includes:

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

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

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

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

[0172] A transaction update module 65, configured to, based on 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.

[0173] The storage device 6 may be a solid-state drive, and for the description of the features in the corresponding embodiments thereof, reference may be made to the relevant description of the corresponding embodiments of the encryption mode conversion method, which will not be elaborated here one by one.

[0174] Figure 7 It is a schematic structural diagram of a data processing device provided by an embodiment of the present application. As Figure 7 shown, the data processing device 7 includes:

[0175] An information acquisition module 71, 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;

[0176] An information configuration module 72, configured to generate 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;

[0177] An instruction sending module 73 is configured to obtain pre-set authentication information, 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 a verified data processing device, and obtains the authentication information and the key configuration table carried in the encryption mode conversion instruction; obtain current key information according to the authentication information, and obtain at least one source storage block passing integrity verification and at least one target key information corresponding to the source storage block according to the key configuration table; allocate a target storage block for 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 according to the current key information to obtain plaintext data, and encrypt the plaintext data with the target key information and write it into 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.

[0178] The data processing device 7 may be a host computer, and the description of the features in the corresponding embodiments thereof may refer to the relevant description of the corresponding embodiments of the encryption mode conversion method, which will not be elaborated here one by one.

[0179] Figure 8 It is a schematic structural diagram of an electronic device provided by this application. As Figure 8 shown, the electronic device 8 provided in this embodiment includes: at least one processor 81 and a memory 82. Optionally, the electronic device 8 further includes a communication component 83. Among them, the processor 81, the memory 82, and the communication component 83 are connected through a bus 84.

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

[0181] The specific implementation process of the processor 81 may refer to the above method embodiment, and its implementation principle and technical effects are similar, which will not be elaborated here in this embodiment.

[0182] In the above embodiments, it should be understood that the processor may be a central processing unit (Central Processing Unit, abbreviated as: CPU), and may also be other general-purpose processors, digital signal processors (Digital Signal Processor, abbreviated as: DSP), application specific integrated circuits (Application Specific Integrated Circuit, abbreviated as: ASIC), etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in combination with the application can be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

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

[0184] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For the sake of convenience in representation, the buses in the drawings of this application are not limited to only one bus or one type of bus.

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

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

[0187] An embodiment of the present application also provides a computer program product, the above computer program product includes a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-described encryption mode conversion method embodiments.

[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 stores a computer program, and when the computer program is executed by a processor, it implements the steps in any of the above-described encryption mode conversion method embodiments.

[0189] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0190] The above has introduced in detail a method for encrypting mode conversion provided by this application. Specific examples have been used herein to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art of this technology, without departing from the principle of this application, several improvements and modifications can be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A method for encrypting mode conversion, characterized in that, Including: Receiving an encryption mode conversion instruction sent by a verified data processing device, and obtaining the authentication information and key configuration table carried by the encryption mode conversion instruction; Obtaining current key information according to the authentication information, and obtaining at least one source storage block that has passed integrity verification and at least one target key information corresponding to the source storage block according to the key configuration table; Allocating a target storage block for the source storage block, 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 with the target key information and writing it into the target storage block; Based on the fact that the plaintext data has been stored in the target storage block, mapping the logical address of the source storage block to point to the target storage block, and updating the conversion record.

2. The encryption mode conversion method according to claim 1, characterized in that The encryption mode conversion method further includes: Based on the fact that the plaintext data has not been stored in the target storage block, obtaining multiple conversion records, and reading the transaction status in the multiple conversion records; Filtering out the conversion records in the pending state according to the transaction status; wherein, when the plaintext data has not been stored in the target storage block, the transaction status in the conversion record is in the pending state; Obtaining at least one of the conversion records in the pending state, and marking the target storage block in the conversion record in the pending state 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, it further includes; Obtaining the signature information in the encryption mode conversion instruction, and obtaining the 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, obtaining the authentication information and key configuration table carried by the encryption mode conversion instruction.

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

5. The encryption mode conversion method according to claim 1, characterized in that, The allocating a target storage block for the source storage block, and generating a conversion record corresponding to the source storage block and the target storage block includes: Selecting an unused storage block from the spare storage block pool as the target storage block; Writing a conversion record into the preset non-volatile log area according to the source storage block and the target storage block; Wherein, the conversion record at least includes 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 the pending state.

6. The encryption mode conversion method according to claim 1, characterized in that, The obtaining the current key information according to the authentication information includes: Determining the current encryption mode according to the current key information; Based on the current encryption mode, according to the authentication information, obtaining the key encryption key through a preset key derivation algorithm, and calculating the 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 media encryption key encrypted and stored in the non-volatile storage area to obtain the first key corresponding to the current encryption mode.

7. The encryption mode conversion method according to claim 6, wherein, The obtaining of 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 includes: Reading and parsing the key configuration table, extracting the start value and end value of the address of at least one namespace to be converted, and obtaining the target key information corresponding to the namespace to be converted; According to the start value and end value of the address of the namespace to be converted, source storage blocks are obtained from the namespace to be converted according to the preset obtaining order; Wherein, the namespace to be converted includes one or more source storage blocks; Based on the source storage block, the first key is used to decrypt and obtain the plaintext data in the source storage block, and the plaintext data is stored in a preset secure buffer; The preset cyclic redundancy check algorithm is used to calculate the current check value of the plaintext data, obtain the preset reference check value corresponding to the plaintext data, and obtain the current check times corresponding to the source storage block; If the check times corresponding to the source storage block are less than the preset times threshold and the current check value is consistent with the reference check value, it is recorded that the source storage block passes the integrity check, and based on the corresponding relationship between the source storage block and the namespace to be converted, 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 the second key corresponding to the target encryption mode is obtained; or, If the check times corresponding to the source storage block are less than the preset times threshold and the current check value is inconsistent with the reference check value, the first key is used to decrypt and obtain the plaintext data in the source storage block again, calculate the current check value of the plaintext data, and update the current check times corresponding to the source storage block, and verify the current check value and the reference check value again; or, If the check times corresponding to the source storage block are equal to or greater than the preset times threshold and the current check value is inconsistent with the reference check value, the source storage block is marked as damaged, and the source storage block is added to a preset damaged block list.

8. The encryption mode conversion method according to claim 7, characterized in that, The decrypting the data of the source storage block according to the current key information to obtain plaintext data, and encrypting the plaintext data with the target key information and writing it into the target storage block includes: Reading the data content in the source storage block, decrypting it with the first key through a preset hardware encryption engine according to the current encryption mode to obtain the plaintext data in the source storage block; Based on the target encryption mode, the plaintext data is encrypted with the second key using a preset encryption algorithm, 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-3, characterized in that The updating the conversion record includes: Marking the transaction status in the conversion record as the committed status, and adding the source storage block to the queue to be recycled.

10. The encryption mode conversion method according to any one of claims 1-3, characterized in that, The encryption mode conversion method further includes: Receiving a start authentication instruction sent by a data processing device and obtaining a data processing device certificate carried by the start authentication instruction; Obtaining a stored institutional public key and using the institutional public key to verify the data processing device certificate; If the data processing device certificate is verified successfully, storing the data processing device certificate and generating a random number of a preset length; Wherein, the current random number is different from the random numbers corresponding to previous start authentication instructions; Sending the stored device certificate and the random number to the data processing device so that the data processing device verifies the stored device certificate according to the stored device certificate and the random number; Receiving a stored device certificate verification passed instruction sent by the data processing device and obtaining signature information carried in the stored device certificate verification passed instruction; Obtaining a data processing device public key according to the stored data processing device certificate and using the data processing device public key to verify the signature information; If the signature information verification fails, sending a verification failure message to the data processing device; or, If the signature information verification passes, marking the data processing device as a verified data processing device.

11. A method for encrypting mode conversion, characterized in that, Includes: 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 the target encryption mode; Generating a key configuration table according to the address information of at least one namespace to be converted and the second keys corresponding to at least one target encryption mode; Obtaining preset authentication information, generating and sending 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; obtaining current key information according to the authentication information, and obtaining at least one source storage block passing integrity verification and at least one target key information corresponding to the source storage block according to the key configuration table; allocating a target storage block for the source storage block 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 with the target key information and writing it into the target storage block; Based on the fact that the plaintext data has been stored in the target storage block, mapping the logical address of the source storage block to point to the target storage block and updating the conversion record.

12. The encryption mode conversion method according to claim 11, wherein The encryption mode conversion method further includes: Obtaining at least one conversion record in the non-volatile log area of the storage device; Obtaining address information of at least one namespace not converted according to the address information of at least one namespace to be converted recorded in the key configuration table and according to the at least one conversion record; Obtain the second key corresponding to the un-converted namespace according to the key configuration table, and generate a new key configuration table according to the address information of the at least one un-converted namespace and its corresponding second key; Obtain the preset authentication information, and generate and send an encryption mode conversion instruction carrying the authentication information and the new key configuration table to the storage device.

13. The encryption mode conversion method according to claim 11, wherein 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: Send a start authentication instruction carrying the data processing device certificate to the storage device to enable the storage device to verify the data processing device certificate; Receive the storage device certificate and the random number sent by the storage device; Verify the storage device certificate according to the institutional public key in the stored institutional public key certificate; If the storage device certificate verification passes, sign the random number with the data processing device private key to obtain signature information, and send a storage device certificate verification passed instruction carrying the signature information to the storage device; or, If the storage device certificate verification fails, re-send the start authentication instruction carrying the data processing device certificate to the storage device.

14. A method for encrypting mode conversion, characterized in that, Include: The data processing device obtains the address information of at least one namespace to be converted, and obtains the second key corresponding to the namespace to be converted according to the target encryption mode; 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 keys corresponding to at least one target encryption mode; The data processing device obtains the preset authentication information, and 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 verified data processing device, and obtains the authentication information and the key configuration table carried by the encryption mode conversion instruction; The storage device 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; The storage device allocates a target storage block for the source storage block, 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 encrypts the plaintext data with the target key information and writes it 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: A memory for storing computer programs; A processor for implementing 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.

Citation Information

Patent Citations

  • Key rotation method and device, computer equipment and storage medium

    CN111666558A

  • Secure memory sharing

    CN116745766A

  • Secure data movement

    CN116746114A

  • Encrypted volume migration method and device, computer equipment and storage medium

    CN117591016A

  • Encrypted data conversion method and device, equipment and storage medium

    CN117592068A