Anomaly Handling Method and System Based on Encrypted Solid State Drives

Abstract

This invention relates to the field of solid-state drive (SSD) technology, and in particular to a method and system for handling anomalies in encrypted SSDs. The method acquires access request sequences and encryption status identifiers, parses the requests based on state transition rules to obtain a feature set, matches the target logical address to determine the physical storage region and encryption domain identifier, and determines whether the encryption domain consistency constraint is met. If not, an anomaly flag is generated and corresponding processing is performed. Simultaneously, feedback information is used to dynamically adjust the state transition rules. This invention improves the security of encrypted SSD access, adaptively optimizes the accuracy of anomaly identification, and enhances the reliability of the storage system.

Description

Technical Field

[0001] This invention relates to the field of solid-state drive technology, and in particular to an anomaly handling method and system based on encrypted solid-state drives. Background Technology

[0002] With the increasing demand for information security, encrypted solid-state drives (SSDs) are widely used in important sectors such as government, finance, and healthcare as key devices for data security protection. Encrypted SSDs protect stored data through hardware-level encryption technology, ensuring data security even if the device is lost or stolen. Current encrypted SSDs typically employ a multi-encryption domain architecture, with different keys and security policies corresponding to different data areas, thereby achieving more granular access control and data isolation.

[0003] In practical applications, encrypted SSDs need to handle a large number of complex access requests involving data interaction between different encryption domains, and must ensure that access to various types of data conforms to predetermined security policies. Traditional encrypted SSDs manage data security through static security policies and fixed access control mechanisms, but with the diversification of application scenarios and the increasing sophistication of attack methods, these static security mechanisms have shown significant shortcomings in anomaly handling.

[0004] Existing encrypted SSD technologies suffer from the following shortcomings in anomaly handling: They lack the ability to dynamically analyze access request sequences, failing to effectively identify attack patterns that appear legitimate with a single access but exhibit anomalous sequential behavior, thus allowing some carefully crafted unauthorized accesses to go undetected; existing technologies employ simple access denial policies to handle anomalies, lacking a tiered response mechanism and failing to implement differentiated handling measures based on the severity and type of the anomaly, impacting system availability and user experience; and existing encrypted SSD anomaly handling mechanisms lack adaptive learning capabilities, failing to dynamically adjust security policies based on historical processing results, resulting in limited protection against new attack methods and difficulty adapting to the ever-changing security threat environment. Summary of the Invention

[0005] The embodiments of the present invention provide a method and system for handling anomalies based on encrypted solid-state drives, which can at least solve some of the problems existing in the prior art.

[0006] A first aspect of the present invention provides a method for handling anomalies in encrypted solid-state drives, comprising:

[0007] Obtain the sequence of access requests generated by the encrypted solid-state drive during operation and the corresponding encryption status identifiers;

[0008] Each access request in the access request sequence is parsed based on preset state transition rules to obtain a set of request features;

[0009] Based on the target logical address in the request feature set and the address mapping relationship maintained internally by the encrypted solid-state drive, the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area are determined to obtain the area mapping result;

[0010] Based on the region mapping result, the encryption status identifier, and the key index information in the access request, it is determined whether the current access request satisfies the encryption domain consistency constraint. If it does not, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag to obtain the exception handling instruction.

[0011] Based on the anomaly handling instructions, the access request is denied, redirected, or key renegotiation is performed, and the processing result is used as feedback information. The state transition rules are dynamically adjusted using the feedback information to adaptively optimize the anomaly identification accuracy.

[0012] Each access request in the access request sequence is parsed based on preset state transition rules to obtain a set of request features, including:

[0013] Based on the access request structure template defined in the preset state transition rules, each access request in the access request sequence is segmented by field, and the command field, address field, and additional information field in the access request are identified to obtain the field combination;

[0014] For the command field in the field combination, the command field is converted into a standardized operation type identifier by querying the command type mapping table maintained in the preset state transition rules, thereby obtaining the operation type;

[0015] For the address field in the field combination, extract the logical address information carried in the address field, and use the logical address information as the target logical address. At the same time, parse the key index identifier from the additional information field to obtain the address and key association information.

[0016] Based on the request validity verification conditions defined in the preset state transition rules, the operation type, the target logical address, and the key index identifier are verified for integrity. The operation type, target logical address, and key index identifier that pass the integrity verification are combined to form the request feature set.

[0017] Based on the target logical address in the request feature set and the address mapping relationship maintained internally by the encrypted solid-state drive, the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area are determined to obtain the area mapping result, including:

[0018] Extract the target logical address from the request feature set, and search for the corresponding mapping table entry set in the address mapping relationship maintained inside the encrypted solid-state drive according to the target logical address;

[0019] In the set of mapping entries, by performing interval matching between the target logical address and the logical address segments in each mapping entry, a target mapping entry containing the target logical address is determined, and the physical storage area identifier mapped to the target logical address is read from the target mapping entry to obtain the physical area location result;

[0020] Based on the physical storage area identifier in the physical area location result, the encryption domain management structure maintained inside the encrypted solid-state drive is accessed. The encryption domain identifier associated with the physical storage area identifier and the key version information corresponding to the encryption domain identifier are queried from the encryption domain management structure to obtain the encryption domain association information.

[0021] The physical storage area identifier in the physical area location result is structurally combined with the encryption domain identifier and key version information in the encryption domain association information to obtain the area mapping result.

[0022] Based on the physical storage area identifier in the physical area location result, the encryption domain management structure maintained internally by the encrypted solid-state drive is accessed. The encryption domain identifier associated with the physical storage area identifier and the key version information corresponding to that encryption domain identifier are queried from the encryption domain management structure to obtain encryption domain association information, including:

[0023] Based on the region coding attribute of the physical storage region identifier, the physical group identifier to which the physical storage region belongs is determined, and the group affiliation information is obtained;

[0024] Based on the physical packet identifier in the packet attribution information, locate the encryption domain configuration table corresponding to the physical packet identifier in the encryption domain management structure;

[0025] In the encrypted domain configuration table, by matching the physical storage area identifier with the range of physical storage area identifiers recorded in each entry of the encrypted domain configuration table, the target encrypted domain entry to which the physical storage area identifier belongs is determined, and the corresponding encrypted domain identifier is read from the target encrypted domain entry to obtain the domain identifier query result;

[0026] Based on the encrypted domain identifier in the domain identifier query result, the key version index table maintained in the encrypted domain management structure is accessed, and the currently valid key version identifier associated with the encrypted domain identifier and the key lifecycle status corresponding to the key version identifier are retrieved from the key version index table to obtain the key version query result;

[0027] The encrypted domain identifier in the domain identifier query result is associated and integrated with the current valid key version identifier and key lifecycle status in the key version query result to obtain the encrypted domain association information.

[0028] Based on the region mapping result, the encryption status identifier, and the key index information in the access request, it is determined whether the current access request satisfies the encryption domain consistency constraint. If it does not, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag, resulting in exception handling instructions, including:

[0029] The request key identifier indicated in the key index information is compared with the currently valid key version identifier recorded in the key version information associated with the encryption field identifier to obtain the key consistency determination result;

[0030] Based on the key consistency determination result, the key lifecycle status in the key version information is checked to determine whether the key corresponding to the requested key identifier is in an invalid or rotated state. Combined with the global encryption status, it is determined whether the encrypted solid-state drive is in a key migration process, and the result of the anomaly analysis is obtained.

[0031] Based on the anomaly cause analysis results, if it is determined that the current access request does not meet the encryption domain consistency constraint, an anomaly tag containing an anomaly type identifier is generated. The anomaly type identifier generates a classification anomaly tag based on the inconsistency causes identified in the anomaly cause analysis results.

[0032] Based on the anomaly type identifier in the anomaly classification marker, the processing strategy template corresponding to the anomaly type identifier is queried in the preset anomaly handling strategy mapping table;

