A multi-factor authentication and blockchain storage data processing method and system

Abstract

The application relates to the technical field of data management, and discloses a data processing method and system for multi-factor authentication and block chain storage, which comprises the following modules: an identity authentication module for multi-factor identity verification, writing the verification result and an authentication serial number into an authorization voucher; an authorization contract module for generating a block chain authorization contract according to user authorization and setting a state version number; a government affair data access module for reading government affair data through a government affair network integrated public data platform and adding a request signature generated based on an SM3 algorithm into the request; a block chain storage module for storing the authorization voucher and a call log in the same rule, generating an authorization digest, a call log and a log digest; a consistency checking module for matching the authorization voucher and the call log; and a user authority management module for displaying an authorization state and executing a modification or revocation operation. The application realizes trusted verification and dynamic management and control of the whole authorization process, and improves the security of data sharing.

Description

Technical Field

[0001] This invention relates to the field of data management technology, and more specifically, to a data processing method and system for multi-factor authentication and blockchain-based evidence storage. Background Technology

[0002] With the accelerating digitalization of digital government, public services, and finance, the demand for sharing personal and government data across departments and systems is growing. Existing government data exchange and authorization mechanisms generally rely on centralized identity authentication and access control. Users complete data authorization after logging in through a unified identity platform, but authorization credentials, access records, and verification logs are stored in different systems, making it difficult to achieve reliable traceability and tamper-proof management throughout the entire process.

[0003] Existing technologies for government and public data sharing platforms still have some shortcomings: for example, identity authentication mainly relies on account passwords or digital certificates, which are not integrated with trusted identity authentication platforms and lack multi-factor joint verification mechanisms; authorization credentials and call logs are recorded in a scattered manner, and a unified system for on-chain recording with consistent field order and digest algorithms has not been established, making it impossible to achieve precise correspondence between authorization records and call behaviors; existing authorization tokens do not combine state version number increment and short-term ticket mechanisms, making old tokens easy to reuse and posing a risk of cross-version unauthorization; the use of general hash algorithms instead of the national cryptographic algorithm SM3 makes it difficult to meet government-level security requirements. Taking the invention patent CN112689847A, a blockchain-based government data sharing system, as an example, although it uses blockchain to record data access behaviors, it still does not achieve a unified mechanism for CTID multi-factor identity verification, tamper-proof short-term tickets, and on-chain recording of authorization digests and log digests with consistent rules, making it difficult to meet the high security requirements for identity verification and public service data processing in government application scenarios.

[0004] Therefore, it is necessary to design a data processing method and system for multi-factor authentication and blockchain-based evidence storage to solve the problems existing in the current technology. Summary of the Invention

[0005] In view of this, the present invention proposes a data processing method and system for multi-factor authentication and blockchain notarization, aiming to solve the problem that the existing technology has not achieved a unified mechanism for CTID multi-factor identity verification, anti-tampering of short-term tickets, and on-chaining of authorization digests and log digests with the same rules.

[0006] In one aspect, this invention proposes a data processing system for multi-factor authentication and blockchain-based evidence storage, comprising:

[0007] The identity authentication module is used to perform multi-factor identity verification when a user initiates data authorization. The multi-factor identity verification includes comparing the ID card number with the face. After the matching degree reaches the matching degree threshold, an authentication serial number is generated, and an authentication SMS is sent to the registered mobile phone number to complete the secondary confirmation. The verification result and the authentication serial number are written into the authorization certificate.

[0008] The authorization contract module is used to generate a blockchain authorization contract based on user authorization and set a status version number. Each time the authorization takes effect, is modified, or is revoked, the status version number is incremented and a short-term note is generated. The short-term note includes an authorization number, a status version number, and an expiration time. The note digest is calculated using the SM3 algorithm for anti-tampering verification and becomes invalid when it expires or the version is inconsistent. The authorization contract sets the authorization call time range, the upper limit of the number of authorization calls, and the access IP whitelist.

[0009] The government data access module is used to read government data through the integrated public data platform of the government network after authorization and verification, and to add a request signature generated based on the SM3 algorithm to the request to verify the integrity of the transmission.

[0010] The blockchain notarization module is used to notarize authorization credentials and call logs on the blockchain according to the same rules. The authorization credentials record the authorization number, authentication serial number, authorization policy and status version number, and generate an authorization digest. The call log records the authorization number, call time, access IP, status version number and response digest, and generates a log digest. The authorization digest and the log digest are generated using the same field order and the SM3 algorithm.

[0011] The consistency verification module is used to match authorization credentials with call logs based on the authorization number and status version number;

[0012] The user permission management module is used to display the authorization status and perform modification or revocation operations. When the verification conditions are met, a new authorization contract is generated and uploaded to the chain or the original contract is invalidated.

[0013] Furthermore, after completing the CTID verification, the identity authentication module concatenates the authentication serial number, registered mobile phone number, and authentication timestamp in a fixed order and calculates the authentication digest using the SM3 algorithm, and writes it into the authorization credential along with the verification result.

[0014] Furthermore, the identity authentication module performs a liveness detection before submitting the verification to CTID. After the liveness detection is passed, the ID number and face image are submitted for verification. The matching degree threshold is set to be no less than 90%. The unique verification identifier returned by CTID is bound to the authentication serial number and written into the authorization credential.

[0015] Furthermore, when issuing the short-term note, the authorization contract module concatenates the fields of authorization number, status version number, and expiration time in a fixed order, and calculates the note digest using the SM3 algorithm; when receiving a data call request, it first performs a digest consistency check and a status version number consistency check on the short-term note, and determines that the short-term note is invalid if either is inconsistent.

[0016] Furthermore, the authorization contract module adopts an atomic deduction mechanism for the upper limit of authorized call counts, and records the status version number and remaining count value of the current call within the same transaction where the deduction is successful; when the authorized call time range expires, the upper limit of authorized call counts is zeroed, or a revocation instruction is received, the module increments the status version number and stops issuing the short-term ticket, and writes the version change record and reason code to the blockchain.

[0017] Furthermore, when generating the request signature, the government data access module concatenates the timestamp, random string nonce, authorization number, status version number, request body digest, and appkey in a fixed order, and calculates the request signature using the SM3 algorithm. The government side recalculates the request body digest and request signature within the time window and verifies that the nonce has not been reused. If any one of them does not meet the requirements, the data is rejected.

[0018] Furthermore, when generating the authorization summary and log summary, the blockchain evidence storage module standardizes the authorization certificate and the call log using unified encoding, unified delimiter and fixed field order, respectively. It calculates the summary using the SM3 algorithm and writes the summary and standardized data into the blockchain to obtain the evidence storage transaction identifier; the fixed field order is consistent for both.

[0019] Furthermore, the blockchain evidence storage module records the response summary in the call log and inserts it into the calculation input of the log summary along with the status version number; during auditing and verification, the authorization summary and the log summary and their corresponding evidence storage transaction identifier are matched with the authorization number plus the status version number as the key. When the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the access IP is not in the access IP whitelist, unauthorized evidence is generated and solidified into the blockchain.

[0020] Furthermore, the consistency verification module retrieves the authorization certificate and call log from the blockchain using the authorization number plus the status version number as a composite key. It reconstructs the normalized string according to the unified encoding, unified delimiter and fixed field order, and recalculates the authorization digest and log digest using the SM3 algorithm. When any digest is inconsistent with the on-chain digest, the record is marked as invalid and the reason is output. Otherwise, the authorized call time range, access IP whitelist and authorized call limit are checked one by one in ascending order of call time. For those that do not meet the requirements, unauthorized evidence containing the authorization digest, log digest and corresponding evidence transaction identifier is generated and solidified on the blockchain.

[0021] Compared with existing technologies, the beneficial effects of this invention are as follows: Through a multi-factor authentication mechanism, real-person authentication of user identity and authenticity of authorized actions are ensured; through the authorization contract module, an incrementing status version number mechanism and a short-term invoice summary anti-tampering mechanism are introduced to ensure that each authorization status is unique and verifiable, preventing the reuse of old invoices and cross-version unauthorized access; by embedding a request signature based on the SM3 algorithm when accessing the integrated data platform of the government network, transmission integrity and anti-duplicate verification are achieved; through the blockchain evidence storage module, authorization certificates and call logs are stored on the blockchain with the same field order and the same hash algorithm, constructing a traceable and verifiable authorization and call correspondence; furthermore, combined with the consistency verification module, the authorization number and status version number are matched and compared to achieve automatic detection and evidence solidification of unauthorized calls; finally, through the user permission management module, the dynamic modification and revocation of authorization status are supported, constructing a highly secure data processing system with anti-counterfeiting, anti-tampering, traceability, and revocation characteristics, improving the data security, credibility, compliance, and auditability in government and public data sharing scenarios.

