Cross-department information sharing and verification method and device

Abstract

This application provides a method and apparatus for cross-departmental information sharing and verification, achieving precise control over access through multi-dimensional authentication and permission mapping. A verification mechanism is constructed, combining privacy computing and secure transmission to establish a reliable data sharing strategy. Blockchain-based evidence storage is introduced, ensuring traceability of shared data through evidence chain construction and accountability determination. This method effectively addresses the shortcomings of traditional technologies in identity authentication, data verification, and evidence management, providing technical support for cross-departmental information sharing.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method and apparatus for cross-departmental information sharing and verification. Background Technology

[0002] Existing methods for cross-departmental information sharing have significant shortcomings. Traditional systems perform poorly in terms of identity authentication and access control, failing to effectively achieve secure and controllable information sharing and impacting data security.

[0003] Furthermore, existing technologies face bottlenecks in data verification and privacy protection. Most systems lack robust authorization mechanisms and privacy-preserving computation strategies, resulting in inadequate security during data sharing.

[0004] Existing systems have technical shortcomings in evidence management. The lack of in-depth tracking of the verification process makes it difficult to achieve efficient accountability through blockchain technology, thus affecting the credibility of information sharing. Solving these problems is crucial for improving cross-departmental information sharing capabilities. Summary of the Invention

[0005] In view of the problems in the prior art, this application provides a method and apparatus for cross-departmental information sharing and verification, which can effectively solve the shortcomings of traditional technologies in identity authentication, data verification and evidence management, and provide technical support for cross-departmental information sharing.

[0006] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a cross-departmental information sharing and verification method, including: An identity management module is deployed in each department's system. The identity management module generates departmental identity identifiers and constructs identity documents. Multi-dimensional authentication is performed on the identity documents to obtain a trust metric value. A trust computing engine is built based on the trust metric value to generate identity authentication credentials. Permission mapping is performed on the identity authentication credentials to obtain departmental access permissions. The departmental access permissions are invoked as the basis for cross-departmental data request access. The system receives a data verification request from the requesting department, performs identity verification on the data verification request to obtain business entity information, constructs an authorization verifier based on the business entity information to generate an access authorization code, performs rule matching between the access authorization code and the department's access permissions to obtain a verification result, performs privacy calculation on the verification result to obtain an assertion credential, constructs a secure transmitter based on the assertion credential to generate an encrypted channel, and uses the encrypted channel to transmit the assertion credential to the requesting department. The system receives the verification results returned by the requesting department, performs integrity verification on the verification results to obtain transaction tracking data, constructs a certificate generator based on the transaction tracking data to generate block certificate content, processes the block certificate content through a blockchain network to obtain transaction certificate, constructs an evidence chain on the transaction certificate to obtain a responsibility determination result, and writes the responsibility determination result into a trusted ledger to complete the verification closed loop.

[0007] Furthermore, it also includes: configuring a key generation unit in the department system, constructing an asymmetric key pair through the key generation unit, generating a department identity identifier based on the asymmetric key pair, grouping the department identity identifiers according to node type to generate an identity association chain, performing distributed consensus on the identity association chain to obtain a node authentication certificate, and building a document generator based on the node authentication certificate to generate an identity document; The identity document is divided into evaluation index groups according to authentication dimensions. Weight calculation is performed on the evaluation index groups to obtain index score sets. A trust measurer is constructed based on the index score sets to generate a trust scoring matrix. The trust scoring matrix is ​​then filtered through a threshold to obtain a trust measurement value.

[0008] Furthermore, it also includes: dividing the trust metric values ​​into trust level groups according to trust levels, performing security policy matching on the trust level groups to obtain a set of computational constraints, constructing a trusted computing engine based on the set of computational constraints to generate a chain of computational rules, processing the chain of computational rules through zero-knowledge proof to obtain a trusted proof item, and performing multi-party verification on the trusted proof item to obtain an identity authentication credential. The identity authentication credentials are grouped according to departmental functions to generate permission mapping chains. Hierarchical processing is performed on the permission mapping chains to obtain access control domains. Based on the access control domains, a permission allocator is constructed to generate permission policy sets. The permission policy sets are dynamically adjusted to obtain departmental access permissions.

[0009] Furthermore, it also includes: after receiving the data verification application, parsing the request message structure, performing format verification on the request message structure to obtain the application content set, constructing an identity parser based on the application content set to generate an identity feature chain, passing the identity feature chain through multi-authentication processing to obtain an authentication identifier group, performing trusted verification on the authentication identifier group to obtain business entity information, and constructing a business classifier based on the business entity information to generate a scene identifier code; The scenario identifier code is mapped according to business rules to generate an authorization request item. Security policy matching is performed on the authorization request item to obtain an access authorization code. A rule validator is built based on the access authorization code to generate a verification policy group. The verification policy group is matched with the department access permission in multiple dimensions to obtain the verification result.

[0010] Furthermore, it also includes: dividing the verification results into feature group chains according to data attributes, performing homomorphic encryption on the feature group chains to obtain an encrypted dataset, constructing a privacy calculator based on the encrypted dataset to generate a calculation template group, processing the calculation template group through secure multi-party computation to obtain a result mask, and performing zero-knowledge proof on the result mask to obtain an assertion credential. The assertion credentials are grouped according to transmission requirements to generate a channel parameter set. Key negotiation is performed on the channel parameter set to obtain a session key set. A secure transmitter is built based on the session key set to generate an encrypted channel. The encrypted channel is processed through identity binding to obtain a dedicated link. Integrity protection is performed on the dedicated link to obtain a trusted transmission channel.

[0011] Furthermore, it also includes: after receiving the verification result, parsing the returned message format, performing digital signature verification on the returned message format to obtain an integrity identifier, constructing a verification engine based on the integrity identifier to generate a verification rule group, processing the verification rule group through a consistency check to obtain a verification sequence, performing timestamp encapsulation on the verification sequence to obtain transaction tracking data, and constructing a traceability analyzer based on the transaction tracking data to generate a transaction chain structure; The transaction chain structure is mapped according to the evidence preservation rules to generate an evidence preservation template group. Data preprocessing is performed on the evidence preservation template group to obtain an evidence preservation element set. An evidence preservation generator is constructed based on the evidence preservation element set to generate an evidence preservation proof chain. The evidence preservation proof chain is processed by hash calculation to obtain the block evidence preservation content.

[0012] Furthermore, it also includes: generating a block data chain from the block evidence content according to the block structure specification, performing consensus verification on the block data chain to obtain a block identifier group, building a consensus engine based on the block identifier group to generate consensus proof items, processing the consensus proof items through multi-node confirmation to obtain a confirmation sequence, performing block packaging on the confirmation sequence to obtain transaction evidence, and building an evidence analyzer based on the transaction evidence to generate an evidence element chain; The evidence element chain is used to generate a determination strategy group according to the responsibility determination rules. The determination strategy group is processed by a smart contract to obtain the responsibility determination result. Based on the responsibility determination result, a ledger writer is constructed to generate ledger record items. The ledger record items are processed by distributed storage to obtain a storage location set. Consistency synchronization is performed on the storage location set to obtain the final ledger state.