[0033] An exception handling instruction is generated based on the processing strategy template and the physical storage area identifier in the area mapping result.

[0034] Based on the key consistency determination result, the key lifecycle status in the key version information is checked to determine whether the key corresponding to the requested key identifier is in an expired or rotated state. Combined with the global encryption status, it is determined whether the encrypted solid-state drive is in a key migration process, resulting in an anomaly analysis, including:

[0035] Based on the key consistency determination result, if it is determined that the requested key identifier is inconsistent with the current valid key version identifier, then the key lifecycle status identifier associated with the requested key identifier is extracted from the key version information, and the system-level key management status identifier of the encrypted solid-state drive is extracted from the global encryption status to obtain a set of status information;

[0036] Based on the key lifecycle status identifier in the status information set, determine the current lifecycle stage of the key corresponding to the request key identifier, and determine whether the key is in an expired state or a rotation transition state to obtain the key status determination result;

[0037] Based on the system-level key management status identifier in the status information set, it is determined whether the encrypted solid-state drive is performing a key migration operation across encryption domains, and a system status determination result is obtained;

[0038] Based on the key status determination result and the system status determination result, the abnormal causes are classified into key failure anomalies, key version mismatch anomalies, or key migration conflict anomalies, resulting in an anomaly cause analysis result that includes the anomaly cause category and the corresponding status basis.

[0039] Based on the anomaly handling instructions, the access request is denied, redirected, or key renegotiation is performed, and the processing result is used as feedback information. The state transition rules are dynamically adjusted using this feedback information to adaptively optimize the anomaly identification accuracy, including:

[0040] Extract the processing action type and target physical storage area identifier from the exception handling instruction, and determine the target operation type among access denial operation, request redirection operation, or key renegotiation operation for the access request based on the processing action type, to obtain the operation type determination result;

[0041] Based on the operation type determination result, if the target operation type is an access denial operation, a denial response is returned to the request source that initiated the access request, and the denial response carries the exception type identifier in the exception handling instruction.

[0042] If the target operation type is a request redirection operation, then the access request is redirected to the backup physical storage area according to the target physical storage area identifier;

[0043] If the target operation type is a key renegotiation operation, then the key negotiation process with the requesting source is initiated based on the key negotiation parameters in the exception handling instruction;

[0044] The processing result is used as feedback information and written into the exception handling log. The exception handling log is associated with the request feature set of the access request and the exception type identifier in the exception handling instruction to obtain the exception handling traceability record, so as to adaptively update the state transition rules.

[0045] A second aspect of the present invention provides a system for handling anomalies in encrypted solid-state drives, comprising:

[0046] The first unit is used to obtain the access request sequence and corresponding encryption status identifier generated by the encrypted solid-state drive during operation;

[0047] The second unit is used to parse each access request in the access request sequence based on preset state transition rules to obtain a set of request features;

[0048] The third unit is used to match the target logical address in the request feature set with the address mapping relationship maintained internally by the encrypted solid-state drive, determine the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area, and obtain the area mapping result;

[0049] The fourth unit is used to determine whether the current access request meets the encryption domain consistency constraint based on the region mapping result, the encryption status identifier, and the key index information in the access request. If it does not meet the constraint, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag to obtain the exception handling instruction.

[0050] The fifth unit is used to perform rejection, redirection, or key renegotiation operations on the access request based on the exception handling instruction, and use the processing result as feedback information to dynamically adjust the state transition rules in order to adaptively optimize the accuracy of exception identification.

[0051] A third aspect of the present invention provides an electronic device, comprising:

[0052] processor;

[0053] Memory used to store processor-executable instructions;

[0054] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0055] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0056] This invention obtains the solid-state drive access request sequence and encryption status identifier, parses the request feature set based on preset status transition rules, and then determines the physical storage area and encryption domain identifier through address mapping relationship matching. This enables accurate judgment of whether the access request meets the encryption domain consistency constraint, effectively avoiding the risk of data leakage due to improper key management.

[0057] This invention generates anomaly flags and formulates corresponding processing strategies for cases that do not meet the cryptographic domain consistency constraints. It implements differentiated processing mechanisms such as rejection, redirection, or key renegotiation, which significantly improves the flexibility and adaptability of the system in handling abnormal situations and ensures the stable operation of the encrypted storage system and data security.

[0058] This invention uses the processing results as feedback information to dynamically adjust the state transition rules, forming an adaptive optimization closed-loop control mechanism. This enables continuous optimization of anomaly identification accuracy based on actual operating conditions, reducing the false judgment rate and improving the security performance and user experience of encrypted solid-state drives in complex application scenarios. Attached Figure Description

[0059] Figure 1 This is a flowchart illustrating the anomaly handling method based on encrypted solid-state drives according to an embodiment of the present invention.

[0060] Figure 2 This is a flowchart illustrating the generation of exception handling instructions according to an embodiment of the present invention. Detailed Implementation

[0061] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0062] The technical solution of the present invention will be described in detail below with reference to specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0063] Figure 1 This is a flowchart illustrating the anomaly handling method based on encrypted solid-state drives according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0064] Obtain the sequence of access requests generated by the encrypted solid-state drive during operation and the corresponding encryption status identifiers;

[0065] Each access request in the access request sequence is parsed based on preset state transition rules to obtain a set of request features;

[0066] Based on the target logical address in the request feature set and the address mapping relationship maintained internally by the encrypted solid-state drive, the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area are determined to obtain the area mapping result;

[0067] Based on the region mapping result, the encryption status identifier, and the key index information in the access request, it is determined whether the current access request satisfies the encryption domain consistency constraint. If it does not, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag to obtain the exception handling instruction.

[0068] Based on the anomaly handling instructions, the access request is denied, redirected, or key renegotiation is performed, and the processing result is used as feedback information. The state transition rules are dynamically adjusted using the feedback information to adaptively optimize the anomaly identification accuracy.

[0069] This embodiment addresses the security vulnerability of existing encrypted solid-state drives in multi-tenant environments, where encrypted domain out-of-bounds access is a common issue.

[0070] In this embodiment, the encrypted solid-state drive (SSD) can be equipped with multiple encryption domains, each with its own encryption key. When the system is running, the encrypted SSD receives access requests from different applications or users. To ensure data security, the legitimacy of these requests needs to be monitored and verified in real time.

[0071] First, the access request sequence and corresponding encryption status identifiers generated during the operation of the encrypted SSD are obtained. The access request sequence contains multiple access requests, each including at least the operation type, target logical address, data length, and key index information. For example, a typical access request can be represented as {READ, LBA:0x8000, Length:4KB, KeyIndex:2}, indicating that 4KB of data starting from logical address 0x8000 is read using key index 2. The encryption status identifier records the current encryption operation status of the SSD, including the list of active encryption domains and the key status of each encryption domain. For example, the encryption status identifier can be represented as {ActiveDomains:[1,2,3],DomainKeyStatus:{1:valid, 2:valid, 3:pending}}, indicating that there are currently three active encryption domains, where the keys for domain 1 and domain 2 are valid, and the key for domain 3 is pending.

[0072] The specific implementation of obtaining the access request sequence can be achieved by setting a listening point in the command queue management module of the solid-state drive controller to capture all access commands entering the command queue in real time. The encryption status identifier can be obtained by querying the status register of the internal security management unit of the solid-state drive.

[0073] Each access request in the access request sequence is parsed based on preset state transition rules to obtain a request feature set. The state transition rules define the parsing logic for different access command types, such as the processing flow for read commands, write commands, and erase commands. For each access request, information such as the operation type, target logical address range, data length, and key index are extracted to form a request feature set. For complex commands, such as atomic writes or reads with conditional judgments, the state transition rules define more complex parsing logic. For example, for the request {WRITE, LBA:0x10000, Length:8KB, KeyIndex:1}, the parsed request feature set is {Operation:WRITE,LogicalAddressRange:[0x10000,0x12000],DataSize:8KB,KeyIndex:1,AccessPattern:Sequential}.

