Key management method, electronic device, storage medium and program product

Abstract

The invention discloses a key management method, an electronic device, a storage medium and a program product, and relates to the technical field of data storage security and key management. According to the application, when a data leakage event exists, a key version, an operation main body and a timeline corresponding to leaked data can be quickly positioned according to blockchain evidence storage data, so that the data leakage is avoided; the evidence obtaining time is greatly shortened, and the processing efficiency of data leakage events is improved; authority verification is achieved through the predefined strategy table, the efficiency of dynamic verification of the multi-tenant authority is improved, and the risk of authority retention is reduced; the integrity and authenticity of a key operation record are guaranteed by utilizing the non-tampering characteristic of the block chain, and illegal access of a tenant to key data is avoided through an independent block chain storage area and authority control; by associating the key version, the I / O operation and the tenant information, the responsibility subject can be determined when an abnormal condition occurs, and the problem that the responsibility definition of the log system is fuzzy is solved.

Description

Technical Field

[0001] The present application relates to the technical field of data storage security and key management, and in particular to a key management method, electronic device, storage medium and program product. Background Art

[0002] With the increasing popularity of the Non-Volatile Memory Express (NVMe) protocol, solid-state drives (SSDs) have become core devices for enterprise-level storage and edge computing. NVMe Key Per I / O (KPIO) technology enables fine-grained data encryption by assigning a separate key (MEK - Media Encryption Key, used to encrypt and decrypt data on SSDs) to each I / O (input / output) operation. However, this technology has the following drawbacks: (1) Insufficient transparency in key management: Although NVMe KPIO technology enables the host to control keys in a fine-grained manner (such as associating MEK with namespace through Key Tag), it lacks complete audit records of key generation, update, permission change and other operations. When a data leak occurs, it is difficult to quickly locate the associated key version and the operating subject. (2) Lack of traceability: In the key cache management process of KPIO (such as MEK injection and key cache update), the relevant log system cannot effectively associate the key version with the specific I / O operation (such as namespace ID and access time), resulting in unclear responsibility definition; (3) Inefficient dynamic verification of multi-tenant permissions: KPIO achieves tenant isolation through namespaces, but permission changes (such as tenant key access rights recovery) rely on manual configuration and lack an automated verification mechanism, which poses a risk of permission retention. Summary of the Invention

[0003] The present application provides a key management method, an electronic device, a storage medium, and a program product to at least solve the problems existing in the related art.

[0004] This application provides a key management method, including: Receive key management events; Parse key management events to obtain metadata corresponding to key management events and encapsulate the metadata into a transaction structure that conforms to the blockchain format; The transaction structure is packaged into a block and written to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. In response to receiving an abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0005] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the following steps of the key management method when executing the computer program: Receive key management events; Parse key management events to obtain metadata corresponding to key management events and encapsulate the metadata into a transaction structure that conforms to the blockchain format; The transaction structure is packaged into a block and written to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. In response to receiving an abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0006] The present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein when the computer program is executed by a processor, the following steps of the key management method are implemented: Receive key management events; Parse key management events to obtain metadata corresponding to key management events and encapsulate the metadata into a transaction structure that conforms to the blockchain format; The transaction structure is packaged into a block and written to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. In response to receiving an abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0007] The present application also provides a computer program product, including a computer program, which, when executed by a processor, implements the following steps of the key management method: Receive key management events; Parse key management events to obtain metadata corresponding to key management events and encapsulate the metadata into a transaction structure that conforms to the blockchain format; The transaction structure is packaged into a block and written to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. In response to receiving an abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0008] Through this application, all key operations in the KPIO process can be recorded to form an unalterable blockchain evidence chain, so that the entire process from key generation to use can be traced; when there is a data leakage incident, the key version, operation subject and timeline corresponding to the leaked data can be quickly located based on the blockchain evidence data, which greatly shortens the evidence collection time and improves the efficiency of handling data leakage incidents; permission verification is implemented through predefined policy tables, which changes the method of relying on manual permission configuration, improves the efficiency of dynamic verification of multi-tenant permissions, and reduces the risk of permission retention; the tamper-proof characteristics of the blockchain are used to ensure the integrity and authenticity of key operation records, and independent blockchain storage areas and permission control avoid illegal access to key data by tenants; by associating key versions, I / O operations and tenant information, the responsible party can be clearly identified in the event of an abnormal situation, solving the problem of unclear responsibility definition in the log system. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0010] Figure 1 A schematic diagram of the overall process of a key management method is provided for an embodiment of the present application; Figure 2 A schematic diagram of the overall structure of a key management system is provided for an embodiment of the present application; Figure 3 A schematic diagram of the Merkle root generation process provided in an embodiment of the present application; Figure 4 FIG. 4 is a diagram showing the internal structure of an electronic device in one embodiment. DETAILED DESCRIPTION

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

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

