Key management method and storage device

Abstract

The invention discloses a key management method and a storage device, and belongs to the field of storage security, the method comprises the following steps: deriving different types of key fragments from an authentication key according to different preset classification strategies, and respectively storing the different types of key fragments in different storage partitions corresponding to the preset classification strategies; receiving a data access request, wherein the data access request comprises data index information; based on different preset classification strategies, reading candidate key fragments matched with the data index information from the different storage partitions respectively, verifying the legality of the candidate key fragments matched with the data index information, and determining the candidate key fragments passing the verification as effective key fragments; and aggregating the effective key fragments of different types to generate the authentication key, and obtaining target access data of the data access request through the authentication key. According to the invention, the security of key storage and the flexibility of key management can be effectively improved.

Description

Technical Field

[0001] This invention relates to the field of storage security, and more particularly to a key management method and a storage device. Background Technology

[0002] In mobile devices, IoT terminals, and embedded systems, RPMB (Replay Protected Memory Block) technology has been widely used to ensure the integrity and confidentiality of critical data. RPMB provides important security protection for sensitive data by authenticating read and write operations on the storage area and introducing a counting mechanism to resist replay attacks.

[0003] However, existing RPMB schemes still have significant shortcomings in key storage and management. Most common RPMB key storage schemes currently employ static partitioning, meaning a fixed-size secure storage area is pre-allocated at the factory. This approach has the following drawbacks: First, it presents a single point of failure risk: with keys centrally stored in a single static partition, an attacker can obtain all key materials simply by breaching the partition's defenses. Second, it lacks scalability and flexibility: fixed-size storage partitions cannot support dynamic key derivation or multiple key rotation requirements, failing to adapt to increasingly complex application scenarios and security requirements. Furthermore, RPMB keys are typically fixed in a hardware secure area. While this method provides a degree of isolation, it remains vulnerable to physical attacks, including but not limited to fault injection and side-channel analysis, allowing attackers to extract or destroy key materials. Once a key is leaked due to a physical attack, the entire RPMB security mechanism relying on that key risks complete failure.

[0004] Although the RPMB mechanism itself is designed with replay protection, if there are vulnerabilities in the key management process or the key has been leaked, attackers may still exploit potential flaws in the logic or implementation of the replay protection mechanism, combined with stolen keys, to launch a replay attack. This could result in unauthorized data being written into the protected area or critical data being illegally read, seriously compromising the security of the system. Summary of the Invention

[0005] The technical problem to be solved by the present invention is to provide a key management method and storage device that can effectively improve the security of key storage and the flexibility of key management.

[0006] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A key management method, comprising: Different types of key fragments are derived from the authentication key according to different preset classification strategies, and the different types of key fragments are stored in different storage partitions corresponding to the preset classification strategies. Receive a data access request, the data access request including data index information; Based on different preset classification strategies, the legality of candidate key fragments that match the data index information is read from different storage partitions and verified, and the candidate key fragments that pass the verification are determined as valid key fragments. The valid keys of different types are fragmented and aggregated to generate the authentication key, and the target access data of the data access request is obtained through the authentication key.

[0007] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A storage device includes a storage chip and a control chip, wherein the storage chip stores a computer program, and when the computer program is executed by the control chip, it implements the various steps of the aforementioned key management method.

[0008] The beneficial effects of this invention are as follows: First, different preset classification strategies are used to decompose the authentication key into different types of key fragments, which are then stored in corresponding storage partitions. This distributed storage mechanism eliminates the risk of single points of failure and adapts to the dynamic needs of different application scenarios. During the data access phase, a multi-dimensional verification mechanism is triggered by data index information. Candidate key fragments are matched from different storage partitions and their legality is verified to ensure that only valid key fragments that conform to the verification of different preset classification strategies can participate in key reconstruction. Finally, the authentication key is restored by aggregating valid key fragments, achieving secure and controllable data access. The different preset classification strategies form a multi-dimensional protection system, which not only improves the security of key storage but also increases the flexibility of key management. Attached Figure Description

[0009] Figure 1 This is a flowchart of a key management method according to an embodiment of the present invention; Figure 2 This is a schematic diagram illustrating key derivation and aggregation according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of a storage device according to an embodiment of the present invention; Label Explanation: 100. Storage device; 101. Storage chip; 102. Control chip. Detailed Implementation

[0010] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0011] Embodiments of the present invention provide a key management method, including: Different types of key fragments are derived from the authentication key according to different preset classification strategies, and the different types of key fragments are stored in different storage partitions corresponding to the preset classification strategies. Receive a data access request, the data access request including data index information; Based on different preset classification strategies, the legality of candidate key fragments that match the data index information is read from different storage partitions and verified, and the candidate key fragments that pass the verification are determined as valid key fragments. The valid keys of different types are fragmented and aggregated to generate the authentication key, and the target access data of the data access request is obtained through the authentication key.

[0012] As described above, the authentication key is first decomposed into different types of key fragments using different preset classification strategies. These fragments are then stored in corresponding storage partitions, eliminating single-point-of-failure risks through a distributed storage mechanism while adapting to the dynamic needs of different application scenarios. During the data access phase, a multi-dimensional verification mechanism is triggered by data index information. Candidate key fragments are matched from different storage partitions and their legitimacy is verified, ensuring that only valid key fragments conforming to the verification of different preset classification strategies can participate in key reconstruction. Finally, the authentication key is restored by aggregating valid key fragments, achieving secure and controllable data access. These different preset classification strategies form a multi-dimensional protection system, which not only improves the security of key storage but also increases the flexibility of key management.

[0013] Furthermore, it also includes: The current risk index of the system is calculated based on the system's read and write request frequency, the number of illegal write attempts, and the system status. The risk threshold is calculated based on the system's historical risk indices prior to the current risk index. When the current risk index is greater than the risk threshold, the authentication key is updated, and the step of deriving different types of key fragments from the authentication key according to different preset classification strategies is performed.

