A multi-code fusion method and system

Abstract

This application relates to a multi-code fusion method and system, which solves the problem that users need to frequently switch between different QR codes to adapt to various scenarios during interaction with urban service systems. The method includes: starting the system to parse the heterogeneous features of the original codes and generate a standardized feature set with cryptographic identifiers; layered fusion to generate a preliminary fusion code and a behavioral credit chain; verification to form a formal fusion code and calculate the initial credit entropy. During terminal verification, two-way verification is performed, and a minimum transaction credential is generated after matching the scenario. If successful, the fusion code is activated, the transaction is recorded, and permissions are dynamically adjusted; if unsuccessful, a hierarchical security response is triggered, generating a secure sub-credential or switching back to the original code. Offline codes are generated for offline scenarios. This application has the following effects: through dynamic permissions and credit management, without sacrificing security, a single fusion code replaces multiple scenario codes, achieving a balance between convenience and security.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information processing, in particular to a multi-code fusion method and system. BACKGROUND

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

[0003] Currently, city service systems mainly use single-function two-dimensional codes, such as electronic social security codes for social security information query, bus codes for bus payment, and subway codes for subway rides. These two-dimensional codes are independent of each other, and users need to switch different codes in different scenarios, increasing the complexity of operations. At the same time, existing technologies lack unified management and fusion mechanisms for two-dimensional codes, and cannot achieve seamless switching and permission sharing across scenarios.

[0004] The independent operation mode of different two-dimensional codes in existing technologies has obvious drawbacks, mainly in terms of user convenience. Users need to frequently switch different two-dimensional codes to adapt to various scenarios during interaction with city service systems, which not only increases the degree of user operation complexity, but also may cause errors or confusion during switching, thereby reducing service efficiency and user experience. SUMMARY

[0005] In order to replace multiple scenario codes with one fusion code without sacrificing security, and achieve unified convenience and security, the present application provides a multi-code fusion method and system.

[0006] In a first aspect, the present application provides a multi-code fusion method, which adopts the following technical solution:

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

[0008] Starting the multi-code fusion system, analyzing the heterogeneous characteristics of each original code, classifying by reference, field, and dynamic characteristics, matching to generate a standardized feature set with a verifiable cryptographic source identifier, and retaining the independent function interface of the original code;

[0009] Based on the standardized feature set, hierarchical fusion is performed in a way that does not cover the original code data: the reference layer generates an encrypted reference code associated with the original code identifier, the field layer constructs a cross-scenario permission matrix, and the dynamic layer calculates the permission value to form a fusion code prototype; simultaneously generating a behavior credit chain bound to the fusion code prototype;

[0010] The formal fusion code is generated after checking the fusion code prototype and the behavior credit chain, the initial dynamic credit entropy of the fusion code is calculated according to the initial state of the behavior credit chain and the preset risk rule set, and the parallel calling interface of the fusion code and the original code is maintained.

[0011] The three-layer features of the fusion code are associated through the cross-layer hash chain, and the terminal performs a bidirectional verification protocol during verification: first, the matching of the scene and the features of each layer is checked, and then the integrity of the whole chain is verified; subsequently, the terminal announces the scene demand and the minimum credit entropy requirement to the fusion code, and the fusion code generates a minimum one-time transaction voucher corresponding to the scene demand according to the current credit entropy;

[0012] If the verification passes, the fusion code is enabled to realize cross-scene 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 scene is detected, a time-decaying offline code is generated based on the dynamic features;

[0013] If the verification fails, the original code identification associated with the reference layer is used to trigger a hierarchical security response mechanism: first, a security sub-voucher that follows the preset invalidation conditions and function range is generated based on the permission matrix of the domain layer; if the security sub-voucher is invalid or fails to be generated, the corresponding original code is independently run.

[0014] In a second aspect, the present 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 on the memory and executable on the processor, which can be loaded and executed by the processor to implement the multi-code fusion method of the first aspect. BRIEF DESCRIPTION OF DRAWINGS

[0016] Figure 1 is a whole flowchart of a multi-code fusion method in an embodiment of the present application.

[0017] Figure 2 is a flowchart of the encryption reference code generated by the reference layer to associate the original code identification in another embodiment of the present application. DETAILED DESCRIPTION

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

[0019] REFERENCE Figure 1 A multi-code fusion method disclosed in the present application includes the following steps:

[0020] Step S100: starting the multi-code fusion system, parsing the heterogeneous features of each original code, classifying according to the reference, domain, and dynamic features, matching to generate a standardized feature set with a verifiable cryptographic source identification, and retaining the independent function interface of the original code.

[0021] Multi-code fusion system: a system that integrates multiple original codes (such as two-dimensional codes, barcodes, RFID, etc.), achieves unified functions across scenes by analyzing and fusing the characteristics of different original codes. The acquisition method includes integration into existing systems through a software development kit (SDK) or API interface calling through cloud services. Heterogeneous characteristics: the difference in data structure, encoding method, functional use, etc. of different original codes. The acquisition method is through a feature analysis module to read and analyze the original code data.