[0013] Secondly, this application provides a cross-departmental information sharing and verification device, comprising: The identity authentication module is used to deploy the identity management module in each department's system. The identity management module generates departmental identity identifiers and constructs identity documents. The identity documents are subjected to multi-dimensional authentication to obtain a trustworthy measurement value. Based on the trustworthy measurement value, a trustworthy computing engine is constructed to generate identity authentication credentials. The identity authentication credentials are subjected to permission mapping to obtain departmental access permissions. The departmental access permissions are invoked as the basis for cross-departmental data request access. The data encryption module is used to receive data verification applications sent by the requesting department, perform identity verification on the data verification applications to obtain business entity information, build an authorization verifier based on the business entity information to generate an access authorization code, perform rule matching between the access authorization code and the department's access permissions to obtain a verification result, perform privacy calculation on the verification result to obtain an assertion credential, build a secure transmitter based on the assertion credential to generate an encrypted channel, and use the encrypted channel to transmit the assertion credential to the requesting department. The data storage module is used to receive the verification results returned by the requesting department, perform integrity verification on the verification results to obtain transaction tracking data, construct a storage generator based on the transaction tracking data to generate block storage content, process the block storage content through the blockchain network to obtain transaction storage, perform evidence chain construction on the transaction storage to obtain responsibility determination results, and write the responsibility determination results into a trusted ledger to complete the verification closed loop.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the cross-departmental information sharing and verification method.

[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the cross-departmental information sharing and verification method described above.

[0016] Fifthly, this application provides a computer program product, including a computer program / instructions, which, when executed by a processor, implement the steps of the cross-departmental information sharing and verification method.

[0017] As can be seen from the above technical solution, this application provides a method and apparatus for cross-departmental information sharing and verification, which achieves precise control of access through multi-dimensional authentication and permission mapping. A verification mechanism is constructed, combining privacy computing and secure transmission to establish a reliable data sharing strategy. Blockchain-based evidence storage is introduced, ensuring the traceability of sharing through evidence chain construction and responsibility determination. This method effectively solves the shortcomings of traditional technologies in identity authentication, data verification, and evidence storage management, providing technical support for cross-departmental information sharing. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the cross-departmental information sharing and verification method in the embodiments of this application; Figure 2 This is a structural diagram of the cross-departmental information sharing and verification device in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0022] In view of the problems existing in the prior art, this application provides a method and apparatus for cross-departmental information sharing and verification, which achieves precise control of access through multi-dimensional authentication and permission mapping. A verification mechanism is constructed, combining privacy computing and secure transmission to establish a reliable data sharing strategy. Blockchain evidence storage is introduced, and the traceability of sharing is ensured through evidence chain construction and responsibility determination. This method effectively solves the shortcomings of traditional technologies in identity authentication, data verification, and evidence storage management, providing technical support for cross-departmental information sharing.

[0023] To effectively address the shortcomings of traditional technologies in identity authentication, data verification, and evidence storage management, and to provide technical support for cross-departmental information sharing, this application provides an embodiment of a cross-departmental information sharing and verification method, see [link to embodiment]. Figure 1 The cross-departmental information sharing and verification method specifically includes the following: Step S101: Deploy an identity management module in each department's system, generate departmental identity identifiers and construct identity documents through the identity management module, perform multi-dimensional authentication on the identity documents to obtain a trustworthy measurement value, construct a trusted computing engine based on the trustworthy measurement value to generate identity authentication credentials, perform permission mapping on the identity authentication credentials to obtain departmental access permissions, and use the departmental access permissions as the basis for cross-departmental data request access. First, after connecting to the basic environment of each department's system, the identity management module is deployed. The connected objects include the key generation unit and node type configuration files of the department nodes. After deployment, the hardware identifiers and system fingerprints are aligned to generate seed materials for departmental identity identifiers, which are then registered using the node type as the key, serving as input for subsequent identity document construction. During registration, the source time and version identifier are recorded simultaneously to provide traceability for subsequent authentication processes.

[0024] Based on the aforementioned registration results, an identity document is generated. Specifically, the departmental identity identifier, node type, key holding method, network location, and historical trusted records are encoded into structured document fragments, and a mapping relationship between fields is established to form a verifiable reference chain. When the identity document is generated, a document digest and a signature fingerprint are bound to it, pointing to the aforementioned registered version identifier, to ensure consistent comparison during subsequent multi-dimensional authentication.

[0025] Multi-dimensional authentication is performed based on the identity document to obtain a trust metric. Authentication dimensions include key validity, node online stability, historical consistency, and cross-link comparison results. Each dimension is output as a component score by a corresponding detection subprocess, along with supporting evidence. To avoid bias from a single dimension, weight calculation and constraint penalties are introduced during the authentication phase. Only entries covered by minimum evidence are included in the calculation, and abnormal fields are backfilled into the warning markers of the document fragment.

[0026] After the trusted metric is generated, a trusted computing engine is constructed. This engine reads the aforementioned component scores and evidence references, loads the security policies and computational constraints defined by this system, and generates authentication credentials. To clarify the computation process, this embodiment employs the following scoring synthesis formula within the engine: Q = r1·A + r2·B - r3·C, In this system, Q represents the synthesized trusted result, serving as the pre-threshold input for generating identity authentication credentials; A represents the key validity component, derived from key validity period and signature verification pass rate; B represents the node online stability component, derived from reachability statistics within a time window; C represents the historical consistency penalty component, derived from change frequency and anomaly alarm count; and r1, r2, and r3 represent policy weights, whose value range is limited by the policy library and is not fixed. Q is subsequently invoked in the credential generation process to determine the credential validity level and validity period cap.

[0027] After the authentication credentials are generated, permission mapping is performed. The mapping process first assigns credentials to corresponding permission domains based on the departmental function list, and then imposes higher access thresholds on sensitive categories according to security policies. During mapping, the validity level of the aforementioned 'Q' is referenced to limit the accessible data category hierarchy, access frequency, and concurrency, while simultaneously recording the boundary conditions that trigger audits. The result of permission mapping forms departmental access permissions, and a unique reference key is generated for each permission, pointing to a summary of the aforementioned authentication credentials, ensuring that the permission status is traceable.

[0028] After the departmental access permissions are generated, an access call interface is established. This interface uses the unique reference key as the input parameter and is read by the preceding process when a cross-departmental data request arrives, completing the access judgment for the requester. When the request enters the next process, the departmental access permissions are matched with the access authorization codes generated in subsequent steps according to rules. The matcher reads the permission domain and call boundary to determine whether to enter the privacy computation stage. Through the above link, the output of step S101 is continuously referenced in subsequent steps, and the reference relationship between identity documents, trusted metrics, identity authentication credentials, and departmental access permissions remains consistent and traceable.

[0029] Step S102: Receive a data verification application sent by the requesting department, perform identity verification on the data verification application to obtain business entity information, construct an authorization verifier based on the business entity information to generate an access authorization code, perform rule matching between the access authorization code and the department's access permissions to obtain a verification result, perform privacy calculation on the verification result to obtain an assertion credential, construct a secure transmitter based on the assertion credential to generate an encrypted channel, and use the encrypted channel to transmit the assertion credential to the requesting department; First, after receiving the data verification request from the requesting department, the request message structure is parsed. The input for parsing includes the department identifier, timestamp, and signature segment in the message header, as well as the verification items and data pointers in the message body. After parsing, the timestamp and signature segment are aligned and verified to ensure they match the identity authentication credential digest generated in step S101. If the verification is successful, the set of fields that can be used for identity verification is extracted as input for subsequent identity parsing.

[0030] Based on the aforementioned field set, identity verification is performed to obtain business entity information. Specifically, the department identifier and the entity number in the item are mapped to the identity feature chain, and the certificate verification sub-process and the historical consistency comparison sub-process are called sequentially. Certificate verification is used to confirm that the validity level of the credential corresponding to the department identifier is still valid; historical consistency comparison is used to determine whether the binding relationship between the entity number and previous business records is stable. After both checks pass, business entity information is generated, which includes entity identifier, entity type, and trust mark, and retains the reference key to the aforementioned field set.