[0013] It should be noted that the terms "S1", "S2", etc. are used only for the purpose of describing the steps and do not specifically refer to the order or sequence, nor are they used to limit this application. They are merely for the convenience of describing the method of this application and should not be understood as indicating the order of the steps. In addition, the technical solutions between the various embodiments can be combined with each other, but this must be based on the fact that ordinary technicians in this field can implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such combination of technical solutions does not exist and is not within the scope of protection required by this application.

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

[0015] like Figure 1 As shown, the embodiment of the present application provides a key management method, which is applied to Figure 2 The key management system in

[15] is used as an example to illustrate the key management system. The key management system includes a transaction generation module, a block generation module, an account management module, and a security verification module. The transaction generation module is used to capture key management events and generate signed transaction structures. The block generation module is used to batch package transaction structures into blocks and build a hash blockchain. The account management module is used to maintain the blockchain status and query interface. The security verification module is used to ensure the legitimacy of transaction events and blocks. It includes the following steps: S1: Receive key management events.

[0016] Among them, key management events are NVMe KPIO events (such as MEK operations and data encryption and decryption), which are sent by the host and monitored by the transaction generation module. The main function of the transaction generation module is to monitor KPIO events inside the SSD (solid-state drive) (such as MEK injection and data encryption), extract metadata such as key tags, namespace identifiers, timestamps, etc., and encapsulate them into a transaction structure that conforms to the blockchain format to ensure that all key operations are traceable. Among them, MEK is used to encrypt and decrypt data on the solid-state drive. The key management events of the monitoring events include key operation events and I / O operation events. Among them, key operation events include: MEK injection (MEK_INJECT), MEK update (MEK_UPDATE), MEK deletion (MEK_DELETE); I / O operation events include: data encryption (ENCRYPT_OPERATION), data decryption (DECRYPT_OPERATION).

[0017] In some embodiments, before receiving the key management event, the method includes: Monitoring key management events within the solid-state drive, where the key management events include at least one of the following: a key operation event and an input / output operation event; In response to monitoring the key management event, a key management event is received.

[0018] In the above implementation, continuous monitoring can capture all key operations in real time, ensuring that the entire life cycle of the key from injection, use to destruction is recorded completely and tamper-proof, providing a fully trusted data foundation for security audits, leak tracing and responsibility definition.

[0019] S2: Parse the key management event to obtain the metadata corresponding to the key management event, and encapsulate the metadata into a transaction structure that conforms to the blockchain format.

[0020] It should be noted that the metadata corresponding to a key management event includes: event type (such as injection, update), key tag, namespace ID (NSID), timestamp, operation subject (such as KMS - key management server identifier), and event-specific data (such as key ID or data hash). These data together constitute the complete context of the operation behavior; the transaction structure is a standardized format for recording operation data in the blockchain. It contains the event type, key tag, namespace ID, timestamp, event-specific data (such as key ID or data hash), transaction hash, and digital signature, which is used to ensure the immutability and traceability of NVMe KPIO key operations.

[0021] In some specific implementations, parsing a key management event to obtain metadata corresponding to the key management event and encapsulating the metadata into a transaction structure conforming to a blockchain format includes: Determine the raw data of the key management event, where raw data refers to the unprocessed initial information set directly captured from the bottom layer of the NVMe KPIO operation, such as command basic information: fields contained in the NVMe Admin command or I / O command itself, such as Key Tag: the key tag associated with this operation, Namespace ID (NSID): the target namespace of the operation, Operation Code (Opcode): indicating the command type (such as Security Send, Read, Write); Command-specific parameters: specific data contained in the payload of different commands. For Security Send commands (such as MEK injection): the raw data is the key binary block, key identifier, and optional policy table carried in the command; for I / O commands (such as encrypted write operations): the raw data includes logical block address (LBA), data length, etc.; System context information: environmental data automatically obtained when the event occurs; High-precision timestamp: the exact time when the event occurs; Operation subject identification: the identity information of the host or security agent that initiated the command (such as obtained from the security protocol context); Determine metadata of the key management event based on the original data, and fill the metadata into a first transaction structure, wherein the first transaction structure is a structure; Based on the metadata, the event type of the key management event is determined. Based on the event type, the specific data for the key management event is determined and inserted into the second transaction structure. The second transaction structure is a union. The specific data refers to key parameters unique to a specific event type, such as the key ID and operator in a key injection event, or the data hash and address in an encryption operation. It provides the most core information about the operation object of the event. Perform hash value calculation and digital signature calculation on the data in the first transaction structure and the second transaction structure respectively, and store the calculation results in the corresponding fields. Hash value calculation and digital signature calculation are commonly used calculation methods, and the specific process is not repeated here; A transaction structure conforming to a blockchain format is generated based on the first transaction structure and the second transaction structure on which the calculation operation has been performed.