[0014] As described above, by introducing a dynamic risk assessment mechanism, the system can perceive changes in the security environment in real time and proactively update keys. Based on multi-dimensional indicators such as read / write request frequency, number of illegal write attempts, and system status, the current risk index is calculated, and a risk threshold is dynamically generated by combining historical risk data. This ensures that key update decisions reflect both the immediate threat situation and long-term security trends. When the risk index exceeds the threshold, the authentication key update process is triggered, enabling proactive rotation of key materials and effectively preventing attackers from using leaked keys for long-term penetration. This risk-adaptive key management approach not only enhances the system's resistance to new attacks but also reduces the probability of keys being brute-forced through periodic key updates. Furthermore, the inclusion of historical risk indices in the calculation ensures the scientific validity of the threshold setting, avoiding excessive key updates due to short-term risk fluctuations.

[0015] Furthermore, the preset classification strategy includes a spatial partitioning strategy related to the application data type, a time partitioning strategy related to the key storage time, and a functional partitioning strategy related to the key functional attributes. The key fragmentation includes spatial fragmentation corresponding to the spatial partitioning strategy, time fragmentation corresponding to the time partitioning strategy, and functional fragmentation corresponding to the functional partitioning strategy; Different types of key fragments are derived from the authentication key according to different preset classification strategies, and the different types of key fragments are stored in different storage partitions corresponding to the preset classification strategies, including: Based on the space partitioning strategy, space fragments of different application data types are derived from the authentication key, and the space fragments are stored in the first storage partition corresponding to the space partitioning strategy. According to the time partitioning strategy, time slices with different key storage times are derived from the authentication key, and the time slices are stored in the second storage partition corresponding to the time partitioning strategy. Based on the functional partitioning strategy, functional fragments with different key functional attributes are derived from the authentication key, and the functional fragments are stored in a third storage partition corresponding to the functional partitioning strategy.

[0016] As described above, in the spatial dimension, spatial shards are derived based on the application data type and stored in independent partitions, achieving physical isolation of data types. In the temporal dimension, the dynamic storage mechanism of time sharding makes key materials time-sensitive, supporting key rotation and lifecycle management. In the functional dimension, functional shards are derived based on functional attributes, ensuring the permission isolation of different functional keys. This three-dimensional key sharding storage forms a multi-dimensional protection system. Spatial sharding solves the access control problem of data classification storage, time sharding addresses the need for key timeliness management, and functional sharding achieves precise permission granularity. The collaborative work of these three elements not only mitigates the single point of failure inherent in traditional centralized storage but also provides a scalable architectural foundation for dynamic key management. By decomposing the authentication key into three types of shards with different security attributes and storing them in different physical partitions, attackers cannot obtain the complete key through a single partition breach. Furthermore, the combination mechanism of these three types of shards can flexibly adapt to the security requirements of different application scenarios.

[0017] Furthermore, the data access request also includes the application signature of the target application that initiated the data access request; Before reading and verifying the legality of candidate key fragments matching the data index information from different storage partitions based on different preset classification strategies, the process further includes: The legitimacy of the target application is verified based on the application signature; If the target application is legitimate, then based on different preset classification strategies, the legitimacy of candidate key fragments that match the data index information are read from and verified from different storage partitions. If the target application is illegitimate, the data access request will be refused.

[0018] As described above, the data access request contains the target application's application signature, enabling the system to trace the request's origin. Based on the application signature's legitimacy verification, key shard access permissions are bound to trusted applications; only legitimate applications can trigger subsequent key shard verification processes. This mechanism effectively blocks the key access path of unauthorized applications; even if an attacker forges data index information, they cannot bypass the application identity verification step. The direct rejection of responses upon verification failure avoids the risk of invalid requests probing the key storage partition. Through pre-emptive application legitimacy verification, key shard access control is extended from simple key verification to application-layer identity authentication, forming a multi-dimensional security protection system.

[0019] Furthermore, the data index information includes the target data type, current access time, and target functional attributes; Based on different preset classification strategies, the legality of candidate key fragments matching the data index information is read from different storage partitions and verified, including: In the first storage partition, find the first sub-partition that stores the candidate space fragment of the target data type, and verify the access permission of the data access request in the first sub-partition based on the space partitioning strategy. If the access permission is granted, the candidate space fragment is determined to be valid. In the second storage partition, find the candidate time slice that is closest to the current access time, and verify the validity of the candidate time slice based on the time partitioning strategy. If it is valid, then determine that the candidate time slice is legal. In the third storage partition, a candidate function fragment corresponding to the target function attribute is searched, and the matching between the candidate function fragment and the target function attribute is verified based on the function partitioning strategy. If they match, the candidate function fragment is determined to be valid.

[0020] As described above, the data index information is decomposed into three dimensions: target data type, current access time, and target functional attribute, corresponding to the verification conditions for spatial, temporal, and functional shards, respectively. In the spatial dimension, access control for application data types is achieved by limiting access permissions to the first sub-partition, avoiding the risk of cross-partition key access. In the temporal dimension, the candidate time shard closest to the current access time is used for validity verification, ensuring the temporal validity of the key shard. In the functional dimension, functional attribute matching verification strengthens the binding relationship between key shards and key functions. This multi-dimensional verification mechanism not only achieves dynamic combination verification of key shards but also effectively resists unauthorized extraction or replay attacks of key shards through triple protection of spatial isolation, time window limits, and functional binding.

[0021] Furthermore, the first storage partition is located in the hardware encryption module; Storing the space fragments in a first storage partition corresponding to the space partitioning strategy includes: The first storage partition is divided into multiple first sub-partitions according to the application data type, and the space fragments are stored in the corresponding first sub-partitions according to the application data type of the space fragments.

[0022] As described above, the first storage partition is located within the hardware encryption module, isolated from the external environment, ensuring its storage security. The first storage partition is sub-partitioned according to the application data type, allowing space fragments of different data types to be stored isolated within their corresponding first sub-partitions. This achieves both physical distributed storage of key fragments to eliminate single points of failure and enhanced access control through data type-level storage isolation. The targeted storage operation based on the application data type of the space fragments supports multiple applications simultaneously accessing different space keys, improving key access efficiency.

[0023] Furthermore, the second storage partition is located in a trusted execution environment; Storing the time slices in a second storage partition corresponding to the time partitioning strategy includes: The second storage partition is divided into multiple second sub-partitions according to different time dimensions, and the time slice is dynamically stored in the corresponding second sub-partition according to the time interval between the real time and the storage time of the time slice.