[0022] The necessary process is described as follows: 1. Start the system and collect data: after starting the multi-code fusion system, first read the data of various original codes through the data collection module, including bus codes, subway codes, and social security codes, etc. The system collects data according to the type of the original code using the corresponding technical means. 2. Feature classification and extraction: the system classifies and extracts the collected original data according to the preset rules. The reference features include the encoding format (such as the QRCode format of two-dimensional code and the UID format of NFC) and the data structure (such as the format of user ID). The field features involve application scenarios, for example, bus codes and subway codes belong to the public transportation field, and social security codes belong to the social security field. Dynamic features include timestamps (such as usage time) and usage frequency, etc. The system matches the reference features through regular expressions, extracts the field features through keywords, and extracts the dynamic features through timestamps to ensure the accuracy of feature classification. 3. Generate verifiable cryptographic source identification: the system generates verifiable cryptographic source identification for each feature to ensure data integrity and security. The specific process is: extract the key information of the original code (such as user ID, timestamp, etc.), generate a hash value through the SHA-256 algorithm, and then sign the hash value with the RSA algorithm to generate a digital signature. The digital signature is bound with the original data to form a verifiable cryptographic source identification. 4. Generate standardized feature set: the system standardizes the extracted features to form a standardized feature set. For example, the user ID is unified as a fixed-length string, and the timestamp is unified as an ISO standard format. The standardized features are bound with the cryptographic source identification to form a standardized feature set. 5. Preserve independent function interface: while generating the standardized feature set, the system preserves the independent function interface of the original code through the 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 original codes. At this time, the multi-code fusion system is started, the heterogeneous characteristics of each original code are analyzed, classified according to reference, field, and dynamic characteristics, and a standardized feature set with verifiable cryptographic source identification is matched and generated, including:

[0024] Step S101, access each original code through the differentiated interface and corresponding security policy preset for electronic social security code, bus code and subway code, wherein the electronic social security code adopts encryption channel and data desensitization processing, the bus code and subway code are accessed through a special network and a verification retry mechanism is configured.

[0025] Among them, the differentiated interface refers to the special interface designed for different types of original codes (such as electronic social security code, bus code and subway code). These interfaces are customized according to the characteristics and security requirements of the original code. The encryption channel refers to the secure communication path established by encryption technology (such as TLS / SSL) to protect the privacy and integrity of data transmission. Data desensitization refers to the use of technical means (such as masking and hashing) to hide or change the original data when storing or processing sensitive information to reduce the risk of data leakage. Special network access refers to data transmission through a special network (such as VPN) to improve the security of data transmission and prevent external attacks. The verification retry mechanism refers to the system automatically resending data if an error is detected during data transmission to ensure data accuracy.

[0026] The process is described as follows:

[0027] 1. Secure access of electronic social security code: Electronic social security code contains sensitive personal information, so encryption channel is used to ensure data security during transmission. At the same time, sensitive information such as ID number is desensitized, for example, replacing part of the digits in the ID number "11010519491231002X" with asterisks "********" to protect user privacy. This process involves data access control and encryption technology to ensure that only authorized systems and personnel can access the original data.

[0028] 2. Special network access of bus code and subway code: Bus code and subway code access the system through a special network, using VPN technology to establish a secure network environment. This access method can reduce the exposure of data on public networks and reduce the risk of interception or tampering. During data transmission, the system configures a verification retry mechanism such as CRC verification to ensure data integrity. If an error occurs during data packet transmission, the system will automatically retry until the data is successfully transmitted.

[0029] 3. Design of differentiated interface: In order to adapt to different types of original codes, the system designs differentiated interfaces. These interfaces are customized according to the characteristics and security requirements of the original code, for example, the electronic social security code interface may require more stringent authentication and authorization mechanisms, while the bus code and subway code interfaces may focus more on data transmission efficiency and reliability.

[0030] Step S102, call the preset heterogeneous analysis rule library to extract the key fields and format uniform processing of the three types of original codes. The rule library includes the format conversion rules and field mapping relationships corresponding to each original code type.

[0031] Among them, the format uniform processing: convert the extracted data fields into a uniform format that the system can recognize and process. Field mapping relationship: define the corresponding relationship between the original code field and the system internal data model field.

[0032] The process is described as follows: 1. Rule library calling: after accessing the original code, the system will call the preset heterogeneous analysis rule library. This rule library contains analysis rules for different original code types, which are used to guide the system how to extract key information from the original code and convert it into a format that the system can handle 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 contain ride time, route information, etc.; subway codes may contain entry and exit information. The analysis rules in the rule library will guide the system to identify these key fields and extract them from the original data. 3. Format uniform processing: the extracted key fields may need further format conversion to meet the system internal data standards. For example, date fields may need to be unified into "YYYY-MM-DD" format, and time fields may need to be unified into "HH:MM:SS" format. The rule library contains specific rules for format conversion. 4. Establishment of field mapping relationship: in order to correctly map the extracted and converted data fields to the system internal data model, the rule library defines the field mapping relationship. This includes mapping the field name in the original code to the field name in the system, and determining the corresponding relationship of the field data type.

[0033] 5. Automatic processing: the entire analysis process is automated. Once the original code is accessed, the system will automatically execute the analysis rules in the rule library, extract the key fields, perform format conversion, and establish the field mapping relationship.

[0034] Step S103, based on the preset classification rules, classify and integrate the extracted features according to the criteria, fields and dynamic features.

[0035] The process is as follows: 1. Application of classification rules: After feature extraction, the system will classify these features according to pre-set classification rules. These rules define how to classify features into different categories according to their attributes and uses. 2. Identification and integration of benchmark features: The system first identifies benchmark features related to the basic functions of the original code. For example, for an electronic social security code, the benchmark features may include the version of the code and the coding standard. These features are crucial to ensuring data compatibility and consistency. 3. Extraction of domain features: Next, the system extracts features related to the application domain of the original code. For example, the domain features of bus and subway codes may include information such as boarding location, route and time, which helps to understand the use scenarios of the code. 4. Capture of dynamic features: The system also captures features related to dynamic changes during the use of the original code. For example, the specific time of a transaction, the frequency of code use, etc., which can reflect the user's usage habits and behavior patterns. 5. Feature integration: After classification, the system integrates these features into a unified data structure. This step involves data cleaning, conversion and formatting to ensure that all features can be effectively used by the system.