[0022] Specifically, the event data is converted into a fixed-format transaction structure, and the code includes: struct Transaction { uint8_t type; / / event type (e.g. MEK_INJECT=1, ENCRYPT=2) uint32_t key_tag; / / KPIO Key Tag (4 bytes, associated with MEK) uint32_t ns_id; / / Namespace ID (4 bytes) uint64_t timestamp; / / Timestamp (8 bytes, millisecond Unix time) union { / / event-specific data struct { / / MEK injection event uint8_t key_id

[16] ; / / MEK unique identifier (UUID format) uint8_t operator

[16] ; / / Operation subject (such as KMS UUID) } mek_inject; struct { / / Encryption operation event uint8_t data_hash

[32] ; / / data block SHA-256 hash uint64_t lba; / / logical block address } encrypt_op; } payload; uint8_t hash

[32] ; / / Hash generated by the above data uint8_t signature

[64] ; / / Signature generated by the above data (excluding hash value) (using SSD private key) }; Among them, the signature data in the above structure is obtained by signing the transaction data in front of the structure using the SSD private key to ensure that the transaction cannot be forged. The SSD private key is a pair of public and private keys generated by the administrator through a private command to the SSD before leaving the factory. It is stored in the internal non-volatile secure storage area and cannot be exported in any way and cannot be accessed by other modules of the firmware. Private key signature, public key verification.

[0023] In the above implementation, by encapsulating metadata into a blockchain transaction structure, data standardization, immutability and verifiability are achieved, providing a reliable and efficient audit traceability basis for the entire life cycle of the key, and ensuring the integrity and authenticity of operation records.

[0024] In some specific embodiments, when generating the transaction structure, the method further includes: When generating a transaction structure, a zero-knowledge proof algorithm is used to generate proof of the legitimacy of key operations (such as range proofs and operation validity proofs) and store the proof in a dedicated field of the transaction structure. The zero-knowledge proof algorithm allows the prover (SSD) to prove to the verifier (blockchain node or auditor) that a statement is true (such as "this encryption operation is authorized") without revealing any specific information about the statement itself (such as the key used or the data operated on). Specifically, the proof generation process includes compiling key operation rules (such as policy tables) into mathematical circuits. During the operation, the SSD uses private parameters (such as key tags and NSID) as witness inputs (private inputs of circuit constraints) and runs ZKP (such as zk-SNARK) to generate a proof. The proof can be publicly verified for its legitimacy without revealing any sensitive operation details. When packaging blocks, blockchain verification nodes verify the validity of the zero-knowledge proof rather than directly parsing the transaction content. During auditing, the auditor provides the characteristic value of the operation to be verified (such as data hash), and the device returns the corresponding zero-knowledge proof and transaction hash. The auditor can verify the legitimacy of the operation through public parameters without having the right to obtain specific operation details.

[0025] In the above implementation, by generating zero-knowledge proof, while meeting the audit and traceability requirements, key operation details (such as the direct association between key labels and namespaces) are prevented from being leaked to unauthorized parties, achieving a balance between privacy protection and compliance auditing.

[0026] In some specific embodiments, after encapsulating the metadata into a transaction structure conforming to the blockchain format, the method includes: Build a ring buffer; Write the transaction structure into the ring buffer and sort the transaction structure according to the timestamp of the key management event.

[0027] In some embodiments, after writing the transaction structure to the ring buffer, the method includes: Based on the hash value of the transaction structure, determine whether there is a duplicate transaction structure in the ring buffer; In response to the existence of duplicate transaction structures, the duplicate transaction structures are deleted to save a target number of transaction structures; A security check is performed on the transaction structure, and in response to failure of the security check, the transaction structure is filtered.