[0024] As described above, placing the second storage partition within a trusted execution environment leverages its hardware-level isolation to form a physical attack protection barrier against time-sharded key fragments, effectively resisting attacks targeting the key storage medium, such as fault injection and side-channel analysis. By dividing the second sub-partition according to different time dimensions, independent storage spaces are established for key fragments with different timeframes, avoiding management chaos caused by mixed storage of fragments with large time span differences. Dynamically adjusting the fragment storage location based on the time interval between real-time and storage time implements a mechanism for automatic migration of key fragments as their timeframe changes. This ensures fast access efficiency for recently frequently used fragments while strengthening the protection of historical keys by periodically migrating expired fragments to specific sub-partitions.

[0025] Furthermore, the third storage partition is located in a one-time programmable memory bound to the chip fingerprint; Storing the functional fragments in a third storage partition corresponding to the functional partitioning strategy includes: In the third storage partition, functional index information is created. After storing the functional fragment in the third storage partition, the functional attributes and index tags of the functional fragment are written into the functional index information.

[0026] As described above, by setting the third storage partition in a chip fingerprint-bound one-time programmable memory (OTP), the physical immutability of the OTP memory is utilized to block attackers' attempts to tamper with the functional fragments. Simultaneously, the chip fingerprint binding mechanism ensures a strong association between the storage medium and the physical carrier, enhancing resistance to physical attacks at the hardware level. When storing functional fragments, functional index information is created and functional attributes and index tags are written, establishing a logical mapping relationship between the functional fragments and the storage medium. This facilitates rapid location of the target fragment during subsequent verification and ensures that the functional fragment has not been illegally replaced through the integrity verification of the index information. The operation of jointly writing functional attributes and index tags achieves dual binding between the functional fragment metadata and the storage medium, preventing cloned devices from accessing the functional index information. This ensures that any unauthorized extraction or modification of the functional fragment will compromise the integrity of the index information and be detected.

[0027] Furthermore, verifying the access rights of the data access request in the first sub-partition based on the spatial partitioning strategy includes: The identity identifier of the target application requesting access to the first sub-partition is obtained from the data access request, and the target application is detected as being in the access whitelist of the first sub-partition based on the identity identifier.

[0028] As described above, when verifying access permissions based on the space partitioning strategy, the target application's identity identifier is first extracted from the data access request. This identifier serves as the sole credential for the application's legitimacy. Then, by comparing the identity identifier with the pre-defined access whitelist of the first sub-partition, it dynamically determines whether the application has permission to access that storage sub-partition. Specifically, the space partitioning strategy divides the storage area into multiple isolated sub-partitions based on application data types. Each sub-partition only allows access from specific types of applications, while the access whitelist mechanism further restricts the specific application instances that can access that sub-partition. This dual-verification mechanism avoids the risk of attackers centrally breaching traditional single storage partitions and prevents unauthorized applications from illegally reading key fragments through a dynamic whitelist filtering mechanism, thereby simultaneously improving the access security of key fragments in both the space and application identity dimensions.

[0029] Furthermore, verifying the effectiveness of the candidate time slices based on the time partitioning strategy includes: Obtain the time interval between the access time and the storage time of the candidate time segment, and determine whether the candidate time segment is within the validity period based on the time interval.

[0030] As described above, by first obtaining the time interval between the access time and the key fragment storage time, the lifecycle status of the key fragment is quantified, accurately capturing the time attribute of the key fragment and providing an objective basis for subsequent validity judgment. Then, based on the time interval, it is determined whether it is within the validity period. Dynamic expiration control of the key fragment is achieved through a preset validity period threshold, avoiding the risk of key leakage caused by long-term storage and proactively intercepting illegal access requests based on expired key fragments. Verifying the storage time interval of time fragments allows the system to dynamically adjust the availability status of key fragments according to real-time access needs, effectively solving the problem of rigid key timeliness management in static storage schemes. Simultaneously, the proactive verification mechanism in the time dimension blocks the path for attackers to launch replay attacks using historical key fragments.

[0031] Further, the candidate function segment is checked to see if it matches the target function attribute based on the function index information. If so, the physical chip fingerprint is obtained and compared with the chip fingerprint of the third storage partition. If they match, the candidate function segment is determined to be a match.

[0032] As described above, the system verifies whether the candidate function fragment matches the target function attribute based on the function index information, ensuring that the function fragment is compatible with the requested function and guaranteeing the correctness of subsequent key reconstruction. Simultaneously, it obtains the physical chip fingerprint of the current device, which is a unique identifier derived from the hardware level; this fingerprint is then compared with the chip fingerprint pre-written into the third storage partition. This verification mechanism ensures that the physical carrier of the storage function fragment has not been replaced or tampered with, thereby resisting key theft through physical attacks (such as chip replacement or cloning). By binding the chip fingerprint to the storage partition, not only can unauthorized physical access to the storage medium be detected, but attackers can also prevent them from obtaining valid key fragments by forging the storage environment, thus guaranteeing the non-replicability and integrity of the function fragment storage medium at the hardware level.

[0033] Another embodiment of the present invention provides a storage device including a storage chip and a control chip, wherein the storage chip stores a computer program, and when the computer program is executed by the control chip, it implements the various steps in the above-described key management method.

[0034] As described above, the authentication key is first decomposed into different types of key fragments using different preset classification strategies. These fragments are then stored in corresponding storage partitions, eliminating single-point-of-failure risks through a distributed storage mechanism while adapting to the dynamic needs of different application scenarios. During the data access phase, a multi-dimensional verification mechanism is triggered by data index information. Candidate key fragments are matched from different storage partitions and their legitimacy is verified, ensuring that only valid key fragments conforming to the verification of different preset classification strategies can participate in key reconstruction. Finally, the authentication key is restored by aggregating valid key fragments, achieving secure and controllable data access. These different preset classification strategies form a multi-dimensional protection system, which not only improves the security of key storage but also increases the flexibility of key management.