[0031] After the business entity information is generated, an authorization verifier is constructed to generate an access authorization code. The authorization verifier reads the entity type and verification item, maps the item to an authorization request item, and allocates the minimum necessary set of permissions according to the security policy. To avoid unauthorized access, the authorization verifier performs field-level filtering on the authorization request item, retaining only the data category and minimum time range relevant to this verification, generating an access authorization code, and recording the call boundaries and audit triggering conditions.

[0032] After the access authorization code is generated, it is matched with the department access permissions obtained in step S101 to obtain the verification result. The matcher reads the permission domain and concurrency limit of the access permission, compares the category, frequency and time range in the access authorization code item by item. If there is a conflict, it returns the reason for the restriction and marks the rejection type. If the conditions are met, it outputs the verification result that has passed, along with a subset of available permission domains for subsequent calculation stages to read.

[0033] Based on the verification results, privacy computation is performed to obtain the assertion credential. The privacy computation divides the passed field set into a homomorphic processing group and a secure multi-party processing group according to data attributes. For the homomorphic processing group, encrypted template operations are used, and for the secure multi-party processing group, segmented mask computation is used. A new conclusion is generated at the output without revealing the original text. To maintain consistent external presentation, the privacy computation stage only outputs the conclusion marker and verifiable evidence pointer, without outputting any original data, forming the main content of the assertion credential.

[0034] After the assertion credential is generated, a secure transmitter is constructed to generate an encrypted channel. The secure transmitter performs key negotiation on the channel parameters of the requesting department, generates a session key, and binds it to the corresponding authentication credential digest from step S101 to complete the identity binding. Subsequently, integrity protection and replay protection are enabled for the transmission frame, forming a dedicated link, and the assertion credential is sent to the requesting department as segmented messages. After transmission is completed, the transmission status and time boundary are written back for subsequent integrity verification and evidence storage processes, realizing a closed-loop connection from identity verification, authorization generation to assertion output and transmission.

[0035] Step S103: Receive the verification result returned by the requesting department, perform integrity verification on the verification result to obtain transaction tracking data, construct a certificate generator based on the transaction tracking data to generate block certificate content, process the block certificate content through the blockchain network to obtain transaction certificate, perform evidence chain construction on the transaction certificate to obtain responsibility determination result, and write the responsibility determination result into the trusted ledger to complete the verification closed loop.

[0036] First, after receiving the verification result returned by the requesting department, the returned message is parsed. The parsed object includes the identity identifier, timestamp, and signature segment in the message header, as well as the verification conclusion and evidence pointer in the message body. After parsing, the timestamp and session identifier are aligned, and it is compared to see if they fall within the transmission time boundary recorded in step S102. It is also verified whether the signature is verified by the key corresponding to the identity authentication credential generated in step S101. If the conditions are met, the integrity verification process is initiated.

[0037] Based on the parsed results, integrity verification is performed to obtain transaction trace data. Integrity verification involves hashing the segments sequentially to check for sequence number continuity and duplicate markers; cross-checking the consistency between the verification conclusion and the evidence pointer confirms that the assertion credential has been correctly referenced. Upon successful verification, a timestamp is generated and encapsulated for each returned record, along with the verification status, forming transaction trace data. If missing segments or duplicates are found, the gap location is recorded and downgraded, still written into the trace data for subsequent evidence storage to identify anomalies.

[0038] After the transaction tracking data is generated, an evidence generator is constructed and block evidence content is generated. The evidence generator standardizes key fields in the tracking data, extracts time, identity reference key, conclusion summary, and verification status, assembles them into structured fragments, and calculates fragment hashes and fragment chain hashes. To facilitate on-chain verification, the block evidence content embeds fragment chain heights and previous fragment hash references, maintaining a traceable link with the transmission status in step S102.

[0039] After the block evidence is generated, it is submitted to the blockchain network for processing to obtain transaction evidence. During submission, candidate block fragments are broadcast according to network consensus rules, multi-node confirmations are collected, and confirmation sequence numbers are recorded. When the confirmation rate reaches a preset threshold, a transaction identifier and block location are generated. The transaction evidence includes on-chain location, consensus proof, and fragment hash set, which is used as the retrieval entry point for subsequent evidence chain construction.

[0040] Based on the transaction evidence, an evidence chain is constructed to obtain a liability determination result. The evidence chain builder retrieves the assertion credential reference key, session identifier, and identity authentication credential summary related to this transaction, and strings them together to form a causal chain of "requesting party - carrying channel - verification conclusion - on-chain confirmation." It then checks compliance based on rule base parsing permissions, whether assertion calculations were performed according to the template, and whether the return is within the validity period. For links that do not meet the conditions, liability is assigned, resulting in a liability determination result with on-chain verifiability.

[0041] After the liability determination result is generated, it is written to a trusted ledger to complete the verification loop. When writing to the ledger, the attribution of liability, transaction identifier, and evidence chain summary are encoded as record items, and the distributed storage location and version number are registered. Upon successful writing, the ledger status is populated back into the local retrieval index for direct location in subsequent sampling and dispute resolution; simultaneously, the reference key of the record item is returned to steps S101 and S102 to form a closed-loop association, enabling identity documents, departmental access permissions, and assertion credentials to be verified backward along the evidence chain, ensuring that the output of this step is reliably used in subsequent queries and audits.

[0042] As described above, the cross-departmental information sharing and verification method provided in this application can achieve precise control of access through multi-dimensional authentication and permission mapping. It constructs a verification mechanism, combining privacy computing and secure transmission to establish a reliable data sharing strategy. By introducing blockchain evidence storage, the traceability of sharing is ensured through evidence chain construction and responsibility determination. This method effectively solves the shortcomings of traditional technologies in identity authentication, data verification, and evidence storage management, providing technical support for cross-departmental information sharing.

[0043] In one embodiment of the cross-departmental information sharing and verification method of this application, the following may also be included: Step S201: Configure a key generation unit in the department system, construct an asymmetric key pair through the key generation unit, generate a department identity identifier based on the asymmetric key pair, group the department identity identifiers according to node type to generate an identity association chain, perform distributed consensus on the identity association chain to obtain a node authentication certificate, and build a document generator based on the node authentication certificate to generate an identity document. Step S202: Divide the identity document into evaluation index groups according to authentication dimensions, perform weight calculation on the evaluation index groups to obtain index score sets, construct a trust measurer based on the index score sets to generate a trust scoring matrix, and obtain a trust measurement value by filtering the trust scoring matrix through threshold.

[0044] First, after connecting to the hardware security module of the departmental system, the key generation unit is configured. The configuration includes parameters for the random source, key length policy, and selection of curve or modulus type. Once configured, the key generation process is triggered, constructing an asymmetric key pair. The generation log and entropy source quality records are then aligned and verified to confirm that randomness and uniqueness meet the policy constraints. Subsequently, an initial fragment of the departmental identity is generated using the public key digest, node runtime environment fingerprint, and timestamp encoding, and its source and version are registered as input for subsequent grouping.

[0045] After the departmental identity identifiers are generated, they are grouped by node type to obtain an identity association chain. During grouping, business nodes, gateway nodes, and audit nodes within the same department are grouped separately, and cross-node reference relationships are established, recording the mapping between each node and its public key digest. To ensure the stability of the chain order, newly added or replaced nodes are appended to the chain tail incrementally, while retaining the preceding hash reference, forming a traceable identity association chain structure. This structure serves as the input for subsequent consensus, carrying a complete node view and change history.