[0074] State transition rules can be predefined in a configuration file or dynamically adjusted based on the actual operating mode of the SSD. For example, for high-performance computing scenarios, the parsing efficiency of sequential read and write operations can be optimized; for database applications, the ability to identify random small I / O operations can be enhanced.

[0075] The system matches the target logical address in the request feature set with the address mapping relationship maintained internally by the encrypted solid-state drive (SSD) to determine the physical storage region corresponding to the target logical address and the associated encryption domain identifier, thus obtaining the region mapping result. The address mapping relationship is typically maintained by the flash translation layer (FTL) of the SSD, recording the correspondence between logical addresses and physical pages. It also needs to extend the record by including the encryption domain identifier of each physical storage region. For example, logical address 0x8000 can be mapped to physical page 0x2000, and this physical page belongs to encryption domain 2. In practice, an encryption domain identifier field can be added to the SSD's FTL mapping table, such as {LogicalAddress:0x8000, PhysicalAddress:0x2000, EncryptionDomainID:2, BlockStatus:valid}.

[0076] For access requests spanning multiple physical pages, it is necessary to verify that all involved physical pages belong to the same encryption domain. If cross-domain access is detected, it should be marked as a potential anomaly. For example, if a request is made to access the logical address range [0x8000, 0x9000], and the mapping result shows that the physical pages corresponding to this range belong to encryption domain 2 and encryption domain 3 respectively, then the generated region mapping result would be {AddressRange:[0x8000, 0x9000],PhysicalBlocks:[{PBA:0x2000,Domain:2},{PBA:0x3000,Domain:3}],CrossDomain:true}.

[0077] Based on the region mapping results, encryption status identifier, and key index information in the access request, it is determined whether the current access request meets the encryption domain consistency constraints. These constraints require that: the key index used in the access request must match the encryption domain associated with the target physical storage region; the access request should not cross different encryption domains; and the key in the access request must be valid. If these constraints are not met, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag, resulting in an exception handling instruction.

[0078] Anomalies can be categorized into key mismatch, cross-domain access, and invalid key status. For example, when a request is detected to access data belonging to encrypted domain 3 using key index 2, an anomaly flag {ErrorType:KeyMismatch,RequestKeyIndex:2,DomainRequired:3,Severity:High} is generated. Corresponding handling strategies are defined for different anomaly types: for high-risk anomalies such as key mismatch, the strategy is to directly deny access and log the security information; for medium-risk anomalies such as an impending key expiration, the strategy is to allow access but trigger a key renegotiation process; for low-risk anomalies such as abnormal access patterns but correct keys, the strategy is to allow access but increase monitoring frequency.

[0079] Based on exception handling instructions, access requests are rejected, redirected, or renegotiation is performed. The processing results are used as feedback information to dynamically adjust the state transition rules, adaptively optimizing the accuracy of exception identification. A rejection operation returns an error code indicating access denied to the requester; a redirection operation reroutes the request to the correct encryption domain; and a key renegotiation operation triggers a key update process between the encryption module and the security manager. For example, for the exception handling instruction {Action:Reject, LogEvent:true, NotifyAdmin:true}, the access request will be rejected, a detailed security log will be recorded, and the system administrator will be notified. The processing result is {Status:Rejected,ErrorCode:403, EventLogID:SEC20211025001}.

[0080] The feedback adjustment mechanism updates the parameters of the state transition rules using the processing results. For example, if a certain request pattern frequently triggers false alarms, the exception threshold for that pattern will be automatically adjusted; if a certain type of exception continues to increase, the sensitivity of the corresponding rule will be increased. In specific implementations, a counter can be used to record the frequency of occurrence of various exceptions, and when a preset threshold is reached, the rule parameters will be updated. For instance, when the false alarm rate of key mismatch exceptions exceeds 10% in a specific application scenario, the judgment logic will be adjusted to give more consideration to application behavior patterns.

[0081] By monitoring access requests to encrypted solid-state drives in real time, combined with encrypted state management and adaptive rule optimization, this method effectively prevents encrypted domain out-of-bounds access and key abuse, thus improving the security of the encrypted storage system. This approach is particularly suitable for multi-tenant scenarios in cloud computing environments, effectively isolating data from different users and preventing unauthorized access.

[0082] In one optional implementation, each access request in the access request sequence is parsed based on a preset state transition rule to obtain a request feature set, including:

[0083] Based on the access request structure template defined in the preset state transition rules, each access request in the access request sequence is segmented by field, and the command field, address field, and additional information field in the access request are identified to obtain the field combination;

[0084] For the command field in the field combination, the command field is converted into a standardized operation type identifier by querying the command type mapping table maintained in the preset state transition rules, thereby obtaining the operation type;

[0085] For the address field in the field combination, extract the logical address information carried in the address field, and use the logical address information as the target logical address. At the same time, parse the key index identifier from the additional information field to obtain the address and key association information.

[0086] Based on the request validity verification conditions defined in the preset state transition rules, the operation type, the target logical address, and the key index identifier are verified for integrity. The operation type, target logical address, and key index identifier that pass the integrity verification are combined to form the request feature set.

[0087] In this embodiment, the preset state transition rules include an access request structure template, a command type mapping table, and request validity verification conditions. The access request structure template defines the basic structure of the access request, including the arrangement and combination of command fields, address fields, and additional information fields. The command type mapping table maintains the correspondence between various command fields and standardized operation type identifiers. The request validity verification conditions specify the criteria for determining whether a request is valid.

[0088] When a sequence of access requests is received, each request is parsed and processed in turn. Taking a typical storage access request sequence as an example, it contains multiple access requests, such as "READ 0x4000 KEY_ID=5", "WRITE 0x5000DATA=0x12345 KEY_ID=8", and "ERASE 0x6000-0x7000 KEY_ID=3".

[0089] For the first access request "READ 0x4000 KEY_ID=5", the field is first segmented according to the access request structure template in the preset state transition rules. Through template matching, the command field is identified as "READ", the address field as "0x4000", and the additional information field as "KEY_ID=5", forming a field combination.

[0090] For the command field "READ", query the command type mapping table maintained in the preset state transition rules. This mapping table contains the mapping relationship between various commands and standardized operation type identifiers, such as: "READ" maps to "OP_READ", "WRITE" maps to "OP_WRITE", "ERASE" maps to "OP_ERASE", etc. By looking up the table, "READ" is converted into the standardized operation type identifier "OP_READ".

[0091] For the address field "0x4000", the logical address information "0x4000" carried within it is extracted as the target logical address. Simultaneously, the key index identifier "5" is parsed from the additional information field "KEY_ID=5". The target logical address "0x4000" is then associated with the key index identifier "5" to obtain the address-key association information.

[0092] Subsequently, based on the request validity verification conditions defined in the preset state transition rules, integrity verification is performed on the operation type "OP_READ", the target logical address "0x4000", and the key index identifier "5". Assuming the validity verification conditions stipulate that a read operation must have a valid address and the key index must be in the range of 1-10, then the validity of the target logical address (e.g., whether it is within the legal address range) and the key index "5" are checked to ensure they are within the range of 1-10 are verified.

[0093] After successful verification, the operation type "OP_READ", the target logical address "0x4000", and the key index identifier "5" are combined to form the request feature set {operation type: OP_READ, target logical address: 0x4000, key index identifier: 5}.