[0035] The key management method and storage device described above are applicable to RPMB key storage management scenarios. The RPMB authentication key is a 32-byte, one-time write-type data, primarily stored in a one-time programmable authentication key register. This register cannot be overwritten, erased, or read. When processing commands, the RPMB engine within the eMMC controller uses this internally stored authentication key to calculate and verify the MAC, thereby authenticating the access subject and protecting data integrity. Similarly, accessing this key and updating it to derive a new key requires engine and hardware encryption module adaptation, as well as pre-designing a secure storage area to store the new key. Traditional RPMB key storage schemes typically use static partitioned storage, i.e., pre-dividing a fixed-size secure area (such as an eMMC RPMB partition). This storage method has the following problems: high single-point failure risk: attackers can obtain all keys by breaking through a single layer of protection; and poor storage scalability: fixed partitions cannot cope with dynamic key derivation requirements.

[0036] To address the above problems, the key management method and storage device provided by this invention can effectively improve the security of key storage and the flexibility of key management. The following detailed embodiments illustrate these improvements: Please refer to Figure 1 and Figure 2 Embodiment 1 of the present invention is as follows: like Figure 1 As shown, a key management method specifically includes steps S10-S40.

[0037] S10. Derive different types of key fragments from the authentication key according to different preset classification strategies, and store the different types of key fragments in different storage partitions corresponding to the preset classification strategies.

[0038] Among them, the preset classification strategy refers to the set of strategies that define the mapping relationship between key fragmentation generation rules and storage locations. Specifically, the preset classification strategy includes space partitioning strategy related to application data type, time partitioning strategy related to key storage time, and function partitioning strategy related to key functional attributes.

[0039] Key fragmentation refers to the generation of sub-key units from the authentication key using cryptographic algorithms. Specifically, it can be implemented using key derivation algorithms. Each fragment, stored separately, cannot reconstruct the complete authentication key. Specifically, key fragmentation includes spatial fragmentation corresponding to spatial partitioning strategies, temporal fragmentation corresponding to temporal partitioning strategies, and functional fragmentation corresponding to functional partitioning strategies.

[0040] Storage partitions refer to storage areas with independent access control mechanisms and physical protection features. Specifically, storage partitions can be hardware security modules, trusted execution environments, or one-time programmable memories, reducing the possibility of coordinated attacks through differentiated storage media.

[0041] In the key derivation stage of this invention, the authentication key is decomposed into three types of fragments. During spatial fragment generation, the authentication key can be hashed according to the application data type tag to generate independent spatial fragments; for example, a payment-specific fragment can be generated for payment applications. During time fragment generation, the authentication key can be time-series encrypted with the current timestamp to generate time-sensitive fragments, such as fragments with a validity period of 24 hours. Functional fragment generation uses a functional attribute encoding algorithm to divide the authentication key into encrypted fragments for different functional modules, such as data encryption fragments and identity authentication fragments. In the storage stage, spatial fragments are written to independent sub-partitions of the hardware encryption module, with each sub-partition having an access whitelist; time fragments are stored in a dynamic partition within a trusted execution environment, automatically migrating their storage location according to time intervals; and functional fragments are stored in a one-time programmable memory and bound to a physical chip fingerprint.

[0042] like Figure 2 As shown, specifically, step S10 includes steps S110-S130.

[0043] S110. Based on the space partitioning strategy, space fragments of different application data types are derived from the authentication key, and the space fragments are stored in the first storage partition corresponding to the space partitioning strategy.

[0044] The space partitioning strategy includes a fragmentation rule that logically divides the key according to the application data type. This can be implemented using a data type label matching algorithm, generating a unique fragmentation identifier for each application data type. The first storage partition is located within the hardware encryption module, isolated from the external environment, and offers a high level of security.

[0045] In step S110, storing space fragments in the first storage partition corresponding to the space partitioning strategy includes step S1101.

[0046] S1101. Divide the first storage partition into multiple first sub-partitions according to the application data type, and store the space fragments in the corresponding first sub-partitions according to the application data type of the space fragments.

[0047] In a specific application scenario, the RPMB in a smartwatch stores sensitive information such as user biometric data, payment transaction data, device access control data, and device communication data. In this case, the first storage partition of the RPMB is divided into four application data types (such as system firmware, payment applications, social applications, and sports and health applications) based on a space partitioning strategy: a system firmware sub-partition, a payment sub-partition, a social sub-partition, and a sports and health sub-partition. The system firmware sub-partition stores system-level space fragments, the payment sub-partition stores space fragments related to payment applications, the social sub-partition stores space fragments for message transmission, and the sports and health sub-partition stores space fragments for human biometric data. Each sub-partition corresponds to one application type, and each application type is allocated independent storage space. This approach supports multiple applications accessing the RPMB area simultaneously, improving storage efficiency and enhancing data security.

[0048] S120. Derive time slices of different key storage times from the authentication key according to the time partitioning strategy, and store the time slices in the second storage partition corresponding to the time partitioning strategy.

[0049] The time-based partitioning strategy includes partitioning rules that dynamically adjust the partition storage location based on the key storage time. Specifically, this can be implemented using a timestamp rotation algorithm, achieving key expiration management by periodically updating the partition storage location. The second storage partition is located in a trusted execution environment (such as a TEE).

[0050] Specifically, in step S120, storing time shards in a second storage partition corresponding to the time partitioning strategy includes step S1201.

[0051] S1201. Divide the second storage partition into multiple second sub-partitions according to different time dimensions, and dynamically store the time slices in the corresponding second sub-partitions according to the time interval between the real-time time and the storage time of the time slice.

[0052] In a specific application scenario, based on the key usage cycle and security requirements, the second storage partition of the RPMB is divided into current sub-partitions and historical sub-partitions according to the time dimension (such as month, quarter, or year) defined by the time partitioning strategy. For example, if the time dimension defined by the time partitioning strategy is quarter, the second storage partition of the RPMB is divided into a current quarter sub-partition and an out-of-quarter sub-partition. A quarterly clock is configured within the device. When the cumulative number of days in this quarterly clock reaches 90, the TEE automatically marks time fragments with storage intervals exceeding 90 days as "out-of-quarter time fragments." Then, by tracking the usage time of key fragments, the out-of-quarter time fragments are automatically migrated to the out-of-quarter sub-partition according to preset rules, while newly generated current quarter time fragments are written to the current quarter sub-partition of the RPMB. In this way, by periodically cleaning up expired keys and storing them in isolation, the risk of key leakage due to long-term use can be effectively reduced, thereby improving data security.

[0053] S130. Derive functional fragments with different key functional attributes from the authentication key according to the functional partitioning strategy, and store the functional fragments in the third storage partition corresponding to the functional partitioning strategy.