[0046] Distributed consensus is executed based on the identity association chain to obtain node authentication certificates. The consensus process broadcasts the current chain snapshot to the preset verification nodes, collects signature confirmations, and compares them with the confirmation threshold conditions. When the confirmation meets the threshold conditions, the signatures and time windows are aggregated to generate an authentication payload covering all nodes. The payload is then hash-bound to the chain snapshot to produce a node authentication certificate. To facilitate subsequent verification, the certificate embeds a signature set digest and a chain height index to maintain a consistent link with the identity association chain.

[0047] After the node authentication certificate is generated, a document generator produces an identity document. The document generator reads the node list, public key digest, and confirmation window from the certificate, and maps them to the initially registered runtime environment fingerprint, network location, and role label to form a structured set of document fragments. Each fragment contains field validation rules and evidence reference keys, which are finally assembled into an identity document, and a document digest and signature are attached to ensure consistent parsing and comparison during subsequent authentication dimension breakdown.

[0048] After the identity document is prepared, it is divided into evaluation indicator groups according to authentication dimensions. During the division, the four dimensions of key validity, operational stability, historical consistency, and cross-domain verification are each expanded into measurable indicator items, and a value source and time window are specified for each item. Subsequently, weight calculations are performed on the evaluation indicator groups to obtain the indicator score set; the weights are given upper and lower bounds by the policy library and constrained by the current business scenario, ensuring greater focus on consistency and cross-domain verification in high-risk scenarios.

[0049] Based on the aforementioned score set, a trust measurer is constructed to generate a trust rating matrix. To clarify the composition logic, this embodiment employs the following composition formula in the measurer: H = s1·U + s2·V + s3·W - s4·X, Wherein, H is a unit value of the trust scoring matrix, used to describe the overall trust level of a node within a certain time window; U is the key legitimacy component, derived from certificate chain verification and key status verification; V is the operational stability component, derived from node reachability and fault interval statistics; W is the historical consistency component, derived from the matching and comparison of configuration changes and audit records; X is the cross-domain inconsistency penalty component, derived from cross-domain verification failures and latency anomalies; s1, s2, s3, and s4 are composite weights, adjustable and non-fixed within the policy range. H, as a matrix unit, is read by the subsequent screening process to determine whether to enter the trusted set.

[0050] After the trust scoring matrix is ​​generated, a threshold filtering process is performed to obtain the trust metric value. The filtering process selects the corresponding threshold strategy according to the scenario, and performs sliding judgment on continuous windows of the same node to avoid misjudgment caused by single instantaneous fluctuations; when the H of a certain window is lower than the scenario threshold, the adjacent windows are reviewed and the reasons are marked to keep the filtering process interpretable. The matrix units that pass the filtering are projected as trust metrics and the corresponding identity document fragment index is populated.

[0051] Finally, the trusted metric value is read by the trusted computing engine in step S101 to generate identity authentication credentials; the identity document is referenced again in subsequent steps as an input source for identity verification and permission mapping. Through the above chain, key generation, identity association, consensus authentication, and multi-dimensional measurement are sequential in time, and the generated trusted metric value provides a stable criterion for subsequent access control and privacy computation.

[0052] In one embodiment of the cross-departmental information sharing and verification method of this application, the following may also be included: Step S301: Divide the trust metric values ​​into trust level groups according to trust level, perform security policy matching on the trust level groups to obtain a set of computational constraints, build a trusted computing engine based on the set of computational constraints to generate a chain of computational rules, process the chain of computational rules with zero-knowledge proof to obtain a trusted proof item, and perform multi-party verification on the trusted proof item to obtain an identity authentication credential. Step S302: Group the identity authentication credentials according to departmental functions to generate a permission mapping chain, perform hierarchical processing on the permission mapping chain to obtain an access control domain, construct a permission allocator based on the access control domain to generate a permission policy set, and obtain departmental access permissions by dynamically adjusting the permission policy set.

[0053] First, after reading the credibility metric values ​​output in step S202, the data is divided according to trust level to generate credibility level groups. The division is done at the time window level, aggregating metric results from the same department within consecutive windows, and smoothly merging windows near critical values ​​to avoid frequent policy oscillations caused by frequent jumps between levels. After merging, the source window set and metric evidence index are registered for each level as input for subsequent policy matching and proof generation.

[0054] Security policy matching is performed based on the aforementioned trust level groups to obtain a set of computational constraints. The matching process, according to a predetermined security policy library, maps different levels to three types of constraints: computation domain restrictions, key usage boundaries, and call frequency limits. Minimum supporting evidence requirements are added for sensitive business scenarios. To ensure the enforceability of the constraints, the computational constraint set provides the effective conditions and fallback paths for each constraint, and these correspond one-to-one with the aforementioned window set, ensuring that constraints can be switched by window during the proof generation phase.

[0055] After the set of computational constraints is prepared, a trusted computing engine is constructed to generate a chain of computational rules. The trusted computing engine loads constraint terms and policy templates, replays the metric evidence index into verifiable statements, and concatenates them to form a rule sequence of "metric declaration—policy binding—threshold condition—output level." To ensure the verifiability of rule selection, this embodiment annotates each rule with input references and triggering conditions within the engine, and performs deduplication encoding on metric statements shared across rules, generating a minimal set of rules that can be proven.

[0056] Zero-knowledge proof processing is performed on the computational rule chain to obtain trusted proof items. The proof process generates a commitment and verifiable hints for each rule, ensuring that external verifiers can verify whether a rule is correctly triggered without accessing the original metric data. Subsequently, multi-party verification is performed on the trusted proof items, selecting multiple verification nodes to verify the consistency of the commitment and the correctness of the hints in parallel. When the consistency condition is met, a verification signature and a time window label are synthesized, and an authentication credential is output. This credential retains the rule summary and the list of verification nodes for easy reference in the subsequent permission mapping stage.

[0057] After the authentication credentials are generated, they are grouped according to departmental functions to create an access control chain. During grouping, the functional directory is used as the primary key, and credential versions and validity levels within the same function are archived, establishing a mapping table from credentials to data categories. To prevent cross-functional misuse, the access control chain explicitly records functional boundaries and a list of incompatible categories, and associates them with the aforementioned time window labels to perform time-based validity checks during real-time invocation.

[0058] Based on the aforementioned permission mapping chain, hierarchical processing is performed to obtain the access control domain. Hierarchical processing divides permissions into a three-layer structure: a basic access layer, a restricted sensitive layer, and an audit enhancement layer, with call constraints and audit requirements layered on top of each layer. Each layer in the access control domain reads the aforementioned credential validity level and the number of verification nodes, combines this with the minimum requirements of the policy library to determine whether to open the corresponding data category and call frequency, and generates boundary parameter groups within the layer.

[0059] After the access control domain is prepared, a permission allocator is constructed to generate a permission policy set. The permission allocator reads the hierarchical boundary parameter group and the mapping from function to category, generates the minimum necessary permission entries for each department, and marks the call frequency, concurrency limit, and required supporting evidence. To facilitate subsequent dynamic adjustments, the permission policy set generates a tracking key for each permission entry, pointing to the identity authentication credential and rule summary, ensuring that policy changes can be traced back to the specific measurement and proof chain.

[0060] Dynamic adjustment processing is performed based on the aforementioned permission policy set to obtain departmental access permissions. The dynamic adjustment reads runtime request load and risk reports, downgrading or suspending entries that do not meet the current risk threshold, and gradually relaxing restrictions according to levels when conditions are met. The adjusted entries inherit their tracking keys and update the effective time window to form the final departmental access permissions. This access permission is read by the access matcher in step S102 and compared item by item with the access authorization code to determine whether to proceed with privacy computing and encrypted transmission. Simultaneously, the identity authentication credentials and trusted proof items are back-referenced in the anomaly audit and evidence storage stages to ensure the consistency and verifiability of the link from metrics, rules, credentials to access.