[0094] The second access request, "WRITE 0x5000 DATA=0x12345 KEY_ID=8", is processed in the same manner as described above. First, the fields are segmented, identifying the command field as "WRITE", the address field as "0x5000", and the additional information field as "DATA=0x12345 KEY_ID=8". Using the command type mapping table, "WRITE" is converted to "OP_WRITE". The target logical address "0x5000" is extracted from the address field, and the key index identifier "8" is parsed from the additional information field. After integrity verification, the request feature set is formed as follows: {Operation Type: OP_WRITE, Target Logical Address: 0x5000, Key Index Identifier: 8}.

[0095] The processing for the third access request, "ERASE 0x6000-0x7000 KEY_ID=3", is similar. After field splitting, we obtain the command field "ERASE", the address field "0x6000-0x7000", and the additional information field "KEY_ID=3". "ERASE" is converted to "OP_ERASE". The address field contains an address range; the start address "0x6000" and the end address "0x7000" are extracted as components of the target logical address. The key index identifier is "3". After integrity verification passes, the request feature set is formed: {Operation Type: OP_ERASE, Target Logical Address: {Start: 0x6000, End: 0x7000}, Key Index Identifier: 3}.

[0096] Through the above processing, the feature set of each request, including operation type, target logical address, and key index identifier, was successfully extracted from the access request sequence. These feature sets can be used in subsequent access control, security verification, and other processing steps, improving the system's security and reliability.

[0097] This implementation standardizes access requests through preset state transition rules, enabling unified management of different types of access requests; it filters out invalid requests that do not conform to the rules through integrity verification, improving system stability; and it extracts key features to form a feature set, providing a foundation for subsequent refined access control.

[0098] In one optional implementation, the target logical address in the request feature set is matched with the address mapping relationship maintained internally by the encrypted solid-state drive to determine the physical storage region corresponding to the target logical address and the encrypted domain identifier associated with the physical storage region, thereby obtaining a region mapping result, including:

[0099] Extract the target logical address from the request feature set, and search for the corresponding mapping table entry set in the address mapping relationship maintained inside the encrypted solid-state drive according to the target logical address;

[0100] In the set of mapping entries, by performing interval matching between the target logical address and the logical address segments in each mapping entry, a target mapping entry containing the target logical address is determined, and the physical storage area identifier mapped to the target logical address is read from the target mapping entry to obtain the physical area location result;

[0101] Based on the physical storage area identifier in the physical area location result, the encryption domain management structure maintained inside the encrypted solid-state drive is accessed. The encryption domain identifier associated with the physical storage area identifier and the key version information corresponding to the encryption domain identifier are queried from the encryption domain management structure to obtain the encryption domain association information.

[0102] The physical storage area identifier in the physical area location result is structurally combined with the encryption domain identifier and key version information in the encryption domain association information to obtain the area mapping result.

[0103] When an encrypted SSD receives a data access request from a host, the request contains a set of request features, including the target logical address information. To process this request correctly, the logical address in the request needs to be translated into the actual physical storage location, and the corresponding encryption field information needs to be determined. The target logical address information is extracted from the request feature set. For example, when the host sends a read request, the request feature set may contain the logical address 0x8000, indicating that it wants to read data starting from that address. This logical address 0x8000 will be extracted as the target logical address. After extraction, the corresponding mapping table entry needs to be searched in the address mapping relationship maintained internally by the encrypted SSD. These mapping table entry sets are typically stored in the SSD's DRAM cache or flash memory, organized using a tree structure or hash table structure to improve search efficiency.

[0104] The address mapping relationship is organized using a multi-level mapping table structure, such as a three-level mapping structure: directory table, page table, and mapping table entries. First, the high-order bits of the target logical address are used to determine the index in the directory table, finding the corresponding page table pointer. Then, the middle bits of the logical address are used to determine the index in the page table, finding the starting address of the mapping table entry set. For example, for the target logical address 0x8000, the high 8 bits (0x80) are extracted first as the directory table index, obtaining the corresponding page table address 0x10000; then, the next 8 bits (0x00) are used as the page table index, locating the address of the mapping table entry set 0x20000.

[0105] After obtaining the set of mapping entries, it is necessary to find the specific mapping entry containing the target logical address within the set. Each mapping entry contains a logical address range and a corresponding physical storage region identifier. The target mapping entry is determined by performing range matching between the target logical address and the logical address ranges in each mapping entry. The range matching method is as follows: check if the target logical address is greater than or equal to the start logical address of the mapping entry and less than or equal to the end logical address.

[0106] For example, the mapping table entry set contains the following three entries:

[0107] Entry 1: Logical address range [0x5000-0x6FFF], physical memory region identifier 0xA1000;

[0108] Item 2: Logical address range [0x7000-0x8FFF], physical memory region identifier 0xB2000;

[0109] Item 3: Logical address range [0x9000-0xAFFF], physical storage area identifier 0xC3000.

[0110] For the target logical address 0x8000, the check reveals that it falls within the logical address range of entry 2, thus identifying entry 2 as the target mapping entry. Subsequently, the physical storage region identifier 0xB2000 is read from this entry to obtain the physical region location result. If the target logical address has an offset, its exact location within the physical storage region is also calculated. For example, if the offset of the target logical address 0x8000 relative to the starting logical address 0x7000 of entry 2 is 0x1000, then its corresponding exact physical address is 0xB2000 + 0x1000 = 0xB3000.

[0111] After obtaining the physical region location result, it is necessary to determine the encrypted domain information associated with that physical storage region. This involves accessing the encrypted domain management structure maintained internally by the encrypted solid-state drive (SSD), which stores the association between physical storage regions and encrypted domains. The encrypted domain management structure typically uses a hash table or balanced tree structure, with the physical storage region identifier as the key and the associated encrypted domain identifier and key version information as the value.

[0112] Using the physical storage area identifier 0xB2000 from the physical area location result as the query key, the corresponding record is searched in the encryption domain management structure. Assuming the query result shows that the encryption domain identifier associated with physical storage area 0xB2000 is 0x03, and the corresponding key version information is 0x05, it indicates that data encryption and decryption operations are performed using the 5th version encryption key of encryption domain 3. This information constitutes the encryption domain association information.

[0113] Finally, the physical storage area identifier from the physical area location result is structurally combined with the encryption domain identifier and key version information from the encryption domain association information to generate the area mapping result. The structural combination method is to create a data structure containing three fields: physical storage area identifier, encryption domain identifier, and key version information. For this example, the final area mapping result is: {physical storage area identifier: 0xB2000, encryption domain identifier: 0x03, key version information: 0x05}.

[0114] This complete region mapping result will be used for subsequent data access operations, including the selection of encryption keys and data encryption / decryption processing, ensuring the security and correctness of data access. The entire matching process efficiently and accurately completes the conversion from logical address to physical address and encrypted information, providing fundamental support for secure data access to encrypted solid-state drives.

[0115] In one optional implementation, based on the physical storage area identifier in the physical area location result, the encryption domain management structure maintained internally by the encrypted solid-state drive is accessed. The encryption domain management structure is then used to query the encryption domain identifier associated with the physical storage area identifier and the key version information corresponding to that encryption domain identifier, thereby obtaining encryption domain association information, including:

[0116] Based on the region coding attribute of the physical storage region identifier, the physical group identifier to which the physical storage region belongs is determined, and the group affiliation information is obtained;

[0117] Based on the physical packet identifier in the packet attribution information, locate the encryption domain configuration table corresponding to the physical packet identifier in the encryption domain management structure;

[0118] In the encrypted domain configuration table, by matching the physical storage area identifier with the range of physical storage area identifiers recorded in each entry of the encrypted domain configuration table, the target encrypted domain entry to which the physical storage area identifier belongs is determined, and the corresponding encrypted domain identifier is read from the target encrypted domain entry to obtain the domain identifier query result;

[0119] Based on the encrypted domain identifier in the domain identifier query result, the key version index table maintained in the encrypted domain management structure is accessed, and the currently valid key version identifier associated with the encrypted domain identifier and the key lifecycle status corresponding to the key version identifier are retrieved from the key version index table to obtain the key version query result;