[0054] The functional partitioning strategy includes partitioning rules based on the functional attributes of the key in the system, which can be implemented using a functional attribute encoding algorithm by assigning a unique functional identifier code to each functional partition. The third storage partition is located in a one-time programmable memory bound to the chip fingerprint. The one-time programmable memory is unique and immutable.

[0055] Specifically, in step S130, storing the functional shards in the third storage partition corresponding to the functional partitioning strategy includes step S1301.

[0056] S1301. Create functional index information in the third storage partition. After storing the functional fragments in the third storage partition, write the functional attributes and index tags of the functional fragments into the functional index information.

[0057] In a specific application scenario, authentication keys are derived into different functional fragments according to the functional attributes defined by the functional partitioning strategy (such as encryption, signature, and authentication functions). Simultaneously, functional index information is created in the bottom three storage partitions of the RPMB. These functional fragments are then categorized, stored, and managed based on their functional attributes. This approach achieves fine-grained key management, ensuring that each functional fragment can adapt to different security attributes and access controls, improving storage efficiency, and enhancing data security.

[0058] Based on steps S110-S130 above, obtaining the authentication key requires simultaneously breaching three independent security zones to reconstruct it. The three independent security zones coordinate with each other, effectively improving key storage security and preventing the risk that malicious users could obtain all keys by breaching only a single layer of protection, thus enhancing storage security. Furthermore, the dynamic partitioning of storage between the different independent security zones avoids the problem of static partitioning being unable to handle dynamic derivation requirements, improving storage scalability.

[0059] S20. Receive a data access request, which includes data index information. The data index information includes the target data type, current access time, and target functional attributes.

[0060] In a specific application scenario, when a user uses a smartwatch to make a payment or interact with messages, a data access request is triggered, which in turn triggers the authentication key reassembly process in steps S30-S40 below.

[0061] The data access request also includes the application signature of the target application that initiated the data access request.

[0062] Before step S30, steps S310-S303 are also included.

[0063] S301. Verify the legitimacy of the target application based on the application signature.

[0064] Application signature refers to the digital certificate or hash value used to identify the origin of the application. Specifically, it can be implemented using digital signatures based on asymmetric encryption algorithms. Verifying the signature confirms the legitimacy and integrity of the application. Legitimacy verification refers to the process of authenticating the application's identity through a pre-defined whitelist or certificate chain verification mechanism. This can be implemented using digital certificates issued by a certificate authority, serving as a prerequisite for key sharding calls and preventing unauthorized applications from initiating key operation requests.

[0065] S302. If the target application is legitimate, then based on different preset classification strategies, read and verify the legitimacy of the candidate key fragments that match the data index information from different storage partitions.

[0066] S303. If the target application is illegitimate, the data access request will be refused.

[0067] In a specific application scenario, when the system receives a data access request containing an application signature, it first extracts the signature and compares it with a pre-stored trusted signature library. For example, the trusted signature library may store application certificate information certified by device manufacturers or security agencies. If signature verification fails, the system immediately terminates the subsequent key fragment reading process to prevent unauthorized applications from triggering key operations. Only after the signature is verified successfully will the system allow access to key fragments in different storage partitions based on the data index information. This phased processing mechanism separates application-layer authentication from key-layer fragment verification, reducing the risk of unauthorized key fragment access and minimizing resource waste caused by invalid requests.

[0068] S30. Based on different preset classification strategies, read and verify the legality of candidate key fragments that match the data index information from different storage partitions, and determine the verified candidate key fragments as valid key fragments.

[0069] Step S30 involves first reading candidate key fragments that match the data index information from different storage partitions, then verifying the legality of the candidate key fragments read from different storage partitions based on different preset partitioning strategies, and finally determining the verified candidate key fragments as valid key fragments.

[0070] Specifically, step S30 includes steps S310-S320.

[0071] S310. Locate the first sub-partition in the first storage partition that stores the candidate space fragment of the target data type, and verify the access permission of the data access request in the first sub-partition based on the space partitioning strategy. If the access permission is granted, the candidate space fragment is determined to be valid.

[0072] In step S310, verifying the access permissions of the data access request in the first sub-partition based on the spatial partitioning strategy includes step S3101.

[0073] S3101. Obtain the identity identifier of the target application requesting access to the first sub-partition from the data access request, and check whether the target application is in the access whitelist of the first sub-partition based on the identity identifier. If so, determine that the target application has access rights.

[0074] The space partitioning strategy also includes a storage strategy that logically partitions key fragments according to the application data type. Specifically, a hash algorithm can be used to map key fragments of different data types to the corresponding first sub-partition, thereby achieving physical isolation storage of key fragments.

[0075] S320. Find the candidate time slice that is closest to the current access time in the second storage partition, and verify the validity of the candidate time slice based on the time partitioning strategy. If it is valid, determine that the candidate time slice is legal.

[0076] In step S320, verifying the validity of candidate time slices based on the time partitioning strategy includes step S3201.

[0077] S3201. Obtain the time interval between the access time and the storage time of the candidate time segment, and determine whether the candidate time segment is within the validity period based on the time interval. If so, determine that the candidate time segment is valid.

[0078] The time partitioning strategy also includes a storage strategy that dynamically migrates the storage partitions of key fragments based on the time dimension. Specifically, a sliding time window algorithm can be used to calculate the time interval between the candidate time fragment and the current access time. This strategy ensures that the key fragment is stored in the corresponding time partition.

[0079] In some embodiments, if the candidate time slice is not within the validity period, the key update process is directly triggered to generate a new authentication key and return to execute the above step S10.

[0080] S330. Locate the candidate function fragments corresponding to the target function attributes in the third storage partition, and verify the matching between the candidate function fragments and the target function attributes based on the function partitioning strategy. If they match, determine that the candidate function fragments are valid.

[0081] In step S330, verifying the matching between candidate function fragments and target function attributes based on the function partitioning strategy includes step S3301.

[0082] S3301. Verify whether the candidate function segment matches the target function attribute based on the function index information. If so, obtain the physical chip fingerprint and compare whether the physical chip fingerprint is consistent with the chip fingerprint of the third storage partition. If they are consistent, determine that the candidate function segment matches.