[0036] Step S104, according to the classification result, combined with the original code type identification and timestamp to generate a unique source identification; based on the preset feature weight strategy integration to form a standardized feature set, and through the cryptographic hash operation on the source identification and feature set for abstract processing, generating a verifiable cryptographic source identification, and establishing a traceability index relationship with each original code.

[0037] The process is as follows: 1. Generate a unique source identification: According to the classification results of step S103, the system will combine the type identification of the original code and the time stamp accurate to milliseconds to generate a unique source identification. For example, for an electronic social security code, the unique source identification may be composed of the social security code type, user ID and time stamp, ensuring the uniqueness of each code. 2. Integration to form a standardized feature set: Based on the 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 the weight. For example, for a bus code, the boarding time may be more important than the boarding location, so the weight of the time feature will be higher in the feature set. 3. Perform cryptographic hash operation: In order to ensure the integrity and consistency of the source identification and feature set, the system will perform a cryptographic hash operation on them. Common hash algorithms include SHA-256, etc. 4. Generate a verifiable cryptographic source identification: Through the hash operation, the system generates a verifiable cryptographic source identification. This identification can be used to verify the source and integrity of the original code. 5. Establish traceability index relationship: Finally, the system establishes a traceability index relationship between the original code and the generated unique source identification. This relationship is usually stored in a database, and the index structure is used to achieve fast query.

[0038] Step S200, based on the standardized feature set, hierarchical fusion is performed in a manner that does not cover the original code data: the reference layer generates the encrypted reference code associated with the original code identification, the field layer constructs the cross-scene permission matrix, and the dynamic layer calculates the permission value to form the fusion code prototype; and the behavior credit chain bound to the fusion code prototype is synchronously generated.

[0039] Among them, the reference layer: the basic structure layer of the fusion code, contains the encrypted reference code associated with the original code identification, used to ensure the uniqueness and security of the fusion code and the original code. The field layer: the function layer of the fusion code, constructs the cross-scene permission matrix, and defines the use permission of the fusion code in different scenes. The dynamic layer: the dynamic adjustment layer of the fusion code, calculates the permission value according to the real-time data to form the prototype of the fusion code.

[0040] The process of generating the encrypted reference code associated with the original code identification by the reference layer can refer to steps S210 to S240, the process of constructing the cross-scene permission matrix by the field layer can refer to steps S2A0 to S2D0, and the process of calculating the permission value to form the fusion code prototype by the dynamic layer can refer to steps S2a0 to S2d0.

[0041] The process of synchronously generating the behavior credit chain can refer to the following: the system synchronously generates the behavior credit chain bound to the fusion code prototype at the same time. The behavior credit chain is based on blockchain technology and records each use behavior of the fusion code, including time, scene, permission value, etc. For example, each time the bus code is used to take the bus, the behavior credit chain records the timestamp, the starting and ending points of the journey, etc.

[0042] Step S300, after the fusion code prototype and the behavior credit chain are checked, the formal fusion code is generated, the initial dynamic credit entropy of the fusion code is calculated according to the initial state of the behavior credit chain and the preset risk rule set, and the parallel calling interface of the fusion code and the original code is maintained.

[0043] Among them, the initial dynamic credit entropy: the initial credit value of the fusion code calculated based on the initial state of the behavior credit chain and the preset risk rule set, used to evaluate the credit level of the fusion code in the initial state. The acquisition method is to calculate through the credit entropy calculation model combined with the behavior credit chain data and the risk rules.

[0044] Necessary process elaboration: 1. Check of fusion code prototype and behavior credit chain: The system first checks the fusion code prototype and behavior credit chain to ensure their integrity and credibility. The check of the fusion code prototype verifies the integrity of each layer of features through a hash algorithm, such as calculating the hash value of the reference layer, domain layer and dynamic layer respectively, and comparing it with the pre-stored hash value. The check of the behavior credit chain uses the tamper-proof feature of the blockchain to check the timestamp, data integrity and hash link between blocks. For example, if the timestamp of a block is detected to be abnormal or data is missing, the check will fail and the fusion code prototype will be marked as invalid. 2. Generation of formal fusion code: After the check passes, the system converts the fusion code prototype into the formal fusion code. This process includes the formatting and security reinforcement of the fusion code. For example, add a digital signature to the formal fusion code to ensure its identity verification and integrity protection during transmission and use. At the same time, the system will assign a unique identifier to the formal fusion code for subsequent management and tracking. For example, after the conversion of the bus code and subway code into the formal fusion code, they will have a unified format and security mechanism to ensure their universality and security in the public transportation scene. 3. Calculation of initial dynamic credit entropy: The system calculates the initial dynamic credit entropy of the fusion code based on the initial state of the behavior credit chain and the preset risk rule set. This process includes the following creative steps:

[0045] Step A: Multi-dimensional feature extraction: The system extracts multi-dimensional features from the behavior credit chain, including usage time, usage frequency, scene type, permission value, etc. For example, for bus codes and subway codes, extract the first usage time, usage frequency within a day, and whether to use during peak hours, etc. These features will be used as the basis for credit entropy calculation.

[0046] Step B: Risk weight allocation: The system allocates risk weights to each feature according to the preset risk rule set. For example, a scene with high peak hour usage frequency may be assigned a higher risk weight, as it may indicate abnormal user behavior. Weight allocation is based on historical data and expert experience to ensure the reasonableness and scientificity of the weights.

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

[0048] Initial dynamic credit entropy = . Where F i represents the i-th feature value (such as usage frequency, scene risk level, etc.). W i represents 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: The system calibrates and adjusts the credit status of the fusion code based on the initial dynamic credit entropy and the pre-set credit threshold. For example, if the initial credit entropy is lower than the pre-set threshold (e.g., threshold of 4.0), the system will mark the fusion code as high-risk and restrict its partial functions until the credit entropy returns to normal level. This process ensures the safety and reliability of the fusion code during use.

