Multi-level access control and authority synchronization method for secure mobile storage

Abstract

The invention discloses a multi-level access control and authority synchronization method for secure mobile storage, and belongs to the field of mobile storage security. Aiming at the problems of data leakage, poor authority management and the like of the mobile storage device, a multi-level access control framework, a decentralized authority synchronization mechanism and a dynamic token and zero-knowledge proof system are constructed. Generating a plurality of layers of sub-keys from a master key by using a PBKDF2 algorithm through hierarchical key generation, and associating different encryption areas and authority strategies; incremental synchronization is carried out based on a Merkle tree, and data consistency is guaranteed through a consistency verification protocol; a temporary token is generated by using a Schnorr protocol, and the permission is verified in combination with zero-knowledge proof, so that the privacy security is ensured. In scene application of a power grid and the like, a master key is activated through biological recognition, permission is loaded according to a strategy, and permission change is efficiently synchronized. According to the method, the mobile storage security and the management efficiency are improved, and accurate authority control and reliable synchronization are realized.

Description

Technical Field

[0001] The present invention relates to the field of mobile storage security, and in particular to a multi-level access control and authority synchronization method for secure mobile storage, aiming to solve problems such as data leakage, unauthorized access and low authority synchronization efficiency in mobile storage devices. Background Art

[0002] With the widespread use of mobile storage devices (such as USB flash drives, mobile hard drives, and portable SSDs), data security faces severe challenges. In existing technologies, traditional encryption methods (such as AES) only provide static protection, lack dynamic permission management capabilities, and cannot flexibly adjust access rights based on factors such as user identity, time, and location. Although role-based access control (RBAC) and attribute-based encryption (ABE) can achieve permission grading, they have problems with complex key management and high synchronization delay. For example, in RBAC, when the association between roles and permissions changes, key updates are cumbersome; in ABE, a large number of attribute calculations and key distributions increase the complexity of the system. In addition, cross-device permission synchronization usually relies on centralized servers, which is prone to single point failures. Once a problem occurs with the server, the entire permission synchronization mechanism will be paralyzed, resulting in blocked data access, seriously affecting data security and availability. Therefore, an innovative solution is urgently needed to solve these problems.

[0003] Full terms and abbreviations

[0004] HSM: Hardware Security Module, a hardware device specifically designed to protect and manage keys. It uses hardware encryption, access control, and other security mechanisms to prevent keys from being stolen or tampered with.

[0005] ●PBKDF2: Password-Based Key Derivation Function 2, used to generate subkeys from a master key and a salt value, increasing key security through multiple iterative calculations.

[0006] SHA-256: Secure Hash Algorithm 256-bit, a widely used hash function that converts data into a 256-bit fixed-length hash value that is unique and irreversible.

[0007] ●AES: Advanced Encryption Standard, a symmetric encryption algorithm. Common versions include AES-128, AES-256, and other versions with different encryption strengths. It is used for data encryption.

[0008] Merkle tree: A binary tree structure whose leaf nodes are the hash values of the data and whose internal nodes are the combined hash values of their child nodes. It is often used to verify data integrity and consistency.

[0009] Schnorr protocol: A cryptographic protocol based on the discrete logarithm problem for implementing zero-knowledge proofs. In this paper, it is used to generate temporary tokens to ensure the security and privacy of permission verification.

[0010] ZKP: Zero-Knowledge Proof, a technology that proves a fact without revealing sensitive information. In this invention, it is used to verify user permissions while protecting subkey security.

[0011] ChaCha20: A stream encryption algorithm with high efficiency and security. It is used in this invention to encrypt low-level data to reduce computational overhead. Summary of the Invention

[0012] The purpose of the present invention is to provide a multi-level access control and permission synchronization method for secure mobile storage. Through innovative technical means, multi-level dynamic access control and decentralized permission synchronization of mobile storage device data are realized, solving the problems of complex key management, high synchronization delay, single point failure, etc. in the prior art, thereby improving the security and management efficiency of mobile storage devices.

[0013] Technical Solution