[0083] The time-sharing strategy also includes a storage strategy that matches and verifies the key's functional attributes. Specifically, attribute-based encryption technology can be used to generate functional index information. This strategy enables precise matching between functional sharding and operational requirements.

[0084] In a specific application scenario, when a data access request containing a target data type is received, the system first locates the first sub-partition corresponding to the target data type in the Hardware Encryption Module (HSM), reads the spatial fragment in the first sub-partition, and verifies whether the identity of the target application initiating the data access request exists in the access whitelist of the first sub-partition. For example, a payment application can only access the payment sub-partition. If so, the spatial fragment corresponding to the target data type is obtained. Next, the storage time interval of the time fragment is obtained in the Trusted Execution Environment (TEE). It checks whether the storage time interval of the time fragment is less than a preset period of days or whether the risk score is less than a preset threshold. If so, the time fragment is determined to be within its validity period and is obtained. Finally, the function fragment is read from the One-Time Programmable Memory (OTP). The function index information is used to verify whether the target function attribute in the data access request matches the function attribute of the obtained function fragment. Simultaneously, the chip fingerprint bound to the OTP is verified to be consistent with the physical chip fingerprint of the device hardware. If they match, the function fragment is obtained.

[0085] S40. Segment and aggregate different types of valid keys to generate an authentication key, and use the authentication key to obtain the target access data of the data access request.

[0086] In some embodiments, aggregating different types of valid key fragments to generate an authentication key specifically involves: in a trusted execution environment, using a key derivation algorithm (HKDF), aggregating valid spatial fragments, temporal fragments, and functional fragments into a complete authentication key. During the aggregation process, the plaintext key only exists temporarily in the trusted execution environment and is immediately cleared after use. The aggregation calculation formula can be specifically expressed as: AuthKey = Key_Space ⊕ Key_Time ⊕ Key_Func, where AuthKey represents the aggregated authentication key, Key_Space represents a valid spatial fragment, Key_Time represents a valid temporal fragment, Key_Func represents a valid functional fragment, and ⊕ represents the aggregation calculation.

[0087] Embodiment 2 of the present invention is as follows: A key management method, which differs from Embodiment 1 in that it further includes steps S50-S60.

[0088] S50. Calculate the current risk index of the system based on the system's read / write request frequency, number of illegal write attempts, and system status, and calculate the risk threshold based on the system's historical risk indices before the current risk index.

[0089] The system's read / write request frequency refers to the number of data read / write operations received by the system per unit of time. This can be achieved by using a counter to track the request count in real time, reflecting the system's current business load and potential security pressure. The number of unauthorized write attempts refers to the number of unauthorized entities attempting to write operations. This can be achieved by monitoring system logs or security module interception records, quantifying the activity level of attack behavior. System status includes hardware resource utilization, running process status, and security module operational status. This can be achieved by checking the boot status and firmware version hash value, used to assess the overall health of the system.

[0090] S60. When the current risk index is greater than the risk threshold, update the authentication key and execute the above step S10.

[0091] The current risk index refers to the real-time security risk assessment value obtained through weighted calculation based on the above parameters. Specifically, it can be dynamically evaluated using linear weighting or machine learning models to comprehensively determine the level of security threats faced by the system. The historical risk index refers to the set of records of system risk indices over a past period. Specifically, it can be implemented by storing historical data in a time-series database, used to analyze risk trends and establish dynamic threshold benchmarks. The risk threshold refers to the security risk critical value dynamically adjusted based on the historical risk index. Specifically, it can be calculated using sliding window statistics or adaptive algorithms, and used as the basis for determining whether to trigger a key update operation.

[0092] It should be noted that when the authentication key update is completed, the old authentication key remains valid for the specified period; both the old and new keys coexist. Key version management is implemented, recording the update history of each key. When updating a key, the key version number is incremented. The system is configured to use only the latest version of the key during operations.

[0093] In a specific application scenario, the system's read / write request frequency is specifically the standardized read / write request frequency, resulting in a quantized value between 0 and 1. The standardization process specifically involves: ; Where norm_rw represents the normalized read / write request frequency, read_write_freq represents the read / write request frequency, and MAX_RE_FREQUENCY represents the maximum read / write request frequency allowed by the system.

[0094] In a specific application scenario, the number of illegal write attempts in the system is specifically a standardized count of illegal write attempts, resulting in a quantified value between 0 and 1. The standardization process involves: ; Here, norm_illegal_w represents the number of illegal write attempts after normalization, illegal_writes represents the number of illegal write attempts, and MAX_ILLEGAL_ATTEMPTS represents the maximum number of illegal write attempts the system can tolerate.

[0095] In a specific application scenario, the system state is standardized using the Boot state and firmware version hash value to obtain a quantized value between 0 and 1. The standardization process specifically involves: ; Here, system_score represents the system state after standardization.

[0096] In a specific application scenario, the current risk index of the system is calculated based on the system's read / write request frequency, the number of illegal write attempts, and the system status as follows: ThreatScore=norm_rw× w r +norm_illegal× w i +(1-system_score)× w s ×100; ThreatScore represents the current risk index. w r Weight values ​​representing the frequency of read and write requests. w i The weight value represents the number of illegal write attempts. w s The weight values ​​represent the system state. In this embodiment, w r =0.4, w i =0.4, w s =0.2.

[0097] In a specific application scenario, the risk threshold is calculated based on the system's historical risk indices prior to the current risk index as follows: ; in, Indicates the risk threshold. This represents the average historical risk index. The standard deviation of the historical risk index This represents the sensitivity coefficient (default is 0.2). TS min This indicates the lower limit of the current risk index (default is 30). TSmax This indicates the upper limit of the current risk index (default is 80).

[0098] During system initialization or when historical risk index data is insufficient, the risk threshold... and The default value is set to: ; ; in, This represents the initial average value. This represents the initial standard deviation.

[0099] In some embodiments, the authentication key is updated when the system's time decay index is less than a time threshold, and step S10 described above is executed. The time decay index... , Represents the attenuation rate constant. The larger the value, the faster it decays. This represents the time interval since the last key update to the current time. Time threshold. T t The default value is 0.2. In this way, the key update mechanism can be triggered when the current risk index is greater than the risk threshold or when the system's time decay index is less than the time threshold.