[0022] On the other hand, this application also provides a data processing method for multi-factor authentication and blockchain evidence storage, applied to the aforementioned data processing system for multi-factor authentication and blockchain evidence storage, including:

[0023] When a user initiates data authorization, the ID number is compared with the face. When the matching degree reaches the matching degree threshold, an authentication serial number is generated, and an authentication SMS is sent to the registered mobile phone number to complete the secondary confirmation. The verification result and the authentication serial number are written into the authorization certificate.

[0024] A blockchain authorization contract is generated based on user authorization and a status version number is set. Each time an authorization takes effect, is modified, or is revoked, the status version number is incremented and a short-term note is generated. The short-term note includes an authorization number, a status version number, and an expiration time. A note digest is generated by calculating the note digest using the SM3 algorithm. The note automatically expires when it expires or the version is inconsistent. At the same time, the authorization call time range, the upper limit of the number of authorization calls, and the access IP whitelist are set in the contract.

[0025] After authorization verification is successful, government data is read through the integrated public data platform of the government network, and a request signature generated based on the SM3 algorithm is added to the request;

[0026] The authorization credential and call log are stored on the blockchain under the same rules. The authorization credential records the authorization number, authentication serial number, authorization policy, and status version number, and generates an authorization digest. The call log records the authorization number, call time, access IP, status version number, and response digest, and generates a log digest. The authorization digest and log digest are generated using the same field order and the SM3 algorithm and stored on the blockchain. The authorization credential and call log are matched according to the authorization number and status version number. The authorization digest and log digest are recalculated and their consistency is compared. When the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the access IP is not in the access IP whitelist, unauthorized evidence is generated and stored on the blockchain.

[0027] The authorization status is displayed on the user side and modification or revocation operations are supported. When the verification conditions are met, a new authorization contract is generated and put on the chain or the original contract is invalidated.

[0028] It is understandable that the data processing methods and systems for multi-factor authentication and blockchain-based evidence storage have the same beneficial effects, and will not be elaborated further here. Attached Figure Description

[0029] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0030] Figure 1 A structural block diagram of the data processing system for multi-factor authentication and blockchain evidence storage provided in this embodiment of the invention;

[0031] Figure 2 A flowchart of a data processing method for multi-factor authentication and blockchain evidence storage provided in an embodiment of the present invention. Detailed Implementation

[0032] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the disclosure to those skilled in the art. It should be noted that, unless otherwise specified, embodiments and features in the embodiments of the present invention can be combined with each other. The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0033] In traditional government data sharing systems, identity authentication relies on a single account password or digital certificate, lacking deep integration with a trusted identity authentication platform. This results in a single verification factor and an inability to prevent forgery attacks. Authorization credentials and call logs are scattered across different subsystems, lacking a standardized processing mechanism with a unified field order and digest algorithm, making it difficult to verify data integrity during cross-system tracing. Authorization tokens do not incorporate a state version number increment mechanism, meaning old tokens may still be maliciously reused after authorization policy changes, posing a risk of unauthorized cross-version calls. Furthermore, the general hash algorithm does not meet national cryptographic standards, leading to compliance deficiencies in data transmission and evidence storage.

[0034] For example, in scenarios involving cross-departmental government data access, users initiate data authorization requests after completing basic authentication through a unified identity platform. Due to the lack of multi-factor authentication, attackers can directly forge authorization operations using leaked account passwords. The generated authorization credentials are stored in the local database of the business system, while the call logs are recorded in a separate log server of the government data platform; the field order and hash algorithm of these two systems are inconsistent. When auditors need to verify the legitimacy of a call, they must extract data from both systems and manually compare them, which is risky for tampering and inefficient. Furthermore, the authorization token is not bound to a status version number; when a user modifies the authorization policy, the old token can still be illegally accessed through the caching mechanism, leading to data leakage. The use of the SHA-256 algorithm to generate request signatures when accessing government data violates the mandatory requirements of national cryptographic algorithms for government systems, presenting a compliance vulnerability.

[0035] If the above issues are not addressed, attackers can exploit the vulnerability of a single authentication factor to forge user identities and illegally obtain data access permissions. Distributed storage of authorization credentials and call logs, lacking a standardized evidence preservation mechanism, fails to achieve end-to-end tamper-proof verification, leading to reduced reliability of audit results. Unversioned authorization tokens experience permission drift after policy changes, making it difficult to prevent unauthorized calls in real time. Using non-national cryptographic algorithms directly violates government system security regulations, causing data sharing processes to fail compliance reviews.

[0036] For this, please refer to Figure 1As shown, this application proposes a data processing system for multi-factor authentication and blockchain notarization, including: an identity authentication module, used to perform multi-factor identity verification when a user initiates data authorization. Multi-factor identity verification includes comparing the ID card number with a face; after the matching degree reaches a matching degree threshold, an authentication serial number is generated, and an authentication SMS is sent to the registered mobile phone number to complete secondary confirmation. The verification result and authentication serial number are written into the authorization certificate. An authorization contract module is used to generate a blockchain authorization contract based on user authorization and set a status version number. The status version number is an incrementing version identifier for each effective / modified / revoked authorization contract. Each time authorization takes effect, is modified, or revoked, the status version number is incremented and a short-term ticket is generated. The short-term ticket includes an authorization number, a status version number, and an expiration time. An SM3 algorithm is used to calculate a ticket digest for tamper-proof verification, and the ticket becomes invalid upon expiration or version inconsistency. The authorization contract sets the authorization call time range, the maximum number of authorization calls, and an access IP whitelist. A government data access module is used to read government data through the integrated public data platform of the government network after authorization verification, and adds a request signature generated based on the SM3 algorithm to the request to verify transmission integrity. The blockchain notarization module stores authorization credentials and call logs on the blockchain according to the same rules. The authorization credential records the authorization number, authentication serial number, authorization policy, and status version number, and generates an authorization digest. The call log records the authorization number, call time, access IP, status version number, and response digest, and generates a log digest. The authorization digest and log digest are generated using the same field order and the SM3 algorithm. The consistency verification module matches the authorization credential and call log based on the authorization number and status version number. The user permission management module displays the authorization status and performs modification or revocation operations. When the verification conditions are met, it generates a new authorization contract on the blockchain or invalidates the original contract.

[0037] Specifically, multi-factor authentication includes, but is not limited to, using the Trusted Identity Authentication Platform (CTID) to cross-verify a user's ID number and face. This can be achieved through ID information and facial image feature extraction and similarity matching algorithms to ensure identity authenticity. The authentication serial number is a unique identifier generated after multi-factor authentication, which can be generated using a combination of timestamps, random numbers, and hash operations, used to associate authorization credentials with the verification process. The blockchain authorization contract is a smart contract that records the user's authorization strategy. It can be written in a blockchain scripting language and deployed to nodes, updating the authorization status through an incrementing state version number mechanism. The state version number is a sequence number that increments with each change to the authorization contract, implemented using an integer counter to identify the latest version of the contract and prevent the reuse of old documents. The short-term document is a temporary document containing an authorization number, state version number, and expiration date. It can be encapsulated in JSON format and have a document digest generated using the SM3 algorithm to ensure data integrity and tamper-proofing. The authorized call time range refers to the valid period for data calls, defined using start and end timestamps to constrain the timeliness of the call operation. The access IP whitelist refers to a list of network addresses allowed to initiate data calls. It can be stored in CIDR format and matched against the request source IP to restrict unauthorized access. The request signature is a government data request verification value generated based on the SM3 algorithm. It can be implemented by concatenating fixed fields and calculating a hash value to verify the integrity of the transmission process. On-chain evidence storage with the same rules means that the authorization credential and the call log use the same field order and the same SM3 algorithm to generate a digest. This can be implemented using unified data serialization rules to ensure the consistency of the stored data. The authorization digest and log digest are hash values ​​calculated from the authorization credential and the call log, respectively. They can be generated using the SM3 algorithm to process and normalize the data for subsequent consistency verification.

[0038] This application integrates multi-factor authentication, blockchain-authorized contract state version control, and a consistent rule-based on-chain evidence storage mechanism to construct a fully tamper-proof and traceable data processing system. This system combines CTID authentication, SM3 national cryptographic algorithm digest generation, and dynamic expiration rules for short-term bills with blockchain evidence storage, solving the problems of insufficient identity verification strength, scattered storage of authorization certificates, cross-version unauthorization risks, and inconsistent evidence storage data in existing technologies.