[0120] The encrypted domain identifier in the domain identifier query result is associated and integrated with the current valid key version identifier and key lifecycle status in the key version query result to obtain the encrypted domain association information.

[0121] In the encrypted domain management of encrypted solid-state drives, the following method can be used to access the internally maintained encrypted domain management structure based on the physical storage area identifier in the physical area location result.

[0122] After obtaining the physical region location result, the first step is to determine the physical group identifier to which the physical storage region belongs based on the region coding attribute of the physical storage region identifier, thus obtaining the group affiliation information. For example, assuming the physical storage region identifier is "P2048", by parsing the encoding rule of the identifier, it can be determined that it belongs to the physical group "PG16". In specific implementation, the group information bits in the physical storage region identifier can be extracted through bit operations, such as taking the high 8 bits of the identifier as the group index, mapping "P2048" to the "PG16" group.

[0123] After obtaining the packet attribution information, the corresponding encrypted domain configuration table is located in the encrypted domain management structure based on the physical packet identifier "PG16". The encrypted domain management structure can be designed as a hierarchical structure, containing a packet index table and the encrypted domain configuration table corresponding to each packet. By searching for the entry with the key value "PG16" in the packet index table, a pointer or offset to the corresponding encrypted domain configuration table is obtained. For example, the configuration table location corresponding to "PG16" in the packet index table is stored at 0x4A000.

[0124] Next, in the located encryption domain configuration table, the target encryption domain entry to which the physical storage region identifier belongs is determined by matching the physical storage region identifier with the range of physical storage region identifiers in each entry record in the table. The encryption domain configuration table structure can contain multiple entries, each including a start physical region identifier, an end physical region identifier, and a corresponding encryption domain identifier field. For the physical storage region identifier "P2048", each entry in the encryption domain configuration table is checked. When an entry's region range is found to contain "P2048", such as an entry record range of "P2000-P3000", then that entry is determined to be the target encryption domain entry. The corresponding encryption domain identifier, such as "ED_35", is read from this entry to obtain the domain identifier query result.

[0125] After obtaining the domain identifier query result, the key version index table maintained in the encrypted domain management structure is accessed based on the encrypted domain identifier "ED_35". The key version index table stores the key version information currently used by each encrypted domain and its lifecycle status. The table structure includes an encrypted domain identifier field, a currently valid key version identifier field, and a key lifecycle status field. The entry with the encrypted domain identifier "ED_35" is retrieved from the key version index table, and its currently valid key version identifier (e.g., "KV_102") and corresponding key lifecycle status (e.g., "ACTIVE") are read to form the key version query result.

[0126] Finally, the encrypted domain identifier "ED_35" from the domain identifier query result is associated and integrated with the currently valid key version identifier "KV_102" and the key lifecycle status "ACTIVE" from the key version query result to generate encrypted domain association information. The integrated information can be represented as a structure containing a triple: {encrypted domain identifier: ED_35, key version identifier: KV_102, lifecycle status: ACTIVE}. This association information will be used for subsequent data encryption and decryption operations.

[0127] In practical implementation, to improve query efficiency, the encrypted domain configuration table can adopt data structures such as interval trees or ordered arrays, supporting fast location of intervals containing specified physical region identifiers. For example, using a binary search algorithm to locate the interval containing "P2048" in an ordered interval boundary array optimizes the search complexity from linear to logarithmic.

[0128] The key version index table can be implemented as a hash table structure, using the encryption field identifier as the key and the key version and lifecycle information as the value, achieving constant-time lookup. For example, a hash table with a capacity of 256 can be constructed, and the hash function can be used to map "ED_35" to table index 87, allowing direct access to that position to retrieve the corresponding key version information.

[0129] Data access throughout the query process is conducted via a secure channel built into the hard disk controller, ensuring that the encrypted domain management structure itself is not accessed by unauthorized personnel. The controller can implement access control lists, allowing only authorized processing units to access these sensitive data structures.

[0130] Through the above, the corresponding encryption domain identifier and key version information can be efficiently queried based on the physical storage area identifier, providing the necessary key management support for secure data access of encrypted solid-state drives and realizing secure isolation of data between storage areas.

[0131] In one optional implementation, based on the region mapping result, the encryption status identifier, and the key index information in the access request, it is determined whether the current access request satisfies the encryption domain consistency constraint. If it does not, an exception flag is generated, and a corresponding processing strategy is determined based on the exception type of the exception flag to obtain an exception handling instruction, including:

[0132] The request key identifier indicated in the key index information is compared with the currently valid key version identifier recorded in the key version information associated with the encryption field identifier to obtain the key consistency determination result;

[0133] Based on the key consistency determination result, the key lifecycle status in the key version information is checked to determine whether the key corresponding to the requested key identifier is in an invalid or rotated state. Combined with the global encryption status, it is determined whether the encrypted solid-state drive is in a key migration process, and the result of the anomaly analysis is obtained.

[0134] Based on the anomaly cause analysis results, if it is determined that the current access request does not meet the encryption domain consistency constraint, an anomaly tag containing an anomaly type identifier is generated. The anomaly type identifier generates a classification anomaly tag based on the inconsistency causes identified in the anomaly cause analysis results.

[0135] Based on the anomaly type identifier in the anomaly classification marker, the processing strategy template corresponding to the anomaly type identifier is queried in the preset anomaly handling strategy mapping table;

[0136] An exception handling instruction is generated based on the processing strategy template and the physical storage area identifier in the area mapping result.

[0137] Figure 2 This is a flowchart illustrating the generation of exception handling instructions according to an embodiment of the present invention. Figure 2 As shown, in the process of implementing encryption domain consistency verification and anomaly handling, a comprehensive judgment is made based on the region mapping result, encryption status identifier, and key index information in the access request to ensure the security and consistency of data access. When the encrypted solid-state drive receives an access request, the controller first obtains the key index information contained in the request, and at the same time reads the current encryption status identifier and encryption domain configuration information from the secure region.

[0138] Extract the request key identifier, such as "KEY_ID_123", from the access request, and then compare it with the key version information associated with the current encryption domain identifier stored in the secure area. For example, if the current valid key version identifier is "KEY_ID_123_V2", but the request uses "KEY_ID_123_V1", a key consistency determination result of mismatch will be generated.

[0139] The key consistency determination result is further examined by checking the key lifecycle status recorded in the key version information. In the key version information data structure, each key identifier is associated with a lifecycle status field; for example, the status of "KEY_ID_123_V1" is marked as expired or in rotation. The global encryption status identifier is also checked to determine whether the entire encrypted SSD is in the process of key migration. For example, a global status of "KEY_MIGRATION_IN_PROGRESS" indicates that key migration is in progress.

[0140] By comprehensively analyzing this information, an anomaly cause analysis result is generated. For example, if the requested key identifier is "KEY_ID_123_V1", while the currently valid version is "KEY_ID_123_V2", and the status of "KEY_ID_123_V1" is expired, and the global encryption status is "KEY_MIGRATION_COMPLETED", then the anomaly cause analysis result is "The requested key version has expired, and the key migration has been completed".

[0141] Based on the anomaly cause analysis results, anomaly markers containing anomaly type identifiers are generated. The anomaly type identifiers are classified according to the inconsistency cause. For example, "TYPE_EXPIRED_KEY_ACCESS" indicates that an expired key was attempted, "TYPE_KEY_ROTATION_IN_PROGRESS" indicates that the key is being rotated, or "TYPE_DOMAIN_MISMATCH" indicates that the encryption fields do not match.