[0028] Specifically, a ring buffer is used to temporarily store transaction structures (the capacity is configurable, the default is 1000), and they are sorted in ascending order by timestamp to ensure that the order of transaction structures in the block is consistent with the actual operation. When the transaction structure is temporarily stored, only the timestamp and the transaction pointer pointing to the transaction data are recorded. The actual sorting operation is completed before the block is packaged (not in real time). The global buffer avoids the complexity of merging and sorting multiple buffers and reduces CPU overhead. The ring buffer structure is as follows: typedef struct { Transaction buffer

[1000] ; / / Fixed size transaction buffer uint32_t read_ptr; / / read pointer (atomic variable) uint32_t write_ptr; / / write pointer (atomic variable) } LockFreeRingBuffer; The ring buffer is identified by a read pointer (read_ptr) and a write pointer (write_ptr). Both are initially 0. Write_ptr increments by 1 when a transaction is written, and read_ptr increments by 1 when a transaction is read. When the value reaches 1000, it restarts from 0. When write_ptr plus 1 equals read_ptr, it indicates that the buffer is full. SSDs have multiple cores, and for multithreading, changes to write_ptr and read_ptr must be atomic.

[0029] Furthermore, the transaction structure in the buffer is deduplicated and filtered for validity. Duplicate transaction detection is to determine whether there are duplicate transactions through the hash value of the transaction structure, and only the first valid record is retained; the permission verification pre-process is to filter out transactions that have not passed the security verification module (such as invalid signature, expired permission), reducing invalid calculations.

[0030] In the above implementation, storing the transaction structure in the ring buffer can achieve efficient and orderly temporary storage and traffic shaping, providing a stable and batch data source for subsequent block packaging, thereby improving the overall performance of the system.

[0031] S3: Package the transaction structure to generate a block, and write the block to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block transaction list.

[0032] It should be noted that this step uses the block generation module to batch-package the discrete transaction structures output by the transaction generation module into blocks, and constructs an unalterable blockchain structure through the Merkle tree and hash chain.

[0033] In some specific implementations, packaging the transaction structure to generate a block and writing the block to the blockchain storage area of ​​the solid-state drive includes: In response to the writing time period reaching a preset time window and / or the number of written transaction structures reaching a preset threshold, the transaction structures are packaged to generate a block. The block includes a block header and a transaction list. The transaction list includes multiple transaction structures. The preset time window and the preset threshold can be set according to actual needs. For example, the preset time window is 1 second and the number of transaction structures is 1000. Construct a Merkle tree, define the hash value of the transaction structure in the transaction list as the leaf node of the Merkle tree, merge the hash values ​​of two adjacent leaf nodes, calculate the merged hash value, and define the merged hash value as the parent node; Recursive hashing to determine the Merkle root, which is then written into the block header. Calculate the hash value of the block header and define the hash value of the block header as the hash field of the next block header to generate a hash chain; Generate blockchain structure based on hash chain and Merkle tree; Based on the block order of the blockchain structure, the blocks are written into the blockchain storage area of ​​the solid-state drive.

[0034] Specifically, the packaging and generation of blocks are triggered by the time window (default 1 second) or the quantity threshold (default 1000). The block consists of a block header and a transaction list, with the following structure: typedef struct { BlockHeader header; / / block header Transaction tx_list

[1000] ; / / Transaction list (up to 1000) } Block; The block header structure is as follows: typedef struct { uint8_t prev_hash

[32] ; / / The block header hash of the previous block (32 bytes) uint8_t merkle_root

[32] ; / / Merkle root of the current block transaction list (32 bytes) uint64_t timestamp; / / Block generation timestamp (8 bytes) uint64_t min_tx_time; / / Minimum transaction timestamp in this block (8 bytes) uint64_t max_tx_time; / / Maximum transaction timestamp in this block (8 bytes) uint32_t block_height; / / Block height (4 bytes, 0 for the first block, increments for subsequent blocks) uint32_t tx_count; / / Number of transactions in the block (4 bytes) uint8_t block_signature

[64] ; / / Signature of block header (64 bytes) } BlockHeader; Among them, merkle_root is the Merkle root, the hash value of the buffer transaction is used as the leaf node, the hash values ​​of adjacent leaf nodes are combined in pairs, and the hash value of the parent node is recursively calculated to finally generate the Merkle root (merkle_root). If the number of leaf nodes is odd, the last leaf node is copied and calculated again. For example, Figure 3 As shown in the figure, there are four transaction structures (including transaction 1, transaction 2, transaction 3 and transaction 4). The hash values ​​of adjacent transaction counts are recursively calculated in sequence to finally obtain the Merkle root. Once any change occurs to the underlying data block, after the hash operation, the hash values ​​of all nodes on the path from the data block to the root node will change, making tampering easy to detect.

[0035] Furthermore, the prev_hash field is the hash value of the previous block header, which is used to ensure the security and integrity of the blockchain. The prev_hash field connects each block to the previous block to form an unalterable blockchain. If someone attempts to tamper with the data of a block, the hash value of the block will change, causing the prev_hash field value of its subsequent blocks to not match the hash value of the actual previous block, making it easily discovered.