[0050] Step S400, by associating the three-layer features of the fusion code through the cross-layer hash chain, the terminal verifies the two-way verification protocol: first, verify the matching of the scene and each layer feature, then verify the integrity of the whole chain; then, the terminal announces the scene demand and the minimum credit entropy requirement to the fusion code, and the fusion code generates the minimum one-time transaction certificate corresponding to the scene demand according to the current credit entropy.

[0051] Wherein, cross-layer hash chain: a technology for associating the three-layer features (reference layer, domain layer, dynamic layer) of the fusion code, which ensures the integrity and consistency of the data through the concatenation of hash values. The acquisition method is to process and concatenate each layer feature through a hash algorithm. Two-way verification protocol: a terminal verification mechanism, including verifying the matching of the scene and each layer feature, and verifying the integrity of the whole chain. The acquisition method is to realize it by designing verification algorithm and protocol. Minimum one-time transaction certificate: a temporary certificate generated according to the scene demand and the current credit entropy, used for single verification in a specific scene. The acquisition method is to dynamically generate it by the fusion code system according to the pre-set rules.

[0052] The process of associating the three-layer features of the fusion code through the cross-layer hash chain can refer to steps 1 to 3; the process of first verifying the matching of the scene and each layer feature, and then verifying the integrity of the whole chain can refer to steps S410 to S430.

[0053] The announcement of the scene demand and the minimum credit entropy requirement is as follows: the terminal announces the current scene demand and the minimum credit entropy requirement to the fusion code. For example, in the subway scene during peak hours, the terminal announces the need for access permission and requires the credit entropy of the fusion code to be no less than 4.0. After receiving this information, the fusion code evaluates whether the current credit entropy meets the requirements.

[0054] The process of generating the minimum one-time transaction certificate is as follows: if the credit entropy of the fusion code meets the requirements of the terminal, the system generates the minimum one-time transaction certificate according to the scene demand. The certificate contains the following contents: 1. Scene identification: identifies the current scene (such as subway, bus). 2. Permission value: the permission value allocated according to the scene demand. 3. Validity period: the validity time range of the certificate, usually for single use. 4. Hash value: the hash value containing the scene demand and the permission value, used to verify the integrity of the certificate.

[0055] Step S500, if the verification passes, enable the fusion code to realize cross-scene functions, record transactions to the behavior credit chain, trigger credit entropy recalculation, and dynamically adjust the permission parameters of the fusion code based on the recalculated credit entropy; if an offline scene is detected, generate an offline code with time decay based on dynamic features.

[0056] Wherein, cross-scene functions: the functions realized by the fusion code in different application scenarios (such as public transportation, subways, social security, etc.), which are dynamically adjusted through permission parameters.

[0057] Necessary process description: 1. Enable the fusion code to realize cross-scene functions: if the terminal verification passes (step S400), the fusion code will be enabled to realize cross-scene functions. The system dynamically adjusts the functions of the fusion code according to its permission parameters, ensuring that it has appropriate permissions in different scenarios. For example, the fusion code has access permissions in the public transportation scenario and query and payment permissions in the social security scenario. These permission parameters are dynamically adjusted according to the preset rule set to adapt to different use scenarios. 2. Record transactions to the behavior credit chain: every time the fusion code is used, the system writes transaction records to the behavior credit chain. Transaction records include information such as use time, scenario, and permission value. For example, when the user uses the fusion code to take 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 credit entropy calculation. 3. Trigger credit entropy recalculation: based on the latest transaction records and the state of the behavior credit chain, the system triggers the recalculation of credit entropy. The credit entropy recalculation model combines new transaction data and preset risk rules to dynamically adjust the credit entropy value. For example, if the user frequently uses the fusion code during peak hours, the credit entropy may decrease; if the user uses it normally and has no abnormal behavior, the credit entropy will remain stable or slightly increase. 4. Dynamically adjust the permission parameters of the fusion code: according to the recalculated credit entropy, the system dynamically adjusts the permission parameters of the fusion code. 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 (such as <4.0): restrict high-risk permissions. 2. Medium credit entropy threshold (such as 4.0-4.5): unlock basic function permissions. 3. High credit entropy threshold (such as >4.5): unlock advanced function permissions.

[0060] Step S502:

[0061] Credit parameter mapping: The system maps the credit parameter of the fusion code to different levels of authority according to the credit entropy value. For example: 1. Low credit entropy (<4.0): Only basic access rights (such as public transportation, subway) are allowed, and payment and query functions are restricted. 2. Medium credit entropy (4.0-4.5): Unlock basic payment rights (such as small payment), allow query function. 3. High credit entropy (>4.5): Unlock advanced payment rights (such as large payment), allow advanced query function (such as social security detail query).

[0062] Step S503:

[0063] Real-time authority adjustment: The system adjusts the authority parameters of the fusion code in real time according to the latest credit entropy value. For example: 1. If the credit entropy decreases from 4.2 to 3.9, the system automatically adjusts the fusion code's authority from the "medium credit entropy" level to the "low credit entropy" level, restricting its payment function. 2. If the credit entropy increases from 3.8 to 4.1, the system automatically adjusts the fusion code's authority from the "low credit entropy" level to the "medium credit entropy" level, unlocking the basic payment function.

[0064] Step S504:

[0065] Authority adjustment notification: The system sends authority adjustment notifications to users and terminal devices to ensure that users are aware of the current authority status. For example, when the user's credit entropy decreases, the user receives a notification: "Your fusion code credit entropy has decreased to 3.9, payment function is temporarily restricted." The specific offline scenario processing process can be referred to steps S510 to S550.

[0066] Step S600, if the verification fails, the original code identification associated with the reference layer is triggered to trigger a hierarchical security response mechanism: first, generate a security sub-certificate that follows the preset invalidation conditions and function range based on the authority matrix of the domain layer; if the security sub-certificate is invalid or fails to generate, switch to independent operation of the corresponding original code.