[0014] The multi-level access control and permission synchronization method for secure mobile storage proposed in this invention mainly includes a multi-level access control architecture, decentralized permission synchronization, dynamic tokens, and zero-knowledge proof. These components work together to achieve the following functions for secure mobile storage:

[0015] 1. Multi-level access control architecture

[0016] 1.1 Hierarchical Key Generation

[0017] In this multi-level access control and permission synchronization method for secure mobile storage, the hierarchical key generation mechanism is the key foundation for ensuring data security and independent access control.

[0018] The master key (MK), the core of the entire key system, is crucial for security. It is typically generated by the user during device initialization using high-strength cryptographic methods, such as a hardware security module (HSM)-based encryption algorithm. This algorithm utilizes the HSM's internal random number generator to generate the master key, ensuring it is highly random and unpredictable.

[0019] The master key MK generates multiple layers of subkeys through a key derivation function (KDF). The present invention uses the PBKDF2 (Password-Based Key Derivation Function 2) algorithm to implement this process. Its formula is:

[0020] SK i =PBKDF2(MK,Salt i ,N),i∈{1,2,…,n}

[0021] Among them, Salt i Salt is a level identifier, which is a unique and deterministic string or byte sequence that is closely associated with each level. i The generation method can be based on the unique hardware identification of the device (such as the device serial number) and the level number to perform a specific hash operation, which can ensure that the Salt of different levels i Different from each other, it can ensure the repeatability and security of its generation process. Its generation rules are: Salt i = SHA-256(DeviceSN|LevelID), where DeviceSN is the device's unique serial number (e.g., 16 bytes) and LevelID is the level ID (e.g., 2 bytes). The concatenation is followed by a SHA-256 hash operation to generate a unique Salt value. The example pseudocode is as follows:

[0022] defgenerate_salt(device_sn,level_id):

[0023] combined=device_sn+level_id.to_bytes(2,'big')

[0024] return hashlib.sha256(combined).digest()

[0025] N is the number of iterations. The choice of this number directly impacts the security and computational cost of generating the subkey. In practical applications, the value of N varies depending on security requirements and device performance. For example, in scenarios with extremely high security requirements and sufficiently powerful devices, N can be set to a larger value, such as 10,000. For resource-constrained devices that still require a certain level of security, N can be appropriately lowered, but generally not less than 1,000. Multiple iterative calculations increase the difficulty of brute-force cracking of the subkey, making it difficult for an attacker to recover the original master key even if they obtain some intermediate calculation results.

[0026] Each layer of subkey SK iEach encryption zone corresponds to an independent encryption zone. These encryption zones are isolated from each other in the logical structure of the storage device. Different encryption zones use different encryption algorithms and keys to encrypt data. For example, the highest-level encryption zone might use the AES-256 algorithm to protect the most important and sensitive data. Lower-level encryption zones might use AES-128 or other relatively lightweight encryption algorithms based on the importance and access frequency of the data, improving data access efficiency while ensuring a certain level of security.

[0027] The advantage of this hierarchical key generation mechanism is that even if the subkeys at one level are compromised, attackers cannot access data in encryption zones at other levels, effectively reducing the data security risks associated with key leaks. Furthermore, the independent encryption zone design facilitates refined management and access control of data at different levels.

[0028] 1.2 Dynamic Permission Strategy:

[0029] Dynamic permission strategy is the key to achieve flexible and secure access to data in mobile storage devices.

[0030] Access rules are defined as a four-tuple (U, R, T, C).

[0031] U represents the user's identity, which is verified using an asymmetric encryption certificate. Asymmetric encryption certificates are issued by an authoritative certification authority (CA). When applying for a certificate, users must provide valid identity information and pass the CA's rigorous identity verification process. The certificate contains the user's public key, identity identifier, and the CA's digital signature. When a user accesses a storage device, the device first obtains the user's certificate and verifies the certificate's digital signature using the CA's public key to ensure its authenticity and integrity. Only verified certificates can be used for subsequent permission verification, ensuring the legitimacy and traceability of the user's identity.

