Multi-code fusion method and system

Abstract

The invention relates to a multi-code fusion method and system, and solves the problem that a user needs to frequently switch different two-dimensional codes to adapt to various scenes in the interaction process with a city service system.The method comprises the steps that the system is started to analyze heterogeneous features of an original code, and a standardized feature set with a cryptographic identifier is generated; and performing hierarchical fusion to generate a fusion code prototype and a behavior credit chain, performing verification to form a formal fusion code, and calculating an initial credit entropy. Bidirectional verification is executed during terminal verification, and a minimum transaction voucher is generated after scene matching. If successful, starting the fusion code, recording the transaction and dynamically adjusting the authority; and if not, triggering a hierarchical security response, generating a security sub-voucher or switching to the original code for operation. The offline scene generates an offline code. The method has the following effects: through dynamic authority and credit management, on the premise of not sacrificing security, one fusion code is used for replacing a plurality of scene codes, and unification of convenience and security is realized.

Description

Technical Field

[0001] This application relates to the field of information processing technology, and in particular to a multi-code fusion method and system. Background Technology

[0002] With the development of information technology, QR codes are increasingly widely used in urban service systems, such as electronic social security codes, bus codes, and subway codes. These QR codes play an important role in scenarios such as identity recognition, payment, and information inquiry, improving service efficiency and user experience.

[0003] Currently, urban service systems primarily use single-function QR codes, such as electronic social security codes for social security information inquiries, bus codes for public transport payments, and subway codes for subway rides. These QR codes are independent, requiring users to switch between different codes in different scenarios, increasing operational complexity. Furthermore, existing technologies lack a unified management and integration mechanism for QR codes, hindering seamless switching and permission sharing across different scenarios.

[0004] The current technology of allowing different QR codes to operate independently has significant drawbacks, primarily in terms of user convenience. Users need to frequently switch between different QR codes to adapt to various scenarios when interacting with city service systems. This not only increases the complexity of user operations but may also lead to errors or confusion during switching, thereby reducing service efficiency and user experience. Summary of the Invention

[0005] In order to replace multiple scenario codes with a single fusion code without sacrificing security, thereby achieving a balance between convenience and security, this application provides a multi-code fusion method and system.

[0006] Firstly, this application provides a multi-code fusion method, which adopts the following technical solution:

[0007] A multi-code fusion method, comprising:

[0008] Launch a multi-code fusion system, analyze the heterogeneous features of each original code, classify them according to benchmark, domain, and dynamic features, match and generate a standardized feature set with verifiable cryptographic source identifiers, and retain the independent functional interfaces of the original code;

[0009] Based on a standardized feature set, layered fusion is performed without overwriting the original code data: the baseline layer generates an encrypted baseline code associated with the original code identifier, the domain layer constructs a cross-scenario permission matrix, and the dynamic layer calculates permission values ​​to form a prototype of the fusion code; a behavior credit chain bound to this prototype of the fusion code is generated simultaneously.

[0010] After verifying the prototype of the fusion code and the behavioral credit chain, a formal fusion code is generated. Based on the initial state of the behavioral credit chain and the preset risk rule set, the initial dynamic credit entropy of the fusion code is calculated, and the parallel calling interface of the fusion code and the original code is maintained.

[0011] By associating the three features of the fusion code through a cross-layer hash chain, the terminal executes a two-way verification protocol during verification: first, it verifies the matching between the scenario and the features of each layer, and then verifies the integrity of the entire chain; subsequently, the terminal announces the scenario requirements and minimum credit entropy requirements to the fusion code, and the fusion code generates a minimum one-time transaction certificate corresponding to the scenario requirements based on the current credit entropy.

[0012] If the verification passes, the fusion code is enabled to achieve cross-scenario functionality, the transaction is recorded to the behavior credit chain, the credit entropy is recalculated, and the permission parameters of the fusion code are dynamically adjusted based on the recalculated credit entropy; if an offline scenario is detected, an offline code with time decay is generated based on dynamic features.

[0013] If the verification fails, a hierarchical security response mechanism is triggered based on the source code identifier associated with the baseline layer: First, a security sub-credential is generated based on the permission matrix of the domain layer, following preset failure conditions and functional scope; if the security sub-credential is invalid or fails to be generated, the corresponding source code is switched to run independently.

[0014] Secondly, this application provides a multi-code fusion system, which adopts the following technical solution:

[0015] A multi-code fusion system includes a memory, a processor, and a program stored in the memory and executable on the processor, the program being loaded and executed by the processor to implement a multi-code fusion method as described in the first aspect. Attached Figure Description

[0016] Figure 1 This is a schematic diagram of the overall process of a multi-code fusion method in an embodiment of this application.

[0017] Figure 2 This is a schematic diagram of the process of generating an encrypted base code for an associated source code identifier in another embodiment of this application. Detailed Implementation

[0018] The present application will be further described in detail below with reference to the accompanying drawings.

[0019] Reference Figure 1 This application discloses a multi-code fusion method, which includes the following steps:

[0020] Step S100: Start the multi-code fusion system, parse the heterogeneous features of each original code, classify them according to benchmark, domain and dynamic features, match and generate a standardized feature set with verifiable cryptographic source identifiers, and retain the independent functional interfaces of the original code.

[0021] Among them, the multi-code fusion system is a system that integrates multiple source codes (such as QR codes, barcodes, RFID, etc.). It achieves unified functionality across different scenarios by parsing and fusing the features of different source codes. Acquisition methods include integration into existing systems via software development kits (SDKs) or API calls via cloud services. Heterogeneous features refer to the differences in data structure, encoding methods, and functional uses of different source codes. Acquisition is achieved through a feature parsing module that reads and analyzes the source code data.

[0022] The necessary processes are described below: 1. System Startup and Data Acquisition: After the multi-code fusion system is started, it first reads data from various raw codes through the data acquisition module. These raw codes include bus codes, subway codes, and social security codes. The system uses appropriate technical means to collect data according to the type of raw code. 2. Feature Classification and Extraction: The system classifies and extracts the collected raw data according to preset rules. Baseline features include encoding format (such as QRCode format for QR codes, UID format for NFC) and data structure (such as user ID format). Domain features involve application scenarios; for example, bus codes and subway codes belong to the public transportation domain, while social security codes belong to the social security domain. Dynamic features include timestamps (such as usage time) and usage frequency. The system matches baseline features using regular expressions, extracts domain features through keywords, and extracts dynamic features through timestamps to ensure the accuracy of feature classification. 3. Generation of Verifiable Cryptographic Source Identifiers: The system generates verifiable cryptographic source identifiers for each feature to ensure data integrity and security. The specific process is as follows: 1. Extract key information from the original code (such as user ID, timestamp, etc.), generate a hash value using the SHA-256 algorithm, and then sign the hash value using the RSA algorithm to generate a digital signature. The digital signature is bound to the original data to form a verifiable cryptographic source identifier. 2. Generate a standardized feature set: The system standardizes the extracted features to form a standardized feature set. For example, user IDs are standardized to fixed-length strings, and timestamps are standardized to the ISO standard format. The standardized features are bound to the cryptographic source identifier to form a standardized feature set. 3. Retain independent functional interfaces: While generating the standardized feature set, the system retains the independent functional interfaces of the original code through an interface adapter.

[0023] In step S100, when starting the multi-code fusion system, electronic social security codes, bus codes, and subway codes can be used as raw codes. At this time, the multi-code fusion system is started, and the heterogeneous features of each raw code are parsed. Classified according to benchmark, domain, and dynamic features, a standardized feature set with verifiable cryptographic source identifiers is generated, including:

[0024] Step S101: Access each original code by pre-setting differentiated interfaces and corresponding security policies for the electronic social security code, bus code, and subway code. The electronic social security code adopts an encrypted channel and data desensitization processing, while the bus code and subway code are accessed through a dedicated network and configured with a verification and retry mechanism.

[0025] Among these, differentiated interfaces refer to specialized interfaces designed for different types of source codes (such as electronic social security codes, bus codes, and subway codes). These interfaces are customized according to the characteristics and security requirements of the source code. Encrypted channels utilize encryption technologies (such as TLS / SSL) to establish secure communication paths, protecting privacy and integrity during data transmission. Data anonymization involves hiding or altering the original data using technical means (such as masking and hashing) when storing or processing sensitive information to reduce the risk of data leakage. Private network access utilizes dedicated networks (such as VPNs) for data transmission, improving data transmission security and preventing external attacks. Verification and retry mechanisms automatically resend data if errors are detected during transmission, ensuring data accuracy.

[0026] The process is described below:

[0027] 1. Secure Access to the Electronic Social Security Code: The electronic social security code contains sensitive personal information; therefore, an encrypted channel is used during access to ensure data security during transmission. Simultaneously, sensitive information such as ID card numbers undergoes anonymization processing. For example, some digits in the ID card number "11010519491231002X" are replaced with asterisks "********" to protect user privacy. This process involves the application of data access control and encryption technologies to ensure that only authorized systems and personnel can access the original data.

[0028] 2. Dedicated Network Access for Bus and Metro Codes: Bus and metro codes access the system via a dedicated network, utilizing VPN technology to establish a secure network environment. This access method reduces data exposure on public networks, lowering the risk of interception or tampering. During data transmission, the system is configured with verification and retry mechanisms, such as CRC checks, to ensure data integrity. If an error occurs in a data packet during transmission, the system will automatically retry until the data is successfully transmitted.

[0029] 3. Differentiated Interface Design: To accommodate different types of source code, the system features differentiated interfaces. These interfaces are customized based on the characteristics and security requirements of the source code. For example, the electronic social security code interface may require stricter authentication and authorization mechanisms, while the bus code and subway code interfaces may prioritize data transmission efficiency and reliability.

[0030] Step S102: Call the pre-set heterogeneous parsing rule base to extract key fields and unify the format of the three types of source code. The rule base contains format conversion rules and field mapping relationships corresponding to each source code type.

[0031] Among these, format unification processing involves converting the extracted data fields into a unified format that the system can recognize and process. Field mapping relationships define the correspondence between the source code fields and the fields in the system's internal data model.

[0032] The process is described as follows: 1. Rule base invocation: After receiving the raw code, the system invokes a pre-built heterogeneous parsing rule base. This rule base contains parsing rules for different raw code types, guiding the system on how to extract key information from the raw code and convert it into a format that the system can process internally. 2. Key field extraction: For electronic social security codes, key fields may include personal identity information, social security account status, etc.; bus codes may include travel time, route information, etc.; subway codes may include entry and exit information. The parsing rules in the rule base guide the system to identify these key fields and extract them from the raw data. 3. Format unification: The extracted key fields may require further format conversion to conform to the system's internal data standards. For example, date fields may need to be unified into the "YYYY-MM-DD" format, and time fields may need to be unified into the "HH:MM:SS" format. The rule base contains specific rules for these format conversions. 4. Establishment of field mapping relationships: To correctly map the extracted and converted data fields to the system's internal data model, the rule base defines field mapping relationships. This includes mapping field names in the source code to field names within the system, and determining the correspondence between field data types.

[0033] 5. Automated processing: The entire parsing process is automated. Once the source code is accessed, the system will automatically execute the parsing rules in the rule base, extract key fields, perform format conversion, and establish field mapping relationships.

[0034] Step S103: Based on preset classification rules, the extracted features are classified and integrated according to benchmark, domain and dynamic features.

[0035] The process is described as follows: 1. Application of Classification Rules: After feature extraction, the system classifies these features according to preset classification rules. These rules define how to categorize features into different classes based on their attributes and uses. 2. Identification and Integration of Baseline Features: The system first identifies baseline features related to the basic functions of the source code. For example, for electronic social security codes, baseline features may include the code version and encoding standard. These features are crucial for ensuring data compatibility and consistency. 3. Extraction of Domain Features: Next, the system extracts features related to the application domain of the source code. For example, the domain features of bus codes and subway codes may include information such as boarding location, route, and time, which helps in understanding the code's usage scenarios. 4. Capture of Dynamic Features: The system also captures features related to dynamic changes during the use of the source code. For example, the specific time of a transaction and the frequency of code usage; these features can reflect user habits and behavioral patterns. 5. Feature Integration: After classification, the system integrates these features into a unified data structure. This step involves data cleaning, transformation, and formatting to ensure that all features can be effectively used by the system.