[0039] The working process and principle of this application are as follows: the data processing system for multi-factor authentication and blockchain evidence storage includes an identity authentication module, an authorization contract module, a government data access module, a blockchain evidence storage module, a consistency verification module, and a user permission management module.

[0040] The identity authentication module performs multi-factor authentication when a user initiates data authorization. The verification process can be based on the trusted identity authentication platform CTID, comparing the user's ID number with their face. Once the match rate reaches a preset threshold, an authentication serial number is generated. The system sends an authentication SMS to the user's registered mobile phone number for secondary confirmation. The verification result and authentication serial number are written into the authorization credential. In this system, SMS secondary authentication is mainly used for authorization confirmation scenarios where third parties access user data. When a user initiates authorization directly within a proprietary system or performs data authorization within a government-owned application, the system can perform only CTID verification without sending SMS authentication again, thus reducing interaction redundancy.

[0041] The authorization contract module generates a blockchain authorization contract based on user authorization and sets an initial state version number. Each time an authorization takes effect, is modified, or revoked, the module increments the state version number and generates a short-term note. The short-term note contains the authorization number, state version number, and expiration time, and a note digest is generated using the SM3 algorithm for tamper-proof verification. The note automatically expires upon expiration or if the version is inconsistent. The authorization contract sets the authorization call time range, the maximum number of authorization calls, and an access IP whitelist.

[0042] After successful authorization and verification, the government data access module reads government data through the integrated public data platform of the government network. The module adds a request signature generated based on the SM3 algorithm to the request to verify the integrity of the transmission.

[0043] The blockchain notarization module stores authorization credentials and call logs on the blockchain using the same rules. The authorization credential records the authorization number, authentication serial number, authorization policy, and status version number, and generates an authorization digest. The call log records the authorization number, call time, accessing IP, status version number, and response digest, and generates a log digest. Both the authorization digest and the log digest are generated using the same field order and the SM3 algorithm.

[0044] The consistency verification module matches the authorization credential with the call log based on the authorization number and status version number to achieve cross-system consistency verification.

[0045] The user permission management module displays the authorization status and performs modification or revocation operations. When the verification conditions are met, a new authorization contract is generated and uploaded to the blockchain, or the original contract is invalidated, realizing dynamic management of authorization.

[0046] The modules work collaboratively to achieve trusted control over the entire process, from identity authentication and authorization management to data access. Multi-factor authentication enhances the security of identity verification. Status version numbers and short-term ticket mechanisms prevent the unauthorized reuse of authorization tokens. On-chain storage of evidence according to the same rules ensures the consistency and immutability of authorization credentials and call logs. The entire process uses the SM3 algorithm, meeting the requirements of national cryptographic standards.

[0047] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0048] The identity authentication module first receives a data authorization request from the user. The module calls the CTID platform's API, passing in the user's ID number and a real-time captured facial image. The CTID platform returns the comparison result and matching score. When the matching score exceeds 90%, the module generates a 32-bit random string as the authentication serial number. The system sends an SMS message containing a 6-digit random verification code to the user's registered mobile phone number. The user enters the verification code to complete secondary confirmation. The module then writes the verification result returned by CTID, the authentication serial number, and the verification timestamp into the authorization credential.

[0049] The authorization contract module generates a smart contract containing the authorization policy based on the user's selected authorization content and deploys it to the blockchain network. The initial state version number of the contract is set to 1. When the user modifies the authorization scope, the module increments the state version number and updates the contract content. The module generates a short-term note containing a 16-digit authorization number, a 4-digit state version number, and an expiration time in Unix timestamp format. These fields are concatenated in a fixed order and a 32-byte note digest is calculated using the SM3 algorithm. The note's validity period is set to 30 minutes. The contract sets the authorization call time range to 9:00-17:00 on weekdays, the maximum number of calls to 100 per day, and the access IP whitelist to include specified government network segments.

[0050] When the government data access module receives a data request, it first verifies the validity of the short-term invoice. The module then retrieves government data within the authorized scope from the integrated public data platform. The request includes the current timestamp, a 16-bit random string (nonce), the authorization number, the status version number, the SM3 digest of the request body, and the application key (appkey), which are concatenated in a fixed order and calculated using the SM3 algorithm to obtain the request signature.

[0051] The blockchain notarization module standardizes authorization credentials and call logs. Authorization credentials include fields such as authorization number, authentication serial number, authorization policy JSON string, and status version number. Call logs include fields such as authorization number, Unix timestamp format call time, accessing IP address, status version number, and SM3 digest of response data. The module concatenates strings using a unified UTF-8 encoding, the "|" separator, and predefined field order, and calculates a 32-byte authorization digest and log digest using the SM3 algorithm. The digests and original data are written to the blockchain transaction.

[0052] The consistency verification module uses the "authorization number-status version number" composite key to query authorization credentials and call logs from the blockchain. The module repeats the normalization and digest calculation steps, comparing the calculation result with the on-chain digest. The module checks if the call time is within the authorized range, if the accessing IP is in the whitelist, and if the number of calls exceeds the limit. For records that do not meet the conditions, the module generates evidence containing the authorization digest, log digest, and corresponding transaction hash and writes it to the blockchain.

[0053] The user permission management module displays the current authorization status through a web interface. Users can view authorization details, modify the scope of authorization, or revoke authorization. The module calls the identity authentication process in the background to re-verify the user's identity. After successful verification, the module calls the authorization contract module to generate a new smart contract and deploy it on the blockchain, or marks the original contract as revoked.

[0054] Through the above scheme, this application achieves trusted control over the entire process of government data processing based on multi-factor authentication and blockchain notarization. The multi-factor mechanism of CTID face comparison and SMS secondary confirmation improves the accuracy and anti-counterfeiting capabilities of identity verification. The incrementing status version number and short-term ticket mechanism prevent the unauthorized reuse of authorization tokens and reduce the risk of unauthorized cross-version calls. Authorization credentials and call logs are stored on the blockchain using a unified field order and the SM3 algorithm, ensuring data integrity and immutability, and facilitating subsequent auditing and traceability. The entire process uses the national cryptographic SM3 algorithm, meeting the compliance requirements of the government system. The system achieves refined management of user authorization and full controllability of data access through technical means, ensuring the security and standardization of government data sharing.

[0055] In some of the schemes described above in this application, the identity authentication module writes the verification result and authentication serial number into the authorization certificate after completing the CTID verification. However, there is a risk that the verification result and authentication serial number may be tampered with during transmission or storage, which makes it impossible to verify the authenticity of the authorization certificate.

[0056] This application further proposes that after the identity authentication module completes CTID verification, it concatenates the authentication serial number, registered mobile phone number, and authentication timestamp in a fixed order and calculates the authentication digest using the SM3 algorithm, and writes it into the authorization credential along with the verification result.

[0057] The fields are concatenated in a fixed order, using the authentication serial number, registered mobile phone number, and authentication timestamp to ensure consistency of the concatenation results across different scenarios. The SM3 algorithm performs a one-way hash calculation on the concatenated string to generate a fixed-length authentication digest. The authentication digest and verification result are simultaneously written to the authorization credential, forming an inseparable data combination.

[0058] Specifically, after completing CTID verification, the identity authentication module first extracts three fields: authentication serial number, registered mobile phone number, and authentication timestamp, and concatenates them into a string according to a preset order. For example, the authentication serial number uses a 32-bit uppercase alphanumeric encoding, the registered mobile phone number is 11 digits, and the authentication timestamp uses the ISO 8601 standard format; these three are connected by underscores to form a standardized string. This string is processed by the SM3 algorithm to generate a 256-bit authentication digest, which is written into the authorization credential along with the verification result. In subsequent data retrieval stages, by reconstructing the same fields and calculating the SM3 digest, the credential can be verified to ensure it has not been tampered with. If the order or content of the concatenated fields changes, the generated digest will differ from the original digest stored on the blockchain, thus triggering a verification failure mechanism.

[0059] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0060] After completing CTID verification, the identity authentication module concatenates the authentication serial number, registered mobile phone number, and authentication timestamp in a fixed order and calculates the authentication digest using the SM3 algorithm. This digest is then written into the authorization credential along with the verification result. Specifically, the identity authentication module first receives the user's submitted ID card number and facial image, sending this information to the CTID platform for verification. The CTID platform returns the verification result and matching score. When the matching score reaches a preset threshold, the identity authentication module generates a unique authentication serial number. Subsequently, the module sends an SMS containing a verification code to the user's registered mobile phone number, and the user enters the verification code to complete secondary confirmation.