[0032] R represents operational permissions, which include three basic types: read, write, and execute. Different user identities and data levels may be assigned different combinations of operational permissions. For example, an administrator user may be granted read, write, and execute permissions for all data levels, enabling system management and data maintenance. Meanwhile, a regular user may only be granted read-only permissions for data at a specific level to prevent accidental operations or malicious tampering with important data.

[0033] T represents a time constraint, such as an expiration date. Time constraints can be specified with specific dates and times. For example, a user's access rights to data at a certain level are valid from 00:00:00 on October 1, 2024, to 23:59:59 on October 15, 2025. During permission verification, the system obtains the current time in real time and compares it with the validity period. If the current time is not within the validity period, the user's access request is denied, effectively preventing the abuse of expired permissions.

[0034] C stands for contextual conditions, such as geographic location and device fingerprint. Geographic location information can be obtained through the device's built-in GPS module or network-based IP address positioning technology. For example, it is set that certain sensitive data can only be accessed when the user's device is within a specific IP address range of the company's internal network. The device fingerprint is a unique identifier generated by collecting the device's hardware information (such as CPU model, hard disk serial number, network card MAC address, etc.) through a specific hash algorithm. During permission verification, the system will compare the obtained device fingerprint with the preset legitimate device fingerprint. Only matching devices can obtain the corresponding access rights, further enhancing the security of access control.

[0035] The authority verification formula is:

[0036]

[0037] In this formula, Sig U It is the digital signature generated by the user based on his private key for the access request. When the user initiates an access request, the system first obtains the user's digital signature Sig U and verify it using the public key in the user certificate to ensure the authenticity and integrity of the access request. i It is the permission policy corresponding to the i-th layer encryption zone, which contains the specific information of the above four-tuple (U, R, T, C).

[0038] H is a secure hash function, such as SHA-256. The hash function converts the input data into Converted into a fixed-length hash value, this hash value is unique and irreversible, that is, different input data will produce different hash values, and the original data cannot be deduced from the hash value. The subkey SK of the i-th layer i and the corresponding permission policy i The XOR operation is performed. The XOR operation has the characteristics that only when SK i and Policy i When all are correct, The result is correct, thus ensuring the accuracy of permission verification.

[0039] Hash chain It is a pre-calculated and stored hash chain value. Hash chain is a secure data structure based on hash function. It generates a series of hash values through multiple hash operations. The previous hash value is used as the input of the next hash operation. During the permission verification process, the system will calculate the With pre-stored Hash chain If the two are equal, the system returns 1, indicating that the permission verification is successful and the user can access the data at the corresponding level; otherwise, it returns 0, denying the user's access request.

[0040] Through this dynamic permission strategy and permission verification mechanism, users' access to data on mobile storage devices can be accurately and dynamically controlled based on multiple factors such as user identity, operation permissions, time constraints and context conditions, effectively ensuring data security and the legitimacy of access.

[0041] 2. Decentralized permission synchronization

[0042] 2.1 Incremental synchronization based on Merkle tree

[0043] In decentralized permission management systems, the Merkle tree-based incremental synchronization mechanism is the core method for achieving efficient permission synchronization. It can quickly and accurately synchronize permission change information between different devices while significantly reducing data transmission.

[0044] Every time a permission change occurs, the system generates an operation log (OpLog). The operation log records detailed information about the permission change, including the time of the change, the users or roles involved, and the specific permissions changed (such as adding permissions, deleting permissions, modifying permissions, etc.). These operation logs are stored in a structured data format to ensure information integrity and readability. For example, an operation log may contain the following fields: {"timestamp":"2024-11-15 10:30:00","user_id":"U001","permission_change":"add:read_access_to_file_X"}.

[0045] In order to more effectively manage and synchronize these operation logs, the system constructs a lightweight Merkle tree. The Merkle tree is a binary tree structure, where the leaf nodes are the hash values of the operation logs, and the internal nodes are the combined hash values of their child nodes. When constructing the Merkle tree, the leaf node processing rule is: if the number of operation logs is odd, copy the hash value of the last log as a filler node. The internal node hash calculation method is: Node paren =SHA-256(Nodeleft ‖Node right )The formula for constructing a Merkle tree is:

[0046] Root=MerkleHash(OpLog1‖OpLog2‖…‖OpLog k )

[0047] Among them, OpLog i represents the i-th operation log, || represents string concatenation, and MerkleHash is a specific hash function used to calculate the hash value of a Merkle tree node. Common hash functions such as SHA-256 can be used for this purpose. By hashing the operation log and combining the hashes layer by layer, the root hash value of the Merkle tree is ultimately obtained.

[0048] The synchronization process between devices is based on exchanging the root hash of the Merkle tree and the difference path. When a device (such as device A) changes its permissions and builds a new Merkle tree, it broadcasts the new root hash value to other devices that need to be synchronized (such as device B). After receiving the root hash value, device B compares it with its own local Merkle tree root hash. If the two root hash values differ, it indicates that a permission change has occurred and synchronization is required.

[0049] Next, device B requests a differential path from device A. A differential path is a series of hash values from the leaf nodes (corresponding to the operation log) of the Merkle tree to the root node. These hash values can be used to verify the authenticity and integrity of the leaf nodes. Device A provides the corresponding differential path information based on device B's request. When device B requests synchronization, device A returns a differential path containing the following:

[0050]

[0051] After receiving the differential path, device B uses the locally stored operation log and the received differential path to recalculate the root hash value and compare it with the root hash value sent by device A. If the two are consistent, the synchronization is successful and device B updates the local permission information.

[0052] This Merkle tree-based incremental synchronization method only requires the transmission of the root hash value and the difference path, rather than the entire operation log, significantly reducing the amount of data transmitted. This can significantly improve synchronization efficiency and reduce synchronization costs, especially in situations with limited network bandwidth or device resources.

[0053] 2.2 Consistency Verification Protocol

[0054] The consistency verification protocol is key to ensuring data consistency during decentralized permission synchronization. It defines a judgment condition for determining whether permission information between different devices is consistent.

[0055] The synchronization consistency judgment conditions are defined as follows:

[0056]

[0057] Among them, D A and D B Represents two different devices, Consistent(D A ,D B ) is a Boolean function used to determine whether the device D A and D B Whether the permission information between Path is consistent. A→B Represents the difference path from device A to device B, which contains the necessary hash value information for verifying the consistency of the Merkle tree of the two devices.

[0058] VerifyPath(Path A→B ,Root A ,Root B ) is a verification function used to verify the validity of the difference path. This function receives the difference path Path A→B , Device A's Merkle tree root hash value Root A and the Merkle tree root hash value Root of device B B As input, if the verification passes, that is, the difference path can prove that the Merkle trees of the two devices are logically consistent, the function returns 1; otherwise, it returns 0.

[0059] In the actual synchronization process, when devices A and B synchronize permissions, device B first receives the root hash value Root of device A. A and with its own root hash value Root B Compare them. If they are different, device B requests the difference path from device A. A→B Device B then calls the VerifyPath function to verify the received differential path and the two root hash values. If the verification result is 1, it means that the permission information of devices A and B is consistent, and device B can update the local permission status. If the verification result is 0, it means that there is a problem in the synchronization process, which may be a differential path transmission error or data tampering, and resynchronization or error handling is required.

[0060] This consistency verification protocol ensures that permission information between different devices remains consistent in a decentralized environment, preventing security vulnerabilities and permission management confusion caused by synchronization errors or data inconsistencies.

[0061] 3. Dynamic Tokens and Zero-Knowledge Proof

[0062] Temporary token generation and verification when a user requests access

[0063] In the security architecture of this system, when a user initiates an access request to a specific resource, the system uses a dynamic token combined with a zero-knowledge proof mechanism to ensure the security and privacy of the permission verification process.

[0064] 3.1 Generation of Temporary Token

[0065] When a user requests access, the system generates a temporary token and uses the Schnorr protocol to implement zero-knowledge proof. The specific parameters are as follows:

[0066] Elliptic curve: secp256k1