[0061] In one embodiment of the cross-departmental information sharing and verification method of this application, the following may also be included: Step S401: After receiving the data verification application, parse the request message structure, perform format verification on the request message structure to obtain the application content set, build an identity parser based on the application content set to generate an identity feature chain, pass the identity feature chain through multi-authentication processing to obtain an authentication identifier group, perform trusted verification on the authentication identifier group to obtain business subject information, and build a business classifier based on the business subject information to generate a scene identifier code. Step S402: Map the scene identifier code according to business rules to generate an authorization request item, perform security policy matching on the authorization request item to obtain an access authorization code, build a rule verifier based on the access authorization code to generate a verification policy group, and perform multi-dimensional matching between the verification policy group and the department access permission to obtain a verification result.

[0062] First, upon receiving the data verification request, the request message structure is parsed. The parsed objects include the department identifier, timestamp, and signature segment in the message header, as well as the verification items and data pointers in the message body. After parsing, the timestamp and sequence number are aligned and verified, and the integrity and type consistency of the fields are checked according to the message format specification to form the request content set. At the same time, the signature segment is compared with the identity authentication credential digest output in step S301, and the comparison status is recorded as a prerequisite for subsequent identity parsing.

[0063] An identity parser is constructed based on the application content set to generate an identity feature chain. The identity parser extracts verifiable fields from the department identifier, subject number, and session identifier, establishes a feature sequence along three main lines: "source, carrier, and binding relationship," and maps it to the fields of the identity document generated in step S201 to obtain an alignment table of fields to evidence references. After alignment, the identity feature chain is output, retaining reference keys pointing to the application content set and identity document to ensure that subsequent authentication paths can be reviewed.

[0064] After the identity feature chain is generated, multi-factor authentication is performed to obtain an authentication identifier group. Multi-factor authentication sequentially calls three sub-processes: certificate chain verification, session binding verification, and historical consistency check. The former verifies the key chain closure and signature validity; the latter verifies whether the session identifier matches the transmission session recorded in step S102; and the latter compares the binding relationship between the subject number and previous business records. When all three checks pass, they are summarized into an authentication identifier group, and a confidence marker and time window are added according to the source.

[0065] After the authentication identifier group is generated, a trusted verification is performed to obtain the business entity information. The trusted verification cross-compares the identifiers from various sources; for identifiers with contradictions, a downgrade decision is triggered and a reason code is output; for consistent identifiers, they are aggregated into a entity identifier and entity type, along with a trusted level and a list of reference keys. This business entity information will be read by the subsequent classifier and used as the base entity for authorization mapping.

[0066] Once the business entity information is ready, a business classifier is constructed to generate a scenario identifier code. The classifier reads the entity type and verification items, performs field-level filtering on item elements, and maps the request to a specific business scenario in conjunction with the departmental function directory. To avoid excessive granularity, the classifier records both data category and time range in the mapping table, outputs the scenario identifier code, and retains a two-way reference between the business entity information and the application content set.

[0067] After the scenario identifier code is output, an authorization request item is generated according to business rules. This mapping reads the correspondence between the scenario and the data category, expands the minimum required field set and minimum time window, and forms a structured authorization request item. To improve auditability, the authorization request item records a reason tag and a risk tag, which are used to provide a clear basis for adjudication when matching security policies.

[0068] Based on the authorization request item, a security policy matching is performed to obtain an access authorization code. The matching process reads the scene admission boundary and sensitive category additional conditions from the policy library, and narrows or rejects items that do not meet the minimum circumstantial evidence or time window exceed the limit; when successful, an access authorization code is generated, which contains the accessible category, frequency limit and concurrency limit, and the matching trajectory is written back for subsequent verification.

[0069] After the access authorization code is generated, a rule validator is constructed, which outputs a verification policy group. The rule validator decomposes the access authorization code into field-level verification rules and time-series verification rules, and loads the access control domain parameters formed in step S302 to generate a verification policy group bound to the real-time request. Before the final comparison, this policy group undergoes a static consistency check with the data pointer in the request body to ensure that the rules are executable.

[0070] Finally, the verification strategy group is matched with the department access permissions obtained in step S302 in a multi-dimensional manner to obtain the verification result. The matching covers three dimensions: category consistency, frequency and concurrency boundaries, and time range endpoints. When all three are satisfied, a pass mark is output along with a subset of available permission domains; when conflicts exist, the rejection type and conflict location are output. This verification result is read in the subsequent privacy computation stage to determine the grouping and template selection for homomorphic processing and multi-party processing, and to form an associated entry point with the assertion credential.

[0071] In one embodiment of the cross-departmental information sharing and verification method of this application, the following may also be included: Step S501: Divide the verification results into feature group chains according to data attributes, perform homomorphic encryption on the feature group chains to obtain an encrypted dataset, construct a privacy calculator based on the encrypted dataset to generate a calculation template group, process the calculation template group through secure multi-party computation to obtain a result mask, and perform zero-knowledge proof on the result mask to obtain an assertion credential. Step S502: Group the assertion credentials according to transmission requirements to generate a channel parameter set, perform key negotiation on the channel parameter set to obtain a session key set, build a secure transmitter based on the session key set to generate an encrypted channel, obtain a dedicated link by identity binding processing of the encrypted channel, and perform integrity protection on the dedicated link to obtain a trusted transmission channel.

[0072] First, after reading the aforementioned verification results, feature grouping chains are generated based on data attributes. The grouping is based on field source and sensitivity level, categorizing numerical indicators, nominal markers, and time-series indexes into groups, and recording the minimum time window and necessary supporting labels for each group. Upon completion of the grouping, a field mapping table is generated for each group, backfilling the reference keys to the access authorization code and departmental access permissions from step S402, ensuring that subsequent encryption and calculations are strictly limited to the permitted scope.

[0073] Homomorphic encryption is performed on the aforementioned feature group chain to obtain an encrypted dataset. During the encryption phase, a homomorphic scheme capable of additive operations is selected for numerical indicators, an encoded consistency check is used for nominal tags, and time-series indices are aligned using interval hashing. To reduce side-channel risk, uniform padding and noise budget recording are applied to each group. The output encrypted dataset carries group identifiers and a list of operation permissions for loading by the privacy calculator.

[0074] Once the encrypted dataset is ready, a privacy calculator is constructed, generating a set of computation templates. The privacy calculator reads the list of permitted operations, breaks down commonly used verification logic into a sequence of minimal operators, such as interval inclusion, threshold comparison, and consistency matching, and binds these operator sequences into templates according to scenarios. The templates do not contain plaintext thresholds; they only reference the promised values ​​of the verification strategy parameters from step S402 to avoid revealing specific boundaries. The output of the computation template set includes a list of dependent groups and a time-series alignment.

[0075] Based on the computational template set, a result mask is obtained through secure multi-party computation. During processing, the requesting department and the providing department respectively input key shares and encrypted datasets, and collaboratively execute template operators to produce a mask vector containing only pass and fail markers. To accommodate the asynchronicity of different windows, the result mask is organized by time slice number and includes alignment offsets for easy subsequent proof.

[0076] After the result mask is generated, zero-knowledge proof is performed to obtain the assertion credential. The proof process generates a proof item for each time slice. To facilitate downstream retrieval, the assertion credential embeds a mask digest, template identifier, and session number, and records the reference relationship with the verification result, forming an independently verifiable output carrier.