[0036] Step S104: Based on the classification results, a unique source identifier is generated by combining the original code type identifier and the timestamp; a standardized feature set is formed by integrating based on a preset feature weight strategy, and the source identifier and feature set are digested by cryptographic hash operation to generate a verifiable cryptographic source identifier, while establishing a traceability index relationship with each original code.

[0037] The process is described as follows: 1. Generate a unique source identifier: Based on the classification result of step S103, the system combines the type identifier of the original code with a timestamp accurate to milliseconds to generate a unique source identifier. For example, for an electronic social security code, the unique source identifier may consist of a combination of the social security code type, user ID, and timestamp, ensuring the uniqueness of each code. 2. Integrate to form a standardized feature set: Based on a preset feature weight strategy, the system integrates the extracted features to form a standardized feature set. This process involves evaluating the importance of different features and integrating them according to their weights. For example, for a bus code, the boarding time may be more important than the boarding location, so the time feature will have a higher weight in the feature set. 3. Perform cryptographic hash operations: To ensure the integrity and consistency of the source identifier and feature set, the system performs cryptographic hash operations on them. Commonly used hash algorithms include SHA-256. 4. Generate a verifiable cryptographic source identifier: Through hash operations, the system generates a verifiable cryptographic source identifier. This identifier can be used to verify the source and integrity of the original code. 5. Establish a source index relationship: Finally, the system establishes a source index relationship between the source code and the generated unique source identifier. This relationship is usually stored in a database, and fast querying is achieved through the index structure.

[0038] Step S200: Based on the standardized feature set, layered fusion is performed in a way that does not cover the original code data: the baseline layer generates an encrypted baseline code associated with the original code identifier, the domain layer constructs a cross-scenario permission matrix, and the dynamic layer calculates permission values ​​to form a prototype of the fusion code; a behavior credit chain bound to the prototype of the fusion code is generated simultaneously.

[0039] The fusion code consists of three layers: Baseline Layer: The foundational structure layer containing an encrypted base code associated with the original code identifier, ensuring the uniqueness and security of the fusion code compared to the original code. Domain Layer: The functional layer of the fusion code, constructing a cross-scenario permission matrix and defining the usage permissions of the fusion code in different scenarios. Dynamic Layer: The dynamic adjustment layer of the fusion code, calculating permission values ​​based on real-time data to form the initial shape of the fusion code.

[0040] For the process of generating the encrypted base code of the associated original code identifier in the base layer, please refer to steps S210 to S240. For the process of constructing the cross-scenario permission matrix in the domain layer, please refer to steps S2A0 to S2D0. For the process of calculating the permission value in the dynamic layer to form the prototype of the fusion code, please refer to steps S2a0 to S2d0.

[0041] The process of synchronously generating the behavioral credit chain can be referenced as follows: Simultaneously with the generation of the initial fusion code, the system synchronously generates the behavioral credit chain bound to it. Based on blockchain technology, the behavioral credit chain records each use of the fusion code, including information such as time, scenario, and permission values. For example, each time a public transport code is used for transportation, the behavioral credit chain records information such as the timestamp, the origin and destination of the journey.

[0042] Step S300: After verifying the prototype of the fusion code and the behavioral credit chain, a formal fusion code is generated. Based on the initial state of the behavioral credit chain and the preset risk rule set, the initial dynamic credit entropy of the fusion code is calculated, and the parallel calling interface of the fusion code and the original code is maintained.

[0043] The initial dynamic credit entropy is the initial credit value of the fusion code calculated based on the initial state of the behavioral credit chain and a preset risk rule set. It is used to assess the credit level of the fusion code in its initial state. It is obtained by calculating the credit entropy using a credit entropy calculation model, combined with behavioral credit chain data and risk rules.

[0044] Necessary Process Description: 1. Verification of the Fusion Code Prototype and Behavioral Trust Chain: The system first verifies the fusion code prototype and behavioral trust chain to ensure their integrity and credibility. The verification of the fusion code prototype uses a hash algorithm to verify the integrity of its various layers of features. For example, hash values ​​are calculated for the base layer, domain layer, and dynamic layer, and compared with pre-stored hash values. The verification of the behavioral trust chain utilizes the immutability of the blockchain to check the timestamp of each block, data integrity, and hash links between blocks. For example, if an abnormal timestamp or missing data is detected in a block, the verification will fail, and the fusion code prototype will be marked as invalid. 2. Generation of the Official Fusion Code: After successful verification, the system converts the fusion code prototype into the official fusion code. This process includes formatting and security hardening of the fusion code. For example, a digital signature is added to the official fusion code to ensure authentication and integrity protection during transmission and use. Simultaneously, the system assigns a unique identifier to the official fusion code for easy subsequent management and tracking. For example, after being converted into a formal fusion code, bus codes and subway codes will have a unified format and security mechanism, ensuring their universality and security in public transportation scenarios. 3. Calculate the initial dynamic credit entropy: Based on the initial state of the behavioral credit chain and a preset risk rule set, the system calculates the initial dynamic credit entropy of the fusion code. This process includes the following innovative steps:

[0045] Step A: Multi-dimensional Feature Extraction: The system extracts multi-dimensional features from the behavioral credit chain, including usage time, usage frequency, scenario type, and permission value. For example, for bus codes and subway codes, features such as first-time use time, daily usage frequency, and whether it was used during peak hours are extracted. These features will serve as the basic data for credit entropy calculation.

[0046] Step B: Risk Weight Allocation: The system assigns a risk weight to each feature based on a preset set of risk rules. For example, scenarios with high usage frequency during peak hours may be assigned a higher risk weight, as this may indicate abnormal user behavior. The weight allocation is based on historical data and expert experience to ensure the rationality and scientific validity of the weights.

[0047] Step C: Dynamic Credit Entropy Calculation Model: The system employs an innovative dynamic credit entropy calculation model, combining features and weights to calculate the initial dynamic credit entropy. The model uses a weighted average algorithm and introduces a time decay factor to ensure that the credit entropy reflects the latest user behavior. The specific formula is as follows:

[0048] Initial dynamic credit entropy = Among them, F i W represents the i-th feature value (such as usage frequency, scenario risk level, etc.). i Let represent the risk weight of the i-th feature. D(t) represents the time decay factor, which gradually decreases over time, for example... , where λ is the attenuation coefficient and t is time.

[0049] Step D: Credit Entropy Calibration and Adjustment: Based on the initial dynamic credit entropy and a preset credit threshold, the system calibrates and adjusts the credit status of the fused code. For example, if the initial credit entropy is lower than the preset threshold (e.g., a threshold of 4.0), the system will mark the fused code as high-risk and restrict some of its functions until the credit entropy returns to a normal level. This process ensures that the fused code maintains security and reliability throughout its use.

[0050] In step S400, the three-layer features of the fusion code are associated through a cross-layer hash chain. During terminal verification, a two-way verification protocol is executed: first, the matching between the scenario and each layer of features is verified, and then the integrity of the entire chain is verified. Subsequently, the terminal announces the scenario requirements and minimum credit entropy requirements to the fusion code. The fusion code generates a minimum one-time transaction certificate corresponding to the scenario requirements based on the current credit entropy.

[0051] Among them, the cross-layer hash chain is a technology used to associate the three layers of features (baseline layer, domain layer, and dynamic layer) of the fusion code, ensuring data integrity and consistency through the concatenation of hash values. It is obtained by processing and concatenating the features of each layer using a hash algorithm. The two-way verification protocol is a terminal verification mechanism that includes verifying the matching of the scenario with the features of each layer and verifying the integrity of the entire chain. It is obtained by designing verification algorithms and protocols. The minimized one-time transaction credential is a temporary credential generated according to scenario requirements and current credit entropy, used for single verification in a specific scenario. It is obtained by dynamically generating the fusion code system according to preset rules.

[0052] The process of associating the three-layer features of the fusion code through cross-layer hash chains can be referred to in steps 1 to 3; the process of first verifying the matching between the scenario and each layer of features, and then verifying the integrity of the entire chain can be referred to in steps S410 to S430.

[0053] The scenario requirements and minimum credit entropy requirements are declared as follows: The terminal declares the current scenario requirements and minimum credit entropy requirements to the fusion code. For example, in a subway scenario during peak hours, the terminal declares that it needs access permission and requires the fusion code's credit entropy to be no less than 4.0. After receiving this information, the fusion code assesses whether the requirements are met based on its current credit entropy.

[0054] The process of generating a minimal one-time transaction credential is as follows: If the credit entropy of the fusion code meets the terminal requirements, the system generates a minimal one-time transaction credential based on the scenario requirements. The credential contains the following: 1. Scenario Identifier: Identifies the current scenario (e.g., subway, bus). 2. Permission Value: Permission values ​​assigned according to scenario requirements. 3. Validity Period: The valid time range of the credential, typically for single use. 4. Hash Value: A hash value containing the scenario requirements and permission values, used to verify the integrity of the credential.

[0055] In step S500, if the verification passes, the fusion code is enabled to realize cross-scenario functions, the transaction is recorded to the behavior credit chain, the credit entropy is recalculated, and the permission parameters of the fusion code are dynamically adjusted based on the recalculated credit entropy; if an offline scenario is detected, an offline code with time decay is generated based on dynamic features.

[0056] Among them, cross-scenario functions: the functions implemented by the fusion code in different application scenarios (such as buses, subways, social security, etc.) are achieved through dynamic adjustment of permission parameters.

[0057] Necessary Process Description: 1. Enable Cross-Scenario Functionality with the Fusion Code: If terminal verification is successful (step S400), the fusion code will be enabled to achieve cross-scenario functionality. The system dynamically adjusts the functionality of the fusion code based on its permission parameters to ensure it has appropriate permissions in different scenarios. For example, the fusion code has access permissions in a public transportation scenario and query and payment permissions in a social security scenario. These permission parameters are dynamically adjusted according to a preset rule set to adapt to different usage scenarios. 2. Record Transactions to the Behavioral Credit Chain: Each time the fusion code is used, the system writes the transaction record to the behavioral credit chain. The transaction record includes information such as usage time, scenario, and permission value. For example, when a user uses the fusion code to ride the subway, the system records the transaction time as 2025-11-06T08:00:00, the scenario as subway, and the permission value as access permission. These records are ensured to be tamper-proof through blockchain technology, providing data support for the calculation of credit entropy. 3. Trigger Credit Entropy Recalculation: Based on the latest transaction records and the status of the behavioral credit chain, the system triggers the recalculation of credit entropy. The credit entropy recalculation model dynamically adjusts the credit entropy value by combining new transaction data and preset risk rules. For example, if a user frequently uses the fusion code during peak hours, the credit entropy may decrease; if the user uses it normally without abnormal behavior, the credit entropy will remain stable or slightly increase. 4. Dynamically adjust the fusion code's permission parameters: Based on the recalculated credit entropy, the system dynamically adjusts the fusion code's permission parameters. This process includes the following specific steps:

[0058] Step S501:

[0059] Define credit entropy thresholds: The system presets multiple credit entropy thresholds for segmented management of fusion code permissions. For example: 1. Low credit entropy threshold (e.g., <4.0): Restricts high-risk permissions. 2. Medium credit entropy threshold (e.g., 4.0-4.5): Unlocks basic function permissions. 3. High credit entropy threshold (e.g., >4.5): Unlocks advanced function permissions.

[0060] Step S502:

[0061] Permission Parameter Mapping: The system maps the permission parameters of the fusion code to different permission levels based on the credit entropy value. For example: 1. Low credit entropy (<4.0): Only basic access permissions (such as buses and subways) are allowed, and payment and query functions are restricted. 2. Medium credit entropy (4.0-4.5): Basic payment permissions (such as small payments) are unlocked, and query functions are allowed. 3. High credit entropy (>4.5): Advanced payment permissions (such as large payments) are unlocked, and advanced query functions (such as social security detail queries) are allowed.

[0062] Step S503:

[0063] Real-time permission adjustment: The system adjusts the permission parameters of the Fusion Code in real time based on the latest credit entropy value. For example: 1. If the credit entropy drops from 4.2 to 3.9, the system automatically adjusts the Fusion Code's permission level from "medium credit entropy" to "low credit entropy," restricting its payment function. 2. If the credit entropy rises from 3.8 to 4.1, the system automatically adjusts the Fusion Code's permission level from "low credit entropy" to "medium credit entropy," unlocking basic payment functions.

[0064] Step S504:

[0065] Permission Adjustment Notification: The system sends permission adjustment notifications to users and terminal devices to ensure users are aware of their current permission status. For example, a user might receive a notification when their credit entropy decreases: "Your fusion code credit entropy has dropped to 3.9, and payment functionality is temporarily restricted." For specific offline scenario processing procedures, please refer to steps S510 to S550.

[0066] In step S600, if the verification fails, a hierarchical security response mechanism is triggered based on the source code identifier associated with the base layer: First, a security sub-credential is generated based on the permission matrix of the domain layer, following preset failure conditions and functional scope; if the security sub-credential is invalid or fails to be generated, the corresponding source code is switched to run independently.

[0067] The base layer-associated source code identifier is a unique identifier contained in the fusion code base layer that is associated with the source code (such as bus code, subway code, social security code), used to trace the source code in case of verification failure. The tiered security response mechanism is a multi-layered security response strategy that takes different security measures based on the specific circumstances of verification failure. The security sub-credential is a temporary credential generated in case of verification failure, following preset failure conditions and functional scope, used to restrict the functionality of the fusion code.

[0068] The necessary processes are described below: 1. Triggering the hierarchical security response mechanism: If the fusion code verification fails (e.g., scenario mismatch or hash chain integrity corruption), the system triggers the hierarchical security response mechanism based on the original code identifier associated with the baseline layer. This process ensures that the system can respond quickly and take appropriate security measures when verification fails. 2. Generating security sub-credentials based on the domain layer permission matrix: The system first generates security sub-credentials based on the domain layer permission matrix. The permission matrix defines the functional scope and permission restrictions under different failure conditions. For example:

[0069] Failure conditions include: credit entropy falling below a threshold, scenario mismatch, and damage to the integrity of the entire chain.

[0070] Functional scope: such as restricting payment functions, allowing only query functions, restricting access permissions, etc.

[0071] For example: Suppose the credit entropy of the fusion code is lower than a preset threshold (e.g., lower than 4.0), the permission matrix stipulates:

[0072] Failure condition: Credit entropy < 4.0; Functional scope: Only query function is allowed, payment and access permissions are restricted.

[0073] The system generates security sub-credentials based on these rules, including: a) scenario identifier: such as bus, subway, social security; b) permission value: such as query function only; c) validity period: such as valid for 15 minutes; d) hash value: a hash value generated based on the above information to ensure the integrity of the credential.

[0074] 3. Verification and Application of Security Sub-credentials: The terminal device verifies the validity of the security sub-credentials, including checking the hash value and validity period. If the security sub-credential is valid, the terminal device will restrict the functionality of the fusion code based on the credential content. For example, it may only allow users to query social security information, while restricting payment and access functions.

[0075] 4. Switch to independent execution of source code: If the security sub-credential is invalid (e.g., hash value verification fails) or fails to be generated (e.g., there is no corresponding rule in the permission matrix), the system will switch to independent execution of the corresponding source code.

[0076] Reference Figure 2 The encrypted base code that generates the associated source code identifier at the base layer includes:

[0077] Step S210: Analyze the baseline features of each source code, extract the unique identifier and core attributes, convert the heterogeneous identifiers into a source identifier set in a unified format through a feature mapping algorithm, and establish a baseline association index between source codes.

[0078] Among them, the unique identifier is the unique identification information in the source code, such as product serial numbers and user accounts. It is extracted from the source code data. Core attributes are the key functional attributes of the source code, determining its main purpose and function. They are obtained by analyzing the functional logic and application scenarios of the source code. Feature mapping algorithm is an algorithm that converts heterogeneous identifiers into a unified format. It is designed based on the characteristics of the source code and the target unified format, such as hash algorithms and encoding conversion algorithms.

[0079] The complete process is described as follows: First, the basic features of each source code are analyzed to extract unique identifiers and core attributes. For example, for bus codes and subway codes, their encoding methods (such as QR codes and NFC tags) and lengths are analyzed to extract user accounts as unique identifiers and access permissions as core attributes. For social security codes, social security account numbers are extracted as unique identifiers and query permissions as core attributes. Then, heterogeneous identifiers are converted into a unified format source identifier set using a feature mapping algorithm. For example, the SHA-256 hash algorithm is used to convert user accounts in different formats into fixed-length hash values, forming a unified format source identifier set. Finally, a basic association index between source codes is established. Based on the source identifier set, an index structure, such as a hash table, is constructed to establish an association index between the source identifiers of the source codes and the source codes themselves, facilitating subsequent fast querying and association of source codes. For example, a hash table is constructed using the hash values ​​of the source identifier set as keys and the relevant information of the source codes as values ​​to realize the basic association index between source codes.

[0080] Step S220: The source identifier set is encrypted using a preset encryption algorithm to generate a unique encryption base code. The encryption process is implemented in an outer encryption wrapping mode. It only establishes an association with the original code through the interface layer, without intruding on its basic data and original encryption system. At the same time, it embeds the reversible association relationship of the source identifier of the original code, so that the base code can trace back to the associated original code and ensure the normal operation of the independent function of the original code.

[0081] The encryption algorithm is defined as follows: **Preset Encryption Algorithm:** A pre-defined encryption algorithm used to encrypt the source identifier set. Common encryption algorithms include Chinese national cryptographic algorithms (such as SM2, SM3, and SM4) and internationally recognized algorithms (such as AES and RSA). **Outer Encryption Wrapping Mode:** An encryption method that does not encrypt the source code data internally, but instead wraps the encrypted content around the source code, forming an encryption layer. **Interface Layer:** An interaction layer between the fused code and the source code, used to establish a connection between the encryption base code and the source code without directly modifying the data structure of the source code. **Reversible Association Relationship:** An association embedded in the encryption process that allows tracing back from the encryption base code to the source code. This relationship is implemented through encryption algorithms and key management, ensuring security and traceability.

[0082] The complete process is described below: 1. Select a preset encryption algorithm: Choose a suitable encryption algorithm based on security and performance requirements. Both Chinese national cryptographic algorithms (such as SM2, SM3, SM4) and internationally recognized algorithms (such as AES, RSA) can be used to encrypt the source identifier set. Chinese national cryptographic algorithms have high security and independent intellectual property rights, making them suitable for application scenarios requiring high security levels. For example, the SM4 algorithm is a symmetric encryption algorithm suitable for fast encryption and decryption operations; SM2 is an asymmetric encryption algorithm suitable for scenarios requiring the separation of public and private keys. When selecting an algorithm, the encryption strength, computational efficiency, and compliance with industry standards must be considered. 2. Implementation of the outer encryption wrapping mode: The source identifier set is encrypted using the outer encryption wrapping mode. The specific steps are as follows: 2.1. Prepare the source identifier set: Obtain a source identifier set in a unified format from step S210. These identifier sets have been converted to a unified format using a feature mapping algorithm. For example, the SHA-256 hash algorithm is used to convert user accounts in different formats into fixed-length hash values. 2.2. Encryption processing: Encrypt the source identifier set using the selected encryption algorithm (such as SM4). The source identifier set is taken as plaintext input, and encryption is performed using a key to generate ciphertext as the encryption base code. For example, the hash value of a user account can be taken as plaintext input and encrypted using the SM4 algorithm to generate the encryption base code. 2.3 Wrapping the Original Code: The encrypted base code is wrapped around the original code to form an encryption layer. This method ensures that the basic data of the original code and the original encryption system are not affected, and the connection with the encryption base code is only established through the interface layer.

[0083] 3. Embedding Reversible Associations: A reversible association of the original code source identifier is embedded during the encryption process to ensure that the original code can be traced back from the encryption base code. Specific methods are as follows: 3.1 Key Management: When using symmetric encryption algorithms (such as AES), the key needs to be securely stored and managed. For asymmetric encryption algorithms (such as SM2), the public key is used for encryption, and the private key is used for decryption, ensuring that only authorized parties can decrypt and trace the original code. 3.2 Association Record: A reversible mapping relationship is embedded in the encryption base code, for example, by adding a pointer or identifier to the original code in the encryption base code. This pointer or identifier can be used to quickly locate and trace the original code during decryption. 3.3 Security Verification: Ensure that the reversible associations during the encryption process do not leak sensitive information from the original code, while guaranteeing accurate tracing back to the original code during decryption. For example, the security of the associations can be ensured through the characteristics of the encryption algorithm (such as the strong encryption of SM4).

[0084] 4. Ensure the independent operation of the source code: After the encryption base code is generated, ensure that the independent functionality of the source code is not affected. Specific measures include: 4.1 Interface Adaptation: Design an adapter through the interface layer to ensure that the functional interfaces of the source code are compatible with the interfaces of the encryption base code. For example, the scanning function of the bus code and the card swiping function of the subway code can still be called independently after integration. The adapter can map the interface of the encryption base code to the functional interface of the source code, ensuring the continuity of function. 4.2 Functional Testing: After the encryption base code is generated, perform functional testing to verify whether the function of the source code is operating normally. For example, test whether the bus code can still scan and pay normally, and whether the social security code can still query information normally. Through testing, ensure that the encryption process does not affect the normal use of the source code. 4.3 Anomaly Handling: Design an anomaly handling mechanism to ensure that the source code can run independently and not affect the normal use of the user when the encryption base code has problems. For example, if the encryption base code fails, the system can automatically switch to the source code to ensure service continuity. The anomaly handling mechanism can be implemented by monitoring the status of the encryption base code and automatically triggering the switching logic.

[0085] Step S230: Set a dynamic security level field in the encryption baseline code. This field calculates the risk value in real time and automatically matches the security level based on a cross-domain risk assessment model that integrates data security, scenario load, and abnormal behavior.

[0086] Among them, the dynamic security level field is a field in the encryption baseline code that can be adjusted in real time and is used to identify the security level. The cross-domain risk assessment model is a model used to comprehensively assess risks from multiple domains, including integrated data security, scenario load, and abnormal behavior.

[0087] The complete process is described below: 1. Set a dynamic security level field: A dedicated field is set in the encryption baseline code to store the dynamic security level. The initial value of this field can be set according to the system default configuration or historical data. For example, the initial security level can be set to "Medium," representing the system's default security state when there are no specific risk warnings. 2. Construct a cross-domain risk assessment model: A comprehensive assessment model is constructed, which combines risk factors from the following three main domains and quantifies the risk in each domain:

[0088] 2.1 Integrating data security risk quantification:

[0089] Data Sensitivity Assessment: Assess the sensitivity of data based on its type and content. For example, personal privacy data (such as social security information) is more sensitive than ordinary transaction data. Sensitivity can be categorized into three levels: low (10), medium (20), and high (30). Access Control Policy: Assess the permission settings and control mechanisms for data access. For example, strict multi-level access control and authentication mechanisms reduce the risk value. Access control policies can be categorized into three levels: weak (10), medium (5), and strong (0). Data Encryption Strength: Assess the encryption strength of data during transmission and storage. For example, using strong encryption algorithms (such as AES-256) reduces the risk value. Encryption strength can be categorized into three levels: weak (10), medium (5), and strong (0).

[0090] Comprehensive data security risk value: The comprehensive data security risk value is obtained by weighted summing of the above three factors.