[0061] Furthermore, the identity authentication module concatenates the authentication serial number, registered mobile phone number, and authentication timestamp in a fixed order, such as the format "Authentication Serial Number | Registered Mobile Phone Number | Authentication Timestamp". Then, the module uses the national cryptographic algorithm SM3 to perform a hash calculation on the concatenated string, generating a fixed-length authentication digest. Finally, the identity authentication module writes the CTID verification result, the authentication serial number, and the calculated authentication digest into the authorization credential. Thus, the authorization credential not only contains the verification result but also the authentication digest that can be used for subsequent verification, enhancing the credential's credibility and tamper-proof capabilities.

[0062] Through the above technical solution, this application achieves complete recording and tamper-proof protection of the identity authentication process. By employing fixed field sequence concatenation and the SM3 algorithm to calculate the authentication digest, the integrity and immutability of the authentication information are improved. Writing the authentication digest along with the verification result into the authorization credential makes the authorization credential a more trustworthy and secure identity authentication credential. This method not only enhances the reliability of identity authentication but also provides a more reliable foundation for authorization operations and data access, preventing security risks such as identity impersonation and authorization forgery.

[0063] In some of the solutions described above in this application, the identity authentication module performs ID card number and face comparison and generates authentication serial number through the trusted identity authentication platform CTID. However, the operator's biometric activity is not verified before submitting the verification request, which may pose a risk of using static face images or forged identity information to initiate verification, leading to identity theft.

[0064] This application further proposes that the identity authentication module perform a liveness detection before submitting the verification to CTID. Only after the liveness detection is successful should the ID number and facial image be submitted for verification. The matching threshold is set to no less than 90%. The unique verification identifier returned by CTID is bound to the authentication serial number and written into the authorization credential.

[0065] The liveness detection process employs dynamic motion recognition or micro-expression analysis technology. It captures real-time facial images of the user via a camera and detects biometric features such as blinking, mouth opening, or head movement to ensure the operator is a real, living person. A matching threshold of over 90% is set, and by adjusting the image acquisition angle, lighting compensation, and feature point comparison algorithms, the system reduces the false positive rate and avoids verification failures due to environmental interference. A unique verification identifier is generated by the CTID platform and appended to the verification result, forming a one-to-one mapping with the authentication serial number to ensure the traceability of the verification process.

[0066] Specifically, when a user initiates data authorization, the identity authentication module first starts a liveness detection process, requiring the user to complete specified actions according to on-screen prompts. The camera captures continuous frames of images and extracts biometric features; if non-liveness features are detected, the process terminates. After successful liveness detection, the module submits the user's input ID number to the CTID platform for comparison. When the similarity calculation result reaches 90%, an authentication serial number is generated, and the unique verification identifier returned by the CTID platform is bound to this serial number and written into the authorization credential. This pre-verification through liveness detection intercepts forged biometric data. The matching threshold is set above 90% to reduce verification failures due to image quality while ensuring verification accuracy. The binding relationship between the unique verification identifier and the authentication serial number ensures that each verification operation has a unique verifiable identifier, facilitating subsequent auditing and traceability.

[0067] As a preferred embodiment, the solution of this application is implemented as follows: The identity authentication module performs a liveness detection before submitting the verification to CTID. After the liveness detection is successful, the ID number and facial image are submitted for verification. The matching threshold is set to no less than 90%. The unique verification identifier returned by CTID is bound to the authentication serial number and written into the authorization certificate.

[0068] Specifically, liveness detection uses a random combination of actions such as blinking, opening the mouth, and shaking the head. Users must complete the specified actions as prompted by the system. The system captures and analyzes the user's actions via camera to determine if it is a real person performing the actions. After successful liveness detection, the system submits the user's uploaded ID number and the real-time captured facial image to the CTID platform for comparison. The comparison result returned by the CTID platform includes a matching score; a score of 90 or higher is considered a successful match. At this point, the CTID platform generates a unique verification identifier. The identity authentication module binds this identifier to the authentication serial number generated by the system and writes the binding result into the authorization credential.

[0069] Through the above technical solutions, this application improves the security and reliability of identity authentication. Liveness detection effectively prevents impersonation using static data such as photos and videos, ensuring that the verified user is a genuine user. Setting a high matching threshold reduces the risk of identity theft. The binding of the unique CTID verification identifier to the authentication serial number ensures a unique association of the identity authentication result, providing a reliable basis for authorization and auditing. This multi-layered protection mechanism enhances the credibility of the entire system's identity authentication, laying a solid foundation for data authorization and access control.

[0070] In some of the solutions described above in this application, the field concatenation order and summary generation rules are not clearly defined when the authorization contract module generates short-term notes. This may cause verification failures due to differences in field order when different modules generate or verify note summaries. At the same time, there is a lack of a synchronous verification mechanism for the status version number, which poses a risk that old version notes may be misused or tampered with.

[0071] This application further proposes that when issuing short-term notes, the authorization contract module concatenates the fields in a fixed order of authorization number, status version number, and maturity date, and calculates the note digest using the SM3 algorithm. Upon receiving a data call request, the short-term note is first checked for digest consistency and status version number consistency; if either is inconsistent, the short-term note is deemed invalid.

[0072] The fixed field order concatenation ensures data structure consistency for the authorization number, status version number, and expiration time, preventing deviations in summary calculation results due to differences in field arrangement. The SM3 algorithm generates a bill summary, providing a foundation for tamper-proof verification. Its collision resistance and one-way nature ensure that the summary is irreversible and uniquely corresponds to the original data. In the dual verification mechanism, the summary consistency check verifies the integrity of the bill content, while the status version number consistency check confirms that the authorization contract corresponding to the bill is in the latest effective version. Both logics are executed in parallel, and failure to meet either condition triggers a bill invalidation determination.

[0073] Specifically, when the authorization contract module generates a short-term note, it first combines the authorization number, status version number, and expiry time into a normalized string in a preset order, and inputs it into the SM3 algorithm to generate a fixed-length note digest. Upon receiving a data request, the module extracts the short-term note from the request, reassembles the fields in the same order, calculates the digest, and compares it with the digest recorded in the note. If the digests match, it further checks whether the status version number in the note matches the latest version number of the current authorization contract. If the digest verification fails or the version number is inconsistent, the module immediately terminates the request processing and marks the note as invalid. For example, if an attacker tampers with the expiry time field in the note, the recalculated digest will not match the original digest, triggering a verification failure. When a user revokes authorization, causing the version number to increment, older version notes are automatically rejected due to version number mismatches, preventing the unauthorized reuse of historical notes.

[0074] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0075] When issuing short-term notes, the authorization contract module concatenates the authorization number, status version number, and maturity date in a fixed order, and then calculates the note digest using the SM3 algorithm. Specifically, the authorization number can be a 32-bit random string, the status version number is an incrementing integer, and the maturity date uses a Unix timestamp format. These three fields are concatenated into a string in a fixed order, and then the SM3 algorithm is used to hash this string to obtain a 32-byte note digest.

[0076] Upon receiving a data request, the authorization contract module first performs a digest consistency check and a status version number consistency check on the short-term note. The specific steps are as follows:

[0077] Extract short-term note information from the request, including the authorization number, status version number, maturity date, and note summary.

[0078] The bill digest is recalculated using the same field order and the SM3 algorithm.

[0079] The calculated summary is compared with the document summary in the request.

[0080] At the same time, check whether the status version number in the request is consistent with the latest status version number currently recorded by the system.

[0081] If the summary or status version number is inconsistent, the short-term ticket is deemed invalid, and the data access request is rejected.

[0082] Through the above technical solution, this application implements a short-term invoice anti-tampering mechanism based on the SM3 algorithm, preventing invoices from being forged or altered. Simultaneously, by verifying the consistency of the status version number, it ensures that only the most recently valid authorization can be used, avoiding the risk of unauthorized reuse of older authorizations. This mechanism improves the security and controllability of data access, providing strong protection for sensitive data.

[0083] In some of the solutions mentioned above in this application, if the deduction operation and the recording operation are not atomic when the authorization contract module manages the upper limit of authorized call counts, it may lead to the remaining value after deduction being inconsistent with the actual number of calls. Old version tickets may be misused due to not being expired in time, which may cause the risk of unauthorized access.

[0084] This application further proposes that the authorization contract module adopts an atomic deduction mechanism for the upper limit of authorized call counts, and records the status version number and remaining count value of the call within the same transaction after successful deduction. When the authorized call time range expires, the upper limit of authorized call counts reaches zero, or a revocation instruction is received, the module increments the status version number and stops issuing short-term tickets, while simultaneously writing a version change record and reason code to the blockchain.