[0036] Furthermore, the SSD writes the generated blocks sequentially (using SSD sequential write optimization to improve performance) to the blockchain storage area (an independent partition of NAND flash memory). The blockchain storage area is an independent NVMe namespace within the SSD (for example, NS=0xFFF). Through the NVMe protocol's namespace access control, only the SSD firmware has read and write permissions. Tenants' I / O commands (such as Read) cannot directly access this area. The content of this area can only be read after the operation and maintenance management personnel pass security authentication. The layout of the blockchain storage area is as follows: ├─Block 0 (height 0): block header + transaction list ├─Block 1 (height 1): block header + transaction list ├─... └─Block N (height N): block header + transaction list In the above implementation, a lightweight private chain is built inside the SSD, combining blockchain technology with NVMe KPIO technology. This can record all key operations in the KPIO process (such as MEK injection, update, deletion, and use), forming an unalterable blockchain evidence chain. This realizes unalterable evidence of key operations throughout their entire life cycle, allowing a traceable record of the entire process from key generation to use. Based on the blockchain evidence data, the key version, operating subject, and timeline corresponding to the leaked data can be quickly located, significantly shortening the evidence collection time and improving the efficiency of handling data leakage incidents. Based on an independent blockchain storage area (NVMe namespace NS=0xFFF), this storage area only allows reading and writing within the SSD firmware and cannot be directly accessed by tenants, ensuring data security from the storage architecture.

[0037] In some specific implementations, the key management event includes at least a key policy table, and the method includes: In response to receiving a data read / write request, verifying the transaction legitimacy of the data read / write request according to the key tag and key policy table in the data read / write request; In response to successful verification, a data read / write operation corresponding to the data read / write request is executed.

[0038] In response to the solid state drive being powered on and / or the solid state drive being in an idle state, obtaining a hash field of a current block and a hash value of a previous block; Compare the hash field and hash value; In response to the comparison being successful, it is determined that the current block passes the integrity verification.

[0039] Recalculate the Merkle root of the transaction structure in the block and compare the recalculated Merkle root with the Merkle root in the block header; In response to the comparison being successful, it is determined that the transaction list passes the integrity verification.

[0040] In response to receiving the key authority change request, updating the key policy table according to the key authority change request; In response to receiving the data read / write request again, verifying the transaction legitimacy of the data read / write request according to the updated key policy table; In response to successful verification, a data read / write operation corresponding to the data read / write request is executed.

[0041] Specifically, the security verification module verifies the legitimacy of transaction signatures, the integrity of blocks, and the compliance of operation permissions to prevent tampering, forgery, or unauthorized operations. This mainly includes transaction legitimacy verification and block integrity verification at power-on or when the SSD is idle. Among them, transaction legitimacy verification is to check the fields, that is, during the data reading and writing process, according to the Key Tag in the IO command, read the policy table of the security metadata area, verify whether the command space ID is correct, whether the timestamp is within the validity period, etc., and then determine whether the transaction is legal; at power-on startup or when the SSD is idle, the integrity of the block is verified, including hash chain verification and Merkle root. Among them, hash chain verification is to check whether the prev_hash of the current block is equal to the hash value of the previous block (calculated from the previous block header) to ensure the integrity of the blockchain; Merkle root verification: recalculate the Merkle root of the transactions in the block and compare it with the merkle_root of the block header to ensure that the transaction list has not been tampered with.

[0042] Furthermore, the policy table is structured data stored in encrypted form and is bound to the Master Encryption Key (MEK). Only when the MEK is injected into the SSD is the policy table information carried in the command. The policy table is signed with the KMS private key. After the SSD receives the signature and successfully verifies it with the KMS public key, it is synchronously loaded into the secure metadata area. When the key is deleted, the policy table is also deleted. Its core fields are as follows: typedef struct { uint32_t version; / / strategy table version number uint32_t key_tag; / / Key tag (bound to MEK) uint32_t ns_id; / / namespace ID uint8_t tenant_id

[32] ; / / tenant name struct { uint64_t start; uint64_t end; } valid_period; / / Valid time range uint8_t allowed_ops[2]; / / Allowed operation type, for example, allowed_ops[0]=1 means encryption is allowed uint8_t signature

[64] ; / / Host KMS signature for the policy table } policy_table; In the above implementation, the security verification module effectively prevents tampering, forgery and unauthorized operations by real-time verification of transaction signatures, permission policies and blockchain integrity, ensures the credibility of key management and system security, and provides a reliable basis for traceability. By binding the policy table with MEK, which contains information such as key labels, namespace IDs, tenant identifiers, valid time ranges, and allowed operation types, dynamic configuration and automatic verification of permissions are achieved, thereby improving the flexibility and security of permission management.