[0091] Data security risk value = w 敏感度 ×Sensitivity + w 访问控制 ×Access Control+w 加密强度 × Encryption strength.

[0092] 2.2 Quantification of Scenario Load Risk:

[0093] System performance metrics: Monitor system performance metrics such as response time, throughput, CPU and memory utilization. For example, a response time exceeding a threshold (e.g., 1 second) increases the risk value. Response time can be categorized into three levels: low (0), medium (5), and high (10). Concurrent access: Assess the current system's concurrent access. For example, high concurrent access (e.g., exceeding 1000 times / second) increases the risk value. Concurrent access can be categorized into three levels: low (0), medium (5), and high (10). Resource utilization: Assess the system's resource utilization. For example, CPU or memory utilization exceeding 80% increases the risk value. Resource utilization can be categorized into three levels: low (0), medium (5), and high (10).

[0094] Overall Scenario Load Risk Value: The overall scenario load risk value is obtained by weighted summing of the above three factors.

[0095] Scenario load risk value = w 响应时间 × Response time + w 并发访问量 ×Concurrent access volume + w 资源占用率 ×Resource utilization rate.

[0096] 2.3 Quantification of Abnormal Behavior Risk:

[0097] User Behavior Analysis: Utilizing machine learning algorithms (such as random forests and support vector machines) to analyze user behavior patterns. For example, frequent erroneous login attempts (more than 5 times / minute) increase the risk value. User behavior can be categorized into three levels: low (0), medium (5), and high (10). Operation Time Analysis: Evaluating the time patterns of user operations. For example, abnormal operation times (such as midnight to 4 AM) increase the risk value. Operation time can be categorized into three levels: low (0), medium (5), and high (10). Access Pattern Analysis: Evaluating user access patterns. For example, accessing multiple different types of resources within a short period increases the risk value. Access patterns can be categorized into three levels: low (0), medium (5), and high (10).

[0098] Comprehensive Abnormal Behavior Risk Value: The comprehensive abnormal behavior risk value is obtained by weighted summing of the above three factors.

[0099] Abnormal behavior risk value = w 用户行为 ×User behavior + w 操作时间 × Operation time + w 访问模式 × Access mode.

[0100] 3. Calculate risk values ​​and match security levels in real time:

[0101] The cross-domain risk assessment model collects and analyzes data from the three domains mentioned above in real time to calculate a comprehensive risk value. The specific steps are as follows: 3.1 Data Collection: Collect real-time data from sources such as system logs, performance monitoring tools, and user behavior logs. 3.2 Feature Extraction: Extract and integrate features related to data security, scenario load, and abnormal behavior. For example, data sensitivity, response time, and number of erroneous logins. 3.3 Risk Value Calculation: Calculate the comprehensive risk value using preset weights and formulas. For example:

[0102] Risk value = w1 × Data security risk value + w2 × Scenario load risk value + w3 × Abnormal behavior risk value. Where w1, w2, and w3 are preset weights that can be adjusted according to actual needs. For example, if the risk value is <30, the security level is set to "Low". If 30 ≤ Risk value < 70, the security level is set to "Medium".

[0103] If the risk value is ≥70, the safety level is set to "high".

[0104] In step S240, the update of the security level field is synchronized to all associated terminals through an end-to-end encrypted tunnel to ensure the dynamic consistency of the security benchmark across the entire link.

[0105] End-to-end encrypted tunnel: A secure communication channel that ensures data is not stolen or tampered with during transmission between the sender and receiver. Implemented through encryption algorithms (such as TLS / SSL), it guarantees data confidentiality and integrity. Dynamic consistency: Ensures that the security level fields on all associated terminals are synchronized and consistent in real time to maintain a security baseline across the entire link. Associated terminals: All devices related to the encryption baseline code, such as user equipment, servers, and authentication terminals, which need to update their security level fields in real time to maintain synchronization.

[0106] The complete process is described below: 1. Synchronization Mechanism Trigger and Encrypted Tunnel Establishment: When the security level field in the encryption base code is updated, the system immediately triggers a synchronization operation through a heartbeat mechanism or event-driven mechanism. To ensure the security of data transmission, the system uses the TLS / SSL protocol to establish an end-to-end encrypted tunnel, securely exchanges session keys through a key exchange algorithm (such as Diffie-Hellman), encrypts the transmitted data, and uses digital certificates to verify the identities of both communicating parties, ensuring the confidentiality and integrity of the communication. 2. Update Message Sending and Terminal Receipt Verification: The system sends the updated security level field to all associated terminals in the form of an encrypted message. The message includes the encryption base code identifier, security level, update timestamp, and digital signature. After receiving the message, the terminal uses the session key to decrypt and verify the integrity and authenticity of the message. After successful verification, the terminal updates its local security level field and records the operation log for subsequent auditing and troubleshooting. 3. Dynamic Consistency Guarantee and Anomaly Handling: To ensure dynamic consistency across the entire link, the system periodically broadcasts the update status and collects terminal feedback. If a terminal fails to update, the system will trigger a retransmission mechanism to resend the update message. Meanwhile, the system records detailed information on all synchronization operations, including successful and failed synchronization attempts, to enable rapid troubleshooting and repair in case of anomalies, and to ensure that the security level fields of all associated terminals remain consistent.

[0107] The domain layer constructs a cross-scenario permission matrix, including:

[0108] Step S2A0: Analyze the domain features of each source code, extract scene-specific permissions and domain rules, distinguish between permission data that can be shared across scenarios and domain-specific permission configurations, establish a mapping relationship between domain features and base layer encryption base code, and retain independent permission configuration interfaces for each source code belonging to its domain. Scene-specific permissions include function access scope and operation permission level, while domain rules include scene access conditions and interaction constraints.

[0109] Among these, the key features include: Domain Characteristics: The attributes and characteristics of the source code within a specific domain, such as station information for subway codes, route information for bus codes, and insurance type for social security codes. These are extracted through domain attribute analysis of the source code. Scenario-Specific Permissions: Permissions unique to the source code in specific scenarios, such as access permissions within subway stations for subway codes, boarding permissions at bus stops for bus codes, and query permissions at social security centers for social security codes. These are obtained by analyzing the functional and operational requirements of the source code in various scenarios. Domain Rules: The general norms and constraints of the domain to which the source code belongs, such as travel time limits in the subway domain, transfer rules in the bus domain, and query limits in the social security domain.

[0110] The process is described as follows: 1. Parsing Domain Features and Extracting Permissions: The system first parses the domain features of each source code, extracting scenario-specific permissions and domain rules. Through a pre-set parsing module, it reads domain attribute information from the source code, such as station information for the subway code, route information for the bus code, and insurance type for the social security code. Simultaneously, it analyzes the functional and operational requirements of the source code in various scenarios, extracting scenario-specific permissions, such as access permissions and ride record query permissions for the subway code, ride permissions and transfer query permissions for the bus code, and personal information query permissions and payment record query permissions for the social security code. Furthermore, based on the domain's business processes, it extracts general rules, such as ride time limits and scenario access conditions for the subway domain, transfer rules and route selection constraints for the bus domain, and query limits and operation time constraints for the social security domain. 2. Differentiating Between Shared and Exclusive Permissions: The system further distinguishes between permission data that can be shared across scenarios and domain-specific permission configurations. It identifies permission data shared by each source code in multiple scenarios, such as the subway code and bus code sharing the permission to view traffic information in public transportation scenarios. Simultaneously, each source code is configured with domain-specific permissions. For example, the subway code's emergency evacuation permission within a subway station is only enabled in emergency scenarios; the bus code's transfer discount permission within a bus station is only enabled in transfer scenarios; and the social security code has exclusive reimbursement application permissions in specific social security business scenarios (such as medical reimbursement). The system retains independent permission configuration interfaces for each source code within its respective domain, ensuring that it can still independently manage permissions within the integrated system. For example, the subway code's permissions can be independently adjusted through the subway system's internal permission management tool, the bus code's permissions can be independently adjusted through the bus system's internal permission management tool, and the social security code's permissions can be independently adjusted through the social security system's internal permission management tool. 3. Establishing mapping relationships: The system establishes a mapping relationship between domain features and the base layer encrypted base code. Through hash tables or other data structures, the domain features of the source code are associated with the base layer encrypted base code. For example, the station information of the subway code, the route information of the bus code, and the insurance type of the social security code are associated with the encrypted base code.

[0111] Step S2B0: Based on the unified benchmark of the encryption benchmark code, determine the dimensions of the cross-scenario permission matrix, classify and fill the domain features of each source code according to the dimensions to form an initial permission matrix, and call the permission data of the source code through preset association fields without directly storing or modifying the domain rules of the source code.

[0112] The cross-scenario permission matrix is ​​a two-dimensional table where rows represent different source codes and columns represent different scenario permissions. It is used to manage the permissions of source codes in various scenarios. Preset associated fields are pre-defined fields in the matrix used to access the permission data of the source codes; they do not directly store or modify the permission rules of the source codes.

[0113] The process is described as follows: 1. Determine the matrix dimensions: Based on the unified benchmark of the encryption base code, the system determines the dimensions of the cross-scenario permission matrix. The rows of the matrix represent different original codes (such as subway codes, bus codes, and social security codes), and the columns represent permissions under different scenarios (such as access permissions in the subway station scenario, ride permissions in the bus station scenario, and query permissions in the social security center scenario). For example, the subway code has access permissions and ride record query permissions in the subway station scenario; the bus code has ride permissions and transfer query permissions in the bus station scenario; and the social security code has personal information query permissions and payment record query permissions in the social security center scenario. 2. Fill the initial permission matrix: The system fills the initial permission matrix with the domain features of each original code according to the dimensions. Specifically, the access permissions and ride record query permissions of the subway code are filled into the columns corresponding to the subway station scenario; the ride permissions and transfer query permissions of the bus code are filled into the columns corresponding to the bus station scenario; and the personal information query permissions and payment record query permissions of the social security code are filled into the columns corresponding to the social security center scenario. 3. Retrieving Permission Data via Preset Associated Fields: The permission matrix retrieves the permission data of the original code via preset associated fields (such as "Permission ID"), without directly storing or modifying the permission rules of the original code. For example, when the system needs to obtain permissions for a subway code in a subway station scenario, it retrieves the permission data associated with the encrypted base code through the "Permission ID" field.

[0114] Step S2C0: Add a scenario risk coefficient field to the cross-scenario permission matrix. This field is associated with real-time scenario data and the coefficient value is calculated using a preset weighted summation algorithm. The scenario data includes load, security level, and anomaly frequency.

[0115] The following are some of the key features of the system: **Scenario Risk Coefficient Field:** This field quantifies and assesses scenario risk, calculated by integrating multiple scenario data indicators. **Preset Weighted Summation Algorithm:** This algorithm calculates coefficient values ​​by assigning weights to different scenario data indicators and performing a weighted summation. **Load (L):** This reflects system resource usage, such as passenger flow at subway stations, vehicle dispatching frequency at bus stations, and query request volume at the social security center. **Security Level (SG):** This reflects the sensitivity of data, such as the sensitivity of passenger information at subway stations, operational data at bus stations, and user privacy data at the social security center. **Abnormal Frequency (EF):** This counts the number of abnormal operations, such as the number of abnormal passages at subway stations, the number of abnormal transfers at bus stations, and the number of abnormal queries at the social security center.

[0116] The complete process is described below: A scenario risk coefficient field is added to the cross-scenario permission matrix. This field is associated with real-time scenario data and is used to dynamically assess scenario risk. The coefficient value is calculated using a preset weighted summation algorithm, with the following formula:

[0117] ;

[0118] Where SRC is the scenario risk coefficient, L is the load, SG is the security level, and EF is the anomaly frequency. Weight W L W SG W EF Based on the importance of the risk, for example, W L =0.3、W SG =0.5, W EF =0.2.

[0119] In step S2D0, when the coefficient value of the scenario risk coefficient reaches the preset threshold, the matrix automatically adjusts the scope of the permissions for the corresponding scenario and adjusts the security level field of the logical association base layer to achieve cross-layer linkage.

