Multi-agency cloud distributed anti-quantum data security management and control platform construction method

Abstract

The application relates to the technical field of data security and discloses a multi-agency cloud distributed quantum-resistant data security management and control platform construction method. The method constructs a league trust root based on a threshold lattice signature, generates a league master public key and an agency certificate, and establishes a hierarchical key management system. Data hierarchical encryption and storage are realized through encryption and erasure code technology, fine-grained attribute key management and access control are supported by combining multi-authority attribute encryption and a delegation authorization protocol. Lattice key exchange and secure multi-party computation protocols are adopted to guarantee session security and data privacy in the collaborative computing process, realize network coding transmission and full-homomorphic ciphertext computation. An audit tracing system is constructed by using a quantum-resistant hash chain and a Merkle tree to form a verifiable log chain, a threat detection mechanism and a compliance report. The application can realize safe sharing, collaborative computing and full-link traceable management of cross-agency data under the threat of quantum computing.

Description

Technical Field

[0001] This invention relates to the field of data security technology, and more specifically, to a method for constructing a multi-organization cloud-distributed quantum-resistant data security management and control platform. Background Technology

[0002] With the development of cloud computing and big data technologies, multiple regulatory agencies, financial institutions, and medical institutions need to conduct cross-domain data sharing and collaborative computing in cloud environments. However, traditional data security technologies face the threat of quantum computing; public-key cryptography systems based on RSA and elliptic curves will lose their security in the face of quantum computers. At the same time, multi-institutional collaboration scenarios present problems such as fragmented data sovereignty, complex trust relationships, and diverse regulatory requirements, making it difficult for existing technologies to achieve secure and efficient data sharing while protecting the data privacy of all parties.

[0003] Existing cloud data security solutions suffer from the following key technical problems: First, there is a lack of systematic application of quantum-resistant cryptographic algorithms; key management, data encryption, and authentication still rely on traditional cryptographic systems, which are unable to cope with the threats of quantum computing. Second, access control mechanisms are coarse-grained, making it difficult to support fine-grained attribute-based authorization and dynamic permission management across institutions. Third, privacy protection technologies are lacking during data sharing; collaborative computing between institutions requires the exchange of plaintext data, posing a risk of data leakage. Fourth, audit and traceability capabilities are insufficient; operation logs are easily tampered with, making it difficult to meet compliance requirements for cross-border data regulation. These technical problems hinder the improvement of data security management capabilities in multi-institutional cloud distributed environments.

[0004] Therefore, there is an urgent need for a method to build a multi-organization cloud-distributed data security management platform that can resist quantum computing attacks, support fine-grained access control, protect data privacy, and provide complete audit traceability. Summary of the Invention

[0005] This invention provides a method for constructing a multi-organization cloud-distributed quantum-resistant data security management and control platform, which solves the technical problems in related technologies such as the lack of systematic application of quantum-resistant cryptographic algorithms, coarse granularity of access control, lack of privacy protection in data sharing, and insufficient audit traceability capabilities.

[0006] This invention provides a method for constructing a multi-organization cloud-distributed quantum-resistant data security management platform, comprising the following steps: S1. Obtain the collaboration requirements of participating institutions, construct the consortium trust root using the threshold lattice signature scheme, and obtain the consortium master public key and institution identity credentials; S2 receives the alliance master public key and the institution's identity credential, constructs a hierarchical key management system, and obtains the institution's master key pair, domain key, and data key; S3 receives the domain key and data key, and uses encryption and erasure coding methods to obtain hierarchical encrypted data files and attribute encrypted ciphertexts; S4 receives the attribute encrypted ciphertext and the organization's identity credential, and uses a multi-authority attribute encryption and delegation authorization protocol method to obtain the user attribute key component, attribute revocation tree and delegation authorization token; S5 receives the receiving organization's master key pair, delegation authorization token, and hierarchical encrypted data file. It uses a lattice-based key exchange protocol and a secure multi-party computation method to establish a quantum-resistant secure channel and privacy computation capabilities, and obtains the session key, network-coded data packets, secret share data, and fully homomorphic ciphertext computation results. S6. Based on all operational events generated during the process, an audit traceability system is constructed using quantum-resistant hash chains and Merkle tree methods to obtain an audit log hash chain, a Merkle tree index, a threat detection rule base, and a compliance report.

[0007] In a preferred embodiment, constructing a consortium trust root using a threshold lattice-based signature scheme includes: Based on N participating institutions, the threshold parameter T is set to half of N plus 1; a lattice-based signature scheme based on NTRU lattice construction is selected to generate the master private key and master public key of the consortium trust root; The Shamir secret sharing algorithm is used to threshold the master private key, construct a polynomial of degree T minus 1, set the constant term as the secret value, calculate the polynomial value at N different horizontal coordinate points to obtain N secret shares, and distribute the shares to each institution through a secure channel and store them in the hardware security module. The certificate issuance is jointly completed by at least T institutions. The initiator constructs the content of the certificate to be signed and calculates the hash value. Each institution uses its private key share to generate a partial signature vector from the hash value. The signing initiator collects at least T partial signatures and then uses the Lagrange interpolation method to perform weighted combination to obtain the complete signature vector.

[0008] In a preferred embodiment, the construction of the hierarchical key management system includes: Each organization selects the ML-KEM algorithm to generate an organizational master key pair, obtaining a sealing key and a desealing key. The sealing key is issued as the organization's master public key after being authenticated by the alliance trust root digital signature, and the desealing key is stored as the organization's master private key in the hardware security module. The institution derives the master key from the random seed key generated during the key generation process, and generates a domain key for each security domain through the HKDF key derivation function. The derivation process executes the HKDF-Extract phase and the HKDF-Expand phase. For a specific data object, a data key is further derived from the corresponding domain key. The derived parameters include the domain key as the input key material; the data object identifier and creation time concatenated as the salt value; and the version number included in the context information.

[0009] In a preferred embodiment, the encryption and erasure coding method includes: Construct an intelligent data classification system to extract structured features, content features, and contextual features from the data to be stored. Use a pre-trained BERT model to semantically encode text fields into vectors, extract statistical features from numerical fields, and use graph neural networks to extract graph structure features from relational data. Multimodal features are input into a hierarchical attention neural network for sensitivity classification. The network includes a feature fusion layer, an attention layer, and a classification layer, and outputs a probability distribution of sensitivity levels. Encryption algorithms are selected based on sensitivity levels: Level 1 sensitive data is encrypted using the BGV fully homomorphic encryption scheme, while Level 2 and Level 3 sensitive data are encrypted using AES-256-GCM with derived data keys.

[0010] In a preferred embodiment, the method of employing encryption and erasure coding further includes: Set the fragmentation parameters M as the number of data blocks and K as the number of parity blocks, and divide the encrypted data into M data blocks of a fixed size; The Reed-Solomon erasure coding algorithm is used to encode M data blocks to generate K parity blocks. The encoding process constructs a generator matrix, with the first M rows corresponding to the data blocks as identity matrices and the last K rows corresponding to the parity blocks as Vandermonde matrices. M plus K storage blocks are distributed across different data centers, and metadata is attached to each storage block. The metadata includes a data object identifier, block number, block type, storage location, and integrity hash value.

[0011] In a preferred embodiment, the attribute-encrypted ciphertext includes: Choose a lattice-based ciphertext policy attribute encryption scheme based on the learning error problem, and convert the access policy expression into an access tree structure, where leaf nodes correspond to single attribute conditions and internal nodes correspond to logic gates. A random symmetric key is generated to encrypt the data content. A secret value is assigned to each node in the access tree. The secret value of the root node is set to the random symmetric key. For internal nodes, the secret value of the child node is assigned according to the logic gate type. To generate a ciphertext component for each leaf node of the access tree, the secret value of the leaf node is encrypted using lattice-based encryption with public parameters associated with the attribute of that leaf node. The generated attribute-encrypted ciphertext contains encrypted data content, an access tree structure description, and a set of ciphertext components.

[0012] In a preferred embodiment, the method employing multi-authority attribute encryption and delegation authorization protocol includes: Each organization, as an independent attribute authority, maintains the attribute authority master key and public parameters. When a user registers, the organization is assigned an attribute set based on the position and responsibilities, and uses the master key to generate an attribute key component for each attribute. When a user decrypts attribute-encrypted ciphertext, the access tree structure and ciphertext component set are extracted from the ciphertext. The attribute key is used to perform decryption operations on the ciphertext access tree. The decryption algorithm recursively traverses the access tree and combines the decryption results of child nodes according to the logic gate type. Construct a hierarchical attribute revocation tree to manage attribute key versions and revocation. When a user revokes a specific attribute, update the key version number of the corresponding leaf node in the revocation tree. Then, traverse upwards from the leaf node to the root node to update the key versions of all internal nodes along the path.

[0013] In a preferred embodiment, the delegation authorization token includes: The delegation authorization is initiated by the data ownership organization to generate a delegation token. The token contains the identifier of the delegated user, the scope of authorized data, the type of authorized operation, the start and end dates of the validity period, the limit on the number of times it can be used, and the digital signature of the initiating organization. The initiating organization uses the lattice-based ML-DSA digital signature algorithm to sign the token content; when the entrusted user accesses the data, he / she submits the user identity credentials, attribute key and entrustment token, and the data storage system verifies the digital signature, validity period, number of uses and consistency of user identity of the entrustment token; After data access is completed, the system records the token usage and updates the usage count. When the token usage reaches the limit or the validity period expires, the token automatically becomes invalid and is added to the revocation list.