[0067] Signature algorithm: Schnorr signature based on discrete logarithm problem;

[0068] The generation formula is expanded to:

[0069] Token=Schnorr.Prove(SK i ,Nonce)

[0070] SK here i This is the i-th subkey generated in the hierarchical key generation mechanism described above. It serves as the core credential for access to data at that level. Subkeys at different levels are independent of each other, providing different levels of security for data at different levels.

[0071] Nonce is a random number, also known as a one-time random number. Its role is to introduce randomness and uniqueness to each temporary token generated. Every time a user initiates an access request, the system will generate a new Nonce. The advantage of this is that even with the same subkey SK i In this case, due to the difference in Nonce, the temporary token generated each time will also be different, which effectively prevents the token from being reused and replay attacks.

[0072] During verification, the validity of the signature and the uniqueness of Nonce must be checked. i , Nonce) generates a temporary token Token containing the proof that the user has the sub-key SK i Necessary information for access rights, but without directly exposing SKi The specific value of .

[0073] 3.2 Verification of Temporary Token

[0074] After the temporary token is generated, it needs to be verified to ensure that the user's access request is legitimate. The verification conditions are as follows:

[0075] Verify ZKP (Token,Policy i )=1 and

[0076] Verify ZKP (Token,Policy i )=1:

[0077] Verify ZKP It is a zero-knowledge proof verification function used to verify whether the temporary token Token complies with the permission policy corresponding to the i-th layer encryption zone. i Policy i As mentioned above, it is a four-tuple containing information such as user identity, operation permissions, time constraints and context conditions. ZKP (Token,Policy i ) is 1, indicating that the temporary token Token can prove that the user's access request complies with the permission policy of this level, that is, the user has the corresponding access rights.

[0078]

[0079] This condition ensures that the subkey SK cannot be derived from the temporary token Token i This is one of the core advantages of the zero-knowledge proof mechanism. It ensures that during the permission verification process, even if an attacker intercepts the temporary token Token, he cannot obtain the subkey SK through the token. i , thus protecting the security of the subkey. Because the subkey is the key to accessing data at a specific level, once leaked, the security of the data at that level may be threatened.

[0080] Through this dynamic token and zero-knowledge proof mechanism, the system can accurately determine whether the user has legal access rights when performing permission verification, and ensure that no sensitive information related to the subkey is leaked during the entire verification process, thereby greatly improving the security of the system and the privacy of user data.

[0081] 4. Innovation

[0082] The present invention proposes a multi-level access control and authority synchronization method for secure mobile storage, which is innovative in many aspects, effectively solves the problems of traditional technologies, and significantly improves the security and management efficiency of mobile storage devices.

[0083] (1) Layered encryption and dynamic permission binding

[0084] A composite key derivation structure is employed to partition storage space into multiple hierarchical zones, each associated with an independent permission policy. A master key generates multiple subkeys using a key derivation function, each corresponding to an independent encryption zone, enhancing security. Access rules are defined as a four-tuple encompassing user identity, operational permissions, time constraints, and contextual conditions, enabling precise dynamic permission control and transcending the limitations of traditional static encryption.

[0085] Clarify the hierarchical classification standards:

[0086] Core data layer: Real-time operating data (voltage, current), encrypted using AES-256.

[0087] ●Business data layer: device configuration and alarm logs, encrypted using AES-128.

[0088] ●Log data layer: Operation audit records, encrypted using ChaCha20.

[0089] The claims explicitly reference the hierarchical strategy of the power grid embodiment to enhance the clarity of the protection scope.

[0090] (2) Decentralized synchronization protocol

[0091] Based on blockchain light node technology, this system implements real-time verification and synchronization of permission changes, avoiding the single point of failure inherent in centralized servers. It utilizes Merkle trees for incremental synchronization, exchanging root hashes and differential paths between devices to reduce data transmission and improve synchronization efficiency. Furthermore, a consistency verification protocol is defined to ensure consistent permission information across different devices.

[0092] (3) Zero-knowledge dynamic token