[0120] The scope of permission effectiveness refers to the range in which permissions are effective in different scenarios. This is defined through system configuration files or database tables.

[0121] The complete process is described below: 1. Real-time monitoring and threshold triggering: The system continuously monitors the Scene Risk Coefficient (SRC) through a real-time monitoring module, dynamically calculating it based on a preset weighted summation algorithm. When the SRC reaches or exceeds a preset threshold, the permission adjustment mechanism is automatically triggered. For example, the SRC threshold for the subway station scene is set to 70. Once the real-time SRC value reaches or exceeds this threshold, the system immediately initiates the permission adjustment process. The preset threshold is determined based on historical data and a risk assessment model to ensure timely response within a controllable risk range. 2. Automatic adjustment of permission effective scope: The permission matrix automatically adjusts the effective scope of permissions for the corresponding scene according to preset rules. Specific technical means include: 2.1 Reduction of permission scope: For example, in the subway station scene, when the SRC reaches 70, the system automatically restricts access permissions during off-peak hours, allowing only users with specific permissions (such as staff) to pass; at the same time, it reduces the range of ride records that users can query, retaining only the most recent 3 ride records. 2.2 Adjustment of permission level: The permission level is adjusted according to the scene risk. For example, the permission for certain high-risk operations is adjusted from "allowed" to "restricted" or "prohibited". For example, restricting users from transferring during high-risk periods (such as evening rush hour). 2.3 Dynamic Configuration Updates: Dynamically updating the scope of permissions through system configuration files or database tables ensures that adjusted permissions take effect immediately. For example, the system updates the access permission rules for subway stations through configuration files, restricting access permissions during specific time periods.

[0122] 3. Enhanced Security Through Cross-Layer Collaboration: The system links the adjustment logic with the base layer security level field to achieve cross-layer collaboration. Specific technical measures include: 3.1 Security Level Field Updates: When the base layer security level field is "High," the system automatically increases the strictness of permission adjustments. For example, adding additional verification steps, such as two-factor authentication or biometric authentication. In a subway station scenario, when the security level is "High," the system requires users to pass through fingerprint verification or facial recognition. 3.2 Interface Calls and Data Interaction: Interface calls and data interaction ensure collaborative work between the base layer and the domain layer. For example, when the base layer security level field is updated, an API call is used to notify the domain layer to make corresponding permission adjustments. 3.3 Real-Time Feedback Mechanism: The system uses a real-time feedback mechanism to ensure that adjustments between each layer are synchronized, avoiding delays or inconsistencies in permission management. For example, the system immediately notifies users and relevant terminal devices after adjusting permissions, ensuring the synchronization of permission adjustments.

[0123] The dynamic layer calculates permission values ​​to form a prototype of the fusion code, including:

[0124] Step S2a0: parse the dynamic security level field of the base layer encryption base code and the scenario risk coefficient value of the domain layer cross-scenario permission matrix, extract the real-time risk parameters containing security level weights and scenario risk coefficient proportions, and establish a dynamic calculation model input set that matches the fusion scenario.

[0125] Among them, real-time risk parameters include security level weights and scenario risk coefficient proportions, used to dynamically assess the current risk level. Dynamic calculation model input set is the input dataset used for the dynamic calculation model, containing real-time risk parameters, and is used to match the fusion scenario.

[0126] The process is described as follows: 1. Parsing the Dynamic Security Level Field: The system first parses the dynamic security level field in the encryption base code to extract the current security level weight. For example, the dynamic security level field may contain the values ​​"high," "medium," and "low," corresponding to weights of 0.8, 0.5, and 0.2, respectively. The parsing module reads the encryption base code and extracts the security level weight as part of the real-time risk parameters. 2. Parsing the Scene Risk Coefficient Value: The system then parses the scene risk coefficient value in the cross-scene permission matrix to extract the scene risk coefficient percentage. For example, the risk coefficient value for the subway station scene is 66, the risk coefficient value for the bus station scene is 63, and the risk coefficient value for the social security center scene is 59. The parsing module reads the permission matrix and extracts the risk coefficient percentage for each scene as another part of the real-time risk parameters. 3. Extracting Real-Time Risk Parameters: The system combines the extracted security level weights and scene risk coefficient percentages into real-time risk parameters. For example, the real-time risk parameters for a subway station scenario might be (security level weight 0.8, risk coefficient percentage 66%), for a bus station scenario might be (security level weight 0.5, risk coefficient percentage 63%), and for a social security center scenario might be (security level weight 0.2, risk coefficient percentage 59%). 4. Establishing a dynamic calculation model input set: Based on the real-time risk parameters, the system establishes a dynamic calculation model input set that matches the integrated scenario. For example, for a subway station scenario, the input set might include a security level weight of 0.8 and a risk coefficient percentage of 66%; for a bus station scenario, the input set might include a security level weight of 0.5 and a risk coefficient percentage of 63%.

[0127] Step S2b0: Calculate the permission value based on the input set using a real-time weighted algorithm: The permission value is weighted and summed with the domain layer scenario risk coefficient value according to the preset weight corresponding to the baseline security level, generating a dynamic permission value in the range of 0-1.

[0128] The necessary process is as follows: 1. Input Set Extraction: The system extracts dynamic security level weights from the encryption baseline code and scenario risk coefficient values ​​from the cross-scenario permission matrix to form the input set. 2. Preset Weight Allocation: The system pre-sets weights for the baseline security level and the domain-level scenario risk coefficient values. For example, the baseline weight is 0.6, and the domain-level weight is 0.4. These weights are determined based on the risk assessment model and historical data to ensure the rationality and accuracy of the calculation results. 3. Real-Time Weighted Algorithm Calculation: The system uses a real-time weighted algorithm to sum the baseline security level weights and the domain-level scenario risk coefficient values ​​to generate dynamic permission values. The calculation formula is:

[0129] Dynamic permission value = (w 安全等级 × Security Level Weight) + (w 风险系数 × Risk coefficient value ÷ 100).

[0130] For example, the dynamic permission value for the subway station scene is calculated as 0.6×0.8+0.4×66÷100=0.744, and the dynamic permission value for the bus station scene is calculated as 0.6×0.5+0.4×63÷100=0.552.

[0131] 4. Generate Dynamic Permission Values: The system normalizes the calculation results to the range of 0 to 1, generating the final dynamic permission values. These dynamic permission values ​​will be used for subsequent permission adjustments, ensuring that the system's permission management is flexible and adaptable in different scenarios. For example, the dynamic permission value for a subway station scenario is 0.744, and the dynamic permission value for a bus station scenario is 0.552.

[0132] Step S2c0 involves binding time-limited tags to dynamic permission values, combining the source identifier association relationship of the base layer encryption base code and the effective scope of the domain layer permission matrix to form a prototype of the fusion code containing base association information, dynamic permission values, time-limited tags, and scenario adaptation scope. The generation process of the prototype of the fusion code only calls the data of each layer through the interface, does not store or modify the original code data and encryption system, and maintains an independent interface with the original code.

[0133] Among them, the validity period label is used to identify the validity period of dynamic permission values, ensuring that permissions are valid for a specific time. It is obtained by generating the label through the system clock and preset validity period rules. The baseline association information is the source identifier association relationship in the encrypted baseline code, used to trace back to the original code.

[0134] The specific process is as follows:

[0135] 1. Bind timeliness tags and extract benchmark information:

[0136] The system first binds expiration tags to dynamic permission values ​​to ensure that permissions are valid for a specific period. These expiration tags are generated based on the system clock and preset validity rules. For example, the expiration tag for a dynamic permission value of 0.744 might be "2025-11-07T14:00:00Z / 2025-11-07T15:00:00Z", indicating that the permission value is valid between 14:00 and 15:00. Simultaneously, the system extracts baseline association information from the encrypted baseline code, including source identifier associations, for reverse tracing of the original code. For example, the encrypted baseline code of a subway code contains a hash value pointing to the original subway code; by parsing this hash value, the system can quickly locate the original subway code.

[0137] 2. Determining the Scene Adaptation Scope and Generating a Prototype Fusion Code: The system extracts the scene adaptation scope from the domain-level permission matrix to determine the scenes to which dynamic permission values ​​apply. For example, the dynamic permission value of 0.744 for the subway station scene only applies to access permissions within the subway station, and the dynamic permission value of 0.552 for the bus station scene only applies to transfer query permissions within the bus station. Subsequently, the system combines the baseline association information, dynamic permission values, time-sensitive tags, and scene adaptation scope to form a prototype of the fusion code.

[0138] For example, a prototype fusion code for a subway station scenario might include the following information: 2.1 Baseline association information: The hash value points to the original subway code. 2.2 Dynamic permission value: 0.744; 2.3 Time expiration tag: 2025-11-07T14:00:00Z / 2025-11-07T15:00:00Z; 2.4 Scenario adaptation scope: Access permissions within the subway station.

[0139] In step S2d0, after the prototype of the fusion code is generated, it is temporarily stored in the dynamic cache area. When the security level of the baseline layer or the scenario risk coefficient value of the domain layer changes, the dynamic layer recalculates and updates the permission value and time expiration label of the prototype in real time to achieve cross-layer linkage.

[0140] The specific process is as follows: 1. Temporarily storing the prototype fusion code: After the prototype fusion code is generated, the system temporarily stores it in a dynamic cache. The dynamic cache is implemented using an in-memory database (such as Redis), supporting fast read / write and real-time updates. For example, the prototype fusion code for a subway station scenario includes baseline association information (hash value pointing to the original subway code), dynamic permission value (0.744), time-limited label, and scenario adaptation range (access permission within the subway station). This prototype is temporarily stored in the dynamic cache. 2. Monitoring change events: The system monitors changes in the baseline layer security level and the domain layer scenario risk coefficient value in real time through an event listening mechanism. When the baseline layer security level field is updated from "medium" to "high", or the domain layer scenario risk coefficient value is updated from 66 to 70, the system triggers an update event, notifying the dynamic layer to recalculate and update. 3. Real-time recalculation by the dynamic layer: After receiving the update event, the dynamic layer recalculates the permission value and time-limited label of the prototype fusion code in real time. The recalculation process uses a real-time weighted algorithm, combining the latest baseline layer security level weight and the domain layer scenario risk coefficient value to generate a new dynamic permission value. 4. Update the Fusion Code Prototype: The dynamic layer updates the recalculated permission values ​​and expiration tags to the fusion code prototype in the dynamic cache, achieving cross-layer linkage. The update process only calls data from each layer through the interface, without storing or modifying the original code data or encryption system. After the update is completed, the system notifies relevant terminal devices through a message queue to ensure that all associated terminals obtain the latest fusion code prototype. 5. Cross-Layer Linkage Implementation: Cross-layer linkage is achieved through interface calls and data interaction. When the security level of the baseline layer or the scenario risk coefficient value of the domain layer changes, the dynamic layer obtains the latest data through API calls, recalculates the permission values ​​and expiration tags, and updates the fusion code prototype.

[0141] The three-layer characteristics of cross-layer hash chain association fusion codes include:

[0142] Step 1: Calculate the first feature hash of the base layer encryption base code, the second feature hash of the domain layer cross-scenario permission matrix, and the third feature hash of the dynamic layer dynamic permission value and time-limited label.

[0143] Specifically, the first feature hash is a fixed-length digest value obtained by cryptographically hashing the base layer encryption base code, used to uniquely identify and verify the integrity of the base layer data. The system uses the SHA-256 hash algorithm to calculate the complete byte sequence of the encryption base code, generating a 256-bit hash value. The specific processing steps are as follows: first, the complete ciphertext data of the encryption base code (including the source identifier association and dynamic security level field) is extracted; then, this data is serialized byte-wise; and finally, the first feature hash value is generated using the SHA-256 algorithm. This hash value serves as the root node of the subsequent Merkle tree structure, ensuring that any tampering with the encryption base code will be detected immediately.