[0014] In a preferred embodiment, the establishment of quantum-resistant secure channels and privacy computing capabilities using a lattice-based key exchange protocol and secure multi-party computation methods includes: Institution A generates a temporary key pair and sends the temporary public key to Institution B. Institution B uses Institution A's temporary public key to execute the ML-KEM encapsulation algorithm to generate a shared key and encapsulated ciphertext. Institution A uses the temporary private key to execute the ML-KEM decapsulation algorithm to recover the shared key and uses HKDF to derive the session key from the shared key. An additive secret sharing scheme is used to share data. Each data value is divided into N secret shares. The secret shares are encrypted using a lattice-based encryption scheme before being exchanged. In the calculation process, the addition operation is performed directly on the shares of each party, and the multiplication operation adopts the Beaver triplet technique. The BGV fully homomorphic encryption scheme is used to encrypt the data and upload it to the cloud computing server. The cloud server performs addition and multiplication operations on the ciphertext, and after the calculation is completed, it returns the ciphertext result to the data owner for decryption.

[0015] In a preferred embodiment, the construction of the audit traceability system using the quantum-resistant hash chain and Merkle tree method includes: The audit logs are organized into a hash chain data structure in chronological order. When a new log is added, the hash value of the previous node is calculated. The new log content is concatenated with the previous hash value and then SHA3-512 hash operation is performed to obtain the hash value of the new node. The log records within a batch are treated as leaf nodes of the Merkle tree. Starting from the leaf node layer, internal nodes are built up layer by layer until a unique root node is constructed. The hash value of the root node is published as the Merkle root to a public and trusted storage. Establish a compliance rule base and user behavior baseline analysis mechanism. The rule engine listens to the audit log stream in real time to perform rule matching, compares the user's current behavior characteristics with the historical baseline to calculate a comprehensive anomaly score, and generates a security event when the comprehensive anomaly score exceeds a preset threshold.

[0016] The beneficial effects of this invention are as follows: A distributed consortium trust root and quantum-resistant key hierarchical management system was constructed using threshold lattice signatures and ML-KEM key encapsulation to achieve cryptographic protection from the consortium level down to the data level. Threshold signatures support collaborative management by multiple organizations, avoiding single points of failure; HKDF-based key derivation establishes a three-level structure of organization master key, domain key, and data key, achieving fine-grained isolation and secure control. A multi-layered data privacy protection system was constructed through intelligent data classification and attribute encryption. The intelligent classification model automatically identifies data sensitivity based on multimodal characteristics and adapts differentiated encryption strategies. Lattice-based ciphertext policy attribute encryption embeds access policies into the ciphertext, enabling fine-grained authorization, and combines attribute revocation trees and delegation authorization mechanisms to support dynamic access management. Secure multi-party computation and fully homomorphic encryption technologies ensure data privacy in cross-organizational collaborative computing, enabling all parties to perform secure computations in ciphertext. The audit and traceability system utilizes quantum-resistant hash chains and Merkle trees to construct an immutable operation log chain, combining a rule engine and behavioral analysis to achieve real-time threat detection, providing complete compliance verification and traceability capabilities for cross-border data flows. Attached Figure Description

[0017] Figure 1 This is a flowchart of the construction method of the multi-organization cloud distributed quantum-resistant data security management and control platform of the present invention; Figure 2 This is a flowchart of the construction method of the multi-organization cloud distributed quantum-resistant data security management platform of the present invention. Detailed Implementation

[0018] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed only to enable those skilled in the art to better understand and implement the subject matter described herein, and changes may be made to the function and arrangement of the elements discussed without departing from the scope of this specification. Various processes or components may be omitted, substituted, or added as needed in the examples. Furthermore, some features described in the examples may be combined in other examples.

[0019] At least one embodiment of the present invention discloses a method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform, such as... Figures 1 to 2 As shown, it includes the following steps: S1. Obtain the collaboration requirements of participating institutions, construct the consortium trust root using the threshold lattice signature scheme, and obtain the consortium master public key and institution identity credentials; S11: Obtain the basic information and security requirements of each participating organization, complete identity registration using the organization registration protocol, and obtain a set of organization identifiers; The alliance initiators send invitations to candidate regulatory agencies via secure email or a dedicated communication system. These invitations include the alliance's bylaws, technical specifications, and security requirements. Candidate agencies submit registration applications, including their legal name, country and region of origin, scope of business, and public key certificate. The verification committee reviews and verifies the applications, assigning each agency a globally unique identifier in UUID format. The agency identifier, name, country of origin, and joining date are recorded in the alliance's registry, which uses distributed storage and a consensus protocol to ensure consistency. The resulting set of agency identifiers serves as the foundational data for building the subsequent trust system.

[0020] S12, based on the set of organization identifiers, uses the threshold secret sharing algorithm to generate the consortium trust root key and obtain the distributed private key share; Based on N participating institutions, a threshold parameter T is set to half of N plus 1 to ensure that more than half of the institutions can jointly execute the signature operation. A lattice-based signature scheme based on the NTRU lattice is selected, whose security can be reduced to the short integer solution problem on a ring and has quantum resistance. The master private key (a short vector on the lattice, such as vector s=(3,-2,1,0,-1), with small absolute values ​​of each component) and the master public key (lattice base matrix and public parameters, such as matrix A being an n x m random matrix, and public parameters including modulus q and vector t=As) are generated for the consortium trust root. The Shamir secret sharing algorithm is used to threshold-segment the master private key, constructing a polynomial of degree T minus 1. The constant term is set as the secret value, and other coefficients are randomly selected. The polynomial value is calculated at N different x-coordinate points to obtain N secret shares. For example, when N equals 3 and T equals 2, the secret value is set to 100. A first-degree polynomial f(x) is constructed, which equals 100 plus 3x, where the coefficient 3 is randomly selected. Shares f(1) equals 103, f(2) equals 106, and f(3) equals 109 are calculated at x-coordinate points 1, 2, and 3, respectively. Any two shares can be used to recover the secret value of 100 through Lagrange interpolation. The shares are distributed to various institutions through a secure channel and stored in a hardware security module. Any T shares can be used to recover the master private key through Lagrange interpolation; less than T shares cannot obtain the master private key information.

[0021] S13, based on distributed private key shares, uses a threshold signature protocol to issue identity credentials to organizations, resulting in quantum-resistant organization certificates; The organization identity credential uses the X.509 certificate format, containing an organization identifier, organization name, organization public key, validity period, certificate serial number, and a digital signature of the consortium's root of trust. The organization public key field in the certificate is filled with the public key from the public key certificate submitted by the organization during registration; this public key is used for inter-organization authentication and initial communication establishment. Certificate issuance is jointly completed by at least T existing organizations. The initiator constructs the certificate content to be signed, calculates the hash value of the certificate content using the SHA3-512 algorithm, and sends the hash value to the other T-1 organizations. Each organization uses a share of its private key stored in a hardware security module to generate a partial signature of the certificate hash value. The partial signature process maps the hash value to a short vector on a lattice, and uses the secret vector in the private key share to perform a lattice-based signature operation to generate a partial signature vector. The threshold signature protocol uses a lattice-based linear secret sharing scheme to ensure that any T partial signatures can be combined to recover the complete signature. After collecting at least T partial signatures, the initiating party uses Lagrange interpolation to weight and combine the partial signature vectors. Based on the identifiers of each institution, it calculates the corresponding interpolation coefficients, then multiplies each partial signature vector by its corresponding interpolation coefficient and sums the results to obtain the complete signature vector. This recovered complete signature vector is appended to the certificate to form the institution's identity credential. Any institution can verify the signature's validity using the consortium trust root public key. The verification process involves performing a lattice basis verification operation on the signature vector, the certificate hash, and the lattice basis matrix in the public key to check if the signature vector length is within a secure range. The resulting institution identity credential possesses quantum-resistant security and distributed trust guarantees, allowing the institution to use this credential to prove its legitimate identity to other institutions.

[0022] S14, based on the institution's identity credentials, uses a certificate chain verification mechanism to establish trust relationships between institutions, thereby obtaining cross-domain identity authentication capabilities; Each organization uses identity credentials issued by the consortium and its own private key to issue secondary certificates to internal users and subsystems. These certificates contain user identifiers, role information, affiliated organization, and validity period, forming a three-tiered certificate chain: user certificate – organization certificate – consortium root of trust. When a user from organization A accesses resources from organization B, they submit the complete certificate chain. Organization B verifies the chain upwards from the leaf nodes: first, it verifies the user certificate signature using organization A's public key; then, it verifies the threshold signature of organization A's identity credentials using the consortium root of trust's master public key. If all verifications pass, access is granted; if any level of verification fails, the request is rejected. This achieves trust transfer between organizations, eliminating the need for users to register separately with each organization.

[0023] This step outputs: the public key parameter file of the consortium trust root master (containing the lattice matrix and public parameters), the private key share data stored in the hardware security modules of each institution, the set of institution identity credentials (X.509 format certificate files), and the certificate chain verification program module.