[0093] Combining two-factor authentication with lightweight zero-knowledge proofs, a temporary token is generated when a user requests access. This token verification process ensures permission verification without leaking key information, ensuring the credibility and privacy of the verification process and effectively defending against man-in-the-middle attacks.

[0094] (4) Incremental synchronization algorithm

[0095] Utilizing operation log compression and differential hash chaining technology, synchronization bandwidth is reduced to less than 30% of traditional methods. Each permission change generates an operation log to construct a Merkle tree. Devices synchronize based on the root hash and differential paths, significantly improving synchronization efficiency, reducing storage overhead, and optimizing system performance.

[0096] Beneficial effects

[0097] The present invention has the following beneficial effects:

[0098] (1) Enhanced access control flexibility and security: Layered encryption is combined with dynamic permissions to divide storage space into multiple levels, with each level associated with an independent permission policy. A master key derives multiple subkeys corresponding to different encryption zones. Combined with a quadruple of access rules containing multiple factors, this allows for precise dynamic permission control, breaking through the limitations of traditional static encryption protection, effectively preventing unauthorized access, and ensuring data security.

[0099] (2) Improve the efficiency and reliability of permission synchronization: Decentralized permission synchronization is achieved based on blockchain light node technology to avoid the single point of failure of centralized servers. Merkle trees are used for incremental synchronization to reduce data transmission volume and improve synchronization efficiency. The consistency verification protocol ensures that permission information is consistent between different devices, ensuring the accuracy and stability of permission management.

[0100] (3) Ensure the security and privacy of the verification process: Combining two-factor authentication with lightweight zero-knowledge proof, a temporary token is generated when a user requests access. The token verification process ensures that permission verification is passed without leaking key information, effectively resisting man-in-the-middle attacks, ensuring the credibility and privacy of the verification process and maintaining the security and privacy of user data.

[0101] (4) Optimizing system performance and resource utilization: Using operation log compression and differential hash chain technology, we reduce synchronization bandwidth to less than 30% of traditional methods. By constructing a Merkle tree for incremental synchronization, we reduce storage overhead, improve synchronization efficiency, optimize overall system performance, and enhance resource utilization efficiency of mobile storage devices. DETAILED DESCRIPTION

[0102] The present invention will be further described below in conjunction with specific embodiments:

[0103] Example 1

[0104] Example: Multi-level access control and permission synchronization in a power grid environment

[0105] Step 1: User inserts the device and activates the master key through biometric authentication

[0106] In the power grid environment, various professional devices have extremely high requirements for data security and access control. When power grid operators or managers need to use mobile storage devices to access power grid system data, they first insert the device into the corresponding interface.

[0107] To ensure that only authorized personnel can activate the master key, the power grid system employs advanced biometric technology. Common biometric methods include fingerprint recognition, facial recognition, and iris recognition. For example, the device is equipped with a high-precision fingerprint sensor. When the user inserts the device, the system prompts the user to place their finger on the sensor. The sensor quickly captures the user's fingerprint image and converts it into a digital feature template. This template is then compared with authorized fingerprint templates pre-stored in the system. This comparison is based on complex algorithms, such as minutiae matching, which precisely analyzes the location and relationship of fingerprint features, such as breakpoints and bifurcations. If the comparison is successful, indicating the user's identity is legitimate, the system activates the master key MK. The master key MK is the core of the entire multi-level access control architecture and is stored in encrypted form in a secure area of the system, such as a hardware security module (HSM), to prevent unauthorized access.

[0108] Step 2: The system loads hierarchical permissions according to the preset strategy