[0144] The second feature hash is a digest value obtained by hashing the cross-scenario permission matrix at the domain layer, used to verify the integrity and consistency of the permission matrix. The system uses the SHA-256 algorithm to calculate the serialized data of the permission matrix. The serialized content includes the matrix's row identifiers (raw code type), column identifiers (scenario permissions), associated field values, and scenario risk coefficient fields. The specific processing is as follows: the structured permission data of the permission matrix (such as the access permission of a subway code in a subway station scenario, the permission to query travel records, etc.) is converted into a binary sequence, and then the second feature hash value is generated by the SHA-256 algorithm. This hash value serves as the first-level child node of a Merkle tree, ensuring that any changes to the permission matrix can be tracked and verified.

[0145] The third feature hash is a digest value obtained by combining the dynamic permission value and the expiration tag of the dynamic layer through a hash operation. It is used to ensure the integrity and timeliness of dynamic permission data. The system uses the SHA-256 algorithm to concatenate the dynamic permission value (floating-point encoding), the expiration tag (timestamp string), and the scene adaptation range identifier before calculating the hash value. The specific processing is as follows: first, the dynamic permission value, the expiration tag, and the scene adaptation range identifier are encoded into a byte stream and concatenated; then, the third feature hash value is generated using the SHA-256 algorithm. This hash value serves as the second-level child node of the Merkle tree, ensuring that any real-time updates to dynamic permissions can be accurately captured and verified.

[0146] Step 2: Using the first feature hash as the root node and the second and third feature hashes as child nodes, construct a three-layer Merkle tree structure cross-layer hash chain, and associate the three features into a whole through cryptographic hash association.

[0147] 1. Merkle Tree Structure Design: The system employs a three-layer Merkle Tree structure to construct cross-layer hash chains. This tree structure uses the first feature hash (base layer) as the root node, and the second feature hash (neighborhood layer) and the third feature hash (dynamic layer) as two child nodes, forming a root-child hierarchical relationship. This design ensures that the base layer serves as a trust anchor, the neighborhood layer and the dynamic layer serve as verifiable derived data, and the three features are unidirectionally linked through cryptographic hashes. Any tampering with any single layer will result in a change in the root node's hash value, thus being detected immediately.

[0148] 2. Cryptographic hash association method:

[0149] Cross-level hash associations employ a bottom-up hash construction method: child nodes (second and third feature hashes) are directly calculated from the original data of their respective levels and serve as leaf nodes; the root node hash value is generated by concatenating the hash values ​​of the two child nodes and then hashing them again, using the following formula:

[0150] .

[0151] in, This indicates a byte string concatenation operation. To ensure that the root node is consistent with the first feature hash, the system verifies that RootHash = FirstHash. If the verification fails, it indicates that the three layers of data are inconsistent, triggering a security alert.

[0152] 3. Integrity Guarantee and Dynamic Updates: The constructed Merkle tree forms a cross-layer hash chain. Its integrity is guaranteed by the one-wayness and collision resistance of the SHA-256 hash function. Any modification to the base layer, domain layer, or dynamic layer data will cause the corresponding hash value to change, thus affecting the root node hash, making tampering immediately detectable. During verification, only the hash value of the modified layer and the hash of the upper-level path need to be recalculated, without traversing all the data, significantly improving verification efficiency.

[0153] When any layer of data is updated, the system only needs to recalculate the hash of that layer and the hash of the root node, generate a new state anchor (RootHash), and link the new anchor with the historical anchor through the hash pointer to form a hash chain that can be traced back to the initial state, realizing the dynamic association and complete change tracing of the three layers of features.

[0154] Step 3: In response to an update event of any of the following: encryption base code, cross-scenario permission matrix, dynamic permission value, or time-limited tag, automatically re-execute steps 1 and 2 to generate a new state anchor, which is the root hash value of the current Merkle tree; and cryptographically link the new state anchor with the historical state anchor before the update through a hash pointer, thereby realizing the dynamic association of the three-layer features and complete change traceability.

[0155] The structure includes: **State Anchor:** The current Merkle root hash value, representing a cryptographic snapshot of the three-layer features at a specific moment. It is obtained by recalculating the Merkle root hash. **Hash Pointer:** A linking mechanism that associates the new state anchor with historical state anchors using a cryptographic hash function. It is obtained by combining the historical anchor hash value as input with the hash of the new anchor. **Change Tracking:** The ability to fully trace historical states through the hash pointer chain. It is obtained by traversing the hash pointer chain and verifying the integrity of each anchor.

[0156] The specific process is as follows: 1. Update Event Listening and Automatic Triggering: The system monitors changes to the encryption base code, cross-scenario permission matrix, dynamic permission values, or time-limited tags in real time through an event-driven architecture. When any data layer is updated (e.g., the security level changes from "medium" to "high," or the risk coefficient increases from 66 to 70), the event listener immediately captures the change and triggers the automatic recalculation process, requiring no manual intervention and ensuring immediate response to changes in the three layers of data. 2. Automatic Recalculation and Merkle Tree Reconstruction: After triggering the update, the system automatically re-executes steps 1 and 2: only recalculating the feature hash of the changed layer, and reconstructing the three-layer Merkle tree with the new feature hash as child nodes. The system verifies whether the new root hash is equal to the recalculated first feature hash, ensuring consistency of the three layers of data. This process uses an incremental calculation method, processing only the changed data, significantly improving computational efficiency. 3. State Anchor Generation and Hash Pointer Linking: The reconstructed Merkle tree generates a new root hash value, which serves as the state anchor at the current moment. The system cryptographically links the new anchor with the historical state anchor through hash pointers.

[0157] Dynamic Association and Complete Change Tracking: Through continuous state anchor linking, the system constructs a complete hash chain from the initial state to the current state, achieving dynamic association and complete change tracking of the three-layer features. All anchors are stored in an immutable log system or blockchain structure, allowing the system to trace back to the state of the three-layer features at any historical moment by traversing the hash pointer chain. A lightweight client verification mechanism allows terminals to complete partial verification by downloading only the latest anchor and its direct predecessor anchor, without traversing the entire chain, significantly improving verification efficiency and providing the system with complete audit trail capabilities and non-repudiation.

[0158] First, verify the matching between the scene and the features of each layer, then check the integrity of the entire chain, including:

[0159] Step S410: parse the current scene information and sequentially call the scene adaptation range and timeliness tags of the dynamic layer fusion code prototype, the authorized scene set of the domain layer cross-scene permission matrix, and the dynamic security level field of the base layer encrypted base code to establish a scene matching verification input set.

[0160] Specifically, the process is as follows: 1. Parse current scene information: The system parses the current scene using the location information, timestamp, and scene identifier reported by the terminal device. For example, in a subway station scene, the terminal obtains the station ID (e.g., "Station_A") and the current timestamp via NFC or QR code scanning, and the system parses it into a scene label of "Subway Station_Station_A_Peak Hour". In a bus scene, the system parses the scene information of "Bus Station_Route_101_Off-Peak Hour" using GPS positioning. The parsed scene information is stored in a structured data format (e.g., JSON), containing three core fields: scene type, location identifier, and time window. 2. Call dynamic layer fusion code prototype data: The system sequentially calls the scene adaptation range and time stamp labels of the fusion code prototype in the dynamic cache. The system obtains the fusion code prototype data corresponding to the current scene through the API interface and verifies whether the scene adaptation range includes the current scene identifier. For example, in the fusion code prototype of the subway station scene, the scene adaptation range field is ["Subway Station_Station_A", "Subway Station_Station_B"]. The system checks whether the current scene "Subway Station_Station_A" is in the list. Simultaneously, the system reads the time range of the validity tag, such as "2025-11-07T14:00:00Z / 2025-11-07T15:00:00Z", and compares it with the current timestamp to ensure that the permissions are within the validity period. If the scenario does not match or has expired, the verification is directly judged as a failure, and no further steps are required. 3. Calling domain layer and base layer data: The system calls the authorization scenario set of the cross-scenario permission matrix of the domain layer to obtain the permission configuration of the current source code in all authorization scenarios. For example, for the subway code, the authorization scenario set includes "Subway Station_Station_A access permission", "Subway Station_Station_B access permission", etc. The system obtains these authorization scenarios through the matrix query interface and performs an intersection operation with the current scenario to ensure that the current scenario is within the authorization range. At the same time, the system calls the dynamic security level field of the base layer encrypted base code to obtain the current security level (such as "high", "medium", "low") and its corresponding weight value. For example, when the security level is "high", the weight is 0.8, providing basic parameters for subsequent permission calculations.

[0161] Constructing the Scene Matching Verification Input Set: The system integrates the data obtained from the above calls into a scene matching verification input set, organized in a standardized JSON format. The input set contains four core parts: current scene information (scene type, location, time window), dynamic layer verification results (scene adaptation range matching flag, timeliness validity flag), domain layer authorized scene list, and baseline layer security level weight.

[0162] Step S420: Perform scenario matching verification based on the input set: First, verify whether the current scenario meets the dynamic layer scenario adaptation scope and timeliness requirements; then, verify whether the current scenario is included in the domain layer authorized scenario set; finally, verify whether the current scenario meets the minimum requirements of the baseline layer dynamic security level field. If all verifications pass, trigger the full-chain integrity verification.

[0163] The process is as follows:

[0164] 1. Dynamic Layer Verification: The system first verifies whether the current scene meets the scene adaptation range and timeliness requirements of the dynamic layer fusion code prototype. The specific process is as follows: The system obtains the current scene identifier (e.g., "Station_A" in the input set) and performs an exact match with the scene adaptation range list in the fusion code prototype. A string matching algorithm is used to verify whether the current scene exists in the authorized scene list. Simultaneously, the system parses the time window of the timeliness tag and verifies whether the current time is within the validity period using a timestamp comparison algorithm. For example, the timeliness tag for the subway scene is "2025-11-07T14:00:00Z / 2025-11-07T15:00:00Z". The system obtains the current timestamp and compares it with this window. If the current time is within the window and the scene match is successful, the dynamic layer verification passes. If any condition is not met, the system immediately terminates the verification and returns a failure result.

[0165] 2. Domain Layer Verification: After the dynamic layer verification passes, the system performs domain layer verification to check whether the current scene is included in the domain layer authorized scene set. The specific process is as follows: The system extracts the current scene information (scene type, location identifier) ​​from the input set and performs set operation with the authorized scene set of the domain layer cross-scene permission matrix. A hash set lookup algorithm is used, with the current scene identifier as the key value, to search for a matching item in the hash table of the authorized scene set. For example, for the subway code, the authorized scene set contains entries such as "Subway Station_Station_A access permission" and "Subway Station_Station_B access permission". The system checks whether the current scene "Subway Station_Station_A" exists in the set. If it exists, the domain layer verification passes; otherwise, the verification fails. This process achieves a fast lookup with O(1) time complexity through a pre-built hash index, ensuring verification efficiency.

[0166] 3. Baseline Verification: After the domain-level verification passes, the system performs baseline verification to check whether the current scenario meets the minimum requirements of the baseline dynamic security level field. The specific process is as follows: The system obtains the security level weight of the current scenario from the input set (e.g., 0.8) and compares it with the preset minimum security level threshold of the baseline layer. A weight comparison algorithm is used; if the current security level weight is greater than or equal to the threshold, the verification passes. For example, the dynamic security level of the subway station scenario is high, corresponding to a weight of 0.8. The system's preset minimum requirement is 0.6, so 0.8 ≥ 0.6, and the verification passes. If the current security level weight is lower than the threshold, the system determines it as a high-risk scenario, and the verification fails. This verification ensures that only scenarios that meet the security baseline can continue with subsequent operations.

[0167] Step S430: Perform full-chain integrity verification: Verify the correct correlation of feature hash values ​​of each layer through the Merkle tree structure of the cross-layer hash chain, that is, verify that the feature hash value of the base layer can be correctly calculated from the feature hash values ​​of the domain layer and the dynamic layer; and verify the continuity and integrity of the update history of the state anchor point through the dynamic hash anchor chain; if the above verification is successful, the two-way verification is determined to be successful and the subsequent process is entered; otherwise, the verification is determined to be unsuccessful and a security response is triggered.