[0043] S4: In response to receiving the abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0044] It should be noted that abnormal events may include data leakage (sensitive data is illegally accessed), unauthorized use of keys (unauthorized tenants use keys), and transaction tampering (transactions within the block are modified). The triggering conditions include system detection and manual triggering. Among them, system detection: the SSD security verification module detects anomalies (such as 10 consecutive permission denials, data hash mismatch, etc.) and automatically sends an alarm to the host. Manual triggering: the administrator discovers data leakage through the monitoring platform and manually initiates a traceability request.

[0045] In some specific implementations, before receiving an abnormal event query request, the method includes: In response to detecting an abnormal event, an abnormal event query request is generated, where the abnormal event includes at least one of the following: transaction legitimacy verification failure and integrity verification failure.

[0046] In some specific embodiments, in response to receiving an abnormal event query request, performing a source tracing query operation of a key operation record based on a block includes: In response to receiving the abnormal event query request, extracting abnormal features corresponding to the abnormal event query request; Based on the abnormal characteristics, the transaction structure associated with the abnormal characteristics in the blockchain storage area is determined through the query interface; The tenant ID is associated with the namespace ID in the transaction structure and the key operation timeline is verified to generate a traceability report.

[0047] Specifically, in the data leakage scenario, the hash of the leaked data (recorded as leak_hash) is extracted. In the key unauthorized operation scenario, the Key Tag of the abnormal operation (such as key_tag=123) is extracted, etc., and the related transactions are located through the query interface of the account management module (before sending the query interface command, the SSD needs to verify whether the sender is legal, and send it after the verification is passed). If the hash leak_hash of the data is known, the host sends a private GET_TX_BY_HASH command to the SSD, carrying the leak_hash. The SSD calls the "Query by Data Hash" interface to obtain the transaction that encrypts the data (including key_tag, ns_id, timestamp). If the key_tag is known, the "Query by Key" interface is called. Tag Query" interface to obtain all operation records of the key (MEK injection time, associated tenant namespace ID); Association Analysis: Key Lineage Tracing: Query MEK injection transactions based on key tags to obtain the key source, injection time, and policy table; Tenant Responsibility Location: Associate tenant identifiers based on namespace IDs (through the tenant mapping table in the security metadata area) to confirm the operating subject (such as Tenant A); Timeline Verification: Check whether the time of the abnormal operation is within the valid_period of the policy table to determine whether it is an unauthorized or expired operation; Generate Traceback Report: Output a report containing the abnormal transaction hash, associated key, responsible tenant, and operation timeline to support auditing and forensics.

[0048] The ledger management module maintains the global state and historical data of the blockchain, provides an efficient query interface, and ensures the consistency and availability of the ledger. The query interface of the ledger management module (such as tracing by KeyTag) is only open to host administrators (such as data center operation and maintenance personnel) and tenants do not have permission to call it. When anomalies such as data leakage and unauthorized operation occur, the system administrator of the SSD (such as data center operation and maintenance personnel) can access the blockchain storage area only after security authentication. It provides the following query interface (called through the private NVMe Admin command): (1) Query by Key Tag: Enter the Key Tag and return all operation records of the key (MEK injection, encryption events, etc.); (2) Query by time range: Enter the start / end timestamp to return all transactions within that time period; (3) Query by data hash: Enter the hash value of a block and return the transaction record (including KeyTag and tenant namespace identifier) ​​for encrypting or decrypting the data; (4) Query by block height: Obtain the complete data of a block to verify historical operations.

[0049] In the above implementation, by formulating a standardized abnormal tracing process, covering steps such as abnormal feature extraction, blockchain query, correlation analysis and generation of tracing reports, abnormal situations such as data leakage and unauthorized operations can be quickly located, thereby improving the system's emergency response capabilities.

[0050] The above-mentioned key management method includes: receiving a key management event; parsing the key management event to obtain metadata corresponding to the key management event, and encapsulating the metadata into a transaction structure that conforms to the blockchain format; packaging the transaction structure to generate a block, and writing the block to the blockchain storage area of ​​the solid-state drive, where the block header includes at least the block header hash value of the previous block and the Merkle root of the current block transaction list; in response to receiving an abnormal event query request, performing a traceability query operation on the key operation record based on the block. The beneficial effects of this application include: (1) Traceability throughout the entire life cycle: All key operations in the KPIO process (such as MEK injection, update, deletion, and use) can be recorded to form an unalterable blockchain evidence chain, allowing the entire process from key generation to use to be traceable.