[0109] After the master key is activated, the system will load the corresponding level of permissions for the user according to the preset permission policy. In the power grid environment, data is divided into different levels according to its importance and sensitivity. For example, the real-time operation data of the power grid, such as voltage, current, power and other parameters, belong to the highest level, because the accuracy and security of these data are directly related to the stable operation of the power grid. Some historical statistical data, such as monthly electricity consumption statistics, belong to a lower level. The preset permission policy is based on the user's role and responsibilities. For example, power grid operation and maintenance personnel may be granted read-only permissions to some real-time operation data for troubleshooting and equipment monitoring; while power grid management personnel may have read and write permissions to all levels of data for decision-making and planning. The system will search for the corresponding permission policy from the database based on the user's identity information (obtained through biometric verification) and load it into the system. At the same time, the system will use the master key MK to generate the subkey SK of the corresponding level through the key derivation function (KDF) according to the hierarchical key generation mechanism. i Each subkey corresponds to an independent encryption zone, used to protect data at that level. Furthermore, to optimize encryption performance, low-level data (such as historical statistics) is encrypted using the ChaCha20 algorithm, which reduces computational overhead by 30% compared to AES-256.

[0110] Step 3: Generate OpLog when permissions change and broadcast it to the synchronization network

[0111] During power grid operation, permissions may change due to personnel adjustments, evolving business needs, and other factors. For example, if an operations and maintenance staff member is promoted to management, their permissions may need to be upgraded from read-only access to some real-time operational data to read and write access to all data at all levels. When a permission change occurs, the system immediately generates an operation log (OpLog). The operation log records detailed information about the permission change, including the time of the change, the users involved, and the permissions before and after the change.

[0112] For example, an operation log may look like this:

[0113] {

[0114] "timestamp":"2024-11-2014:30:00",

[0115] "user_id":"U007",

[0116] "old_permission":"read-only access to real-time voltage data",

[0117] "new_permission":"read-write access to all levels ofgrid data"

[0118] }

[0119] To handle synchronization conflicts, timestamp and version number fields are added to the operation log. When devices synchronize, the latest version of the log is merged first to ensure eventual consistency. After the operation logs are generated, the system constructs a lightweight Merkle tree based on them. The root hash value of the Merkle tree is broadcast to the synchronization network. The synchronization network is a distributed network composed of multiple related devices, including servers and terminal devices, all of which need to maintain consistent permission information.

[0120] Step 4: Other devices complete state synchronization by verifying the Merkle path

[0121] After receiving the broadcasted Merkle tree root hash, other devices in the synchronization network compare it with their locally stored Merkle tree root hash. If the two root hashes differ, a permission change requires synchronization. At this point, the device requests a difference path from the broadcasting device: a series of hash values from the Merkle tree leaf nodes (corresponding to the operation log) to the root node. After receiving the difference path, the requesting device recalculates the root hash using its locally stored operation log and the received difference path. The difference path is verified using the VerifyPath function. If the verification result is true, the devices in the synchronization network can confirm that the received permission change information is authentic and valid, and consistent with the permission status of the broadcasting device. The devices then update their local permission information, completing the state synchronization. In power grid environments, to enhance security, the Merkle tree root hash is protected. When the root hash is broadcast, it is accompanied by a digital signature (based on an ECC private key) from device A. The recipient verifies the signature before performing synchronization to prevent tampering. Furthermore, in terms of nonce management, the system pre-generates a nonce pool (e.g., 1,000 nonces), stores them in the HSM secure cache, allocates them on demand, and marks them as used, avoiding real-time generation delays. Furthermore, for contextual multi-factor authentication, the geographic location must meet both GPS coordinates (error ≤ 50 meters) and an access IP whitelist (e.g., limited to the power grid intranet 10.0.0.0 / 8). This synchronization mechanism ensures that permission information remains consistent across devices, avoiding security vulnerabilities and operational errors caused by inconsistent permissions, thereby ensuring the safe and stable operation of the power grid system. BRIEF DESCRIPTION OF THE DRAWINGS

[0122] Attachment Figure 1 This paper demonstrates the multi-level access control and permission synchronization process of secure mobile storage. The specific process is as follows:

[0123] 1. User Inserts Device and Master Key Activation: The user inserts a mobile storage device into the corresponding port, and the system initiates a biometric recognition program, such as fingerprint recognition, facial recognition, or iris recognition. Taking fingerprint recognition as an example, the high-precision fingerprint recognition sensor on the device captures the user's fingerprint image and converts it into a digital feature template. This is then compared with the authorized fingerprint template pre-stored in a secure area of the system (such as a hardware security module HSM). If the comparison is successful, the system activates the master key MK.