[0168] The specific process is as follows: 1. Merkle Tree Structure Verification: The system verifies the Merkle tree structure of the cross-layer hash chain to ensure that the feature hash values ​​of the base layer can be correctly calculated from the feature hash values ​​of the domain layer and the dynamic layer. Specifically, the system concatenates the second and third feature hash values ​​and calculates the intermediate hash value using the SHA-256 algorithm, then compares it with the first feature hash. If they are equal, it indicates that the three layers of data maintain cryptographic consistency and have not been tampered with; if they are not equal, the verification fails and a security response is triggered. 2. Dynamic Hash Anchor Chain Verification: The system verifies the continuity and integrity of the dynamic hash anchor chain. The system obtains the latest state anchor and its pointed-to historical state anchor hash pointers from the storage module, recalculates the hash pointer using the SHA-256 algorithm, and verifies whether it matches the stored value. The system verifies the hash pointer of each state anchor layer by layer to ensure that the entire chain from the initial anchor to the current anchor is continuous and has not been tampered with. If any link is broken or the hash does not match, the verification fails. 3. Two-way verification and security response: If both Merkle tree structure verification and dynamic hash anchor chain verification pass, the system determines that the two-way verification is successful, generates a verification pass token, and allows entry into subsequent processes. If either verification fails, the system determines that the two-way verification has failed and immediately triggers a tiered security response mechanism: For single-layer data tampering, the system locks the fusion code and records the tampering log; for chain breakage, the system restores historical anchors from trusted backups and notifies the administrator; for comprehensive anomalies, the system switches to the highest security level and initiates the emergency response process.

[0169] If an offline scene is detected, an offline code with time decay is generated based on dynamic features, including:

[0170] Step S510: In response to the detection of a network offline event, the offline code generation process is triggered.

[0171] The specific process is described as follows: 1. Real-time network status monitoring: The system continuously monitors the network connection status through the network status monitoring module of the terminal device, adopting a dual composite strategy of heartbeat packet detection and network interface status monitoring. When three consecutive heartbeat timeouts (5 seconds each) or the packet loss rate exceeds 30%, it is determined to be a network anomaly. For example, in a subway station scenario, when a passenger's mobile phone signal drops from 4G to 2G and cannot establish a connection with the ticketing server for 10 seconds, the monitoring module immediately reports a network offline event. 2. Offline event judgment and triggering: After detecting an offline event, the system verifies whether the duration of the offline state exceeds the preset threshold (5 seconds) and checks whether there is valid fusion code prototype data in the local cache (cache validity period ≥ 30 minutes). If the conditions are met, an offline event token containing a timestamp, device ID, and the last online fusion code digest is generated and pushed to the offline processing queue through an event-driven architecture to trigger the offline code generation process. 3. Offline code generation process start: When the process starts, the system locks the current fusion code prototype data and reads the latest dynamic permission values, time-limited tags, and necessary metadata from the local persistent storage. The entire startup process is implemented through an asynchronous message mechanism, with a response time controlled within 200 milliseconds to ensure that the user's main operation thread is not blocked. For example, in a social security scenario, after the community service terminal goes offline, it reads the latest prototype of the social security fusion code from the local SQLite to prepare the data required to generate the offline social security code.

[0172] Step S520: Based on the preset neighboring scene mapping relationship based on scene association dimension, locate at least one neighboring scene associated with the current online scene from the domain layer permission matrix, and extract its corresponding preset permission subset; wherein, the scene association dimension includes scene type similarity, geographical proximity or risk level matching.

[0173] The specific process is as follows:

[0174] The system pre-constructs a mapping relationship between neighboring scenes, storing it in the domain layer permission matrix using a graph data structure. Each scene is a node, and the association dimension is a weighted edge. The association dimension includes scene type similarity (calculated using the Jaccard similarity coefficient, such as the similarity weight of the intersection of subway station and bus station codes "PT" being 0.7), geographical proximity (matched using the GeoHash algorithm, with adjacent stations having the same 12-bit prefix, resulting in a weight of 0.8), and risk level matching (weight of 0.6 when the level difference is ≤1). The system calculates a comprehensive association score using the Dijkstra algorithm and includes scenes with scores exceeding the threshold (0.5) in the neighbor set. When an offline event is detected, the neighbor scene localization engine locates the current scene mapping relationship in O(1) time using a hash index and filters the neighbor scene list based on the maximum number of neighboring scenes (3) and the minimum association score threshold (0.5).

[0175] For each nearby scene location, the system quickly extracts a preset subset of permissions using the CSR sparse matrix compression format of the permission matrix. The permission matrix is ​​stored in compressed format with row indices as raw code type and column indices as scene permissions. The system locates the column vectors based on the nearby scene identifiers and generates the minimum permission set by filtering valid permission bits through bitwise operations.

[0176] For example, when subway station "Station_A" goes offline, it locates the neighboring scene "Station_B", extracts the column vector to obtain ["BASIC_ACCESS", "EMERGENCY_PASS"], and uses a permission mask to remove high-risk permissions such as "ADMIN_OPERATE" to ensure that the offline code only contains basic necessary permissions. The extraction process uses an asynchronous message mechanism, and the response time is controlled within 100 milliseconds.

[0177] The extracted permission subsets undergo multi-level security checks: redundant permissions are automatically eliminated through the permission dependency graph to ensure the principle of minimization; the validity period of the verified subset is linked to the dynamic layer's expiration tag, forcibly restricting it to within the dynamic layer's time window; an HMAC-SHA256 signature is generated for each subset, with the key dynamically generated based on the device's hardware fingerprint and the current timestamp, ensuring that the subset is used only on a specific device. For example, in an offline scenario at a bus stop, the permission subset signature includes the device ID and GeoHash location information. If the offline code is transferred to another device or geographical location, the signature verification fails, causing the offline code to automatically expire, preventing malicious copying and cross-device abuse.

[0178] Step S530: Based on the latest dynamic permission value and time-limited tag of the dynamic layer, and combined with the extracted preset permission subset, an initial offline code is generated; the initial offline code is associated with the fusion code through a lightweight symmetric encryption algorithm, and its effective scenario is strictly limited to the nearby scene of the location.

[0179] The specific process is as follows:

[0180] 1. Initial offline code generation: The system generates an initial offline code based on the latest dynamic permission values, expiration tags, and the preset permission subset extracted in step S520 of the dynamic layer.

[0181] The generation process employs structured data encoding, integrating dynamic permission values ​​(e.g., 0.744), time-sensitive tags (e.g., "2025-11-07T14:00:00Z / 2025-11-07T15:00:00Z"), permission subsets (e.g., ["BASIC_ACCESS", "EMERGENCY_PASS"]), and proximity scene identifiers (e.g., "Station_B") into a JSON-formatted data packet. The system then performs DER encoding on this data packet, converting it into a binary sequence, and encrypts it using the SM4 lightweight symmetric encryption algorithm. The key is derived from the baseline association information of the fusion code, ensuring that the offline code is bound to a specific fusion code.

[0182] 2. Cryptographic Association with the Fusion Code: The initial offline code establishes a strong association with the fusion code through an HMAC-SM3 message authentication code. The system uses the base layer feature hash of the fusion code as the HMAC key to sign the ciphertext of the offline code, generating an associated verification code. This verification code is embedded in the offline code header, ensuring that the offline code cannot be stripped and used independently. For example, when generating a subway station offline code, the system uses the encryption base code hash of the subway code as the key to calculate the HMAC-SM3 value of the offline code ciphertext, and uses this value as the first 16 bytes of the offline code, achieving a cryptographic binding with the original fusion code.

[0183] 3. Scene Restriction and Anti-Abuse Mechanism: The effective scenes for offline codes are strictly limited to nearby scenes through geofencing and scene whitelisting mechanisms. The system writes the GeoHash code of the nearby scene (e.g., the GeoHash prefix "wx4g0" for "Station_B") and the scene identifier into the permission metadata area of ​​the offline code. When verifying the offline code, the terminal device must first check whether the current GPS location or NFC station identifier matches the metadata area. If they do not match, the offline code automatically becomes invalid. For example, an offline code generated for "Station_A" can only be used for "Station_B" and "Station_C" (nearby stations). When a user attempts to use the code at "Station_D" (a non-nearby station), the terminal determines that the GeoHash match has failed, indicating unauthorized use, immediately refuses access, and reports the abnormal event.

[0184] Step S540 involves embedding a time decay factor into the initial offline code to reduce its permission validity according to a preset decay rule. The decay rule is linked to the time-limited tag mechanism of the dynamic layer, and the decay rate is dynamically adjusted in relation to the dynamic security level field of the base layer.

[0185] The specific process is as follows: 1. Embedding mechanism of time decay factor: The system embeds a time decay factor into the initial offline code, using an exponential decay function to dynamically reduce the validity of permissions. The decay factor is embedded as a metadata field into the offline code, with an initial value of 1.0, and is linked to the dynamic layer time-limited tag. The system calculates the maximum valid duration of the time-limited tag and divides it into decay intervals (e.g., one interval every 600 seconds), and calculates the decay factor value of each interval through a discretized exponential decay model. For example, in the subway station scenario, the decay factor of the offline code is multiplied by 0.9 every 10 minutes, and drops to 0.53 after 60 minutes, reducing the permission validity to 53%.

[0186] 2. Dynamic Correlation between Attenuation Rate and Security Level: The attenuation rate is correlated with the dynamic security level field of the baseline layer; the higher the security level, the more aggressive the attenuation. The system has a preset mapping table: the attenuation base is 0.85 for high security levels, 0.9 for medium security levels, and 0.95 for low security levels. The current security level is read and applied to the attenuation function during offline code generation. Where λ represents the attenuation factor, b represents the attenuation base, t represents the elapsed time, and Δt represents the attenuation interval. This indicates rounding down to the nearest integer.

[0187] For example, when the security level of a subway station is high, the decay factor is multiplied by 0.85 every 600 seconds to accelerate the expiration of permissions and reduce the risk of abuse in high-risk scenarios.

[0188] 3. Implementation of the linkage between attenuation rules and permission validity:

[0189] The attenuation rule is deeply linked to the dynamic layer's validity label. During verification, the terminal device calculates the attenuation factor and permission validity in real time: Current permission validity = Initial permission value × Attenuation factor. If the current permission validity is lower than a preset threshold (e.g., 0.5), the system determines the offline code is invalid. For example, the initial permission value of a subway station offline code is 0.744. After 30 minutes, the attenuation factor is 0.85³ = 0.614, and the current validity is 0.744 × 0.614 = 0.457. Since this is lower than the threshold, service is denied.

[0190] 4. Anti-tampering and auditing mechanism: The attenuation factor is protected by HMAC-SM3 signature. The key is dynamically generated based on the device hardware fingerprint and timestamp, and updated every 600 seconds. During terminal verification, the HMAC is recalculated and compared with the stored value. If they do not match, it is determined that the code has been tampered with and the offline code is invalidated. The system records the attenuation factor change log, including the timestamp, attenuation factor value, and security level, for auditing and anomaly detection. For example, if an abnormal change in the factor is detected during the attenuation of the offline code at a bus stop, the system will immediately trigger a security alarm.

[0191] Step S550: When the network connection is restored, the offline code automatically becomes invalid, and the fusion code recovery process is executed: First, the feature integrity of the fusion code during the offline period is verified through a cross-layer hash chain; after verification, the transaction records generated during the offline period are synchronized to the behavior credit chain, and the recalculation of the fusion code credit entropy and the update of the permission parameters are triggered.