[0024] S2 receives the alliance master public key and the institution's identity credential, constructs a hierarchical key management system, and obtains the institution's master key pair, domain key, and data key; S21, obtain the institution's identity credentials and root key of trust, and use the NIST standardized ML-KEM algorithm to generate the institution's master key pair to obtain quantum-resistant key encapsulation capability; Each institution selects the ML-KEM standard algorithm released by NIST in August 2024 to generate its master key pair. This algorithm is based on the modular fault-tolerant learning problem, and its security can be reduced to the problem of finding the shortest vector on a lattice. For financial regulatory scenarios, the ML-KEM-1024 parameter set is chosen, providing security strength equivalent to AES-256. The key generation algorithm is executed to obtain a sealing key (the public lattice basis matrix and seed parameters) and a desealing key (the secret short vector and decoding parameters). The sealing key, as the institution's master public key, is published to the key server after digital signature authentication through the consortium's root of trust and is bound to the institution's identity credentials. The desealing key, as the institution's master private key, is stored in a hardware security module conforming to the FIPS 140-3 standard.

[0025] S22, based on the institution's master key pair, uses key derivation functions to construct a three-level key hierarchy, thereby obtaining fine-grained key management capabilities; The organization divides its data into multiple security domains based on its organizational structure and data classification system, with criteria including business departments, data sensitivity levels, and geographical location. A domain key is generated for each security domain, derived from the organization's master private key using the HKDF key derivation function and the SHA3-512 hash algorithm. When generating the ML-KEM master key pair, the organization simultaneously derives a key-derived master key from a random seed generated during the key generation process. This key-derived master key is specifically used for subsequent key-level derivation and is separate from the ML-KEM decapsulation key, avoiding direct use of the encryption key for derivation operations. The derivation process first executes the HKDF-Extract stage, using the key-derived master key as input key material. The domain identifier, timestamp, and random salt are concatenated to form the salt value, and a pseudo-random key is extracted using the HMAC-SHA3-512 algorithm. Then, the HKDF-Expand stage is executed, using the extracted pseudo-random key, context information (including the domain identifier and purpose identifier), and a 256-bit output length as input, to iteratively calculate and generate a 256-bit domain key.

[0026] For a specific data object, a data key is further derived from the corresponding domain key. The derivation parameters include the domain key as input key material, the data object identifier and creation time concatenated as a salt, and a version number included in the context information. A pseudo-random key is extracted using the HMAC-SHA3-512 algorithm in the HKDF-Extract stage, and then a 256-bit output length is generated through iterative computation in the HKDF-Expand stage using the pseudo-random key, context information, and an output length of 256 bits as input. By including the data identifier and version information in the derivation parameters, different keys are ensured for different data objects and different versions.

[0027] In the resulting three-tiered key hierarchy, the organization's master private key resides at the top level and is used solely for ML-KEM decapsulation and domain key derivation. Domain keys reside in the middle layer for data key derivation, and data keys reside at the bottom level for actual encryption operations. All keys are generated using one-way derivation functions. Due to the one-way nature of HMAC and hash functions, the master key cannot be derived from the derived key, reducing the risk of master key exposure. When a data key is leaked, only a single data object is affected. When a security domain is revoked, only the domain key needs to be discarded, and a new domain key and its subordinate data keys need to be derived using a new timestamp and salt value; there is no need to replace the organization's master key.

[0028] S23, based on the cross-institutional data sharing requirements and the institution's master public key, uses the ML-KEM encapsulation algorithm to achieve secure distribution of session keys, thus obtaining quantum-resistant key exchange capability; When Institution A needs to securely transmit sensitive data to Institution B, it generates a 256-bit random session key. Institution A obtains Institution B's master public key from a consortium key server and verifies its signature. Using Institution B's master public key, it executes the ML-KEM encapsulation algorithm to encapsulate the session key, mapping the key bit string to points on a lattice. Encryption is then performed using the lattice basis matrix and random noise vector from the public key to generate ciphertext and encapsulation key material. Institution A uses the session key to encrypt the data using AES-256-GCM, packages the encapsulation key material and encrypted data, and sends it to Institution B. Institution B uses its master private key to execute the ML-KEM decapsulation algorithm to recover the session key, verifies the consistency hash value, and decrypts the data. The session key is destroyed immediately after use. This mechanism avoids the plaintext transmission of the session key; even if the network is eavesdropped on, attackers cannot break the ML-KEM encapsulation in a quantum computing environment.

[0029] S24. Based on key usage records and security policies, a hash chain-based key version management mechanism is adopted to achieve traceability of the key lifecycle. A version management record is established for each key object, including the key identifier, type, affiliated organization, security domain, generation time, and current status (active, pending update, revoked, archived). A hash chain structure is constructed, with the initial node containing the key generation event and a seed hash value calculated using the SHA3-256 algorithm. Each key usage, update, or status change adds a new node to the hash chain, containing the operation type, time, subject, associated data object, and the hash value of the previous node, forming an immutable operation history. When a key reaches its usage period or limit, it automatically changes to a pending update state, triggering the update process. When a key leak is detected, a revocation operation is performed. Revoked keys cannot be used for new encryption but are retained for decrypting historical data. By traversing the hash chain, the entire lifecycle of the key can be traced, verifying operational compliance.