[0100] In some embodiments, other relevant data, such as random numbers, timestamps, and device identifiers, may be used during the key update derivation process. These data need to be checked for accuracy to ensure they conform to the expected format and range. For example, it's necessary to check whether the random number has sufficient randomness, whether the timestamp is within a reasonable range, and whether the device identifier matches the actual device, to prevent problems in the key update derivation due to incorrect or malicious data input.

[0101] Furthermore, due to the dynamic update mechanism of the authentication key, the host no longer possesses the previously fixed authentication key. Therefore, the host needs to exchange authentication keys with the device. The specific process of authentication key exchange between the host and the device is as follows: Based on a pre-set signature key pair, the host and the device negotiate a shared key using the Diffie-Hellman key exchange protocol for digital signature authentication; then, using a key derivation function, a session key for subsequent secure communication is derived from the shared key; finally, a secure channel is established based on the session key for encrypted transmission and updating of the authentication key.

[0102] In a specific application scenario, the method for the host and device to exchange authentication keys includes steps ag.

[0103] Step a: Parameter negotiation and initialization.

[0104] The host and device sides negotiate or jointly adopt a predefined set of Diffie-Hellman parameters, including a large prime number p and a primitive root g. This step ensures that both sides perform subsequent calculations on the same mathematical basis.

[0105] Step b: Key pair generation.

[0106] The device generates its temporary Diffie-Hellman key pair: a private key a_dh is randomly generated, and its corresponding public key A_dh = g^(a_dh)modp is calculated.

[0107] The host generates its temporary Diffie-Hellman key pair: a private key b_dh is randomly generated, and its corresponding public key B_dh = g^(b_dh)modp is calculated.

[0108] Step c: Public key signing.

[0109] To defend against man-in-the-middle attacks and achieve identity authentication, both parties use a pre-set, asymmetric signing key to digitally sign their generated Diffie-Hellman public key.

[0110] The device uses its device signing private key priv_dev_sign to sign the public key A_dh, resulting in the signature value Sig_A=sign(A_dh,priv_dev_sign).

[0111] The host uses its host signing private key priv_host_sign to sign the public key B_dh, resulting in the signature value Sig_B=sign(B_dh,priv_host_sign).

[0112] Step d: Exchange and verify the signing public key.

[0113] The device sends its signed public key data group (A_dh, Sig_A) to the host.

[0114] Upon receiving the data, the host uses the pre-securely obtained device-side signature public key pub_dev_sign to verify the validity of the signature Sig_A for A_dh. If verification fails, it is determined that authentication has failed or the data has been tampered with, and the process is immediately terminated.

[0115] The host sends its signed public key data set (B_dh, Sig_B) to the device.

[0116] Upon receiving the data, the device uses the pre-securely obtained host-side signature public key pub_host_sign to verify the validity of the signature Sig_B for B_dh. If verification fails, the process is immediately terminated.

[0117] Step e: Calculate the shared secret.

[0118] If both parties successfully verify their signatures, they can calculate the same shared key S.

[0119] Device-side calculation: S_device=(B_dh)^(a_dh)modp.

[0120] Host-side calculation: S_host=(A_dh)^(b_dh)modp.

[0121] According to the principles of the Diffie-Hellman key exchange protocol, mathematically, S_device = S_host. Both parties determine this value as the shared key S.

[0122] Step f: Derive the session key.

[0123] The host and device use a pre-negotiated key derivation function (KDF), such as an HMAC-based key derivation function (HKDF), to extend and strengthen the shared key S.

[0124] The inputs to the KDF include: a shared key S as the initial key material (IKM); an optional salt value to increase the entropy source and resist rainbow table attacks; and optional context information to bind the derived key to a specific application context, thereby achieving key separation.

[0125] By executing KDF, both parties derive one or more session keys, such as a key K_session_enc for encryption and a key K_session_mac for message authentication.

[0126] Step g: Establish secure communication and update the key.

[0127] The host and device establish a secure, authenticated communication channel using derived session keys (K_session_enc, K_session_mac) according to a predetermined secure communication protocol (such as encryption based on AEAD). Through this secure channel, the host can securely transmit new RPMB authentication keys or related key update commands to the device in an encrypted and authenticated manner. Upon receiving and verifying the data, the device can complete the secure update operation of the authentication key.

[0128] In this way, the origin of the Diffie-Hellman public key is verified through digital signatures, effectively resisting man-in-the-middle attacks and greatly improving the overall security of Diffie-Hellman key exchange. Utilizing key derivation functions (KDFs) to process the shared secret generates session keys with excellent cryptographic properties, enhancing the strength of the final key material. Secure key separation is possible, deriving multiple independent keys with different purposes from a single shared key, reducing the risk of a single key being leaked. Furthermore, keys of different lengths can be derived as needed, adapting to various encryption algorithms and security protocols, demonstrating excellent flexibility and adaptability.

[0129] Please refer to Figure 3 Embodiment 3 of the present invention is as follows: A storage device 100 includes a storage chip 101 and a control chip 102. The storage chip 101 stores a computer program, which, when executed by the control chip 102, implements the various steps of a key management method in Embodiment 1 or Embodiment 2 described above.

[0130] In summary, this invention provides a key management method and storage device that achieves a balance between key security and management flexibility through multi-dimensional protection and dynamic update mechanisms. First, it employs a three-tiered classification strategy based on space, time, and function to decompose the authentication key into corresponding fragments and store them separately in independent partitions of different security levels, such as hardware encryption modules, trusted execution environments, and chip fingerprint-bound OTP memory. This completely eliminates the single point of failure risk inherent in traditional centralized storage and effectively resists physical attacks, side-channel analysis, and unauthorized tampering through a combination of physical and logical isolation. Second, it introduces a dynamic risk index calculated based on real-time system behavior and historical states to trigger proactive key rotation, enabling the system to adaptively defend against persistent and novel attacks. During the data access phase, multiple security mechanisms, including application signature verification, multi-dimensional key fragment legality verification, and chip fingerprint comparison, ensure that only legitimate applications meeting spatiotemporal and functional constraints can aggregate and restore the authentication key, significantly raising the security threshold of the key reconstruction process. This method not only significantly enhances the system's resilience against replay attacks, key leaks, and unauthorized access, but also supports dynamic security management needs in complex application scenarios through flexible policy configuration, achieving an organic balance between security, efficiency, and scalability.