[0067] Among them, the original code identification associated with the reference layer: the unique identification associated with the original code (such as public transportation code, subway code, social security code) contained in the fusion code reference layer, used to trace the original code when verification fails. Hierarchical security response mechanism: a multi-level security response strategy that takes different security measures according to the specific circumstances of the verification failure. Security sub-certificate: a temporary certificate generated when verification fails, following the preset invalidation conditions and function range, used to restrict the functions of the fusion code.

[0068] The necessary procedures are as follows: 1. Triggering the hierarchical security response mechanism: If the fusion code verification fails (such as scene mismatch or hash chain integrity is damaged), the system triggers the hierarchical security response mechanism according to the original code identification associated with the reference layer. This process ensures that the system can quickly respond and take appropriate security measures when verification fails. 2. Generating security sub-certificate based on domain layer permission matrix: The system first generates a security sub-certificate based on the permission matrix of the domain layer. The permission matrix defines the function range and permission limit under different failure conditions. For example:

[0069] Failure conditions: such as credit entropy below threshold, scene mismatch, full chain integrity damaged, etc.

[0070] Function range: such as limiting payment function, allowing only query function, limiting access rights, etc.

[0071] For example: Assuming that the credit entropy of the fusion code is below the preset threshold (such as below 4.0), the permission matrix stipulates:

[0072] Failure condition: credit entropy <4.0; function range: only query function, limit payment and access rights.

[0073] The system generates a security sub-certificate according to these rules, including: a, scene identification: such as public transportation, subway, social security; b, permission value: such as only query function; c, validity period: such as valid for 15 minutes; d, hash value: hash value generated based on the above information, to ensure the integrity of the certificate.

[0074] 3. Verification and application of security sub-certificate: The terminal device verifies the validity of the security sub-certificate, including checking the hash value and validity period. If the security sub-certificate is valid, the terminal device will limit the functions of the fusion code according to the certificate content. For example, only allow users to query social security information, and limit payment and access functions.

[0075] 4. Switch to original code independent operation: If the security sub-certificate is invalid (such as hash value verification fails) or fails to generate (such as no corresponding rules in the permission matrix), the system will switch to the corresponding original code for independent operation.

[0076] Referring to Figure 2 , the reference layer generates an encrypted reference code associated with the original code identification, including:

[0077] Step S210, analyze the reference features of each original code, extract the unique identification and core attributes, convert the heterogeneous identification into a unified format of the source identification set through a feature mapping algorithm, and establish a reference association index between the original codes.

[0078] Among them, unique identification: unique identification information in the original code, such as product serial number, user account, etc. Extracted in the original code data. Core attribute: the key functional attribute of the original code, which determines the main purpose and function of the original code. Obtain by analyzing the functional logic and application scenario of the original code. Feature mapping algorithm: an algorithm that converts heterogeneous identifiers into a unified format. According to the characteristics of the original code and the target unified format, such as hash algorithm, encoding conversion algorithm, etc.

[0079] The complete process is described as follows: First, analyze the reference features of each original code, and extract the unique identification and core attribute. For example, for bus codes and subway codes, analyze their encoding methods (such as QR codes, NFC tags) and length, etc. Reference features, extract user account as unique identification, and access rights as core attribute. For social security codes, extract the social security account as the unique identification, and the query right as the core attribute. Then, through the feature mapping algorithm, the heterogeneous identification is converted into a unified format of the source identification set. For example, use the SHA-256 hash algorithm to convert user accounts of different formats into fixed-length hash values to form a unified format of the source identification set. Finally, establish the reference association index between the original codes. Based on the source identification set, an index structure such as a hash table is constructed to associate the source identification of the original code with the original code itself, facilitating subsequent quick query and association of the original code. For example, a hash table is constructed with the hash value of the source identification set as the key and the original code related information as the value to realize the reference association index between the original codes.

[0080] In step S220, a preset encryption algorithm is used to encrypt the source identification set to generate a unique encrypted reference code. The encryption process is implemented in an outer encryption wrapping mode, which only establishes an association with the original code through the interface layer without invading the underlying data and the original encryption system, while embedding the reversible association relationship of the original code source identification, so that the reference code can be traced back to the associated original code and the independent function of the original code is ensured to operate normally.

[0081] Among them, the preset encryption algorithm: a pre-set encryption algorithm used to encrypt the source identification set. Common encryption algorithms include national encryption algorithms (such as SM2, SM3, SM4) and international general algorithms (such as AES, RSA). Outer encryption wrapping mode: an encryption method that does not encrypt within the original code data, but wraps the encrypted content outside the original code to form an encryption layer. Interface layer: the interaction layer between the fusion code and the original code, used to establish an association between the encrypted reference code and the original code without directly modifying the data structure of the original code. Reversible association relationship: the association relationship embedded in the encryption process, which allows tracing back from the encrypted reference code to the original code. This relationship is achieved through encryption algorithms and key management to ensure security and traceability.