[0051] (2) Real-time leak tracing and response: Based on blockchain evidence data, the key version, operating entity, and timeline corresponding to the leaked data can be quickly located, significantly shortening the evidence collection time and improving the efficiency of handling data leak incidents; (3) Lightweight permission verification: Permission verification is implemented through a predefined policy table, which changes the way of relying on manual permission configuration, improves the efficiency of dynamic verification of multi-tenant permissions, and reduces the risk of permission retention; (4) Enhanced data security: The tamper-proof nature of blockchain is utilized to ensure the integrity and authenticity of key operation records. Independent blockchain storage areas and permission control prevent tenants from illegally accessing key data. (5) Clear definition of responsibilities: By associating key versions, I / O operations, and tenant information, the responsible party can be clearly identified when an abnormal situation occurs, solving the problem of unclear responsibility definition in traditional log systems.

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

[0053] It should be understood that although Figure 1-Figure 2The steps in the flowchart are shown in sequence as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified in this document, there is no strict order restriction for the execution of these steps, and these steps can be executed in other orders. In addition, Figure 1-Figure 2 At least part of the steps may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be executed in turn or alternately with other steps or at least part of the sub-steps or stages of other steps.

[0054] In one embodiment, an electronic device is provided. The electronic device may be a terminal, and its internal structure diagram may be as follows: Figure 4 As shown. The electronic device includes a processor, a memory, a network interface, a display screen and an input device connected via a system bus. The processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the electronic device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, a key management method is implemented. The display screen of the electronic device can be a liquid crystal display screen or an electronic ink display screen, and the input device of the electronic device can be a touch layer covering the display screen, or a button, trackball or touchpad provided on the housing of the electronic device, or an external keyboard, touchpad or mouse, etc.

[0055] Those skilled in the art will understand that Figure 4 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the electronic device to which the solution of the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0056] An embodiment of the present application provides an electronic device, including a memory and a processor. The memory stores a computer program, and the processor is configured to run the computer program to perform steps in an embodiment of a key management method, including: S1: Receive key management events; S2: Parse the key management event to obtain the metadata corresponding to the key management event and encapsulate the metadata into a transaction structure that conforms to the blockchain format; S3: Pack the transaction structure into a block and write the block to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. S4: In response to receiving the abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0057] An embodiment of the present application further provides a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, wherein the computer program is configured to execute the steps of the key management method embodiment when running, including: S1: Receive key management events; S2: Parse the key management event to obtain the metadata corresponding to the key management event and encapsulate the metadata into a transaction structure that conforms to the blockchain format; S3: Pack the transaction structure into a block and write the block to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. S4: In response to receiving the abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

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

[0059] An embodiment of the present application further provides a computer program product. The computer program product includes a computer program. When the computer program is executed by a processor, the steps in the key management method embodiment are implemented, including: S1: Receive key management events; S2: Parse the key management event to obtain the metadata corresponding to the key management event and encapsulate the metadata into a transaction structure that conforms to the blockchain format; S3: Pack the transaction structure into a block and write the block to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. S4: In response to receiving the abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

[0060] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program. When the computer program is executed by a processor, the steps in the key management method embodiment are implemented, including: S1: Receive key management events; S2: Parse the key management event to obtain the metadata corresponding to the key management event and encapsulate the metadata into a transaction structure that conforms to the blockchain format; S3: Pack the transaction structure into a block and write the block to the blockchain storage area of ​​the solid-state drive. The block header includes at least the block header hash value of the previous block and the Merkle root of the current block's transaction list. S4: In response to receiving the abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

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

[0062] The above describes in detail a key management method, device, electronic device, and storage medium provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only intended to help understand the method and core ideas of the present application. It should be noted that, for those skilled in the art, without departing from the principles of the present application, several improvements and modifications may be made to the present application, and these improvements and modifications also fall within the scope of protection of the present application.

Claims

1. A key management method, characterized in that: Applied to a solid-state drive, the method includes: Receive key management events; Parsing the key management event to obtain metadata corresponding to the key management event, and encapsulating the metadata into a transaction structure that conforms to the blockchain format; Packaging the transaction structure to generate a block, and writing the block into the blockchain storage area of ​​the solid-state drive, wherein the block header includes at least a block header hash value of the previous block and a Merkle root of the transaction list of the current block; In response to receiving the abnormal event query request, a traceability query operation of the key operation record is performed based on the block.

2. The key management method according to claim 1, characterized in that: Prior to receiving a key management event, the method includes: Monitoring key management events within the solid-state drive, wherein the key management events include at least one of the following: a key operation event and an input / output operation event; In response to monitoring the key management event, the key management event is received.