[0131] In the embodiments provided in this application, it should be understood that the disclosed methods, apparatuses, computer-readable storage media, and electronic devices can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple components or modules may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between devices, components, or modules may be electrical, mechanical, or other forms.

[0132] The components described as separate parts may or may not be physically separate. The components shown as components may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the components can be selected to achieve the purpose of this embodiment according to actual needs.

[0133] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each component can exist physically separately, or two or more modules can be integrated into one module. The integrated modules described above can be implemented in hardware or as software functional modules.

[0134] If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0135] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the present invention is not limited to the described order of actions, because according to the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to the present invention.

[0136] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0137] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A key management method, characterized in that, include: Different types of key fragments are derived from the authentication key according to different preset classification strategies, and the different types of key fragments are stored in different storage partitions corresponding to the preset classification strategies. Receive a data access request, the data access request including data index information; Based on different preset classification strategies, the legality of candidate key fragments that match the data index information is read from different storage partitions and verified, and the candidate key fragments that pass the verification are determined as valid key fragments. The valid keys of different types are fragmented and aggregated to generate the authentication key, and the target access data of the data access request is obtained through the authentication key.

2. The key management method according to claim 1, characterized in that, Also includes: The current risk index of the system is calculated based on the system's read and write request frequency, the number of illegal write attempts, and the system status. The risk threshold is calculated based on the system's historical risk indices prior to the current risk index. When the current risk index is greater than the risk threshold, the authentication key is updated, and the step of deriving different types of key fragments from the authentication key according to different preset classification strategies is performed.

3. The key management method according to claim 1, characterized in that, The preset classification strategy includes a spatial partitioning strategy related to the application data type, a time partitioning strategy related to the key storage time, and a functional partitioning strategy related to the key functional attributes. The key fragmentation includes spatial fragmentation corresponding to the spatial partitioning strategy, time fragmentation corresponding to the time partitioning strategy, and functional fragmentation corresponding to the functional partitioning strategy; Different types of key fragments are derived from the authentication key according to different preset classification strategies, and the different types of key fragments are stored in different storage partitions corresponding to the preset classification strategies, including: Based on the space partitioning strategy, space fragments of different application data types are derived from the authentication key, and the space fragments are stored in the first storage partition corresponding to the space partitioning strategy. According to the time partitioning strategy, time slices with different key storage times are derived from the authentication key, and the time slices are stored in the second storage partition corresponding to the time partitioning strategy. Based on the functional partitioning strategy, functional fragments with different key functional attributes are derived from the authentication key, and the functional fragments are stored in a third storage partition corresponding to the functional partitioning strategy.

4. The key management method according to claim 1, characterized in that, The data access request also includes the application signature of the target application that initiated the data access request; Before reading and verifying the legality of candidate key fragments matching the data index information from different storage partitions based on different preset classification strategies, the process further includes: The legitimacy of the target application is verified based on the application signature; If the target application is legitimate, then based on different preset classification strategies, the legitimacy of candidate key fragments that match the data index information are read from and verified from different storage partitions. If the target application is illegitimate, the data access request will be refused.

5. A key management method according to claim 3, characterized in that, The data index information includes the target data type, current access time, and target functional attributes; Based on different preset classification strategies, the legality of candidate key fragments matching the data index information is read from different storage partitions and verified, including: In the first storage partition, find the first sub-partition that stores the candidate space fragment of the target data type, and verify the access permission of the data access request in the first sub-partition based on the space partitioning strategy. If the access permission is granted, the candidate space fragment is determined to be valid. In the second storage partition, find the candidate time slice that is closest to the current access time, and verify the validity of the candidate time slice based on the time partitioning strategy. If it is valid, then determine that the candidate time slice is legal. In the third storage partition, a candidate function fragment corresponding to the target function attribute is searched, and the matching between the candidate function fragment and the target function attribute is verified based on the function partitioning strategy. If they match, the candidate function fragment is determined to be valid.

6. The key management method according to claim 3, characterized in that, The first storage partition is located in the hardware encryption module; Storing the space fragments in a first storage partition corresponding to the space partitioning strategy includes: The first storage partition is divided into multiple first sub-partitions according to the application data type, and the space fragments are stored in the corresponding first sub-partitions according to the application data type of the space fragments.

7. The key management method according to claim 3, characterized in that, The second storage partition is located in a trusted execution environment; Storing the time slices in a second storage partition corresponding to the time partitioning strategy includes: The second storage partition is divided into multiple second sub-partitions according to different time dimensions, and the time slice is dynamically stored in the corresponding second sub-partition according to the time interval between the real time and the storage time of the time slice.

8. A key management method according to claim 5, characterized in that, The third storage partition is located in a one-time programmable memory that is bound to the chip fingerprint; Storing the functional fragments in a third storage partition corresponding to the functional partitioning strategy includes: In the third storage partition, functional index information is created. After storing the functional fragment in the third storage partition, the functional attributes and index tags of the functional fragment are written into the functional index information.

9. A key management method according to claim 5, characterized in that, Verifying the access permissions of the data access request in the first sub-partition based on the spatial partitioning strategy includes: The identity identifier of the target application requesting access to the first sub-partition is obtained from the data access request, and the target application is detected as being in the access whitelist of the first sub-partition based on the identity identifier. If so, it is determined that the target application has access rights.

10. A key management method according to claim 5, characterized in that, Verifying the effectiveness of the candidate time slices based on the time partitioning strategy includes: Obtain the time interval between the access time and the storage time of the candidate time segment, and determine whether the candidate time segment is within the validity period based on the time interval. If so, determine that the candidate time segment is valid.

11. A key management method according to claim 8, characterized in that, Verifying the matching between the candidate function fragments and the target function attributes based on the function partitioning strategy includes: According to the function index information, verify whether the candidate function segment matches the target function attribute. If so, obtain the physical chip fingerprint and compare whether the physical chip fingerprint is consistent with the chip fingerprint of the third storage partition. If they are consistent, determine that the candidate function segment matches.

12. A storage device comprising a storage chip and a control chip, wherein the storage chip stores a computer program, characterized in that, When the computer program is executed by the control chip, it implements the various steps of a key management method as claimed in any one of claims 1 to 11.

Images