[0030] This step outputs: ML-KEM master key pair files for each organization (containing encapsulation and decapsulation keys), a key derivation relationship configuration table (recording the derivation parameters from the organization's master key to the domain key to the data key), the domain key and data key of each security domain and data object, and a key version management hash chain database (recording the generation, use, update, and revocation history of each key).

[0031] S3 receives the domain key and data key, and uses encryption and erasure coding methods to obtain hierarchical encrypted data files and attribute encrypted ciphertexts; S31, obtain the data to be stored and its security attributes, use an intelligent data classification model to determine the encryption strength, and obtain an adaptive differentiated encryption strategy; An intelligent data classification system is constructed, employing multimodal feature extraction and classification models to automatically identify data sensitivity. This classification system, as an independent component of the platform, was trained and validated using historical financial regulatory data before platform deployment; its model parameters are fixed and can be directly used for classification inference on new data. Structured features (field type, name, numerical range), content features (text semantics, sensitive word frequency), and contextual features (source institution, business scenario) are extracted from the data to be stored. A pre-trained BERT model is used to semantically encode text fields. After text segmentation, the text is input into the BERT encoder, and semantic features are extracted through a 12-layer Transformer structure. The output of the last layer's CLS marker is used as the text representation, converted into a 768-dimensional vector. Statistical features, including mean, variance, maximum, minimum, and quantiles, are extracted from numerical fields to form a 5-dimensional statistical vector. For relational data, a graph neural network (GNN) is used to extract graph structure features, constructing the data table as a graph structure. Nodes represent fields, and edges represent foreign key relationships. A 3-layer graph convolutional network aggregates neighbor node information to generate node embedding vectors.

[0032] Multimodal features are input into a hierarchical attention neural network for sensitivity classification. The network includes a feature fusion layer (which concatenates a 768-dimensional text vector, a 5-dimensional statistical vector, and a 128-dimensional graph embedding vector, then maps them to a 512-dimensional fused feature through a fully connected layer), an attention layer (which calculates the attention weights of each modality feature, with the weights equal to the softmax (fully connected layer (fused feature)), and weighted fusion to obtain a 256-dimensional attention feature), and a classification layer (using two fully connected layers and a softmax activation function). The network outputs a probability distribution for five sensitivity levels. The model is trained using supervised learning with approximately 100,000 samples, employing a cross-entropy loss function and the Adam optimizer (learning rate 0.001, batch size 32). After 50 epochs of training, it achieves an accuracy of over 92% on the validation set.

[0033] Sensitivity prediction is performed on new data. The data is input into a classification model to obtain a probability distribution of five levels. The level with the highest probability is selected as the prediction result, and the confidence level is defined as the highest probability value. Data with a confidence level below 0.8 is marked as requiring manual review. Based on the predicted sensitivity level and the security domain to which the data belongs, the corresponding domain key identifier is retrieved from the key derivation configuration table output from step S2. The domain key is retrieved from the key management system, and the data key for the data object is derived using the HKDF scheme. The derivation parameters include the domain key as input key material, the unique identifier of the data object and the creation time concatenated as salt, and the version number included in the context information. Encryption algorithms are selected based on sensitivity levels: Level 5 highly sensitive data uses the BGV fully homomorphic encryption scheme (128-bit security strength, supporting 10 to 20 levels of multiplication depth) and directly encrypts the data using a fully homomorphic encryption public key. Level 3-4 medium sensitive data uses a derived data key for AES-256-GCM encryption (256-bit key length, randomly generated 96-bit initialization vector IV, and generated 128-bit authentication tag). Level 1-2 low sensitive data also uses a derived data key for AES-256-GCM encryption. After encryption, the data key identifier, domain key identifier, encryption algorithm type, initialization vector IV, and authentication tag are recorded in the data object metadata, facilitating subsequent decryption by retrieving the corresponding key from the key management system in step S2 and verifying data integrity. The system incrementally updates the classification model monthly, fine-tuning model parameters using newly labeled data. For data with increased sensitivity, an encryption strength upgrade process is automatically triggered, re-encrypting the data using a higher-level encryption algorithm. The model is deployed on a GPU server, with a single classification inference time of approximately 30 milliseconds.

[0034] S32, based on encrypted data and distributed storage requirements, uses Reed-Solomon erasure coding technology to fragment data and obtain a redundant storage scheme; Encrypted data is fragmented and stored across multiple physical locations to prevent single points of leakage and failure. Fragmentation parameters M (number of data blocks) and K (number of verification blocks) are set; for critical regulatory data, M equals 6 and K equals 3, resulting in a total of 9 storage blocks. Any 6 blocks can be used to recover the complete data. The encrypted data is divided into M data blocks of a fixed size. The Reed-Solomon erasure coding algorithm is used to encode the M data blocks to generate K verification blocks. The encoding process constructs a generation matrix, with the first M rows representing the identity matrix corresponding to the data blocks and the last K rows representing the Vandermonde matrix corresponding to the verification blocks. The M plus K storage blocks are distributed across data centers of different cloud service providers, with metadata (data object identifier, block number, block type, storage location, and integrity hash value) appended to each block. When reading data, the storage block location is queried from the metadata service, and at least M storage blocks are downloaded in parallel. The erasure coding decoding algorithm is then used to recover the complete encrypted data, and decryption is performed after verifying the integrity hash value. This scheme achieves high availability, and data can still be recovered even if K storage nodes fail. An attacker must compromise at least M nodes in different locations to obtain the complete encrypted data.

[0035] S33, based on the data access control requirements, a lattice-based ciphertext policy attribute encryption is adopted to embed the access policy in the encryption layer to obtain the attribute-encrypted ciphertext with the embedded access policy. Access policies are embedded during the data encryption phase, defining the attribute conditions required for data decryption. Access policies are represented using Boolean expressions, supporting AND, OR, and NOT logical combinations. A lattice-based ciphertext policy attribute encryption scheme based on the learning error problem is selected, encoding the access policy into the ciphertext structure. When the data owner encrypts data, they define access control policies, such as "institution equals institution A and role equals regulator" or "institution equals institution B and role equals senior analyst and data purpose equals risk assessment." The access policy expression is converted into an access tree structure, where leaf nodes correspond to single attribute conditions (e.g., institution equals institution A), and internal nodes correspond to logic gates (AND gate, OR gate, threshold gate).

[0036] Data is encrypted using publicly available system parameters and the access tree structure, generating a 256-bit random symmetric key K for encrypting the data content. A secret value is assigned to each node in the access tree, with the root node's secret value set to the random symmetric key K. For internal nodes, child node secret values ​​are assigned based on the logic gate type: AND gates copy the parent node's secret value to all child nodes, while OR gates use secret sharing to divide the parent node's secret value into the sum of the child node secret values. A ciphertext component is generated for each leaf node in the access tree. The leaf node's secret value is cipher-based encrypted using publicly available parameters (lattice base matrix and noise parameters) associated with the leaf node's attributes. The ciphertext component equals the lattice base matrix multiplied by the secret vector plus the noise vector, where the secret vector encodes the leaf node's secret value. The root node's ciphertext component encrypts the data using the symmetric key K and performs lattice base encryption using the system's main publicly available parameters. The data content is encrypted using the symmetric key K and the AES-256-GCM algorithm, generating encrypted data and an authentication tag. The generated attribute-encrypted ciphertext contains the encrypted data content, the authentication tag, an access tree structure description (node ​​type, logic gates, attribute conditions), and a set of ciphertext components corresponding to each node in the access tree. This mechanism implements fine-grained authorization at the encryption level. Access policies are inseparable from data; even if an attacker gains storage access, they cannot bypass the access policy to decrypt the data. Decryption requires an attribute key that satisfies the policy. The resulting attribute-encrypted ciphertext will then be used as the decryption target for the S4 step of access control.

[0037] S34, based on the retrieval needs of encrypted data, a searchable encrypted system is built using secure indexing technology to obtain data query capabilities that protect privacy; To support efficient retrieval of massive amounts of encrypted data, a searchable encrypted index is constructed. When the data owner encrypts the data, key fields (such as transaction number, customer name, and transaction date) are extracted as index keywords. For each keyword, a secure index trapdoor is generated using a search key derived from the domain key in step S2. The derivation process of the search key uses the HKDF scheme, with the domain key as the input key material, the string search key as the salt value, and the string searchable encrypted index as the context information. A pseudo-random key is extracted using the HMAC-SHA3-512 algorithm in the HKDF-Extract stage, and then a 256-bit output length is derived through iterative calculation in the HKDF-Expand stage using the pseudo-random key, context information, and an output length of 256 bits. A trapdoor value is generated using the search key and keywords, and the trapdoor value is obtained by hashing the search key and keywords using the HMAC-SHA3-512 algorithm. The trapdoor value is one-way; keywords cannot be deduced from the trapdoor value. The trapdoor value and encrypted data identifier are stored in an inverted index structure. The inverted index maintains the mapping relationship from the trapdoor value to the list of data identifiers, and a hash table or B-tree structure is used to achieve efficient lookup.

[0038] When a user queries data, the corresponding domain key is retrieved from the key management system in step S2. A search key is derived using the same HKDF scheme. The search key and query keywords are used to calculate the query trapdoor value using the HMAC-SHA3-512 algorithm, and the query trapdoor is sent to the cloud storage server. The server searches for a matching trapdoor value in the inverted index and returns a list of corresponding encrypted data identifiers. The user downloads the encrypted data based on the identifiers. The data key identifier, domain key identifier, encryption algorithm type, and initialization vector IV are obtained from the data object metadata. The corresponding domain key is retrieved from the key management system in step S2. The data key is re-derived using the HKDF scheme (derived parameters include the domain key as input key material, the data object identifier and creation time concatenated as salt, and the version number included in the context information). The derived data key and initialization vector IV are used to decrypt the data using AES-256-GCM, and the authentication tag is verified to confirm data integrity. Throughout the entire query process, the server only accesses the trapdoor value and the encrypted data, without disclosing the query keywords or data content to the server. The search key is changed periodically (quarterly or annually), and the index trapdoors are regenerated and the inverted index is updated using the new search key to prevent the server from inferring query patterns through long-term observation. Multi-keyword combination queries are supported. A trapdoor value is generated for each query keyword, and multiple trapdoor values ​​are inserted into a Bloom filter (a bit array of size 10,000 and 7 hash functions). The Bloom filter is then sent to the server, which tests the Bloom filter on the keyword trapdoor set for each data object and returns a list of potentially matching data identifiers, achieving efficient multi-condition matching.

[0039] This step outputs: data files encrypted according to sensitivity levels (including highly sensitive data encrypted with BGV fully homomorphic encryption, and medium-to-low sensitive data encrypted with AES-256-GCM; each data object's metadata records the data key identifier, domain key identifier, and encryption algorithm type), M plus K data block files in distributed storage and their metadata index table, attribute-encrypted ciphertext data with embedded access policies (including access tree structure and ciphertext component set), a searchable encrypted inverted index database (storing the mapping from trapdoor values ​​to data identifiers), data classification model files, and a classification rule configuration library.

[0040] S4 receives the attribute encrypted ciphertext and the organization's identity credential, and uses a multi-authority attribute encryption and delegation authorization protocol method to obtain the user attribute key component, attribute revocation tree and delegation authorization token; This step establishes an access control mechanism that supports complex authorization policies, issues attribute keys to users to decrypt the attribute encryption ciphertext generated in step S3, and enables cross-organizational permission collaboration.

[0041] S41, obtain the organization's organizational structure and user role information, establish a distributed attribute management system using a multi-authoritative attribute encryption scheme, and obtain cross-domain attribute keys; In a multi-organizational environment, each organization acts as an independent attribute authority, maintaining its own attribute authority master key and public parameters. Attributes are divided into global attributes (consortium member identifier, data access level) and organizational attributes (department role, scope of responsibility). During user registration, organizations assign attribute sets (user identifier, affiliated organization, department name, role type, permission level, validity period) based on position and responsibilities, and generate attribute key components (lattice-based secret vectors) for each attribute using the master key. Users collect all attribute key components to form a complete attribute key. When a user needs to access data from other organizations and the access policy requires cross-organizational attribute combinations, they apply for additional attribute keys from the organization where the data resides. After verifying the user's identity credentials and the reason for the access application, the organization where the data resides decides whether to issue attribute key components based on the inter-organizational data sharing agreement. Users integrate attribute key components from different organizations to form a cross-domain attribute key. This system achieves decentralized attribute authority, allowing each organization to maintain autonomous management of its own attributes while supporting cross-domain attribute combinations.

[0042] S42, based on the attribute encryption ciphertext and user attribute key generated in step S3, use the attribute key to decrypt the access tree to realize access control verification, and obtain the attribute key decryption capability; When a user attempts to access the attribute-encrypted ciphertext data generated in step S3, decryption is required using the attribute key obtained from step S41. Specifically, when a user requests access to an encrypted data object stored in a distributed storage system, the system returns attribute-encrypted ciphertext with an embedded access policy generated in sub-step S33 of step S3. The user's decryption key is issued by an attribute authority and bound to the user's attribute set. When decrypting data, the user extracts the access tree structure and the set of ciphertext components from the ciphertext. Decryption operations are performed on the ciphertext access tree using the attribute key. The decryption algorithm recursively traverses the access tree, starting from the leaf nodes. If the user possesses the attribute required by the leaf node, the corresponding attribute key component is used to decrypt the ciphertext component of that node, yielding a partial decryption result. For internal nodes, the decryption results of child nodes are combined according to the logic gate type: AND gates require all child nodes to decrypt successfully, OR gates require at least one child node to decrypt successfully, and threshold gates require at least a threshold number of child nodes to decrypt successfully. If the user's attributes meet the access tree's policy requirements, the decryption algorithm can recursively reach the root node and successfully decrypt the root node's ciphertext component to recover the data encryption key, thereby decrypting the data content. If user attributes do not meet the access policy, the decryption operation cannot be completed, and only a meaningless random value is obtained. This decryption process implements fine-grained access control verification based on attributes; only users with attribute keys that meet the policy can successfully decrypt data.

[0043] S43, based on the dynamic adjustment requirements of access policies, adopts the attribute revocation tree mechanism to achieve efficient updating of user permissions, thus obtaining dynamic permission management capabilities; A hierarchical attribute revocation tree is constructed to manage attribute key versions and revocation. The revocation tree is a binary tree structure, where leaf nodes correspond to individual user attribute instances, and internal nodes correspond to attribute group key versions. During initialization, a leaf node containing the user identifier and initial attribute key version is assigned to each user. When a specific attribute of a user is revoked, the key version number of the corresponding leaf node in the revocation tree is updated, generating a new version attribute key. The tree then traverses upwards from that leaf node to the root node to update the key versions of all internal nodes along the path. The attribute authority sends a key update message to all users whose attributes have not been revoked, containing the new version attribute key component and the update path. Users whose attributes have not been revoked update their local attribute keys upon receiving the update message. Users whose attributes have been revoked, having not received the update message, have local attribute key versions that do not match the current version in the revocation tree and cannot decrypt data encrypted with the new version key. The hierarchical structure of the revocation tree ensures that the key update communication overhead is logarithmically related to the tree height. For a system with N users, the height of the binary revocation tree is logarithm N, and the number of key update messages for a single revocation operation is approximately logarithm N. Batch revocation operations are supported by calculating the minimum covering subtree of the revoked user and updating only the keys of users outside the covering subtree.

[0044] S44, based on the needs of temporary access and emergency response, adopts a delegated authorization protocol based on grid signature to realize flexible transfer of permissions and obtain temporary authorization capability; To support temporary access requests in cross-institutional collaboration, a delegation authorization mechanism is employed. The delegation authorization is initiated by the data-owning institution, which generates a delegation token. The token uses a structured format, including the delegated user's identifier, the authorized data scope, the authorized operation type, the validity period, usage limits, and the initiating institution's digital signature. The initiating institution uses a lattice-based ML-DSA digital signature algorithm to sign the token content, ensuring quantum-resistant security. When a delegated user accesses data, they submit an access request to the data storage system, including their identity credentials, attribute key, and delegation token. The data storage system verifies the digital signature, validity period, usage limits, and user identity consistency of the delegation token. Upon successful verification, the system combines the user's attribute key and the delegation token authorization information to generate a temporary enhanced decryption key. The user uses the enhanced key to decrypt data within the authorized scope; the decryption process simultaneously verifies the data access policy and the delegation token's authorization scope. After data access is completed, the system records token usage and updates the usage count. When the token reaches its usage limit or its validity period expires, the token automatically becomes invalid and is added to the revocation list. A proactive revocation mechanism is supported; the initiating institution can proactively revoke the token within its validity period, and the revocation information is broadcast to all data storage nodes via a real-time notification system.

[0045] This step outputs: the authoritative master key and public parameter file for each institution's attributes, a set of user attribute key components (stored on the user's client and used to decrypt the encrypted attribute ciphertext generated in step S3), an attribute revocation tree data structure and its version update records, and a delegation authorization token database (recording token content, validity period, number of uses, and revocation status).

[0046] S5 receives the receiving organization's master key pair, delegation authorization token, and hierarchical encrypted data file. It uses a lattice-based key exchange protocol and a secure multi-party computation method to establish a quantum-resistant secure channel and privacy computation capabilities, and obtains the session key, network-coded data packets, secret share data, and fully homomorphic ciphertext computation results. S51: Obtain inter-institutional communication requirements and network topology, establish session keys using a key exchange protocol based on the model learning error problem, and obtain a quantum-resistant secure channel; When Institution A needs to establish real-time secure communication with Institution B, both parties execute a key exchange protocol. The protocol employs a non-interactive key exchange scheme based on the modular learning error problem, combined with an ML-KEM key encapsulation mechanism. Institution A generates a temporary key pair (its lifespan is limited to a single session) and sends the temporary public key to Institution B through an established secure channel. The secure channel uses the identity credentials of both institutions for authentication. Institution B generates its own temporary key pair, uses Institution A's temporary public key to execute the ML-KEM encapsulation algorithm to generate a shared key and encapsulated ciphertext, and sends the temporary public key and encapsulated ciphertext to Institution A. Institution A uses its temporary private key to execute the ML-KEM decapsulation algorithm on the encapsulated ciphertext to recover the shared key. Both parties independently compute the same 256-bit shared key. A session key is derived from the shared key using HKDF, with derivation parameters including the identifiers of both institutions and the session identifier, ensuring that different sessions use different session keys. After the session key is derived, the shared key is immediately and securely erased from memory.

[0047] After establishing a session key, in scenarios involving temporary cross-organizational authorized access, users of Organization B need to submit a delegation authorization token obtained from step S4 for identity and permission verification. The data transmission system retrieves token information from the delegation authorization token database in step S4, verifying the token's validity period, usage limit, and authorized data scope. Upon successful verification, the system records token usage and updates the usage count, allowing users to access data within the authorized scope using the established session key. If the token has expired, exceeded the usage limit, or been revoked, the system rejects the access request and records an audit log. This mechanism ensures fine-grained authorization control and traceability for cross-organizational data transmission.

[0048] Both parties use a session key and the AES-256-GCM algorithm to encrypt and authenticate subsequent communication data. Each message includes encrypted content, an authentication tag, and a message sequence number to prevent replay attacks. The session key is updated periodically (hourly or after every 1GB of data transmitted), and the key exchange protocol is re-executed upon update. All temporary key materials and the session key are deleted after the session ends. This secure channel possesses forward security and quantum-resistant security.

[0049] S52, based on the requirements of secure channels and data transmission reliability, adopts random linear network coding technology to enhance transmission robustness and obtain anti-eavesdropping and anti-tampering capabilities; For large-scale data transmission across borders, network coding technology is employed to enhance transmission security and reliability. The data sender divides the data to be transmitted into fixed-size data packets (1KB to 10KB), organizing each packet into a data group containing M original data packets. Random linear network coding is applied to the data group, randomly generating a coding coefficient matrix (matrix elements are randomly selected from a finite field). The M original data packets are then linearly combined to generate coded data packets, each containing the linearly combined data content and corresponding coding coefficient vectors. N coded data packets are generated (N > M, with redundancy N - M). The coding coefficient matrix is ​​transmitted encrypted through a secure channel. The coded data packets are transmitted in parallel via multiple network paths. Even if some transmission paths are eavesdropped on, the eavesdropper only obtains a portion of the coded data packets and cannot recover the original data without knowing the coding coefficients. The receiver can recover the original data after collecting at least M linearly independent coded data packets. The receiver verifies the integrity of the coded data packets, constructs a decoding matrix (composed of the M received coding coefficient vectors), calculates the inverse of the decoding matrix, and uses the inverse matrix to linearly combine the coded data packets to recover the M original data packets. The integrity of the recovered data is confirmed by verifying the hash value. If some encoded data packets are tampered with, manifested as a mismatch between the encoded coefficient vector and the data content, or a failed hash verification after decoding, the receiver discards the tampered data packets and continues to receive other data packets. This scheme provides information-theoretic security and fault tolerance.

[0050] S53, based on the needs of multi-agency collaborative computing and data privacy protection, adopts a lattice-based secret sharing scheme to achieve secure multi-party computing and obtain privacy-preserving joint analysis capabilities; When multiple organizations need to conduct joint statistical analysis on their respective sensitive data, a secure multi-party computation protocol is adopted to protect the data privacy of all parties. The protocol participants include N data providers and one computation coordinator. Each data provider preprocesses its local data, extracting the data fields and features to be used in the computation. An additive secret sharing scheme is used to share the data, dividing each data value into N secret shares. All shares are added together to equal the original data value. The first N minus one shares are randomly selected, and the last share is calculated by subtracting the sum of all previous shares from the original value. A lattice-based encryption scheme based on the learning error problem is used to encrypt the secret shares. Each organization encrypts its generated secret share and sends it to other organizations to form a share exchange. Each organization decrypts the received secret shares to obtain the plaintext share and stores the corresponding secret shares for all organizations locally. The computation process operates on the secret shares. Addition operations directly add the shares of each party. Multiplication operations use Beaver triplet technology. Participants pre-generate random multiplication triplet shares, and during online computation, triplet masks the input values, completing the share multiplication in one round of communication. For complex statistical analysis tasks such as mean calculation and analysis of variance, the calculation is decomposed into a combination of addition and multiplication. Each institution performs the corresponding operation on the secret share locally to obtain the secret share of the calculation result. After the calculation is completed, each institution sends the result share to the result recipient, and the recipient sums the received result shares to restore the final calculation result. Throughout the entire calculation process, the original data of each institution does not leave its local machine; only the encrypted secret share and the intermediate calculation result share are exchanged.

[0051] S54, based on the needs of cloud data processing and privacy computing, adopts a lattice-based fully homomorphic encryption scheme to support data computing in ciphertext state, thus achieving the security of outsourced computing; For highly sensitive data requiring complex analysis in the cloud but where plaintext cannot be exposed, fully homomorphic encryption is employed. The data owner selects the BGV fully homomorphic encryption scheme based on the ring learning error problem, generating public and private keys. The public key is used to encrypt local data; the encryption process encodes the data into a polynomial, which is then encrypted using a lattice basis to generate ciphertext. Batch processing is used to package multiple data items into a single ciphertext, leveraging SIMD parallel processing to improve efficiency. The encrypted data is uploaded to a cloud computing server, along with a predefined computation task description (specifying the algorithms and operational procedures to be executed). The cloud server performs computational operations on the ciphertext; the fully homomorphic encryption scheme supports addition and multiplication operations. Addition operations perform polynomial addition on the ciphertext components, while multiplication operations perform polynomial multiplication and perform relinearization to reduce ciphertext noise growth. For complex nonlinear operations such as activation functions, a polynomial approximation method is used, replacing the nonlinear function with a low-order polynomial expansion to control the computational depth. The cloud server executes the ciphertext operations step-by-step according to the computation task description, storing the results as new ciphertext. To control the accumulation of noise in the ciphertext, the multiplication depth is limited in the computation task design. Typical BGV schemes support 10 to 20 multiplication depths, suitable for medium-complexity computation tasks. After the computation is completed, the cloud server returns the ciphertext result to the data owner, who uses their private key to decrypt the ciphertext result to obtain the plaintext computation result. Throughout the entire computation process, the cloud server only interacts with the encrypted data and has no knowledge of the data content or the computation result.

[0052] This step outputs: the inter-agency session key negotiation module and session key cache, the network coding coefficient matrix and coded data packets, the secret share data for secure multi-party computation and the Beaver triple pre-computation library, and the ciphertext computation result data for fully homomorphic encryption.

[0053] S6. Based on all operational events generated during the process, an audit traceability system is constructed using quantum-resistant hash chains and Merkle tree methods to obtain an audit log hash chain, a Merkle tree index, a threat detection rule base, and a compliance report. S61: Obtain operation events from each module of the system, capture security-related activities using a structured log recording mechanism, and obtain complete audit data; An audit agent module is deployed at key nodes of the platform. The audit agent runs in an independent secure container, possessing its own execution environment and storage space. The modules monitored by the audit agent include: identity authentication (user login and organization authentication events), key management (key generation, distribution, update, and revocation events), data access (data read, write, and delete events), computation execution (secure multi-party computation and fully homomorphic encrypted computation events), policy management (access policy change and permission adjustment events), attribute management (extracting user attribute key issuance, update, and revocation events from the attribute revocation tree of the S4 steps, as well as the generation, use, and revocation of delegated authorization tokens), and system configuration (security parameter modification and algorithm upgrade events). The audit agent intercepts key operations of these modules through hook functions or aspect-oriented programming techniques, recording audit logs before and after each operation. Each audit log entry uses a structured format, including a timestamp (NTP synchronized trusted clock), the operation subject (user identifier or organization identifier), operation type (login, encryption, decryption, signature, verification, query, attribute key issuance, attribute revocation, token generation, token usage, etc.), operation object (data object ID, key ID, policy ID, attribute identifier or token ID), operation parameters (encryption algorithm type, key length, attribute type, token validity period, etc.), operation result (success or error code), and context information (client IP address, geographical location, and session identifier). Log recording uses an asynchronous write mechanism; the audit agent temporarily stores logs in a memory buffer, and a background thread writes them in batches to persistent storage. Log storage uses an append-only write mode and does not support modification or deletion operations.

[0054] S62, based on audit log records, uses the SHA3 hash function to construct a hash chain storage structure to achieve log integrity protection; Audit logs are organized chronologically into a hash chain data structure. Each node contains the log content and a hash pointer to its predecessor node. A genesis node is created during hash chain initialization, containing the system initialization time, deployment environment information, and a random seed value. When a new log is added, the hash value of the predecessor node is calculated (using the SHA3-512 algorithm). The new log content is then concatenated with the predecessor hash value, and a SHA3-512 hash operation is performed to obtain the new node's hash value. SHA3-512 is based on the Keccak sponge function, providing stronger resistance to quantum attacks. Each new node contains the log content, the predecessor hash value, and the new node's hash value, forming a chain structure. The current head hash value represents a summary of the entire chain; any modification to the content of a historical node will cause changes to the hash values ​​of all subsequent nodes. The hash value of the hash chain head is periodically published to an external trusted storage (distributed ledger, timestamp server, or public blockchain network) as a public commitment to prove the audit log status at a specific point in time. When verifying log integrity, the hash value of each node is recalculated sequentially starting from the genesis node and compared with the stored hash values. The calculated current header hash value is then compared with the previously published public commitment. This hash chain storage structure provides strong integrity guarantees for audit logs. Based on the collision resistance and one-wayness of SHA3, attackers cannot forge or modify historical logs without being detected.

[0055] S63, based on the need for efficient querying of audit logs, uses Merkle tree technology to build a verifiable log index, thereby obtaining the selective verification capability of logs; To support efficient querying and verification of massive audit logs, a log index structure based on a Merkle tree is constructed. Audit logs within a certain time period are treated as a log batch (typically 1 hour or 10,000 logs). Log records within a batch are treated as leaf nodes of the Merkle tree, with the leaf node value being the SHA3-256 hash of the log content. Internal nodes of the Merkle tree are constructed, with the internal node value being the combined hash of its two child node values ​​(the hash values ​​of the left and right child nodes are concatenated in order and then subjected to a SHA3-256 hash operation). Internal nodes are constructed layer by layer upwards from the leaf node level until a unique root node is built. The root node hash value is called the Merkle root, representing the summary of the entire batch of logs. The Merkle root is published to a publicly trusted storage platform, recording the batch start and end times and the number of logs. When proof of a specific log record is required to be provided to regulatory agencies or third-party auditors, the log and its verification path in the Merkle tree (including the hash values ​​of all sibling nodes along the path from the log leaf node to the Merkle root) are extracted. The verification path length is the tree height. For a batch containing N log entries, the tree height is logarithmic N, and the verification path contains logarithmic N hash values. The log content, verification path, and Merkle root are provided to the verifier. The verifier calculates the hash value of the log content, and then uses the hash values ​​of sibling nodes in the verification path to calculate the hash value of the parent nodes layer by layer until the root node hash value is calculated. The calculated root hash value is compared with the publicly released Merkle root. If they match, it proves that the log does indeed belong to the batch and has not been tampered with. This Merkle tree index structure enables efficient selective log verification, proving the authenticity of a specific log without providing the full log, and the verification computation complexity is logarithmic.

[0056] S64, based on security policies and regulatory requirements, uses a rule engine combined with behavioral baseline analysis to achieve compliance monitoring, thereby obtaining threat detection and response capabilities; Build a threat detection system based on a rule engine and behavioral baseline analysis to automatically identify violations and abnormal behavior patterns through predefined compliance rules and statistical analysis methods. Establish a compliance rule library containing explicit compliance requirements extracted from laws, regulations, and industry standards. Rule types include access control rules (account lockout triggered by 5 consecutive decryption failures by the same user, alarm triggered by accessing sensitive data outside of working hours), key management rules (alarm triggered by keys not being updated for more than 90 days, rotation triggered by keys exceeding the usage threshold), attribute management rules (alarm triggered by attempting to access data after a user attribute has been revoked from the attribute revocation tree in step S4, blocking triggered by expired or overused delegated authorization tokens, re-authentication triggered by user attribute key version mismatch with the current system version), data protection rules (blocking triggered by unencrypted transmission of sensitive data, prohibition of transmission triggered by the destination geographic location not in the authorization list), and operation audit rules (alarm triggered by failure to record audit logs for critical operations, security event triggered by failed audit log integrity verification).

[0057] The rules engine employs an event-driven architecture to monitor the audit log stream in real time. When a new audit log arrives, the rules engine extracts key fields from the log and matches them against rule conditions in the rule base. Rule conditions are described using logical expressions, supporting comparison operations such as equal to, not equal to, greater than, less than, contain, and regular expression matching, as well as AND, OR, and NOT logical combinations. When the log content meets the rule conditions, the rule-defined response action is triggered (generating an alarm message, sending a notification to the security administrator, temporarily locking the user account, blocking data transmission, initiating a forensic investigation process, etc.).

[0058] A user behavior baseline analysis mechanism is established. The system collects historical user operation logs and statistically analyzes normal behavioral characteristics (login time distribution, operation frequency, access data range, and operation type distribution). A behavioral baseline model is built for each user, recording the mean and standard deviation of each behavioral characteristic. During real-time monitoring, the user's current behavioral characteristics are compared with the historical baseline to calculate the degree of deviation, using the standard deviation multiple as the anomaly metric. When a behavioral characteristic deviates by more than 3 times the standard deviation, it is marked as abnormal behavior. The system calculates a comprehensive anomaly score by combining multiple abnormal behavioral characteristics. A weighted summation method is used, multiplying the anomaly metric of each behavioral characteristic by its corresponding weight and summing them to obtain the comprehensive score. The anomaly metric is defined as the multiple of the behavioral characteristic's deviation from the standard deviation. The weights are allocated according to the security importance of the characteristic: login time anomaly weight 0.2, operation frequency anomaly weight 0.3, access range anomaly weight 0.3, and operation type anomaly weight 0.2. When the comprehensive anomaly score exceeds a preset threshold (usually set between 0.7 and 0.9), a high-priority security event is generated and notified to the security administrator for manual review. The system automatically updates user behavior baselines weekly, using a sliding window mechanism to recalculate behavioral characteristic statistics based on the most recent 30 days of operation logs. When a significant change in a user's role or permissions is detected, the user's behavior baseline is immediately reset, and a new baseline model is built using the updated operation logs. The baseline update process employs a smooth transition mechanism, with the old and new baselines running in parallel for 7 days. During this period, anomaly detection references both baselines simultaneously to avoid false alarms caused by baseline switching. The threat detection system has a response time of approximately 100 milliseconds, and the rule base can be flexibly updated according to new regulatory requirements and security events. The behavior baseline automatically adjusts as user behavior evolves.

[0059] S65, based on the regulatory requirements of different countries, uses a compliance mapping framework to generate customized compliance reports, thereby obtaining cross-border compliance verification capabilities; Establish a regulatory knowledge base to structurally store the clauses and compliance points of major data protection regulations, including the EU GDPR (data subject rights, legal basis, restrictions on cross-border transfers, and data breach notification), the US HIPAA (healthcare data access control, encryption protection, and audit logs), and China's Personal Information Protection Law and Data Security Law (the principles of legality, legitimacy, and necessity in personal information processing, data classification and tiered protection, and cross-border data security assessment). Each regulatory clause is mapped to specific security control measures and audit data fields on the platform. Establish a compliance mapping framework that automatically selects applicable regulatory standards based on the organization's country of origin, the nature of data processing activities, and the nationality of the data subject. Extract compliance evidence (user consent records, data processing purpose statements, data retention period settings, access permission configurations, encryption algorithm usage, cross-border transfer security assessment reports, etc.) from audit logs and system configurations. Match the extracted evidence with the regulatory clauses, determining the compliance status of each clause as compliant, partially compliant, or non-compliant. For compliant clauses, record supporting evidence citations; for non-compliant clauses, identify gaps and generate risk assessments and improvement suggestions. Generate structured compliance reports, including an execution summary (overviewing the overall compliance status and key findings), regulatory compliance (listing assessment results and evidence citations for each regulatory provision), risk identification (describing the potential legal risks and business impacts of non-compliance), and improvement recommendations (providing specific corrective actions and prioritization). The reports support multiple output formats (PDF documents, HTML web pages, and structured JSON data), and the report generation process is configurable, supporting both scheduled automatic generation (quarterly compliance reports) and on-demand generation (special reports for regulatory inspections).

[0060] This step outputs: a structured audit log database (containing operation records for all steps from S1 to S5, including fields such as timestamp, operation subject, operation type, and operation object), a hash chain storage file (containing genesis node, log node, and header hash value), a Merkle tree index database (containing the Merkle root and verification path of batch logs), a compliance rule configuration file and a user behavior baseline statistics database, and customized compliance report documents (PDF, HTML, and JSON formats). These specific deliverables provide complete support for the platform's transparent operation and regulatory compliance, enabling full-process traceability of all preceding steps.

[0061] In one embodiment of the present invention, a complete application example is given below to verify the effectiveness and feasibility of the method of the present invention.

[0062] Financial regulatory agencies from three different countries have formed a cross-border financial regulatory alliance to jointly oversee cross-border payments and securities trading activities across their three jurisdictions. Each agency manages transaction data reported by its own national financial institutions and must collaborate to identify suspicious cross-border money laundering activities and systemic financial risks while protecting their respective data sovereignty.

[0063] Three institutions used the method of this invention to construct a cross-border financial data security management platform. A consortium trust root was established, with a threshold parameter set to 2, meaning any two institutions can jointly perform signature operations. A lattice-based threshold signature scheme was used to generate the consortium trust root master key, with the private key divided into three parts, each held by one of the three institutions. An identity credential was issued to each institution, generated by joint signatures from at least two institutions. Each institution generated an ML-KEM-1024-level institutional master key pair, and the public key was publicly released after being signed by the consortium trust root.

[0064] A regulatory agency input transaction data reported by domestic financial institutions into a data classification system for sensitivity assessment. The system uses an intelligent data classification model to automatically identify data sensitivity, classifying 100,000 transaction records in just 0.5 seconds. Customer ID numbers and account information were identified as Level 5 highly sensitive data by the classification model and encrypted using the BGV fully homomorphic encryption scheme. Transaction amounts and counterparties were identified as Level 4 medium sensitive data and encrypted using AES-256-GCM using a data key derived from the domain key. Transaction time and transaction type were identified as Level 2 low sensitive data and also encrypted using AES-256-GCM using a data key derived from the domain key. The classification model, through multimodal feature extraction and deep learning analysis, achieved an accuracy rate of over 92%.

[0065] The encrypted data is fragmented, with parameters M equal to 6 and K equal to 3. The data is divided into 6 data blocks and 3 check blocks are generated, resulting in a total of 9 storage blocks distributed across data centers of different cloud service providers. Complete data can be recovered from any 6 storage blocks, even if 3 storage blocks are lost or damaged.

[0066] Table 1 shows an example of how a batch of transaction data is stored: Table 1. Example of transaction data storage block distribution

[0067] Access policies for highly sensitive customer identity data are set as follows: the institution must be equal to institution A, the role must be equal to an anti-money laundering investigator, and the data purpose must be equal to a case investigation. The access policy is encrypted using a ciphertext policy attribute, embedding the access policy into the encrypted data. Analysts from other institutions, who do not meet the condition of "institution equal to institution A," are unable to decrypt the data.

[0068] When joint analysis of cross-border fund flows is required, Institution A issues a temporary authorization token to a senior analyst at Institution B. The token authorizes access to anonymized transaction amounts and counterparty data, valid for 24 hours and limited to 50 uses. Institution B's analyst uses the authorization token and their own attribute key to decrypt the data within the authorized scope.

[0069] Institution A needs to transmit data related to a specific transaction to Institution C. Both parties establish a session key using the ML-KEM key exchange protocol. Institution A generates a temporary key pair and sends the temporary public key to Institution C. Institution C generates its own temporary key pair, uses Institution A's temporary public key to execute the ML-KEM encapsulation algorithm to generate a shared key and encapsulated ciphertext, and sends the temporary public key and encapsulated ciphertext to Institution A. Both parties independently calculate the same shared key and derive the session key using HKDF. The transmission process employs random linear network coding, dividing the data into 10 original data packets, generating 13 encoded data packets, which are transmitted in parallel through 3 different network paths. Institution C recovers the complete data after collecting at least 10 linearly independent encoded data packets.

[0070] Three institutions needed to calculate the total amount and average transaction size of cross-border transactions involving three jurisdictions, but none of them wanted to expose their detailed local transaction data. A secure multi-party computation protocol was adopted, where each institution shared its local transaction amount data additively and secretly, exchanging encrypted shares. Each institution then performed addition operations on its secret shares locally to calculate its share of the total transaction amount. For the average calculation, division operations were performed, completed through multiple rounds of interaction and Beaver triplet technology. Finally, Institution A, as the result recipient, collected the result shares from all three parties, reconstructing the total cross-border transaction amount to $285 billion and the average transaction size to $470,000. Throughout the entire calculation process, the original transaction records of each institution remained locally.

[0071] The platform records audit logs for all critical operations. In the 24 hours from January 15th to 16th, 2026, the system recorded 15,847 audit log entries, including 2,134 user logins, 4,562 data encryption operations, 3,891 data decryption operations, 2,103 key encapsulations, 5,157 access policy verifications, 87 attribute key issuances, and 73 delegation token uses. The audit logs are constructed as a hash chain, with the chain head hash value 3A7F…B2C8, and published to the consortium's distributed ledger.

[0072] The threat detection system, based on a rule engine and behavioral baseline analysis, continuously monitors audit log streams and automatically detects abnormal behavioral patterns. The system detected three potential threat events: 1. A user continuously accessed data from five different countries between 2 AM and 4 AM. The access time significantly deviated from the user's historical behavioral baseline by more than five standard deviations. The system calculated an anomaly score of 0.87, automatically triggering a two-factor authentication request. The user failed authentication, the system temporarily froze the account, and notified the security administrator. Subsequent investigation confirmed the account had been compromised. 2. An organization's data decryption requests surged by 300% in a short period, and the decryption failure rate rose from the usual 2% to 15%. The system identified this as a potential brute-force attack, automatically elevating the organization's access control level and requiring manual approval for all decryption operations, successfully preventing an attack attempt targeting highly sensitive data. 3. A data transmission target IP address was not in the authorized geographic location list, triggering compliance rule matching. The system automatically blocked the transmission and generated an alert. After review by the security administrator, it was confirmed as a mistake, preventing unauthorized cross-border data transmission.

[0073] The threat detection system triggered 127 compliance rule alerts and 18 behavioral baseline anomaly alerts within 24 hours. After manual review, 11 events were confirmed as genuine threats, resulting in a false alarm rate of 8.9%. The system's average response time was 100 milliseconds, meeting real-time monitoring requirements. Through continuous updates to the rule base and automatic adjustments to the behavioral baseline, the system maintained its ability to detect emerging threats.

[0074] The quarterly compliance report shows that the platform complies with the technical and organizational requirements of major international data protection regulations, and all personal data is protected by quantum-resistant encryption; a data classification and grading mechanism and a cross-border transfer approval mechanism have been established; and a complete audit and traceability system has been established. The introduction of the threat detection system has reduced the platform's security incident response time by 60% and reduced security operation costs by 35%. Table 2 shows the platform's security performance indicators; Table 2, Examples of Platform Security Performance Indicators

[0075] This application example validates the feasibility and effectiveness of the method of this invention. The platform successfully achieves quantum-resistant security control of cross-border financial data, supporting collaborative supervision while protecting the data sovereignty of various institutions and meeting the compliance requirements of multiple national regulations. The data classification system achieves efficient and accurate sensitivity identification through an intelligent classification model, classifying 100,000 records in 0.5 seconds with an accuracy rate of over 92%. The threat detection system, through a combination of rule engine and behavioral baseline analysis, effectively detects known violations and abnormal patterns with a response time of 100 milliseconds, providing practical and efficient security control capabilities for multi-institutional collaborative supervision.

[0076] The embodiments of the present invention have been described above. However, the embodiments are not limited to the specific implementation methods described above. The specific implementation methods described above are merely illustrative and not restrictive. Those skilled in the art can make more equivalent embodiments under the guidance of the present embodiments, and all of them are within the protection scope of the present embodiments.

Claims

1. A method for constructing a multi-institutional cloud-distributed quantum-resistant data security management and control platform, characterized in that: Includes the following steps: S1. Obtain the collaboration requirements of participating institutions, construct the consortium trust root using the threshold lattice signature scheme, and obtain the consortium master public key and institution identity credentials; S2 receives the alliance master public key and the institution's identity credential, constructs a hierarchical key management system, and obtains the institution's master key pair, domain key, and data key; S3 receives the domain key and data key, and uses encryption and erasure coding methods to obtain hierarchical encrypted data files and attribute encrypted ciphertexts; S4 receives the attribute encrypted ciphertext and the organization's identity credential, and uses a multi-authority attribute encryption and delegation authorization protocol method to obtain the user attribute key component, attribute revocation tree and delegation authorization token; S5 receives the receiving organization's master key pair, delegation authorization token, and hierarchical encrypted data file. It uses a lattice-based key exchange protocol and a secure multi-party computation method to establish a quantum-resistant secure channel and privacy computation capabilities, and obtains the session key, network-coded data packets, secret share data, and fully homomorphic ciphertext computation results. S6. Based on all operational events generated during the process, an audit traceability system is constructed using quantum-resistant hash chains and Merkle tree methods to obtain an audit log hash chain, a Merkle tree index, a threat detection rule base, and a compliance report.

2. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, The method of constructing a consortium trust root using a threshold lattice-based signature scheme includes: Based on N participating institutions, the threshold parameter T is set to half of N plus 1; a lattice-based signature scheme based on NTRU lattice construction is selected to generate the master private key and master public key of the consortium trust root; The Shamir secret sharing algorithm is used to threshold the master private key, construct a polynomial of degree T minus 1, set the constant term as the secret value, calculate the polynomial value at N different horizontal coordinate points to obtain N secret shares, and distribute the shares to each institution through a secure channel and store them in the hardware security module. The certificate issuance is jointly completed by at least T institutions. The initiator constructs the content of the certificate to be signed and calculates the hash value. Each institution uses its private key share to generate a partial signature vector from the hash value. The signing initiator collects at least T partial signatures and then uses the Lagrange interpolation method to perform weighted combination to obtain the complete signature vector.

3. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, The construction of the hierarchical key management system includes: Each organization selects the ML-KEM algorithm to generate an organizational master key pair, obtaining a sealing key and a desealing key. The sealing key is issued as the organization's master public key after being authenticated by the alliance trust root digital signature, and the desealing key is stored as the organization's master private key in the hardware security module. The institution derives the master key from the random seed key generated during the key generation process, and generates a domain key for each security domain through the HKDF key derivation function. The derivation process executes the HKDF-Extract phase and the HKDF-Expand phase. For a specific data object, a data key is further derived from the corresponding domain key. The derived parameters include the domain key as the input key material; the data object identifier and creation time concatenated as the salt value; and the version number included in the context information.

4. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, The encryption and erasure coding methods employed include: Construct an intelligent data classification system to extract structured features, content features, and contextual features from the data to be stored. Use a pre-trained BERT model to semantically encode text fields into vectors, extract statistical features from numerical fields, and use graph neural networks to extract graph structure features from relational data. Multimodal features are input into a hierarchical attention neural network for sensitivity classification. The network includes a feature fusion layer, an attention layer, and a classification layer, and outputs a probability distribution of sensitivity levels. Encryption algorithms are selected based on sensitivity levels: Level 1 sensitive data is encrypted using the BGV fully homomorphic encryption scheme, while Level 2 and Level 3 sensitive data are encrypted using AES-256-GCM with derived data keys.

5. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 4, characterized in that, The encryption and erasure coding methods also include: Set the fragmentation parameters M as the number of data blocks and K as the number of parity blocks, and divide the encrypted data into M data blocks of a fixed size; The Reed-Solomon erasure coding algorithm is used to encode M data blocks to generate K parity blocks. The encoding process constructs a generator matrix, with the first M rows corresponding to the data blocks as identity matrices and the last K rows corresponding to the parity blocks as Vandermonde matrices. M plus K storage blocks are distributed across different data centers, and metadata is attached to each storage block. The metadata includes a data object identifier, block number, block type, storage location, and integrity hash value.

6. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, Attribute-encrypted ciphertext includes: Choose a lattice-based ciphertext policy attribute encryption scheme based on the learning error problem, and convert the access policy expression into an access tree structure, where leaf nodes correspond to single attribute conditions and internal nodes correspond to logic gates. A random symmetric key is generated to encrypt the data content. A secret value is assigned to each node in the access tree. The secret value of the root node is set to the random symmetric key. For internal nodes, the secret value of the child node is assigned according to the logic gate type. To generate a ciphertext component for each leaf node of the access tree, the secret value of the leaf node is encrypted using lattice-based encryption with public parameters associated with the attribute of that leaf node. The generated attribute-encrypted ciphertext contains encrypted data content, an access tree structure description, and a set of ciphertext components.

7. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, The method employing multi-authority attribute encryption and delegation authorization protocol includes: Each organization, as an independent attribute authority, maintains the attribute authority master key and public parameters. When a user registers, the organization is assigned an attribute set based on the position and responsibilities, and uses the master key to generate an attribute key component for each attribute. When a user decrypts attribute-encrypted ciphertext, the access tree structure and ciphertext component set are extracted from the ciphertext. The attribute key is used to perform decryption operations on the ciphertext access tree. The decryption algorithm recursively traverses the access tree and combines the decryption results of child nodes according to the logic gate type. Construct a hierarchical attribute revocation tree to manage attribute key versions and revocation. When a user revokes a specific attribute, update the key version number of the corresponding leaf node in the revocation tree. Then, traverse upwards from the leaf node to the root node to update the key versions of all internal nodes along the path.

8. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 7, characterized in that, The delegation authorization token includes: The delegation authorization is initiated by the data ownership organization to generate a delegation token. The token contains the identifier of the delegated user, the scope of authorized data, the type of authorized operation, the start and end dates of the validity period, the limit on the number of times it can be used, and the digital signature of the initiating organization. The initiating organization uses the lattice-based ML-DSA digital signature algorithm to sign the token content; when the entrusted user accesses the data, he / she submits the user identity credentials, attribute key and entrustment token, and the data storage system verifies the digital signature, validity period, number of uses and consistency of user identity of the entrustment token; After data access is completed, the system records the token usage and updates the usage count. When the token usage reaches the limit or the validity period expires, the token automatically becomes invalid and is added to the revocation list.

9. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, The establishment of quantum-resistant secure channels and privacy computing capabilities using lattice-based key exchange protocols and secure multi-party computation methods includes: Institution A generates a temporary key pair and sends the temporary public key to Institution B. Institution B uses Institution A's temporary public key to execute the ML-KEM encapsulation algorithm to generate a shared key and encapsulated ciphertext. Institution A uses the temporary private key to execute the ML-KEM decapsulation algorithm to recover the shared key and uses HKDF to derive the session key from the shared key. An additive secret sharing scheme is used to share data. Each data value is divided into N secret shares. The secret shares are encrypted using a lattice-based encryption scheme before being exchanged. In the calculation process, the addition operation is performed directly on the shares of each party, and the multiplication operation adopts the Beaver triplet technique. The BGV fully homomorphic encryption scheme is used to encrypt the data and upload it to the cloud computing server. The cloud server performs addition and multiplication operations on the ciphertext, and after the calculation is completed, it returns the ciphertext result to the data owner for decryption.

10. The method for constructing a multi-organization cloud distributed quantum-resistant data security management and control platform according to claim 1, characterized in that, The construction of the audit traceability system using quantum-resistant hash chains and Merkle trees includes: The audit logs are organized into a hash chain data structure in chronological order. When a new log is added, the hash value of the previous node is calculated. The new log content is concatenated with the previous hash value and then SHA3-512 hash operation is performed to obtain the hash value of the new node. The log records within a batch are treated as leaf nodes of the Merkle tree. Starting from the leaf node layer, internal nodes are built up layer by layer until a unique root node is constructed. The hash value of the root node is published as the Merkle root to a public and trusted storage. Establish a compliance rule base and user behavior baseline analysis mechanism. The rule engine listens to the audit log stream in real time to perform rule matching, compares the user's current behavior characteristics with the historical baseline to calculate a comprehensive anomaly score, and generates a security event when the comprehensive anomaly score exceeds a preset threshold.

Images