[0085] The atomic deduction mechanism ensures the indivisibility of deduction and recording operations through database transactions, such as using transaction locks or optimistic locking. Within the same transaction, when recording the status version number and remaining count, the status version number identifies the validity of the currently authorized contract, and the remaining count reflects the remaining number of calls in real time. The version change record includes the change time, change reason code, and the changed status version number. The reason code distinguishes between different scenarios such as time expiration, count reaching zero, or active revocation.

[0086] Specifically, upon receiving a data access request, the system first verifies the validity of the short-term ticket. Then, within an atomic transaction, it deducts the authorized access count, writing the current state version number and the remaining value after deduction to the database within the same transaction. For example, if the initial access limit is 10 accesses, the remaining value after deduction is updated to 9 accesses, and the current state version number is recorded as V1. If the remaining value reaches zero, the system automatically increments the state version number to V2, stops issuing short-term tickets based on V1, and records the reason for the version change as "access exhausted" on the blockchain. Subsequent requests carrying V1 version tickets are rejected due to the inconsistent state version numbers. This linkage mechanism of atomic deduction and version number increment ensures the accuracy of access count statistics and the consistency of version status, preventing unauthorized access issues caused by the reuse of older version tickets.

[0087] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0088] The authorization contract module employs an atomic deduction mechanism for the maximum number of authorized calls, recording the status version number and remaining count value of the call within the same transaction after successful deduction. When the authorized call timeframe expires, the maximum number of authorized calls reaches zero, or a revocation instruction is received, the module increments the status version number and stops issuing short-term tickets, while simultaneously writing a version change record and reason code to the blockchain.

[0089] Specifically, the authorization contract module maintains an authorization call count counter, initially set to the maximum number of user authorization calls. Each time a data call request is received, the module first checks if the authorization is valid. If valid, it attempts to atomically decrement the counter. If the decrement is successful, the module updates the status version number corresponding to this call within the same database transaction and records the remaining value of the counter.

[0090] Furthermore, the module continuously monitors the validity of authorizations. When it detects that the authorization call time range has expired, the counter has reached zero, or a user's revocation instruction has been received, the module immediately performs the following operations: First, it increments the status version number. Second, it stops issuing new short-term tickets for that authorization. Finally, it writes a version change record on the blockchain, including the new status version number, the change timestamp, and the corresponding reason code (e.g., "1" indicates time expired, "2" indicates the number of uses has been exhausted, and "3" indicates the user has actively revoked the authorization).

[0091] As a result, the system can precisely control the number of times each authorization is used and update the status in a timely manner when the authorization expires, preventing the authorization from being abused or used beyond one's authority.

[0092] Through the above technical solutions, this application achieves precise control and real-time monitoring of authorized usage. The atomic deduction mechanism ensures the accuracy of authorized usage counts, avoiding counting errors caused by concurrent access. The incrementing status version number and the mechanism for ceasing the issuance of short-term tickets prevent the continued use of expired authorizations. Simultaneously, writing version change records and reason codes to the blockchain provides an immutable authorization status change log, facilitating subsequent auditing and traceability. These measures collectively improve the security and controllability of data access, reducing the risk of data leakage and misuse.

[0093] In some of the solutions mentioned above in this application, the government data access module does not use a fixed field order and SM3 algorithm for normalization when generating request signatures, which leads to the risk of request data being tampered with or replayed during transmission, and cannot effectively verify the legitimacy of the request source and the integrity of the data.

[0094] This application further proposes that when generating a request signature, the government data access module should concatenate the timestamp, a random string (nonce), authorization number, status version number, request body digest, and appkey in a fixed order, and calculate the request signature using the SM3 algorithm. The government side recalculates the request body digest and request signature within a time window and verifies that the nonce has not been reused; if any of these conditions are not met, the returned data is rejected.

[0095] The fixed-field sequence includes six elements: timestamp, nonce, authorization number, status version number, request body digest, and appkey. Predefined arrangement rules ensure the uniqueness and consistency of the concatenated string. The SM3 algorithm, a national standard hash function, performs a one-way irreversible computation on the concatenated string to generate a fixed-length request signature. The random string nonce is a unique value generated by the system and can only be used once within a time window. The government side maintains a set of used nonces to prevent replay verification. The timestamp is associated with the authorized call time range to ensure the request is executed within its validity period. The status version number is synchronized with the version number in the authorization contract module to avoid data call anomalies due to contract version expiration. The appkey, as an identity identification key issued by the system, participates in the signature calculation to verify the caller's legitimacy.

[0096] Specifically, when the government data access module initiates a data request, it first obtains the current timestamp and generates a random nonce value. Then, it concatenates the timestamp, nonce, authorization number, status version number, request body digest, and appkey into a standardized string in a fixed order. The string is then hashed using the SM3 algorithm to generate a request signature, which is appended to the request header. Upon receiving the request, the government side extracts the timestamp to verify if the request is within a valid time window and checks if the nonce has already been recorded. If the timestamp is valid and the nonce is not duplicated, the request signature is recalculated using the same field order and algorithm, and compared with the signature in the request. If they match and the request body digest matches the result calculated by the government side, the request is deemed legitimate and the data is returned. For example, if an attacker tampers with the request body content, the request body digest will change, causing the recalculated signature on the government side to differ from the original signature, thus triggering a rejection response mechanism. This dual protection of a fixed field order and the SM3 algorithm prevents data from being tampered with or forged during transmission. Furthermore, the collaborative mechanism of timestamps and nonces prevents malicious replay of historical requests.

[0097] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0098] When generating a request signature, the government data access module concatenates fields in a fixed order. Specifically, it first concatenates the timestamp, the random string nonce, the authorization number, the status version number, the request body digest, and the appkey in this order. For example, the timestamp can use the Unix timestamp format, the nonce can be a 16-bit random string, the authorization number and status version number are obtained from the authorization contract, the request body digest is a 32-byte digest value obtained by performing an SM3 hash calculation on the request body content, and the appkey is a unique identifier assigned to the caller.

[0099] After concatenation, the concatenated result is hashed using the SM3 algorithm to obtain the final request signature. This signature is added to the data request to verify the request's legitimacy and completeness.

[0100] Upon receiving a data request, the government side performs a series of verification steps. First, it checks if the request's timestamp is within the allowed time window, typically set to 5 minutes. Second, it recalculates the SM3 digest of the request body and compares it with the digest carried in the request to ensure the request content has not been tampered with. Then, it recalculates the request signature using the same field order and SM3 algorithm and compares it with the received signature. Finally, it checks if the nonce has been used before to prevent replay attacks.

[0101] If all the above verification steps pass, the government side will process the data request and return the corresponding data. If any verification step fails, the data will be rejected and an corresponding error message will be returned.

[0102] Through the above technical solutions, this application achieves a high level of security and integrity assurance in the process of government data access. By using a fixed field order and the SM3 algorithm to generate request signatures, tampering or forgery of requests is prevented. Time window checks and nonce uniqueness verification further enhance system security and prevent replay attacks. Verification of the request body digest ensures the integrity of the data request. These measures collectively construct a reliable government data access mechanism, improve the security and credibility of data exchange, and provide strong protection for the secure sharing of government data.

[0103] In some of the solutions described above in this application, there may be inconsistencies in the field order or encoding methods in the storage of authorization credentials and call logs, making it difficult to accurately identify data tampering or processing errors through summary comparison during subsequent auditing.

[0104] This application further proposes that when generating authorization digests and log digests, the blockchain evidence storage module uses unified encoding, unified delimiters, and a fixed field order to standardize the authorization credentials and call logs respectively. The digest is calculated using the SM3 algorithm, and the digest and standardized data are written together into the blockchain to obtain the evidence storage transaction identifier. The fixed field order remains consistent for both.

[0105] In this context, unified encoding refers to using standardized encoding formats such as UTF-8 or Base64 for fields like the authorization number, authentication serial number, authorization policy, and status version number in the authorization credential, as well as fields like the authorization number, call time, access IP, status version number, and response digest in the call log. Unified separators use invisible characters or specific symbols, such as the vertical bar "|" or the hash symbol "#". A fixed field order requires that the fields contained in the authorization credential and call log be arranged in a preset order during concatenation. For example, the authorization credential is concatenated in the order of "authorization number | authentication serial number | authorization policy | status version number", and the call log is concatenated in the order of "authorization number | call time | access IP | status version number | response digest". The SM3 algorithm calculates a digest from the normalized concatenated string and writes the original normalized data and the digest together into the blockchain transaction.