[0077] After the assertion credential is generated, a channel parameter set is generated according to transmission requirements. Based on message size, real-time requirements, and playback pointer requirements, the credential is divided into short messages and long messages, and a retransmission strategy and latency threshold are set for each type. Subsequently, key negotiation is performed on the channel parameter set to obtain a session key set; the negotiation process uses two-way authentication and verifies the consistency with the authentication credential in step S301, outputting two key shares: encryption and integrity.

[0078] A secure transmitter is built upon the session key set to generate an encrypted channel. The secure transmitter loads key shares and channel parameters, enabling low-latency suites for short messages and segmentation and flow control for long messages; it also enables forward secrecy and replay protection to ensure tamper-proof and replay-proof capabilities across network environments. After the encrypted channel is established, the channel identifier and session number are written to a local index for backtracking and auditing.

[0079] After the encrypted channel is generated, identity binding is performed to obtain a dedicated link. The binding uses the identity authentication credential digest from step S301 as an anchor, mapping the identities of the requesting department and the providing department to the current session, restricting credentials to be received and decoded only within this session. Subsequently, integrity protection is performed on the dedicated link, enabling frame-level tagging and rolling checksums, and recording packet loss and retransmission events to form a trusted transmission channel. Finally, the assertion credential is delivered to the requesting department through this channel, and its session number and mask digest are used in subsequent steps as the alignment basis for returning verification results and constructing transaction trace data.

[0080] In one embodiment of the cross-departmental information sharing and verification method of this application, the following may also be included: Step S601: After receiving the verification result, parse the returned message format, perform digital signature verification on the returned message format to obtain an integrity identifier, build a verification engine based on the integrity identifier to generate a verification rule group, process the verification rule group through a consistency check to obtain a verification sequence, perform timestamp encapsulation on the verification sequence to obtain transaction tracking data, and build a traceability analyzer based on the transaction tracking data to generate a transaction chain structure; Step S602: Map the transaction chain structure according to the evidence preservation rules to generate an evidence preservation template group, perform data preprocessing on the evidence preservation template group to obtain an evidence preservation element set, construct an evidence preservation generator based on the evidence preservation element set to generate an evidence preservation proof chain, and process the evidence preservation proof chain through hash calculation to obtain the block evidence preservation content.

[0081] First, after receiving the verification result, the returned message format is parsed. The parsed objects include the returning department identifier, session number, timestamp, signature segment, verification conclusion, assertion reference, and calculation template identifier. After parsing, the session number and timestamp are compared within a specified range to ensure they fall within the time boundary of the trusted transmission channel recorded in step S502. The signature segment is then extracted and associated with the previously established channel identifier to form a message fragment to be verified, providing stable input for subsequent digital signature verification.

[0082] Digital signature verification is performed on the message fragment to be verified to obtain an integrity identifier. During the verification process, the verification node list and public key digest from the authentication credentials generated in step S301 are read. Message digests are calculated for both the message header and message body, and the signature coverage and algorithm markers are verified to be consistent with the channel parameters. If successful, an integrity identifier is generated, containing the verification result, the list of covered fields, and the time boundary. If a coverage gap or replay error is found, the anomaly type is registered in the integrity identifier for subsequent degradation processing.

[0083] After the integrity identifier is generated, a verification engine is constructed and a set of verification rules is generated. The verification engine reads the list of covered fields and exception types, and categorizes the rules into three types: structural consistency, assertion reference consistency, and template matching consistency. Structural consistency is used to compare the field order and required fields; assertion reference consistency is used to verify the mask digest and session number in the assertion credential; and template matching consistency is used to verify the correspondence between the returned conclusion and the calculated template identifier. The three types of rules are bound to the aforementioned time boundaries during generation to ensure that the verification closes within the same time window.

[0084] A consistency check is performed based on the aforementioned verification rule group to obtain a verification sequence. The consistency check is executed rule by rule according to priority, and the pass / fail results are recorded by sequence number. A reason code and a lookback pointer are appended to the failed items. To avoid partial failures interrupting the entire process, the verification sequence retains partially failed but still functional states, ensuring a complete and verifiable timeline. This verification sequence will serve as direct input for timestamp encapsulation.

[0085] After the verification sequence is generated, timestamp encapsulation is performed to obtain transaction trace data. During encapsulation, a trusted timestamp and sequence hash are appended to each sequence item, and adjacent items are linked through a chain reference to form an immutable micro-chain. The transaction trace data includes session number, assertion reference, template identifier, and verification status, serving as the unique entry point for tracing back and ensuring that subsequent on-chain evidence can reconstruct the verification process.

[0086] A traceability analyzer is built based on the transaction tracking data to generate a transaction chain structure. The traceability analyzer concatenates multiple tracking data entries under the same session number in chronological order, inserting reference points from the transmission event in step S502 and the application event in step S401 to form a closed-loop path from request to response. Branches are set at the locations of anomaly markers in the path, along with references to the minimum necessary evidence, to facilitate differentiated processing when selecting evidence templates later.

[0087] After the transaction chain structure is generated, it is mapped into a group of evidence storage templates according to the evidence storage rules. The mapping uses the business type and exception marker as keys to select either a basic template or an enhanced template. The basic template records a key summary of the successful path, while the enhanced template adds the exception reason and a lookback pointer. Each template specifies the field order, hash granularity, and cross-chain referencing method to ensure that on-chain validators can verify independently without accessing the original text.

[0088] Based on the aforementioned evidence template set, data preprocessing is performed to obtain the evidence element set. Preprocessing normalizes the digests, timestamps, and sequence hashes involved in the transaction chain structure, unifies the encoding and time format, and removes redundant markers unrelated to on-chain verification. Missing segments are marked with placeholders and gap descriptions are recorded to ensure the continuity of the element set even when some parts fail.

[0089] A proof generator is constructed based on the aforementioned set of evidence elements, outputting a proof chain. The generator calculates fragment hashes and cross-fragment link hashes according to the template field order, forming a verifiable chained proof; simultaneously, the session number, assertion reference, and template identifier are encoded into a metadata area for easy on-chain indexing. To ensure cross-node consistency, the generator node identifier and local time correction offset are embedded in the proof chain.

[0090] Finally, the evidence storage chain is processed through hash calculation to obtain the block evidence storage content. The block evidence storage content includes a fragment hash set, a link hash, a metadata area, and a generating node identifier, serving as the smallest encapsulated unit for subsequent submission to the blockchain network. This content is read and written by the consensus engine during the on-chain processing stage in step S103, and the subsequent evidence chain construction and responsibility determination use this as the starting point to complete the tracing process.

[0091] In one embodiment of the cross-departmental information sharing and verification method of this application, the following may also be included: Step S701: Generate a block data chain from the block evidence content according to the block structure specification, perform consensus verification on the block data chain to obtain a block identifier group, build a consensus engine based on the block identifier group to generate consensus proof items, process the consensus proof items through multi-node confirmation to obtain a confirmation sequence, perform block packaging on the confirmation sequence to obtain transaction evidence, and build an evidence analyzer based on the transaction evidence to generate an evidence element chain; Step S702: Generate a determination strategy group from the evidence element chain according to the responsibility determination rules, execute smart contract processing on the determination strategy group to obtain the responsibility determination result, construct a ledger writer based on the responsibility determination result to generate ledger record items, process the ledger record items through distributed storage to obtain a storage location set, and perform consistency synchronization on the storage location set to obtain the final ledger state.

[0092] First, after reading the aforementioned block evidence, a block data chain is generated according to the block structure specification. During generation, the fragment hash, link hash, and metadata area are encoded in a predefined field order, and a reference pointer from the previous height and a local time correction offset are inserted to form continuous block candidate fragments. To ensure verifiability within the chain, a local checksum is calculated for each candidate fragment, and the generating node identifier is recorded as input for subsequent consensus verification.