3. The key management method according to claim 1, wherein: Parsing the key management event to obtain metadata corresponding to the key management event, and encapsulating the metadata into a transaction structure that conforms to the blockchain format includes: Determining raw data of the key management event; Determining metadata of the key management event based on the original data, and filling the metadata into a first transaction structure; Determining an event type of the key management event based on the metadata, determining specific data of the key management event according to the event type, and filling the specific data into a second transaction structure; Perform hash value calculation and digital signature calculation on the data in the first transaction structure and the second transaction structure respectively, and store the calculation results in corresponding fields; Based on the first transaction structure and the second transaction structure on which the calculation operation has been performed, the transaction structure that complies with the blockchain format is generated.

4. The key management method according to claim 1, wherein: After encapsulating the metadata into a transaction structure conforming to the blockchain format, the method includes: Build a ring buffer; The transaction structures are written into a ring buffer, and the transaction structures are sorted according to the timestamps of the key management events.

5. The key management method according to claim 4, characterized in that: After writing the transaction structure into the ring buffer, the method includes: Determining whether there is a duplicate transaction structure in the ring buffer based on the hash value of the transaction structure; In response to the existence of duplicate transaction structures, the duplicate transaction structures are deleted to save a target number of transaction structures; A security check is performed on the transaction structure, and in response to failure of the security check, a filtering process is performed on the transaction structure.

6. The key management method according to claim 4, characterized in that: Packaging the transaction structure to generate a block, and writing the block into the blockchain storage area of ​​the solid-state drive includes: In response to a writing time period reaching a preset time window and / or the number of written transaction structures reaching a preset threshold, packaging the transaction structures to generate a block, wherein the block includes a block header and a transaction list, and the transaction list includes multiple transaction structures; Constructing a Merkle tree, defining the hash value of the transaction structure in the transaction list as a leaf node of the Merkle tree, merging the hash values ​​of two adjacent leaf nodes, calculating the merged hash value, and defining the merged hash value as a parent node; A recursive hashing process to determine a Merkle root, which is written into the block header; Calculating a hash value of the block header, and defining the hash value of the block header as a hash field of the next block header to generate a hash chain; Generate a blockchain structure based on the hash chain and the Merkle tree; Based on the block order of the blockchain structure, the blocks are written into the blockchain storage area of ​​the solid state drive.

7. The key management method according to claim 1, characterized in that: The key management event includes at least a key policy table, and the method includes: In response to receiving a data read / write request, verifying the transaction legitimacy of the data read / write request according to the key tag in the data read / write request and the key policy table; In response to successful verification, a data read / write operation corresponding to the data read / write request is executed.

8. The key management method according to claim 7, characterized in that: The method further comprises: In response to the solid state drive being powered on and / or the solid state drive being in an idle state, obtaining a hash field of a current block and a hash value of a previous block; Comparing the hash field with the hash value; In response to the comparison being successful, it is determined that the current block passes the integrity verification.

9. The key management method according to claim 8, characterized in that: The method further comprises: Recalculate the Merkle root of the transaction structure in the block and compare the recalculated Merkle root with the Merkle root in the block header; In response to the comparison being successful, it is determined that the transaction list passes the integrity verification.

10. The key management method according to claim 9, characterized in that: Before receiving an abnormal event query request, the method includes: In response to detecting an abnormal event, the abnormal event query request is generated, where the abnormal event includes at least one of the following: transaction legitimacy verification failure and integrity verification failure.

11. The key management method according to claim 7, characterized in that: The method further comprises: In response to receiving a key authority change request, updating a policy table for the key according to the key authority change request; In response to receiving the data read / write request again, verifying the transaction legitimacy of the data read / write request according to the updated key policy table; In response to successful verification, a data read / write operation corresponding to the data read / write request is executed.

12. The key management method according to claim 1, wherein: In response to receiving the abnormal event query request, performing a traceability query operation of the key operation record based on the block includes: In response to receiving an abnormal event query request, extracting abnormal features corresponding to the abnormal event query request; According to the abnormal characteristics, determining, through a query interface, a transaction structure associated with the abnormal characteristics in the blockchain storage area; The tenant ID is associated with the namespace ID in the transaction structure, and the key operation timeline is verified to generate a traceability report.

13. An electronic device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the key management method according to any one of claims 1 to 12 when executing the computer program.

14. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program implements the steps of the key management method according to any one of claims 1 to 12 when executed by a processor.

15. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the key management method according to any one of claims 1 to 12 are implemented.

Images