[0106] Specifically, when authorization credentials are generated, the module extracts the authorization number, authentication serial number, authorization policy, and status version number fields, arranges them in a fixed order, inserts a uniform delimiter to form a normalized string, and generates an authorization digest through SM3 calculation. When call logs are generated, the module extracts the authorization number, call time, access IP, status version number, and response digest fields, concatenates them in a corresponding fixed order to form a normalized string, and generates a log digest. The generation process of both digests uses the same field order, encoding rules, and delimiters to ensure that the normalized string can be reconstructed using the same rules during subsequent auditing. For example, if the normalized string of the authorization credentials is "A001|S20250901001|Policy A|V1", and the normalized string of the call log is "A001|2025-09-01 10:00:00|192.168.1.1|V1|HASH123", both will obtain unique digest values ​​through SM3 calculation. During the audit phase, by reassembling the fields and calculating the digest, it is possible to verify whether the original data stored on the chain has been tampered with. At the same time, by comparing the associated fields of the authorization digest and the log digest, it is possible to identify whether there is any unauthorized call behavior.

[0107] As a preferred embodiment, the solution of this application is specifically implemented as follows:

[0108] When generating authorization and log digests, the blockchain evidence storage module first standardizes the authorization credentials and call logs. Specifically, both authorization credentials and call logs are encoded in UTF-8, using "|" as a uniform separator, and concatenated according to a fixed field order. For example, the field order of the authorization credentials could be "Authorization Number | Authentication Serial Number | Authorization Policy | Status Version Number", and the field order of the call logs could be "Authorization Number | Call Time | Access IP | Status Version Number | Response Digest".

[0109] Furthermore, the SM3 algorithm is used to calculate a digest of the normalized data. The SM3 algorithm is a cryptographic hash algorithm standard issued by the State Cryptography Administration, with an output length of 256 bits. The calculated digest value is written to the blockchain along with the normalized data, and a corresponding notarization transaction identifier is obtained.

[0110] Therefore, authorization credentials and call logs use the same field order and SM3 algorithm to generate digests, ensuring the consistency and comparability of the stored data. This unified standardization process and digest generation mechanism provides a foundation for consistency verification and audit reconciliation.

[0111] Through the above technical solutions, this application achieves unified and standardized processing and digest generation of authorization credentials and call logs, improving the consistency and verifiability of data storage. Employing the SM3 national cryptographic algorithm for digest calculation enhances data security and meets the security requirements of government-level applications. By storing the digest along with the standardized data on the blockchain, a complete evidence storage chain is formed, facilitating auditing and traceability. This rule-based on-chain evidence storage mechanism solves the problem of accurately matching authorization records with call behaviors, providing technical support for achieving end-to-end trusted traceability and tamper-proof management.

[0112] In some of the solutions mentioned above in this application, although the authorization credentials and call logs use a unified field order and the SM3 algorithm to generate digests, they cannot effectively identify whether the call time, number of calls, or access IP exceeds the authorized scope during auditing and verification, making it difficult to detect unauthorized behavior in a timely manner and solidify evidence.

[0113] This application further proposes that the blockchain evidence storage module records the response digest in the call log and includes the status version number as the calculation input for the log digest. During auditing and verification, the authorization digest and the log digest, along with their corresponding evidence storage transaction identifiers, are matched using the authorization number plus the status version number as the key. When the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the access IP is not in the access IP whitelist, unauthorized evidence is generated and solidified into the blockchain.

[0114] The response digest of the call log is generated by calculating the response body returned by the government data access module using the SM3 algorithm. This digest, along with the status version number, serves as the input element for the log digest. During auditing and verification, a composite key is constructed using the authorization number and the status version number to extract the corresponding authorization credential and call log from the blockchain. The access IP whitelist is verified by comparing it against the IP address list set by the authorization contract module, and the maximum number of calls is verified using the remaining value recorded by the atomic deduction mechanism. Evidence of unauthorized access includes the authorization digest, the log digest, and the corresponding evidence transaction identifier. After generating an evidence digest using the SM3 algorithm, it is written to the blockchain.

[0115] Specifically, during the call log generation process, the response data returned by the government data access module is processed using the SM3 algorithm to generate a response digest. This digest, along with the call time and access IP, is written into the call log. The blockchain evidence storage module concatenates the status version number and response digest in a fixed order and generates a log digest using the SM3 algorithm. During auditing, the authorization certificate and call log on the blockchain are retrieved using a composite key composed of the authorization number and status version number. The normalized strings are reconstructed and the digests are recalculated. When the call time exceeds the time range set by the authorization contract, or the number of calls exceeds the remaining value recorded by the atomic counter, or the access IP is not included in the whitelist, the system concatenates the authorization digest, log digest, and evidence storage transaction identifier in a fixed order, generates an evidence digest using the SM3 algorithm, and writes it into the blockchain. This process ensures that the identification of unauthorized behavior is based on tamper-proof on-chain data, and the solidified evidence forms a complete audit trail.

[0116] As a preferred embodiment, the solution of this application is implemented as follows: When a government data interface is called and a response is returned, the government data access module obtains the response content and calculates the response digest. The response digest and the current status version number are used together as components of the call log. During the call log generation process, data is normalized according to a fixed field order of authorization number, call time, access IP, status version number, and response digest. After concatenation using a unified delimiter, the data is input into the SM3 algorithm to generate the log digest. The blockchain evidence storage module writes the call log containing the response digest and status version number, along with the corresponding log digest, into the blockchain to form an immutable evidence storage record. During the auditing phase, the authorization certificate and call log on the blockchain are retrieved using the authorization number and status version number combination key. The authorization digest and log digest are recalculated according to the same field order and the SM3 algorithm. When it is detected that the call time exceeds the time range set by the authorized contract, or the access IP is not registered in the authorized IP whitelist, or the cumulative number of calls exceeds the upper limit set by the contract, the system automatically associates the authorized summary, log summary and corresponding blockchain transaction identifier of the abnormal call record to generate unauthorized evidence containing the abnormal type, timestamp and verification data, and writes the summary of the evidence into a new block for solidification and storage after calculating the summary of the evidence using the SM3 algorithm.

[0117] Through the above technical solution, this application realizes the full lifecycle correspondence verification of government data call logs and authorization credentials on the blockchain. The binding mechanism of status version number and response summary ensures the consistency between call behavior and authorization status, preventing unauthorized access risks caused by version lag or data tampering. During the audit process, deviations between authorization policies and call logs can be quickly located. Based on the immutability of blockchain evidence storage, a legally valid chain of evidence for unauthorized access is formed, solving the technical deficiency of traditional decentralized storage models where authorization records and call behavior cannot be accurately traced.

[0118] In some of the solutions mentioned above in this application, the blockchain evidence storage module stores authorization certificates and call logs on the blockchain according to the same rules. However, during auditing and verification, it only relies on matching the authorization number with the status version number, which cannot effectively verify whether the response data in the call log has been tampered with, and lacks an automated evidence generation mechanism for whether the call behavior has exceeded the authority.

[0119] This application further proposes recording the response digest in the call log and including the status version number as the calculation input for the log digest. During auditing and verification, the authorization digest and the log digest, along with their corresponding evidence-based transaction identifiers, are matched using the authorization number plus the status version number as the key. When the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the access IP is not in the access IP whitelist, unauthorized access evidence is generated and solidified into the blockchain.

[0120] The response digest is generated using the SM3 algorithm to calculate the response content returned by the government data access module, ensuring the integrity of the response data. The status version number and response digest jointly participate in the calculation of the log digest, ensuring that the digest value of the call log and the digest value of the authorization credential are consistent in field order and algorithm rules. During auditing and verification, the authorization credential and call log are associated using a composite key of the authorization number and status version number. A standardized data string is reconstructed using unified encoding, unified delimiters, and a fixed field order, and the digest is recalculated for consistency verification. When a call exceeds the authorization policy, the system automatically extracts the on-chain data corresponding to the notarized transaction identifier, generating unauthorized evidence containing the authorization digest, log digest, and details of the call violation. This evidence is then solidified through the blockchain notarization module.

[0121] Specifically, during the log generation process, the response data returned by the government data access module is processed using the SM3 algorithm to generate a response digest. This digest is then concatenated with the status version number in a fixed order and input into the log digest calculation process. For example, the response digest uses hexadecimal encoding, separated from the status version number by a colon, and after concatenation, it is processed using the SM3 algorithm to generate the log digest. During auditing, the consistency verification module extracts the authorization certificate and the original data of the call log from the blockchain, reconstructs the normalized string according to the same field order and encoding rules, and recalculates the authorization digest and log digest. If the digests match but the call time exceeds the authorized call time range, the system writes the call time, the authorized time range, and the corresponding evidence transaction identifier into the unauthorized evidence. After generating the evidence digest using the SM3 algorithm, it is written into the blockchain. This process ensures the non-repudiation of unauthorized behavior through automated verification and evidence solidification, while using the status version number to avoid misjudgments caused by contract version updates.