[0093] Consensus verification is performed on the aforementioned block data chain to obtain a block identifier group. Consensus verification broadcasts candidate fragments to the set of verification nodes, collects votes and signatures by window, and performs double checks on vote coverage and signature validity. A block identifier is generated upon reaching the window threshold, containing the block height, fragment root hash, and signature digest; candidate fragments that do not reach the threshold are marked with the reason for the delay and retried in the next window. The block identifier group is arranged in chronological order and serves as the input index for subsequent consensus engines.

[0094] Once the block identifier group is ready, a consensus engine is built to generate consensus proof items. The consensus engine reads the block identifiers one by one, replays the ticket and signature set, and generates a publicly verifiable proof structure. The proof structure records the list of verification nodes, voting time windows, and signature coverage. To avoid redundancy, the consensus engine deduplicates duplicate signatures in adjacent windows, retaining only the minimum necessary set. The output consensus proof items correspond one-to-one with the block identifiers, providing confirmation material for subsequent confirmation processing.

[0095] A multi-node confirmation process is performed based on the consensus proof, resulting in a confirmation sequence. The confirmation process selects independent verification nodes to perform secondary verification of the proof structure, checking the signature format, time window overlap, and root hash consistency. Entries that pass verification are written into the confirmation sequence, which assigns an incrementing sequence number to each entry and includes a digest tag from the verification node. The confirmation sequence serves as the trigger condition for block packaging, ensuring that only fully verified content is solidified on-chain.

[0096] After the confirmation sequence is generated, block packaging is performed to obtain transaction evidence. The packaging process slices the data in sequence, merging several confirmation items and their corresponding block candidate fragments into a publishable block, calculating the block-level hash and appending a Merkle root. The generated transaction evidence includes the block location, confirmation sequence number, and root hash, serving as a retrieval entry point for on-chain browsing and subsequent evidence analysis, and is also populated back into the local index for cross-module retrieval.

[0097] An evidence analyzer is built upon the transaction evidence storage to generate an evidence element chain. The evidence analyzer extracts key summaries related to the request session, assertion credentials, and template identifier from the transaction evidence storage, and strings the nodes together in the order of "request path, transmission event, verification conclusion, and on-chain confirmation" to form a traversable element chain. To enhance the readability of the parsing, each element node retains the source block location and fragment hash, facilitating external verifiers to verify along the chain.

[0098] After the evidence element chain is prepared, a judgment strategy group is generated according to the responsibility determination rules. The strategy generation is based on the compliance boundaries defined in the scenario, translating three types of check items—authority matching, template execution, and time validity—into judgment conditions. It specifies priority attribution paths for missing or contradictory evidence and adds review pointers. Each rule in the strategy group is labeled with the element nodes it depends on, ensuring that the source of evidence can be directly located during execution.

[0099] Based on the aforementioned judgment strategy group, a smart contract is executed to obtain the liability determination result. The contract reads the node digests of the evidence element chain on the blockchain, evaluates the satisfaction of the judgment conditions one by one, and outputs the attribution conclusion and evidence citation for paths that meet the necessary conditions and do not trigger conflicts; for conflicting paths, it records the unmet items and reason tags. The execution trajectory of the contract and intermediate judgments are recorded on the blockchain to ensure that the conclusions are replayable and verifiable.

[0100] After the liability determination results are generated, a ledger writer is constructed to generate ledger record items. The writer encodes the attribution conclusion, transaction identifier, and evidence citation into structured records, and attaches a version number and time window label to facilitate subsequent retrieval and discrepancy comparison. To support large-scale storage, ledger record items generate sharding keys locally and map them to node storage strategies to form routeable write requests.

[0101] Distributed storage processing is performed on the ledger entries to obtain a storage location set. During processing, entries are distributed to multiple replica nodes, write confirmations are collected, and a location list is generated, containing node addresses, physical offsets, and checksums. Consistency synchronization is then performed on the storage location set, using read-after-write confirmation and version comparison to eliminate temporary discrepancies. When the checksums of each replica match the version number, the final ledger state is output. This ledger state is invoked in step S103 for evidence review and subsequent dispute resolution, achieving closed-loop alignment of responsibility conclusions, on-chain evidence, and local indexes.

[0102] To effectively address the shortcomings of traditional technologies in identity authentication, data verification, and evidence storage management, and to provide technical support for cross-departmental information sharing, this application provides an embodiment of a cross-departmental information sharing and verification device for implementing all or part of the aforementioned cross-departmental information sharing and verification method. See [link to embodiment]. Figure 2 The cross-departmental information sharing and verification device specifically includes the following components: The identity authentication module 10 is used to deploy the identity management module in each department system. The identity management module generates departmental identity identifiers and constructs identity documents. The identity documents are subjected to multi-dimensional authentication to obtain a trustworthy measurement value. Based on the trustworthy measurement value, a trustworthy computing engine is constructed to generate identity authentication credentials. The identity authentication credentials are subjected to permission mapping to obtain departmental access permissions. The departmental access permissions are invoked as the access basis for cross-departmental data requests. Data encryption module 20 is used to receive data verification applications sent by requesting departments, perform identity verification on the data verification applications to obtain business entity information, construct an authorization verifier based on the business entity information to generate an access authorization code, perform rule matching between the access authorization code and the department's access permissions to obtain a verification result, perform privacy calculation on the verification result to obtain an assertion credential, construct a secure transmitter based on the assertion credential to generate an encrypted channel, and use the encrypted channel to transmit the assertion credential to the requesting department. The data storage module 30 is used to receive the verification results returned by the requesting department, perform integrity verification on the verification results to obtain transaction tracking data, construct a storage generator based on the transaction tracking data to generate block storage content, process the block storage content through the blockchain network to obtain transaction storage, perform evidence chain construction on the transaction storage to obtain responsibility determination results, and write the responsibility determination results into a trusted ledger to complete the verification closed loop.

[0103] As described above, the cross-departmental information sharing and verification device provided in this application embodiment can achieve precise control of access through multi-dimensional authentication and permission mapping. It constructs a verification mechanism, combining privacy computing and secure transmission to establish a reliable data sharing strategy. By introducing blockchain evidence storage, it ensures the traceability of sharing through evidence chain construction and responsibility determination. This method effectively solves the shortcomings of traditional technologies in identity authentication, data verification, and evidence storage management, providing technical support for cross-departmental information sharing.

[0104] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the cross-departmental information sharing and verification method.

[0105] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the aforementioned cross-departmental information sharing and verification method.

[0106] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the aforementioned cross-departmental information sharing and verification method.

[0107] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0108] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0109] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0110] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0111] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for cross-departmental information sharing and verification, characterized in that, The method includes: An identity management module is deployed in each department's system. The identity management module generates departmental identity identifiers and constructs identity documents. Multi-dimensional authentication is performed on the identity documents to obtain a trust metric value. A trust computing engine is built based on the trust metric value to generate identity authentication credentials. Permission mapping is performed on the identity authentication credentials to obtain departmental access permissions. The departmental access permissions are invoked as the basis for cross-departmental data request access. The system receives a data verification request from the requesting department, performs identity verification on the data verification request to obtain business entity information, constructs an authorization verifier based on the business entity information to generate an access authorization code, performs rule matching between the access authorization code and the department's access permissions to obtain a verification result, performs privacy calculation on the verification result to obtain an assertion credential, constructs a secure transmitter based on the assertion credential to generate an encrypted channel, and uses the encrypted channel to transmit the assertion credential to the requesting department. The system receives the verification results returned by the requesting department, performs integrity verification on the verification results to obtain transaction tracking data, constructs a certificate generator based on the transaction tracking data to generate block certificate content, processes the block certificate content through a blockchain network to obtain transaction certificate, constructs an evidence chain on the transaction certificate to obtain a responsibility determination result, and writes the responsibility determination result into a trusted ledger to complete the verification closed loop.