[0082] The complete process is described as follows: 1. Select a preset encryption algorithm: according to the security requirements and performance requirements, select a suitable encryption algorithm. National encryption algorithm (such as SM2, SM3, SM4) and international general algorithm (such as AES, RSA) can be used for encryption of source identification set. National encryption algorithm has high security and independent intellectual property rights, and is suitable for application scenarios that require high security level. For example, SM4 algorithm is a symmetric encryption algorithm, which is suitable for fast encryption and decryption operation; SM2 is an asymmetric encryption algorithm, which is suitable for scenarios that need to separate public key and private key. When selecting the algorithm, the encryption strength, calculation efficiency and whether it meets the industry standard should be considered. 2. Outer layer encryption wrapping mode implementation: the outer layer encryption wrapping mode is used to encrypt the source identification set, and the specific steps are as follows: 2.1, prepare the source identification set: obtain the unified format source identification set from step S210, which has been converted to unified format by feature mapping algorithm. For example, different formats of user account are converted into fixed length hash value by SHA-256 hash algorithm. 2.2, encryption processing: use the selected encryption algorithm (such as SM4) to encrypt the source identification set. The source identification set is input as plaintext, and the key is used for encryption operation to generate ciphertext as encryption reference code. For example, the hash value of user account is input as plaintext, and SM4 algorithm is used to generate encryption reference code. 2.3, wrap the original code: wrap the encrypted reference code outside the original code to form an encryption layer. This way ensures that the basic data of the original code and the original encryption system are not affected, and only the interface layer is associated with the encryption reference code.

[0083] 3. Embed reversible association relationship: embed the reversible association relationship of the original code source identification in the encryption process to ensure that the original code can be traced back from the encryption reference code, and the specific method is as follows: 3.1, key management: when using symmetric encryption algorithm (such as AES), the key needs to be stored and managed safely. For asymmetric encryption algorithm (such as SM2), public key is used for encryption and private key is used for decryption, which ensures that only authorized party can decrypt and trace back the original code. 3.2, association relationship record: embed a reversible mapping relationship in the encryption reference code, for example, add a pointer or identifier pointing to the original code in the encryption reference code. This pointer or identifier can be used to quickly locate and trace back the original code when decrypted. 3.3, security verification: ensure that the reversible association relationship in the encryption process does not leak the sensitive information of the original code, and ensure that the original code can be accurately traced back when decrypted. For example, through the characteristics of encryption algorithm (such as the strong encryption of SM4) to ensure the security of the association relationship.

[0084] 4. Ensure the independent function of the original code runs normally: After the generation of the encrypted reference code, ensure that the independent function of the original code is not affected, specific measures include: 4.1, interface adaptation: through the design of the adapter in the interface layer, ensure that the function interface of the original code is compatible with the interface of the encrypted reference code. For example, the scanning function of the bus code and the card swiping function of the subway code can still be independently called after fusion. The adapter can map the interface of the encrypted reference code to the function interface of the original code, ensuring the continuity of the function. 4.2, function test: after the generation of the encrypted reference code, perform function test to verify whether the function of the original code runs normally. For example, test whether the bus code can still pay normally by scanning the code, and whether the social security code can still query information normally. Through the test, ensure that the encryption process will not affect the normal use of the original code. 4.3, exception handling: design an exception handling mechanism to ensure that the original code can run independently when the encrypted reference code has a problem, without affecting the normal use of users. For example, if the encrypted reference code is invalid, the system can automatically switch to the original code to ensure the continuity of the service. The exception handling mechanism can be realized by monitoring the state of the encrypted reference code and automatically triggering the switching logic.

[0085] Step S230, setting a dynamic security level field in the encrypted reference code, which calculates the risk value in real time and automatically matches the security level according to the fusion data security, scene load, and cross-domain risk assessment model of abnormal behavior.

[0086] Among them, the dynamic security level field: a field in the encrypted reference code that can be adjusted in real time, used to identify the security level. Cross-domain risk assessment model: a model for comprehensive assessment of multi-domain risks such as fusion data security, scene load, and abnormal behavior.

[0087] The complete process is described as follows: 1. Set the dynamic security level field: set a special field in the encrypted reference 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", indicating the default security state of the system when there is no specific risk prompt. 2. Build a cross-domain risk assessment model: build a comprehensive assessment model that combines the risk factors in the following three main areas and quantitatively calculates the risk in each area:

[0088] 2.1, fusion 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 divided into low (10), medium (20), and high (30) levels. Access control policy: Evaluate the permission settings and control mechanisms for data access. For example, strict multi-level permission control and identity verification mechanisms can reduce risk values. Access control policy can be divided into weak (10), medium (5), and strong (0) levels. Data encryption strength: Assess the encryption strength of data during transmission and storage. For example, using strong encryption algorithms (such as AES-256) can reduce risk values. Encryption strength can be divided into weak (10), medium (5), and strong (0) levels.

[0090] Comprehensive data security risk value: Weighted sum of the above three factors to get the comprehensive data security risk value:

[0091] Data security risk value = w 敏感度 x sensitivity + w 访问控制 x access control + w 加密强度 x encryption strength.

[0092] 2.2, Scenario load risk quantification:

[0093] System performance indicators: Monitor system performance indicators such as response time, throughput, CPU and memory usage, etc. For example, response time exceeding threshold (such as 1 second) will increase risk value. Response time can be divided into low (0), medium (5), and high (10) levels. Concurrent access volume: Evaluate the current system's concurrent access volume. For example, high concurrent access (such as more than 1000 times / second) will increase risk value. Concurrent access volume can be divided into low (0), medium (5), and high (10) levels. Resource occupancy rate: Evaluate the occupancy of system resources. For example, CPU or memory usage exceeding 80% will increase risk value. Resource occupancy rate can be divided into low (0), medium (5), and high (10) levels.

[0094] Comprehensive scenario load risk value: Weighted sum of the above three factors to get the comprehensive scenario load risk value:

[0095] Scenario load risk value = w 响应时间 x response time + w 并发访问量 x concurrent access volume + w 资源占用率 x resource occupancy rate.

[0096] 2.3, Abnormal behavior risk quantification:

[0097] User behavior analysis: Analyze user behavior patterns using machine learning algorithms (e.g., random forest, support vector machine). For example, frequent failed login attempts (e.g., more than 5 times per minute) will increase the risk value. User behavior can be classified into low (0), medium (5), and high (10) levels. Operation time analysis: Evaluate the time pattern of user operations. For example, non-normal operation time (e.g., 12 am to 4 am) will increase the risk value. Operation time can be classified into low (0), medium (5), and high (10) levels. Access pattern analysis: Evaluate the access pattern of users. For example, accessing multiple different types of resources in a short period of time will increase the risk value. Access pattern can be classified into low (0), medium (5), and high (10) levels.