[0122] As a preferred embodiment, the solution of this application is implemented as follows: When a user initiates a request to access government data, the consistency verification module receives a composite key containing the authorization number B20251107001 and the status version number V3. The system retrieves the authorization credential and access log corresponding to this composite key from the blockchain. The authorization credential contains the field sequence "B20251107001|A2025110700123|Time range: 2025-11-07 to 2025-11-10|V3", and the access log contains the field sequence "B20251107001|2025-11-07 14:30:00|192.168.1.100|V3|RESP_7A2E". The module reassembles the fields of the two records according to the unified encoding UTF-8, the delimiter vertical bar, and a fixed order to generate a normalized string, and then inputs it into the SM3 algorithm to calculate the authorization digest and log digest respectively.

[0123] Calculations revealed that the log digest of a certain record in the call log did not match the digest value stored on the chain. This record was marked as invalid and a "digest verification failed" reason code was output. For valid records, the module checked them one by one in ascending order of call time. It was found that the IP address 192.168.2.5 of a certain call was not within the whitelist of 192.168.1.0 / 24 set by the authorization contract. An unauthorized evidence was generated, containing the authorization digest SM3-89A2, the log digest SM3-5B1F, and the corresponding evidence storage identifier TXID_7788. This evidence was then used to calculate and solidify the digest using the SM3 algorithm and written into a new block on the blockchain.

[0124] Through the above technical solution, this application achieves full lifecycle consistency verification of authorization credentials and call logs, ensuring that every data call operation strictly matches the authorization policy. Through a dual guarantee mechanism of fixed field order and the SM3 algorithm, data tampering is detected and abnormal records are automatically identified. Simultaneously, based on the immutability of blockchain, evidence of unauthorized access is solidified, forming a complete audit traceability chain. This solution addresses the technical shortcomings of traditional government data sharing systems, such as the inability to accurately match authorization records with call behaviors and the difficulty in tracing risks associated with cross-version operations, providing a reliable technical verification method for compliant data use.

[0125] The above embodiments utilize a multi-factor authentication mechanism based on a trusted identity authentication platform to ensure the authenticity of user identity verification and authorization behavior. An incremental status version number mechanism and a short-term invoice summary anti-tampering mechanism are introduced through the authorization contract module to ensure that each authorization status is unique and verifiable, preventing the reuse of old invoices and cross-version unauthorized access. By embedding a request signature based on the SM3 algorithm when accessing the integrated data platform of the government network, transmission integrity and anti-replay verification are achieved. The blockchain notarization module stores authorization credentials and call logs on the blockchain with the same field order and the same hash algorithm, constructing a traceable and verifiable correspondence between authorization and call. Combined with a consistency verification module, the authorization number and status version number are matched and compared to automatically detect unauthorized calls and solidify evidence. Finally, the user permission management module supports dynamic modification and revocation of authorization status, constructing a highly secure data processing system with anti-counterfeiting, anti-tampering, traceability, and revocation features, improving data security, credibility, compliance, and auditability in government and public data sharing scenarios.

[0126] In another preferred embodiment based on the above embodiments, see [reference] Figure 2 As shown, this embodiment provides a data processing method for multi-factor authentication and blockchain notarization, applied to the aforementioned data processing system for multi-factor authentication and blockchain notarization, including:

[0127] S100: When a user initiates data authorization, the ID number is compared with the face. When the matching degree reaches the matching degree threshold, an authentication serial number is generated, and an authentication SMS is sent to the registered mobile phone number to complete the secondary confirmation. The verification result and the authentication serial number are written into the authorization certificate.

[0128] S200: Generates a blockchain authorization contract based on user authorization and sets a state version number. Each time an authorization takes effect, is modified, or revoked, the state version number is incremented and a short-term note is generated. The short-term note includes an authorization number, a state version number, and an expiration time. A note digest is calculated using the SM3 algorithm, and the note automatically expires upon expiration or version inconsistency. The contract also sets the authorization call time range, the maximum number of authorization calls, and an access IP whitelist.

[0129] S300: After authorization verification is successful, government data is read through the integrated public data platform of the government network, and a request signature generated based on the SM3 algorithm is added to the request.

[0130] S400: Authorization credentials and call logs are stored on the blockchain using the same rules. The authorization credential records the authorization number, authentication serial number, authorization policy, and status version number, and generates an authorization digest. The call log records the authorization number, call time, accessing IP, status version number, and response digest, and generates a log digest. The authorization digest and log digest are generated using the same field order and the SM3 algorithm, and stored on the blockchain. The authorization credential and call log are matched based on the authorization number and status version number. The authorization digest and log digest are recalculated and compared for consistency. If the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the accessing IP is not on the accessing IP whitelist, unauthorized access evidence is generated and stored on the blockchain.

[0131] S500: Displays the authorization status on the user's end and supports modification or revocation operations. When the verification conditions are met, a new authorization contract is generated and uploaded to the chain or the original contract is invalidated.

[0132] Specifically, this method uses the CTID platform to compare ID card numbers with facial features. Once a 90% match is achieved, a secondary SMS confirmation is triggered, ensuring double protection for identity verification. When generating the blockchain authorization contract, an initial state version number is set. Each contract change increments the version number and generates a short-term note with an expiration date. The note summary is generated by concatenating fixed fields and then performing SM3 calculations to prevent old notes from being tampered with and reused. When requesting government data, the timestamp, nonce, authorization number, and other fields are concatenated in a fixed order to calculate an SM3 signature. The government side verifies the signature validity and nonce uniqueness before returning the data. Authorization credentials and call logs use a unified field order to generate SM3 summaries and upload them to the blockchain, ensuring data integrity. The consistency verification module matches on-chain data using the authorization number plus the state version number as the key. When the call time exceeds the contract's set range, the cumulative number of calls exceeds the limit, or the access IP is not on the whitelist, unauthorized evidence containing a notarized transaction identifier is automatically generated and solidified on the blockchain. The user permission management module displays authorization status changes in real time. When verification conditions such as liveness detection and SMS verification are met, the contract is updated or invalidated by incrementing the state version number. This method solves the traceability problem caused by distributed storage through multi-factor authentication, state version control and same rule summary mechanism, while using SM3 algorithm and short-term bill mechanism to improve the security of government data sharing.

[0133] As a preferred embodiment, the specific implementation of this application's solution is as follows: When a user initiates a government data authorization request through a mobile terminal, the identity authentication process is triggered. The Trusted Identity Authentication Platform (CTID) receives the ID card number and facial image, performs a liveness detection, and initiates the verification process. When the facial feature matching degree reaches 90%, a unique authentication serial number is generated, and an authentication SMS containing a verification code is sent to the user's registered mobile phone number via an SMS gateway. After the user enters the verification code on the interface to complete secondary confirmation, the system concatenates the authentication serial number, verification timestamp, and mobile phone number in a fixed order, generates an authentication digest using the SM3 algorithm, and writes it into the authorization certificate. Subsequently, the authorization contract module generates a blockchain authorization contract, with an initial state version number of V1, setting the authorization call time range to October 1, 2025 to December 31, 2025, limiting the access IP whitelist to the government private network address range, and setting the maximum number of calls to 100. This contract issues short-term notes with a validity period of 24 hours, and its note digest is generated by concatenating the authorization number, state version number, and expiration time field using the SM3 algorithm. In the government data access phase, the system concatenates data in a fixed order, consisting of a timestamp, a random string (nonce), an authorization number, a status version number, and a request body digest. It then generates a request signature using the SM3 algorithm and appends it to the data request header. Upon receiving the request, the government platform verifies the validity of the request signature and the uniqueness of the nonce. If verification is successful, it returns encrypted government data. The blockchain notarization module standardizes the authentication serial number, authorization policy, and status version number in the authorization credential according to a unified field order. An authorization digest is generated using the SM3 algorithm and uploaded to the blockchain. Access IPs, response data digests, and status version numbers in the call logs are processed using the same rules to generate log digests and uploaded to the blockchain. The consistency verification module uses the authorization number combined with the status version number as a composite key to extract the corresponding notarization record from the blockchain. When an access IP for a call is detected to be outside the whitelist, unauthorized access evidence containing a notarization transaction identifier is automatically generated and solidified into the blockchain. Users can view the remaining call counts and contract status through the permission management interface. Before the call count is exhausted, a contract revocation operation is initiated. The system generates a new contract with a status version number of V2 and invalidates the original contract.