[0142] The exception handling policy mapping table is stored in the controller's security area and contains preset handling policy templates. This table structure includes an exception type identifier field and a corresponding handling policy template field. For example, for an exception of type "TYPE_EXPIRED_KEY_ACCESS", the corresponding handling policy template is "TEMPLATE_REJECT_WITH_ERROR", indicating that the request is directly rejected and an error is returned; for an exception of type "TYPE_KEY_ROTATION_IN_PROGRESS", the corresponding handling policy template is "TEMPLATE_RETRY_WITH_NEW_KEY", indicating that an attempt will be made to retry using a new key.

[0143] Based on the retrieved processing policy template and the physical storage region identifier in the region mapping results, the final exception handling instruction is generated. For example, for an access request with a physical block address range of "PBA_10000-PBA_20000", if the policy template is "TEMPLATE_REJECT_WITH_ERROR", the generated exception handling instruction is {command:REJECT,error_code:0x0503,physical_address_range:PBA_10000-PBA_20000}; if the policy template is "TEMPLATE_RETRY_WITH_NEW_KEY", the generated exception handling instruction is {command:RETRY,new_key_id:KEY_ID_123_V2,physical_address_range: PBA_10000-PBA_20000}.

[0144] These exception handling instructions are passed to the SSD's execution engine, which then performs corresponding operations based on the instructions, such as denying the access request, retrying with a new key, or logging the security log. For example, when an access denial instruction is executed, the controller returns the corresponding error code to the host and logs the abnormal access event in the security log; when a retry with a new key instruction is executed, the controller re-encrypts or decrypts the data using the currently valid key version and completes the access request.

[0145] Through this fine-grained anomaly handling mechanism, encrypted solid-state drives can ensure the security and consistency of data access in scenarios such as key rotation, key expiration, and encryption domain changes. Meanwhile, differentiated handling strategies for different types of anomalies also improve system flexibility and user experience. For example, recoverable anomalies are automatically retried using a valid key, while anomalies posing serious security risks are directly rejected and alerted, thereby maximizing system availability while ensuring security.

[0146] In one optional implementation, the key lifecycle status in the key version information is checked based on the key consistency determination result to determine whether the key corresponding to the requested key identifier is in an expired or rotated state. The global encryption status is then combined to determine whether the encrypted solid-state drive is in a key migration process, resulting in an anomaly analysis, including:

[0147] Based on the key consistency determination result, if it is determined that the requested key identifier is inconsistent with the current valid key version identifier, then the key lifecycle status identifier associated with the requested key identifier is extracted from the key version information, and the system-level key management status identifier of the encrypted solid-state drive is extracted from the global encryption status to obtain a set of status information;

[0148] Based on the key lifecycle status identifier in the status information set, determine the current lifecycle stage of the key corresponding to the request key identifier, and determine whether the key is in an expired state or a rotation transition state to obtain the key status determination result;

[0149] Based on the system-level key management status identifier in the status information set, it is determined whether the encrypted solid-state drive is performing a key migration operation across encryption domains, and a system status determination result is obtained;

[0150] Based on the key status determination result and the system status determination result, the abnormal causes are classified into key failure anomalies, key version mismatch anomalies, or key migration conflict anomalies, resulting in an anomaly cause analysis result that includes the anomaly cause category and the corresponding status basis.

[0151] When a key verification failure is detected, further analysis of the cause of the anomaly is needed to take appropriate measures. For key verification failures, the key lifecycle status in the key version information is checked to determine whether the key corresponding to the requested key identifier is in an expired or rotated state. This, combined with the global encryption status, determines whether the encrypted solid-state drive is in the process of key migration, thus obtaining the anomaly cause analysis results.

[0152] In practice, the process begins by determining the key consistency. If the requested key identifier is inconsistent with the current valid key version identifier, an anomaly analysis process is executed. This process extracts the key lifecycle status identifier associated with the requested key identifier from the key version information and extracts the system-level key management status identifier of the encrypted solid-state drive from the global encryption status, resulting in a set of status information.

[0153] To illustrate with a specific example, suppose a storage device receives a data decryption request with a request key identifier of "KEY_ID_0x5A3F", while the currently recorded valid key version identifier is "KEY_ID_0x7B2D". Upon detecting the key mismatch, the device queries the key version information table for the record "KEY_ID_0x5A3F" and extracts its lifecycle status identifier as "DEPRECATED" (obsolete). Simultaneously, it extracts the system-level key management status identifier as "NORMAL" (normal state) from the global encryption status. This yields a set of status information containing both the key lifecycle status and the system key management status.

[0154] Next, based on the key lifecycle status identifier in the status information set, the current lifecycle stage of the key corresponding to the requested key identifier is determined to identify whether the key is in an expired or transitional state, thus obtaining the key status determination result. In the above case, checking the "DEPRECATED" status determines that the key has entered the expired stage and is no longer a currently valid encryption key.

[0155] Key lifecycle states typically include "ACTIVE", "ROTATING", "DEPRECATED", and "REVOKED". According to preset state mapping rules, "DEPRECATED" and "REVOKED" are determined as invalid states, "ROTATING" is determined as a transitional state, and "ACTIVE" is a normal state.

[0156] Based on the system-level key management status identifier in the status information set, the system determines whether the encrypted solid-state drive is performing a key migration operation across encryption domains, thus obtaining the system status determination result. System-level key management statuses include "NORMAL," "MIGRATING," and "RECOVERY." In the example, the system status is "NORMAL," indicating that the device is not currently performing a key migration operation.

[0157] Finally, based on the key status determination result and the system status determination result, the cause of the anomaly is classified into a specific type. In this example, since the key status determination result shows that the key is in a deactivated state (DEPRECATED) and the system status determination result shows that the device is in a normal state (NORMAL), the anomaly is classified as a key deactivated anomaly, and the cause of the anomaly is recorded as "The requested key KEY_ID_0x5A3F has been deactivated, and the currently valid key is KEY_ID_0x7B2D".

[0158] In another scenario, if the requested key identifier is “KEY_ID_0x6C1E”, its lifecycle status is “ROTATING”, and the system-level key management status is “NORMAL”, it is determined to be a “key version mismatch exception”, indicating that the request uses an older version key that is in the process of being rotated.

[0159] For example, if the requested key identifier is "KEY_ID_0x8D4F" and the lifecycle status is "ACTIVE", but the system-level key management status is "MIGRATING", it is judged as a "key migration conflict exception", indicating that a cross-encryption domain key migration operation is currently in progress and the requested key cannot be used temporarily.

[0160] A complete anomaly analysis result includes the anomaly cause category and corresponding status basis, for example: "Anomaly type: Key expiration anomaly; Status basis: The lifecycle status of the requested key (KEY_ID_0x5A3F) is DEPRECATED, and the system key management status is NORMAL; Suggested action: Re-encrypt the data using the currently valid key (KEY_ID_0x7B2D)."

[0161] Through the detailed analysis of the above-mentioned causes of anomalies, accurate problem diagnosis can be provided for different types of key verification failures, helping the storage device management system to automatically select appropriate recovery strategies. For example, for key invalidation anomalies, the user can be prompted to re-encrypt the data using a new key; for key version mismatch anomalies, the system can automatically try to use the currently valid key version; for key migration conflict anomalies, the system can wait for the migration to complete and then retry the operation.

[0162] In one optional implementation, the access request is denied, redirected, or key renegotiation is performed based on the anomaly handling instruction, and the processing result is used as feedback information. The state transition rules are dynamically adjusted using the feedback information to adaptively optimize the anomaly identification accuracy, including:

[0163] Extract the processing action type and target physical storage area identifier from the exception handling instruction, and determine the target operation type among access denial operation, request redirection operation, or key renegotiation operation for the access request based on the processing action type, to obtain the operation type determination result;

[0164] Based on the operation type determination result, if the target operation type is an access denial operation, a denial response is returned to the request source that initiated the access request, and the denial response carries the exception type identifier in the exception handling instruction.

[0165] If the target operation type is a request redirection operation, then the access request is redirected to the backup physical storage area according to the target physical storage area identifier;