[0098] Comprehensive abnormal behavior risk value: Weighted sum of the above three factors to get the comprehensive abnormal behavior risk value:

[0099] Abnormal behavior risk value = w1 × user behavior + w2 × operation time + w3 × access pattern. 用户行为 操作时间 访问模式

[0100] 3. Real-time risk value calculation and security level matching:

[0101] The cross-domain risk assessment model collects and analyzes data in the above three areas in real time to calculate the comprehensive risk value. The specific steps are as follows: 3.1, Data collection: Collect real-time data from system logs, performance monitoring tools, user behavior logs, etc. 3.2, Feature extraction: Extract and integrate features related to data security, scenario load, and abnormal behavior. For example, data sensitivity, response time, and failed login attempts. 3.3, Risk value calculation: Calculate the comprehensive risk value using pre-set 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, w3 are pre-set weights, which can be adjusted according to actual needs. For example, risk value < 30, security level set to "low". 30 ≤ risk value < 70, security level set to "medium".

[0103] Risk value ≥ 70, security level set to "high".

[0104] Step S240, the update of the security level field is synchronized to all associated terminals through an end-to-end encrypted tunnel, ensuring the dynamic consistency of the full-link security baseline.

[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 the verification is successful, 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 method of multi-code fusion, comprising: Comprise: Start a multi-code fusion system, analyze the heterogeneous characteristics of each original code, classify by reference, field, and dynamic characteristics, match to generate a standardized feature set with a verifiable cryptographic source identifier, and retain the independent function interface of the original code; Based on the standardized feature set, perform hierarchical fusion in a way that does not cover the original code data: the reference layer generates an encrypted reference code associated with the original code identifier, the field layer constructs a cross-scenario permission matrix, and the dynamic layer calculates the permission value to form a fusion code prototype; Synchronously generate a behavior credit chain bound to the fusion code prototype; After checking the fusion code prototype and the behavior credit chain, generate the official fusion code, calculate the initial dynamic credit entropy of the fusion code based on the initial state of the behavior credit chain and the preset risk rule set, and maintain the parallel calling interface of the fusion code and the original code; Through the cross-layer hash chain associated with the three-layer features of the fusion code, the terminal performs a two-way verification protocol: first, verify the matching of the scene and each layer feature, then verify the integrity of the whole chain; Subsequently, the terminal announces the scene demand and the minimum credit entropy requirement to the fusion code, and the fusion code generates a minimum one-time transaction voucher corresponding to the scene demand based on the current credit entropy; If the verification is passed, the fusion code is enabled to implement cross-scenario functions, record transactions to the behavior credit chain, trigger credit entropy recalculation, and dynamically adjust the permission parameters of the fusion code based on the recalculated credit entropy; If an offline scene is detected, generate an offline code with time decay based on the dynamic characteristics; If the verification fails, trigger a hierarchical security response mechanism based on the original code identifier associated with the reference layer: first, generate a security sub-voucher that follows the preset invalidation conditions and function range based on the permission matrix of the field layer; If the security sub-voucher is invalid or fails to generate, switch to the corresponding original code for independent operation.

2. The method of claim 1, wherein The reference layer generates an encrypted reference code associated with the original code identifier, which includes: Analyzing the reference characteristics of each original code, extracting unique identifiers and core attributes, converting heterogeneous identifiers to a unified format of source identifier set through feature mapping algorithm, establishing reference association index between original codes; Encrypt the source identifier set using a preset encryption algorithm to generate a unique encrypted reference code. The encryption process is implemented in an outer-layer encryption wrapping mode, which only associates with the original code through the interface layer without invading its basic data and original encryption system. At the same time, the reversible association relationship of the original code source identifier is embedded, so that the reference code can be traced back to the associated original code and ensure the normal operation of the original code independent function; Set the dynamic security level field in the encrypted reference code. This field calculates the risk value in real time and automatically matches the security level based on the cross-field risk assessment model of fusion data security, scene load, and abnormal behavior; The update of the security level field is synchronized to all associated terminals through an end-to-end encryption tunnel to ensure the dynamic consistency of the whole link security reference.

3. A multi-code fusion method as recited in claim 2, wherein, The field layer constructs a cross-scenario permission matrix, which includes: The field characteristics of each original code are analyzed, the scene-specific permissions and field rules are extracted, the permissions data that can be shared across scenes and the field-specific permission configurations are distinguished, the mapping relationship between the field characteristics and the encryption reference code of the benchmark layer is established, and the independent permission configuration interface of the field to which each original code belongs is reserved, wherein the scene-specific permissions include function access range and operation permission level, and the field rules include scene access conditions and interaction constraints; Based on the unified benchmark of the encryption reference code, the dimensions of the cross-scene permission matrix are determined, the field characteristics of each original code are classified and filled according to the dimensions to form an initial permission matrix, and the matrix calls the permission data of the original code through a preset association field without directly storing or modifying the field rules of the original code; A scene risk coefficient field is added to the cross-scene permission matrix, which is associated with real-time scene data and calculates the coefficient value through a preset weighted summation algorithm, wherein the scene data includes load capacity, security level and abnormal frequency; When the coefficient value of the scene risk coefficient reaches a preset threshold, the matrix automatically adjusts the permission validity range of the corresponding scene, and the cross-layer linkage is realized through the logical association of the benchmark layer security level field.

4. The method of claim 3, wherein the step of combining the plurality of codes comprises the step of: The dynamic layer calculates the permission value to form a fusion code prototype, including: ​ Analyzing the dynamic security level field of the benchmark layer encryption reference code and the scene risk coefficient value of the cross-scene permission matrix of the field layer, extracting real-time risk parameters including security level weight and scene risk coefficient proportion, and establishing a dynamic calculation model input set matched with the fusion scene; Based on the input set, the real-time weighting algorithm is used to calculate the permission value: the benchmark layer security level is weighted with a preset weight, and the weighted sum of the field layer scene risk coefficient value is generated to generate a dynamic permission value in the range of 0-1; The dynamic permission value is bound with a time limit label, combined with the source identification association relationship of the benchmark layer encryption reference code and the validity range of the field layer permission matrix, and combined to form a fusion code prototype containing benchmark association information, dynamic permission value, time limit label and scene adaptation range. The generation process of the fusion code prototype only calls the data of each layer through the interface, does not store or modify the original code data and the encryption system, and maintains independent interfaces with the original code; The fusion code prototype is temporarily stored in the dynamic cache area; when the benchmark layer security level or the field layer scene risk coefficient value changes, the dynamic layer recalculates and updates the permission value and the time limit label of the prototype to realize cross-layer linkage.

5. The method of claim 4, wherein, The three-layer characteristics of the fusion code are associated through the cross-layer hash chain, including: Step 1, respectively calculating the first feature hash of the benchmark layer encryption reference code, the second feature hash of the field layer cross-scene permission matrix, and the third feature hash of the dynamic layer dynamic permission value and time limit label; Step 2, taking the first feature hash as the root node, the second feature hash and the third feature hash as the child nodes, constructing a three-layer Merkle tree structure cross-layer hash chain, and associating the three-layer characteristics into a whole through a cryptographic hash association method; Step 3, in response to any one of the update events of the encryption reference code, the cross-scene permission matrix, the dynamic permission value or the time limit tag, automatically re-executes steps 1 and 2 to generate a new state anchor point, which is the root hash value of the current Merkle tree; and the new state anchor point and the historical state anchor point before the update are linked through a hash pointer, thereby realizing dynamic association and complete change tracing of the three-layer features.

6. A multi-code fusion method as recited in claim 5, wherein, First, verify the scene and the matching of each layer feature, and then verify the integrity of the whole chain, including: Analyze the current scene information, and in turn call the scene adaptation range and time limit tag of the dynamic layer fusion code prototype, the authorized scene set of the cross-scene permission matrix of the domain layer, and the dynamic security level field of the encryption reference code of the reference layer, to establish a scene matching verification input set; Based on the input set, perform scene matching verification: first, verify whether the current scene meets the dynamic layer scene adaptation range and time limit requirements, then verify whether the current scene is included in the domain layer authorized scene set, and finally verify whether the current scene meets the minimum requirements of the dynamic security level field of the reference layer; if all verifications pass, trigger the whole chain integrity verification; Perform whole chain integrity verification: verify the correct association of each layer feature hash value through the Merkle tree structure of the cross-layer hash chain, that is, verify that the feature hash value of the reference layer can be correctly calculated from the feature hash value of the domain layer and the dynamic layer; and verify the continuity and integrity of the state anchor point update history through the dynamic hash anchor chain; if the above verifications pass, it is determined that the bidirectional verification is successful and the subsequent process is entered, otherwise it is determined that the verification fails and a security response is triggered.

7. A multi-code fusion method as recited in claim 6, wherein, If an offline scene is detected, a time-decaying offline code is generated based on the dynamic feature, including: In response to detecting a network offline event, trigger the offline code generation process; According to the preset adjacent scene mapping relationship based on the scene association dimension, at least one adjacent 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 value and time limit tag of the dynamic layer, an initial offline code is generated combined with the extracted preset permission subset; the initial offline code is associated with the fusion code through a lightweight symmetric encryption algorithm, and its effective scene is strictly limited to the located adjacent scene; Embed a time decay factor in the initial offline code to reduce its permission validity according to the preset decay rule; the decay rule is linked with the time limit tag mechanism of the dynamic layer, and the decay rate is associated with the dynamic security level field of the reference layer to adjust dynamically; When the network connection is restored, the offline code automatically expires, and the fusion code recovery process is performed: first, verify the feature integrity of the fusion code during the offline period through the cross-layer hash chain; after the verification passes, synchronize the transaction records generated during the offline period to the behavior credit chain, and trigger the recalculation of the credit entropy of the fusion code and the update of the permission parameters.

8. A multi-code fusion method according to any one of claims 1 to 7, characterized by If the electronic social security code, the bus code and the subway code are taken as the original code, the multi-code fusion system is started, the heterogeneous features of each original code are analyzed, the features are classified according to the reference, domain and dynamic features, and the standardized feature set with a verifiable cryptographic source identifier is matched and generated, including: The electronic social security code, the bus code and the subway code are accessed through preset differentiated interfaces and corresponding security strategies, wherein the electronic social security code adopts an encrypted channel and data desensitization processing, and the bus code and the subway code are accessed through a special network and are configured with a verification retry mechanism; A preset heterogeneous analysis rule library is called to extract key fields and perform format uniform processing on the three types of original codes, and the rule library includes format conversion rules and field mapping relationships corresponding to each type of original code; Based on a preset classification rule, the extracted features are classified and integrated according to the criteria, the fields and the dynamic features; According to the classification result, a unique source identifier is generated in combination with the original code type identifier and the time stamp; based on a preset feature weight strategy, a standardized feature set is integrated, and the source identifier and the feature set are subjected to digest processing through a cryptographic hash operation to generate a verifiable cryptographic source identifier, and a traceability index relationship with each original code is established.

9. A multi-code fusion system, comprising: The program can be loaded and executed by the processor to implement the multi-code fusion method of any one of claims 1-8.

Images