[0134] Through the above technical solutions, this application addresses the technical problems of insufficient identity verification security, susceptibility to tampering of authorization credentials, and difficulty in tracing call behavior in existing government data sharing scenarios. By integrating CTID multi-factor authentication with blockchain evidence storage mechanisms, the credibility and non-repudiation of the identity verification process are ensured. The linkage mechanism between status version numbers and short-term tickets eliminates the risk of unauthorized reuse of old version authorization contracts. Based on a unified field order and SM3 algorithm-based rule-based digest generation method, a precise correspondence between authorization credentials and call logs is achieved. Through an automated consistency verification process, evidence of unauthorized calls can be detected and solidified in real time, forming a complete audit traceability chain. This solution improves the security protection level and compliance management capabilities in the government data sharing process.

[0135] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A data processing system for multi-factor authentication and blockchain-based evidence storage, characterized in that, include: The identity authentication module is used to perform multi-factor identity verification when a user initiates data authorization. The multi-factor identity verification includes comparing the ID card number with the face. After the matching degree reaches the matching degree threshold, an authentication serial number is generated. When the matching degree exceeds 90%, a 32-bit random string is generated as the authentication serial number, and an authentication SMS is sent to the registered mobile phone number to complete the secondary confirmation. The verification result and the authentication serial number are written into the authorization certificate. The authorization contract module is used to generate a blockchain authorization contract based on user authorization and set a status version number. Each time the authorization takes effect, is modified, or is revoked, the status version number is incremented and a short-term note is generated. The short-term note includes an authorization number, a status version number, and an expiration time. The note digest is calculated using the SM3 algorithm for anti-tampering verification and becomes invalid when it expires or the version is inconsistent. The authorization contract sets the authorization call time range, the upper limit of the number of authorization calls, and the access IP whitelist. The government data access module is used to read government data through the integrated public data platform of the government network after authorization and verification, and to add a request signature generated based on the SM3 algorithm to the request to verify the integrity of the transmission. The blockchain notarization module is used to store authorization credentials and call logs on the blockchain according to the same rules. The authorization credential records the authorization number, authentication serial number, authorization policy, and status version number, and generates an authorization digest. The call log records the authorization number, call time, access IP, status version number, and response digest, and generates a log digest. The authorization digest and log digest are generated using the same field order and the SM3 algorithm. The response digest is generated by calculating the response body returned by the government data access module using the SM3 algorithm. The consistency verification module is used to match authorization credentials with call logs based on the authorization number and status version number; The user permission management module is used to display the authorization status and perform modification or revocation operations. When the verification conditions are met, a new authorization contract is generated and uploaded to the chain or the original contract is invalidated. The verification conditions are to view authorization details, modify the scope of authorization, or revoke authorization, call the identity authentication process to re-verify the user's identity, and after the verification is passed, call the authorization contract module to generate a new smart contract and deploy it on the chain, or mark the original contract as revoked.

2. The data processing system for multi-factor authentication and blockchain evidence storage according to claim 1, characterized in that, After completing the CTID verification, the identity authentication module concatenates the authentication serial number, registered mobile phone number, and authentication timestamp in a fixed order and calculates the authentication digest using the SM3 algorithm. This digest is then written into the authorization credential along with the verification result.

3. The data processing system for multi-factor authentication and blockchain-based evidence storage according to claim 2, characterized in that, The identity authentication module performs a liveness detection before submitting the verification to CTID. After the liveness detection is passed, the ID number and face image are submitted for verification. The matching degree threshold is set to be no less than 90%. The unique verification identifier returned by CTID is bound to the authentication serial number and written into the authorization credential.

4. The data processing system for multi-factor authentication and blockchain-based evidence storage according to claim 1, characterized in that, When issuing the short-term note, the authorization contract module concatenates the fields in a fixed order of authorization number, status version number, and expiration time, and calculates the note digest using the SM3 algorithm. When receiving a data call request, the module first performs a digest consistency check and a status version number consistency check on the short-term note. If either is inconsistent, the short-term note is deemed invalid.

5. The data processing system for multi-factor authentication and blockchain evidence storage according to claim 4, characterized in that, The authorization contract module adopts an atomic deduction mechanism for the upper limit of authorized call counts, and records the status version number and remaining count value of the call within the same transaction where the deduction is successful; when the authorized call time range expires, the upper limit of authorized call counts is zeroed, or a revocation instruction is received, the module increments the status version number and stops issuing the short-term tickets, and writes the version change record and reason code to the blockchain.

6. The data processing system for multi-factor authentication and blockchain evidence storage according to claim 1, characterized in that, When generating a request signature, the government data access module concatenates the timestamp, random string nonce, authorization number, status version number, request body digest, and appkey in a fixed order, and calculates the request signature using the SM3 algorithm. The government side recalculates the request body digest and request signature within a time window and verifies that the nonce has not been reused. If any one of them does not meet the requirements, the data is rejected.

7. The data processing system for multi-factor authentication and blockchain-based evidence storage according to claim 1, characterized in that, When generating the authorization summary and log summary, the blockchain evidence storage module standardizes the authorization certificate and the call log by using unified encoding, unified delimiter and fixed field order, respectively. It calculates the summary using the SM3 algorithm and writes the summary and standardized data into the blockchain to obtain the evidence storage transaction identifier. The order of the fixed fields remains consistent for both.

8. The data processing system for multi-factor authentication and blockchain evidence storage according to claim 7, characterized in that, The blockchain evidence storage module records the response summary in the call log and simultaneously inserts the status version number into the calculation input of the log summary; during auditing and verification, it uses the authorization number plus the status version number as the key to match the authorization summary and the log summary and their corresponding evidence storage transaction identifier. When the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the access IP is not in the access IP whitelist, it generates unauthorized evidence and solidifies it into the blockchain.

9. The data processing system for multi-factor authentication and blockchain-based evidence storage according to claim 1, characterized in that, The consistency verification module retrieves the authorization certificate and call log from the blockchain using the authorization number plus the status version number as a composite key. It reconstructs the normalized string according to the unified encoding, unified delimiter and fixed field order, and recalculates the authorization digest and log digest using the SM3 algorithm. When any digest is inconsistent with the on-chain digest, the record is marked as invalid and the reason is output. Otherwise, the module checks the authorized call time range, access IP whitelist and authorized call limit one by one in ascending order of call time. For those that do not meet the requirements, it generates unauthorized evidence containing the authorization digest, log digest and corresponding evidence transaction identifier and puts it on the blockchain for solidification.

10. A data processing method for multi-factor authentication and blockchain-based evidence storage, applied to the data processing system for multi-factor authentication and blockchain-based evidence storage as described in any one of claims 1-9, characterized in that, include: When a user initiates data authorization, the ID number is compared with the face. When the matching degree reaches the matching degree threshold, an authentication serial number is generated. When the matching degree exceeds 90%, a 32-bit random string is generated as the authentication serial number, and an authentication SMS is sent to the registered mobile phone number to complete the secondary confirmation. The verification result and the authentication serial number are written into the authorization certificate. A blockchain authorization contract is generated based on user authorization and a status version number is set. Each time an authorization takes effect, is modified, or is revoked, the status version number is incremented and a short-term note is generated. The short-term note includes an authorization number, a status version number, and an expiration time. A note digest is generated by calculating the note digest using the SM3 algorithm. The note automatically expires when it expires or the version is inconsistent. At the same time, the authorization call time range, the upper limit of the number of authorization calls, and the access IP whitelist are set in the contract. After authorization verification is successful, government data is read through the integrated public data platform of the government network, and a request signature generated based on the SM3 algorithm is added to the request; The authorization credentials and call logs are stored on the blockchain under the same rules. The authorization credentials record the authorization number, authentication serial number, authorization policy, and status version number, and generate an authorization digest. The call logs record the authorization number, call time, access IP, status version number, and response digest, and generate a log digest. The authorization digest and log digest are generated using the same field order and the SM3 algorithm and stored on the blockchain. The response digest is generated by calculating the response body returned by the government data access module using the SM3 algorithm. The authorization credentials and call logs are matched according to the authorization number and status version number. The authorization digest and log digest are recalculated and compared for consistency. When the call time exceeds the authorized call time range, the number of calls exceeds the limit, or the access IP is not in the access IP whitelist, unauthorized evidence is generated and stored on the blockchain. The authorization status is displayed on the user side and modification or revocation operations are supported. When the verification conditions are met, a new authorization contract is generated and put on the chain or the original contract is invalidated. The verification conditions are to view authorization details, modify the scope of authorization, or revoke authorization, call the identity authentication process to re-verify the user's identity, and after the verification is passed, call the authorization contract module to generate a new smart contract and deploy it on the chain, or mark the original contract as revoked.

Images