[0192] In step S550, the key technical operation during network recovery first focuses on the immediate invalidation mechanism of the offline code. This process involves an internal monitoring service that continuously monitors the network status. Once network connectivity is detected to have been restored, the monitoring service triggers an internal signal, which is transmitted to the access control module via the system's message queue. Upon receiving the signal, the access control module immediately marks the offline code as invalid and broadcasts this change to all relevant service nodes via an encrypted protocol, ensuring that the offline code cannot be used further after network recovery.

[0193] Subsequently, the system utilizes cross-layer hash chaining technology to verify the integrity of the merge code. Cross-layer hash chaining is a technique that links data from different system layers using hash functions, ensuring data integrity and consistency during transmission. During offline periods, every change to the merge code is hashed and added to the chain. When the network recovers, the system recalculates the hash value and compares it with the value in the chain to verify whether the merge code was tampered with during the offline period.

[0194] Finally, the system synchronizes the transaction records from the offline period to the Behavioral Credit Chain. The Behavioral Credit Chain is a credit recording system built on blockchain technology, providing a decentralized and tamper-proof credit record storage solution. Transaction record synchronization involves data serialization, encryption, and on-chain operations. During this process, the system uses smart contracts to automatically recalculate credit entropy and update permission parameters.

[0195] Based on the same inventive concept, embodiments of the present invention provide a multi-code fusion system, including a memory and a processor, wherein the memory stores information that can run on the processor to implement, as described above. Figures 1 to 2 The procedure for any method.

[0196] The above are all preferred embodiments of this application and are not intended to limit the scope of protection of this application. Any feature disclosed in this specification (including the abstract and drawings) may be replaced by other equivalent or similar features unless specifically stated otherwise. That is, unless specifically stated otherwise, each feature is only one example of a series of equivalent or similar features.

Claims

1. A multi-code fusion method, characterized in that, include: Launch a multi-code fusion system, analyze the heterogeneous features of each original code, classify them according to benchmark, domain, and dynamic features, match and generate a standardized feature set with verifiable cryptographic source identifiers, and retain the independent functional interfaces of the original code; Based on a standardized feature set, layered fusion is performed without overwriting the original code data: the baseline layer generates an encrypted baseline code associated with the original code identifier, the domain layer constructs a cross-scenario permission matrix, and the dynamic layer calculates permission values ​​to form a prototype of the fusion code. Simultaneously generate a behavioral credit chain bound to the prototype of the fusion code; After verifying the prototype of the fusion code and the behavioral credit chain, a formal fusion code is generated. Based on the initial state of the behavioral credit chain and the preset risk rule set, the initial dynamic credit entropy of the fusion code is calculated, and the parallel calling interface of the fusion code and the original code is maintained. By associating the three features of the fusion code through a cross-layer hash chain, the terminal executes a two-way verification protocol during verification: first, it verifies the matching between the scenario and the features of each layer, and then verifies the integrity of the entire chain; subsequently, the terminal announces the scenario requirements and minimum credit entropy requirements to the fusion code, and the fusion code generates a minimum one-time transaction certificate corresponding to the scenario requirements based on the current credit entropy. If the verification passes, the fusion code is enabled to achieve cross-scenario functionality, the transaction is recorded to the behavior credit chain, the credit entropy is recalculated, and the permission parameters of the fusion code are dynamically adjusted based on the recalculated credit entropy; if an offline scenario is detected, an offline code with time decay is generated based on dynamic features. If the verification fails, a hierarchical security response mechanism is triggered based on the source code identifier associated with the baseline layer: First, a security sub-credential is generated based on the permission matrix of the domain layer, following preset failure conditions and functional scope; if the security sub-credential is invalid or fails to be generated, the corresponding source code is switched to run independently.

2. The multi-code fusion method according to claim 1, characterized in that, The encrypted base code that generates the associated source code identifier at the base layer includes: The baseline features of each source code are analyzed, unique identifiers and core attributes are extracted, and heterogeneous identifiers are converted into a source identifier set in a unified format through a feature mapping algorithm to establish a baseline association index between source codes. The source identifier set is encrypted using a preset encryption algorithm to generate a unique encryption base code. The encryption process is implemented in an outer encryption wrapping mode. It only establishes an association with the original code through the interface layer, without intruding on its basic data and the original encryption system. At the same time, it embeds the reversible association relationship of the source identifier of the original code, so that the base code can trace back to the associated original code and ensure the normal operation of the independent function of the original code. A dynamic security level field is set in the encryption baseline code. This field calculates the risk value in real time and automatically matches the security level based on a cross-domain risk assessment model that integrates data security, scenario load, and abnormal behavior. Updates to the security level field are synchronized to all associated terminals via an end-to-end encrypted tunnel, ensuring dynamic consistency of the security baseline across the entire link.

3. The multi-code fusion method according to claim 2, characterized in that, The domain layer constructs a cross-scenario permission matrix, including: The domain characteristics of each source code are analyzed, scene-specific permissions and domain rules are extracted, permission data that can be shared across scenarios is distinguished from domain-specific permission configurations, a mapping relationship between domain characteristics and base layer encryption base code is established, and independent permission configuration interfaces for each source code are reserved for its respective domain. Scene-specific permissions include function access scope and operation permission level, while domain rules include scene access conditions and interaction constraints. Based on a unified benchmark of the encryption benchmark code, the dimensions of the cross-scenario permission matrix are determined. The domain features of each source code are classified and filled according to the dimensions to form an initial permission matrix. The matrix calls the permission data of the source code through preset associated fields, without directly storing or modifying the domain rules of the source code. A scenario risk coefficient field is added to the cross-scenario permission matrix. This field is associated with real-time scenario data and the coefficient value is calculated by a preset weighted summation algorithm. The scenario data includes load, security level, and anomaly frequency. When the risk coefficient of a scenario reaches a preset threshold, the matrix automatically adjusts the scope of permissions for the corresponding scenario and adjusts the security level field of the logical association base layer to achieve cross-layer linkage.

4. The multi-code fusion method according to claim 3, characterized in that, The dynamic layer calculates permission values ​​to form a prototype of the fusion code, including: The dynamic security level field of the base layer encryption base code and the scenario risk coefficient value of the domain layer cross-scenario permission matrix are analyzed. Real-time risk parameters containing security level weights and scenario risk coefficient proportions are extracted to establish a dynamic calculation model input set that matches the fusion scenario. The permission value is calculated using a real-time weighted algorithm based on the input set: the preset weight corresponding to the security level of the baseline layer is used to perform a weighted sum with the scenario risk coefficient value of the domain layer to generate a dynamic permission value in the range of 0-1. By binding time-limited tags to dynamic permission values ​​and combining the source identifier association relationship of the base layer encrypted base code and the effective scope of the domain layer permission matrix, a prototype of the fusion code is formed, which includes base association information, dynamic permission values, time-limited tags, and scenario adaptation scope. The generation process of the prototype of the fusion code only calls the data of each layer through the interface, does not store or modify the original code data and encryption system, and maintains an independent interface with the original code. After the prototype of the fusion code is generated, it is temporarily stored in the dynamic cache area. When the security level of the baseline layer or the scenario risk coefficient value of the domain layer changes, the dynamic layer recalculates and updates the permission value and time expiration label of the prototype in real time to achieve cross-layer linkage.

5. The multi-code fusion method according to claim 4, characterized in that, The three-layer features of the fusion code associated through cross-layer hash chains include: Step 1: Calculate the first feature hash of the base layer encryption base code, the second feature hash of the domain layer cross-scenario permission matrix, and the third feature hash of the dynamic layer dynamic permission value and time-limited tag, respectively. Step 2: Using the first feature hash as the root node and the second and third feature hashes as child nodes, construct a three-layer Merkle tree structure cross-layer hash chain, and associate the three features into a whole through cryptographic hash association. Step 3: In response to an update event of any of the following: encryption base code, cross-scenario permission matrix, dynamic permission value, or time-limited tag, automatically re-execute steps 1 and 2 to generate a new state anchor, which is the root hash value of the current Merkle tree; and cryptographically link the new state anchor with the historical state anchor before the update through a hash pointer, thereby realizing the dynamic association of the three-layer features and complete change traceability.

6. The multi-code fusion method according to claim 5, characterized in that, First, verify the matching between the scene and the features of each layer, then check the integrity of the entire chain, including: The current scene information is parsed, and the scene adaptation range and timeliness tags of the dynamic layer fusion code prototype, the authorized scene set of the domain layer cross-scene permission matrix, and the dynamic security level field of the base layer encrypted base code are called in sequence to establish the scene matching verification input set. Scenario matching verification is performed based on the input set: First, it is verified whether the current scenario meets the dynamic layer scenario adaptation range and timeliness requirements; then, it is verified whether the current scenario is included in the domain layer authorized scenario set; finally, it is verified whether the current scenario meets the minimum requirements of the baseline layer dynamic security level field; if all verifications pass, the full-chain integrity verification is triggered. Perform full-chain integrity verification: Verify the correct correlation of feature hash values ​​of each layer through the Merkle tree structure of the cross-layer hash chain, that is, verify that the feature hash value of the base layer can be correctly calculated from the feature hash values ​​of the domain layer and the dynamic layer; and verify the continuity and integrity of the update history of the state anchor point through the dynamic hash anchor chain; if the above verification passes, the two-way verification is determined to be successful and the subsequent process is entered; otherwise, the verification is determined to be unsuccessful and a security response is triggered.

7. The multi-code fusion method according to claim 6, characterized in that, If an offline scene is detected, an offline code with time decay is generated based on dynamic features, including: In response to the detection of a network offline event, the offline code generation process is triggered; Based on the preset neighboring scene mapping relationship based on scene association dimension, at least one neighboring scene associated with the current online scene is located from the domain layer permission matrix, and its corresponding preset permission subset is extracted; wherein, the scene association dimension includes scene type similarity, geographical proximity or risk level matching. Based on the latest dynamic permission values ​​and time-limited tags of the dynamic layer, and combined with the extracted preset permission subset, an initial offline code is generated. The initial offline code is associated with the fusion code through a lightweight symmetric encryption algorithm, and its effective scenarios are strictly limited to the nearby scenarios of the location. A time decay factor is embedded in the initial offline code to reduce its permission validity according to a preset decay rule; the decay rule is linked to the time-limited tag mechanism of the dynamic layer, and the decay rate is dynamically adjusted in relation to the dynamic security level field of the base layer. When the network connection is restored, the offline code automatically becomes invalid, and the fusion code recovery process is executed: First, the integrity of the fusion code's features during the offline period is verified through a cross-layer hash chain; after successful verification, the transaction records generated during the offline period are synchronized to the behavioral credit chain, and the recalculation of the fusion code's credit entropy and the update of the permission parameters are triggered.

8. A multi-code fusion method according to any one of claims 1 to 7, characterized in that, If we use the electronic social security code, bus code, and subway code as raw codes, and launch a multi-code fusion system to analyze the heterogeneous features of each raw code, classify them according to benchmark, domain, and dynamic features, and match and generate a standardized feature set with verifiable cryptographic source identifiers, including: By pre-setting differentiated interfaces and corresponding security policies for electronic social security codes, bus codes, and subway codes, the original codes are accessed. Among them, electronic social security codes adopt encrypted channels and data desensitization processing, while bus codes and subway codes are accessed through a dedicated network and configured with verification and retry mechanisms. The pre-built heterogeneous parsing rule library is invoked to extract key fields and unify the format of the three types of source code. The rule library contains format conversion rules and field mapping relationships corresponding to each source code type. Based on preset classification rules, the extracted features are classified and integrated according to benchmark, domain and dynamic features; Based on the classification results, a unique source identifier is generated by combining the original code type identifier and the timestamp; a standardized feature set is formed by integrating based on a preset feature weight strategy, and the source identifier and feature set are digested by cryptographic hash operation to generate a verifiable cryptographic source identifier, while establishing a traceability index relationship with each original code.

9. A multi-code fusion system, characterized in that, It includes a memory, a processor, and a program stored in the memory and executable on the processor, which, when loaded and executed by the processor, implements a multi-code fusion method as described in any one of claims 1 to 8.

Images