2. The cross-departmental information sharing and verification method according to claim 1, characterized in that, The process involves deploying an identity management module in each department's system, generating departmental identity identifiers and constructing identity documents through these modules, and performing multi-dimensional authentication on these identity documents to obtain trust metrics, including: A key generation unit is configured in the department system. An asymmetric key pair is constructed through the key generation unit. A department identity identifier is generated based on the asymmetric key pair. The department identity identifier is grouped according to node type to generate an identity association chain. Distributed consensus is performed on the identity association chain to obtain a node authentication certificate. A document generator is constructed based on the node authentication certificate to generate an identity document. The identity document is divided into evaluation index groups according to authentication dimensions. Weight calculation is performed on the evaluation index groups to obtain index score sets. A trust measurer is constructed based on the index score sets to generate a trust scoring matrix. The trust scoring matrix is ​​then filtered through a threshold to obtain a trust measurement value.

3. The cross-departmental information sharing and verification method according to claim 1, characterized in that, The process involves building a trusted computing engine based on the trusted metric value to generate identity authentication credentials, performing permission mapping on the identity authentication credentials to obtain departmental access permissions, and invoking these departmental access permissions as the basis for cross-departmental data request access, including: The trust metric values ​​are divided into trust level groups according to trust level. Security policy matching is performed on the trust level groups to obtain a set of computational constraints. A trust computing engine is built based on the set of computational constraints to generate a chain of computational rules. The chain of computational rules is processed through zero-knowledge proof to obtain a trust proof item. Multi-party verification is performed on the trust proof item to obtain an identity authentication credential. The identity authentication credentials are grouped according to departmental functions to generate permission mapping chains. Hierarchical processing is performed on the permission mapping chains to obtain access control domains. Based on the access control domains, a permission allocator is constructed to generate permission policy sets. The permission policy sets are dynamically adjusted to obtain departmental access permissions.

4. The cross-departmental information sharing and verification method according to claim 1, characterized in that, The receiving department sends a data verification application, performs identity verification on the application to obtain business entity information, constructs an authorization verifier based on the business entity information to generate an access authorization code, and performs rule matching between the access authorization code and the department's access permissions to obtain a verification result, including: After receiving the data verification application, the request message structure is parsed, and the format of the request message structure is validated to obtain the application content set. Based on the application content set, an identity parser is constructed to generate an identity feature chain. The identity feature chain is processed through multiple authentication to obtain an authentication identifier group. Trust verification is performed on the authentication identifier group to obtain business entity information. Based on the business entity information, a business classifier is constructed to generate a scene identifier code. The scenario identifier code is mapped according to business rules to generate an authorization request item. Security policy matching is performed on the authorization request item to obtain an access authorization code. A rule validator is built based on the access authorization code to generate a verification policy group. The verification policy group is matched with the department access permission in multiple dimensions to obtain the verification result.

5. The cross-departmental information sharing and verification method according to claim 1, characterized in that, The process of performing privacy calculations on the verification result to obtain an assertion credential, constructing a secure transmitter based on the assertion credential to generate an encrypted channel, and using the encrypted channel to transmit the assertion credential to the requesting department includes: The verification results are divided into feature group chains according to data attributes. Homomorphic encryption is performed on the feature group chains to obtain an encrypted dataset. A privacy calculator is constructed based on the encrypted dataset to generate a calculation template group. The calculation template group is processed through secure multi-party computation to obtain a result mask. Zero-knowledge proof is performed on the result mask to obtain an assertion credential. The assertion credentials are grouped according to transmission requirements to generate a channel parameter set. Key negotiation is performed on the channel parameter set to obtain a session key set. A secure transmitter is built based on the session key set to generate an encrypted channel. The encrypted channel is processed through identity binding to obtain a dedicated link. Integrity protection is performed on the dedicated link to obtain a trusted transmission channel.

6. The cross-departmental information sharing and verification method according to claim 1, characterized in that, The receiving department returns a verification result, performs an integrity check on the verification result to obtain transaction trace data, and constructs a certificate generator based on the transaction trace data to generate block certificate content, including: After receiving the verification result, the returned message format is parsed, digital signature verification is performed on the returned message format to obtain an integrity identifier, a verification engine is built based on the integrity identifier to generate a verification rule group, the verification rule group is processed through consistency check to obtain a verification sequence, the verification sequence is encapsulated with a timestamp to obtain transaction trace data, and a traceability analyzer is built based on the transaction trace data to generate a transaction chain structure. The transaction chain structure is mapped according to the evidence preservation rules to generate an evidence preservation template group. Data preprocessing is performed on the evidence preservation template group to obtain an evidence preservation element set. An evidence preservation generator is constructed based on the evidence preservation element set to generate an evidence preservation proof chain. The evidence preservation proof chain is processed by hash calculation to obtain the block evidence preservation content.

7. The cross-departmental information sharing and verification method according to claim 1, characterized in that, The process of processing the block-stored evidence content through a blockchain network to obtain transaction evidence, constructing an evidence chain on the transaction evidence to obtain a liability determination result, and writing the liability determination result into a trusted ledger to complete the verification loop includes: The block evidence content is generated into a block data chain according to the block structure specification. Consensus verification is performed on the block data chain to obtain a block identifier group. A consensus engine is built based on the block identifier group to generate consensus proof items. The consensus proof items are processed through multi-node confirmation to obtain a confirmation sequence. Block packaging is performed on the confirmation sequence to obtain transaction evidence. An evidence analyzer is built based on the transaction evidence to generate an evidence element chain. The evidence element chain is used to generate a determination strategy group according to the responsibility determination rules. The determination strategy group is processed by a smart contract to obtain the responsibility determination result. Based on the responsibility determination result, a ledger writer is constructed to generate ledger record items. The ledger record items are processed by distributed storage to obtain a storage location set. Consistency synchronization is performed on the storage location set to obtain the final ledger state.

8. A cross-departmental information sharing and verification device, characterized in that, The device includes: The identity authentication module is used to deploy the identity management module in each department's system. The identity management module generates departmental identity identifiers and constructs identity documents. The identity documents are subjected to multi-dimensional authentication to obtain a trustworthy measurement value. Based on the trustworthy measurement value, a trustworthy computing engine is constructed to generate identity authentication credentials. The identity authentication credentials are subjected to permission mapping to obtain departmental access permissions. The departmental access permissions are invoked as the basis for cross-departmental data request access. The data encryption module is used to receive data verification applications sent by the requesting department, perform identity verification on the data verification applications to obtain business entity information, build an authorization verifier based on the business entity information to generate an access authorization code, perform rule matching between the access authorization code and the department's access permissions to obtain a verification result, perform privacy calculation on the verification result to obtain an assertion credential, build a secure transmitter based on the assertion credential to generate an encrypted channel, and use the encrypted channel to transmit the assertion credential to the requesting department. The data storage module is used to receive the verification results returned by the requesting department, perform integrity verification on the verification results to obtain transaction tracking data, construct a storage generator based on the transaction tracking data to generate block storage content, process the block storage content through the blockchain network to obtain transaction storage, perform evidence chain construction on the transaction storage to obtain responsibility determination results, and write the responsibility determination results into a trusted ledger to complete the verification closed loop.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the cross-departmental information sharing and verification method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the cross-departmental information sharing and verification method as described in any one of claims 1 to 7.

Images