[0124] 2. Permission loading: After the master key is activated, the system searches and loads the corresponding hierarchical permissions from the database based on the preset permission policy and user identity information (obtained by biometric verification). At the same time, according to the hierarchical key generation mechanism, the master key MK is used to generate the corresponding hierarchical subkey SK through the PBKDF2 algorithm. i , each subkey corresponds to an independent encryption area, which is used to protect the data at that level.

[0125] 3. Access request and temporary token generation: When a user requests access to a specific resource (such as a file or data), the system uses the i-th subkey SK based on the Schnorr protocol i And the random number Nonce, according to the formula Token=Schnorr.Prove(SK i ,Nonce) generates a temporary token Token.

[0126] 4. Permission verification: The system loads the preset permission policy and verifies the temporary token Token. Verify the function through zero-knowledge proof ZKP (Token,Policy i ) Determine whether the Token complies with the permission policy corresponding to the i-th encryption zone i , while ensuring that the subkey Sk cannot be derived from the Token i ). If the verification is successful, Verify ZKP (Token,Policy i )=1 and The user's permissions are determined to be legal, and the user is allowed to access the corresponding level of data; if the verification fails, access is denied.

[0127] The embodiments of the present invention are not limited to the above description. In actual application scenarios, device configurations, encryption algorithm parameters, and permission policies can be adjusted to meet different needs. For example, in the financial sector, where security is extremely important, stronger encryption algorithms and stricter permission verification mechanisms can be selected. In resource-constrained IoT device scenarios, algorithms can be optimized to reduce computational overhead and resource usage. Such improvements fall within the scope of protection of the present invention.

Claims

1. A multi-level access control and permission synchronization method for secure mobile storage, characterized in that: The following steps are involved: 1.1 Multi-level access control architecture construction: Hierarchical key generation: Generate the master key MK using the encryption algorithm based on the hardware security module (HSM), and then use the PBKDF2 algorithm according to the formula SK i =PBKDF2(MK,Salt i ,N), where Salt i =SHA-256(DeviceSN|LevelID), generating multiple layers of subkeys, each corresponding to an independent encryption zone and using a different encryption algorithm; Dynamic permission strategy formulation: define access rules as a four-tuple (U, R, T, C), verify user identity U based on asymmetric encryption certificate, clarify operation permission R, set time constraint T and context condition C, and use permission verification formula Perform permission verification; 1.2 Synchronous implementation of decentralized permissions: Merkle tree-based incremental synchronization: When permissions change, an operation log OpLog is generated and a Merkle tree is constructed. Devices synchronize by exchanging the tree root hash and difference paths. Consistency verification: based on synchronization consistency judgment conditions Ensure that permission information is consistent across different devices; 1.3 Dynamic Token and Zero-Knowledge Proof Application: Temporary token generation: When a user requests access, based on the Schnorr protocol, according to the formula Token=Schnorr.Prove(SK i ,Nonce) generates a temporary token; Temporary token verification: pass verification condition Verify ZKP (Token,Policy i )=1 and Determine the legitimacy of user access rights.

2. The multi-level access control and authority synchronization method for secure mobile storage according to claim 1, characterized in that: When used in a power grid environment, the user activates the master key through biometric identification after inserting the device. The system loads hierarchical permissions according to the preset strategy. When permissions change, an OpLog is generated and broadcast to the synchronization network. Other devices verify the Merkle path to complete status synchronization.

3. The multi-level access control and authority synchronization method for secure mobile storage according to claim 1, characterized in that: The number of iterations N is determined based on security requirements and device performance. For scenarios with high security requirements and powerful device performance, N is not less than 10,000 times; for resource-constrained devices, N is not less than 1,000 times.

4. The multi-level access control and authority synchronization method for secure mobile storage according to claim 1, characterized in that: Add timestamp and version number fields to the operation log OpLog. When synchronizing devices, the latest version log is merged first to ensure eventual consistency.

Images