[0166] If the target operation type is a key renegotiation operation, then the key negotiation process with the requesting source is initiated based on the key negotiation parameters in the exception handling instruction;

[0167] The processing result is used as feedback information and written into the exception handling log. The exception handling log is associated with the request feature set of the access request and the exception type identifier in the exception handling instruction to obtain the exception handling traceability record, so as to adaptively update the state transition rules.

[0168] When an abnormal access request is detected, a corresponding exception handling instruction is generated. By executing the exception handling instruction, the access request can be rejected, redirected, or the key can be renegotiationd. The processing result is used as feedback information to dynamically adjust the state transition rules in order to optimize the accuracy of exception identification.

[0169] In the specific implementation process, the processing action type and the target physical storage area identifier are first extracted from the exception handling instruction. The processing action type is one of access denial, request redirection, or key renegotiation. For example, when the processing instruction content is {Action type: access denial, Exception type: unauthorized access, Target area: null}, the extracted action type is access denial and the exception type is unauthorized access; when the instruction content is {Action type: request redirection, Exception type: temporary congestion, Target area: STOR-B32}, the extracted action type is request redirection and the target area is STOR-B32; when the instruction content is {Action type: key renegotiation, Exception type: key expired, Negotiation parameters: {Encryption algorithm: AES-256, Key length: 256}}, the extracted action type is key renegotiation and related parameters.

[0170] The target operation type is determined based on the extracted processing action type. In the implementation, an action mapping table is maintained to map processing action types to specific operation execution functions. For example, "deny access" maps to the `rejectAccess()` function, "redirect request" maps to the `redirectRequest()` function, and "key renegotiation" maps to the `renegotiateKey()` function. This table lookup method quickly determines the target operation type to be executed.

[0171] When the target operation is determined to be an access denied operation, a denial response is returned to the requesting source, carrying an exception type identifier in the response. For example, when user ID "user_123" attempts to access file "secure_document.pdf" from IP address "192.168.1.100", if this is detected as unauthorized access, a denial response message is generated: "Access denied: An unauthorized access attempt was detected. Please contact the system administrator to obtain appropriate permissions." This response is returned to the requesting source with HTTP status code 403 Forbidden, and the denial event is recorded, including the timestamp "2023-05-15 14:23:07", requesting source information, target resource, and reason for denial.

[0172] When the target operation type is determined to be a request redirection operation, the access request is redirected to the backup physical storage area based on the target physical storage area identifier. For example, if the primary storage area "STOR-A15" is detected to be overloaded, the original access request " / storage / STOR-A15 / data.bin" is redirected to the backup storage area "STOR-B32", and the actual access path becomes " / storage / STOR-B32 / data.bin". A 307 Temporary Redirect response is generated, setting the Location field in the response header to the new access path. Simultaneously, this redirection operation is recorded, including the original request path, the redirection target path, the redirection reason, and a timestamp.

[0173] When the target operation is determined to be a key renegotiation operation, a key negotiation process with the requesting source is initiated based on the key negotiation parameters in the exception handling instruction. For example, if it is detected that the encryption key used by user "user_456" has expired, a renegotiation process will be initiated. The negotiation process includes: generating a temporary session identifier "session_78912"; sending a negotiation request message to the requesting source, containing a list of supported encryption algorithms [AES-256, ChaCha20] and suggested key lengths [256, 512]; waiting for the requesting source to select specific parameters and reply; after verifying the identity of the requesting source, generating a new key using the negotiated parameters; securely transmitting the new key to the requesting source; and updating the key record in the system, marking the old key as invalid and the new key as valid. The entire negotiation process is completed through a TLS encrypted channel to ensure secure key exchange.

[0174] After completing the above operations, the processing result is written as feedback information to the exception handling log. The log also associates the request characteristic set and exception type identifier of the access request, forming an exception handling traceability record. For example, the log content for an access denial operation may include: {Time: 2023-05-15 14:23:07, Operation: Access Denied, Request Source: user_123@192.168.1.100, Requested Resource: secure_document.pdf, Exception Type: Unauthorized Access, Result: 403 Denied Response Returned to User}. The log content for a redirection operation may include: {Time: 2023-05-15 15:30:22, Operation: Request Redirection, Original Path: / storage / STOR-A15 / data.bin, Redirection Path: / storage / STOR-B32 / data.bin, Exception Type: Temporary Congestion, Result: Redirection Successful, 307 Status Code Returned}. The log content for the key renegotiation operation may include: {Time: 2023-05-15 16:45:33, Operation: Key Renegotiation, Request Source: user_456, Original Key ID: key_98765, New Key ID: key_98766, Exception Type: Key Expired, Negotiation Algorithm: AES-256, Key Length: 256, Result: Negotiation successful, new key has been deployed}.

[0175] These anomaly handling traceability records are analyzed regularly to adaptively update state transition rules. For example, if a large number of normal accesses are misjudged as anomalies during a specific time period (e.g., 9:00-10:00 AM daily), leading to frequent operation rejections, the corresponding state transition rules will be adjusted to increase the anomaly detection threshold for that time period. Similarly, if a certain type of redirection operation consistently resolves access issues, the weight given to selecting redirection operations in such cases will be increased. Through this feedback mechanism based on actual processing results, the accuracy of anomaly identification is continuously optimized, improving the efficiency of storage access security management and enhancing the user experience.

[0176] The encrypted solid-state drive-based anomaly handling system of this invention includes:

[0177] The first unit is used to obtain the access request sequence and corresponding encryption status identifier generated by the encrypted solid-state drive during operation;

[0178] The second unit is used to parse each access request in the access request sequence based on preset state transition rules to obtain a set of request features;

[0179] The third unit is used to match the target logical address in the request feature set with the address mapping relationship maintained internally by the encrypted solid-state drive, determine the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area, and obtain the area mapping result;

[0180] The fourth unit is used to determine whether the current access request meets the encryption domain consistency constraint based on the region mapping result, the encryption status identifier, and the key index information in the access request. If it does not meet the constraint, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag to obtain the exception handling instruction.

[0181] The fifth unit is used to perform rejection, redirection, or key renegotiation operations on the access request based on the exception handling instruction, and use the processing result as feedback information to dynamically adjust the state transition rules in order to adaptively optimize the accuracy of exception identification.

[0182] A third aspect of the present invention provides an electronic device, comprising:

[0183] processor;

[0184] Memory used to store processor-executable instructions;

[0185] The processor is configured to invoke instructions stored in the memory to execute the aforementioned method.

[0186] A fourth aspect of the present invention provides a computer-readable storage medium having stored thereon computer program instructions that, when executed by a processor, implement the aforementioned method.

[0187] This invention can be a method, apparatus, system, and / or computer program product. The computer program product may include a computer-readable storage medium having computer-readable program instructions loaded thereon for performing various aspects of the invention.

[0188] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for handling anomalies in encrypted solid-state drives, characterized in that: include: Obtain the sequence of access requests generated by the encrypted solid-state drive during operation and the corresponding encryption status identifiers; Each access request in the access request sequence is parsed based on preset state transition rules to obtain a set of request features; Based on the target logical address in the request feature set and the address mapping relationship maintained internally by the encrypted solid-state drive, the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area are determined to obtain the area mapping result; Based on the region mapping result, the encryption status identifier, and the key index information in the access request, it is determined whether the current access request satisfies the encryption domain consistency constraint. If it does not, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag to obtain the exception handling instruction. Based on the anomaly handling instructions, the access request is denied, redirected, or key renegotiation is performed, and the processing result is used as feedback information. The state transition rules are dynamically adjusted using the feedback information to adaptively optimize the anomaly identification accuracy.

2. The method according to claim 1, characterized in that, Each access request in the access request sequence is parsed based on preset state transition rules to obtain a set of request features, including: Based on the access request structure template defined in the preset state transition rules, each access request in the access request sequence is segmented by field, and the command field, address field, and additional information field in the access request are identified to obtain the field combination; For the command field in the field combination, the command field is converted into a standardized operation type identifier by querying the command type mapping table maintained in the preset state transition rules, thereby obtaining the operation type; For the address field in the field combination, extract the logical address information carried in the address field, and use the logical address information as the target logical address. At the same time, parse the key index identifier from the additional information field to obtain the address and key association information. Based on the request validity verification conditions defined in the preset state transition rules, the operation type, the target logical address, and the key index identifier are verified for integrity. The operation type, target logical address, and key index identifier that pass the integrity verification are combined to form the request feature set.

3. The method according to claim 1, characterized in that, Based on the target logical address in the request feature set and the address mapping relationship maintained internally by the encrypted solid-state drive, the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area are determined to obtain the area mapping result, including: Extract the target logical address from the request feature set, and search for the corresponding mapping table entry set in the address mapping relationship maintained inside the encrypted solid-state drive according to the target logical address; In the set of mapping entries, by performing interval matching between the target logical address and the logical address segments in each mapping entry, a target mapping entry containing the target logical address is determined, and the physical storage area identifier mapped to the target logical address is read from the target mapping entry to obtain the physical area location result; Based on the physical storage area identifier in the physical area location result, the encryption domain management structure maintained inside the encrypted solid-state drive is accessed. The encryption domain identifier associated with the physical storage area identifier and the key version information corresponding to the encryption domain identifier are queried from the encryption domain management structure to obtain the encryption domain association information. The physical storage area identifier in the physical area location result is structurally combined with the encryption domain identifier and key version information in the encryption domain association information to obtain the area mapping result.

4. The method according to claim 3, characterized in that, Based on the physical storage area identifier in the physical area location result, the encryption domain management structure maintained internally by the encrypted solid-state drive is accessed. The encryption domain identifier associated with the physical storage area identifier and the key version information corresponding to that encryption domain identifier are queried from the encryption domain management structure to obtain encryption domain association information, including: Based on the region coding attribute of the physical storage region identifier, the physical group identifier to which the physical storage region belongs is determined, and the group affiliation information is obtained; Based on the physical packet identifier in the packet attribution information, locate the encryption domain configuration table corresponding to the physical packet identifier in the encryption domain management structure; In the encrypted domain configuration table, by matching the physical storage area identifier with the range of physical storage area identifiers recorded in each entry of the encrypted domain configuration table, the target encrypted domain entry to which the physical storage area identifier belongs is determined, and the corresponding encrypted domain identifier is read from the target encrypted domain entry to obtain the domain identifier query result; Based on the encrypted domain identifier in the domain identifier query result, the key version index table maintained in the encrypted domain management structure is accessed, and the currently valid key version identifier associated with the encrypted domain identifier and the key lifecycle status corresponding to the key version identifier are retrieved from the key version index table to obtain the key version query result; The encrypted domain identifier in the domain identifier query result is associated and integrated with the current valid key version identifier and key lifecycle status in the key version query result to obtain the encrypted domain association information.

5. The method according to claim 1, characterized in that, Based on the region mapping result, the encryption status identifier, and the key index information in the access request, it is determined whether the current access request satisfies the encryption domain consistency constraint. If it does not, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag, resulting in exception handling instructions, including: The request key identifier indicated in the key index information is compared with the currently valid key version identifier recorded in the key version information associated with the encryption field identifier to obtain the key consistency determination result; Based on the key consistency determination result, the key lifecycle status in the key version information is checked to determine whether the key corresponding to the requested key identifier is in an invalid or rotated state. Combined with the global encryption status, it is determined whether the encrypted solid-state drive is in a key migration process, and the result of the anomaly analysis is obtained. Based on the anomaly cause analysis results, if it is determined that the current access request does not meet the encryption domain consistency constraint, an anomaly tag containing an anomaly type identifier is generated. The anomaly type identifier generates a classification anomaly tag based on the inconsistency causes identified in the anomaly cause analysis results. Based on the anomaly type identifier in the anomaly classification marker, the processing strategy template corresponding to the anomaly type identifier is queried in the preset anomaly handling strategy mapping table; An exception handling instruction is generated based on the processing strategy template and the physical storage area identifier in the area mapping result.

6. The method according to claim 5, characterized in that, Based on the key consistency determination result, the key lifecycle status in the key version information is checked to determine whether the key corresponding to the requested key identifier is in an expired or rotated state. Combined with the global encryption status, it is determined whether the encrypted solid-state drive is in a key migration process, resulting in an anomaly analysis, including: Based on the key consistency determination result, if it is determined that the requested key identifier is inconsistent with the current valid key version identifier, then the key lifecycle status identifier associated with the requested key identifier is extracted from the key version information, and the system-level key management status identifier of the encrypted solid-state drive is extracted from the global encryption status to obtain a set of status information; Based on the key lifecycle status identifier in the status information set, determine the current lifecycle stage of the key corresponding to the request key identifier, and determine whether the key is in an expired state or a transitional state, thus obtaining the key status determination result; Based on the system-level key management status identifier in the status information set, it is determined whether the encrypted solid-state drive is performing a key migration operation across encryption domains, and a system status determination result is obtained; Based on the key status determination result and the system status determination result, the abnormal causes are classified into key failure anomalies, key version mismatch anomalies, or key migration conflict anomalies, resulting in an anomaly cause analysis result that includes the anomaly cause category and the corresponding status basis.

7. The method according to claim 1, characterized in that, Based on the anomaly handling instructions, the access request is denied, redirected, or key renegotiation is performed, and the processing result is used as feedback information. The state transition rules are dynamically adjusted using this feedback information to adaptively optimize the anomaly identification accuracy, including: Extract the processing action type and target physical storage area identifier from the exception handling instruction, and determine the target operation type among access denial operation, request redirection operation, or key renegotiation operation for the access request based on the processing action type, to obtain the operation type determination result; Based on the operation type determination result, if the target operation type is an access denial operation, a denial response is returned to the request source that initiated the access request, and the denial response carries the exception type identifier in the exception handling instruction. If the target operation type is a request redirection operation, then the access request is redirected to the backup physical storage area according to the target physical storage area identifier; If the target operation type is a key renegotiation operation, then the key negotiation process with the requesting source is initiated based on the key negotiation parameters in the exception handling instruction; The processing result is used as feedback information and written into the exception handling log. The exception handling log is associated with the request feature set of the access request and the exception type identifier in the exception handling instruction to obtain the exception handling traceability record, so as to adaptively update the state transition rules.

8. A system for handling anomalies in encrypted solid-state drives, used to implement the method as described in any one of claims 1-7, characterized in that, include: The first unit is used to obtain the access request sequence and corresponding encryption status identifier generated by the encrypted solid-state drive during operation; The second unit is used to parse each access request in the access request sequence based on preset state transition rules to obtain a set of request features; The third unit is used to match the target logical address in the request feature set with the address mapping relationship maintained internally by the encrypted solid-state drive, determine the physical storage area corresponding to the target logical address and the encrypted domain identifier associated with the physical storage area, and obtain the area mapping result; The fourth unit is used to determine whether the current access request meets the encryption domain consistency constraint based on the region mapping result, the encryption status identifier, and the key index information in the access request. If it does not meet the constraint, an exception flag is generated, and the corresponding processing strategy is determined based on the exception type of the exception flag to obtain the exception handling instruction. The fifth unit is used to perform rejection, redirection, or key renegotiation operations on the access request based on the exception handling instruction, and use the processing result as feedback information to dynamically adjust the state transition rules in order to adaptively optimize the accuracy of exception identification.

9. An electronic device, characterized in that, include: processor; Memory used to store processor-executable instructions; The processor is configured to invoke instructions stored in the memory to execute the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1 to 7.

Images