A trusted cross-domain authentication method for data spaces based on digital certificates

Abstract

This invention discloses a cross-domain authentication method for trusted data spaces based on digital certificates, belonging to the field of trusted data space authentication technology. The method includes S1, constructing a trusted data space cross-domain authentication system; S2, system initialization; S3, trusted data space and user registration; S4, intra-domain two-way authentication between the trusted data space and the user; and S5, cross-domain authentication and key negotiation between the trusted data space and the user. This invention combines a lightweight algorithm to achieve lightweight intra-domain authentication and secure cross-domain communication. Addressing the single point of failure problem in traditional authentication, it designs a blockchain distributed verification mechanism to avoid the risk of system paralysis by a centralized trusted party. During the authentication process, the identity information of the trusted data space and the user is anonymized through pseudo-identity and hash processing. Simultaneously, location privacy and communication security are protected through timestamps and digital signatures. The blockchain stores a permission table, simplifying the cross-domain verification steps for authenticated entities and reducing system computation and communication costs.

Description

Technical Field

[0001] This invention belongs to the field of trusted data space authentication technology, specifically relating to a trusted data space cross-domain authentication method based on digital certificates. Background Technology

[0002] Trusted data space authentication technology refers to a technical system that uses cryptographic algorithms to achieve lightweight authentication within a domain and secure verification across domains, addressing the secure communication needs of trusted data spaces in multi-domain environments. Its core objective is to balance real-time performance, low computational overhead, and high security requirements in resource-constrained trusted data spaces, while simultaneously addressing the single point of failure problem of traditional centralized authentication. Existing trusted data space authentication schemes generally fall into two categories: 1) intra-domain trusted data space authentication schemes and 2) cross-domain trusted data space authentication schemes. Compared to intra-domain trusted data space authentication schemes, cross-domain trusted data space authentication operates less frequently but is also more vulnerable to attacks. It is difficult to achieve a balance between high security and real-time requirements and reduced computational and communication costs by using different cryptographic algorithms for different authentication scenarios.

[0003] Therefore, there is an urgent need to invent a trusted cross-domain authentication method for data spaces based on digital certificates. Summary of the Invention

[0004] In view of this, the purpose of this invention is to provide a trusted cross-domain authentication method for data spaces based on digital certificates.

[0005] To achieve the above objectives, the present invention provides the following technical solution:

[0006] A trusted data space cross-domain authentication method based on digital certificates includes the following steps:

[0007] S1. Construct a cross-domain authentication system for a trusted data space: including users, Trusted Data Space (TDS), Trusted Data Service Provider (TDSP), Key Generation Organization (KGC), Verification Server (VS), and blockchain;

[0008] S2. System Initialization: This includes KGC running the initialization function, setting the security parameter λ, generating the global parameter Pr, and initializing the blockchain.

[0009] S3, Trusted Data Space and User Registration: When TDS enters the domain, VS generates the first verification information for TDS, stores the first verification information and returns it to TDS; when a user registers, the user sets the first password information, calculates the first password using the first password information, and sends the first password information and the first password to VS. VS generates the second password information for the user, sends the second password information to the user, and saves the user's information locally.

[0010] S4. Intra-domain two-way authentication between the trusted data space and the user: The user initiates an authentication request and sends the message to the VS; after the VS accepts and verifies the authentication request from the user, the VS starts generating second verification information and sends it to the TDS; after receiving the second verification information from the VS, the TDS starts to verify the received information; after the TDS verifies the authenticity of the information source and content, the TDS calculates the communication channel and sends the communication channel to the user. After receiving the communication channel, the user starts to reverse verify the TDS identity. If it is trusted, the user interacts with the TDS through the session key SK.

[0011] S5. Trusted Data Space and User Cross-Domain Authentication and Key Negotiation: Users initiate cross-domain requests to TDS in other domains and pass them through the TDSP of their own domain. i TDSP in the counterpart domain j After verification, cross-domain authentication is completed and the message is transmitted.

[0012] As a further preferred embodiment of the present invention, the specific functions of each module in the trusted data space cross-domain authentication system in S1 include:

[0013] User: refers to a node that needs to access the trusted data space. To obtain access or control permissions for the trusted data space, a user needs to register. When accessing or operating the trusted data space of other domains, the user node needs to perform cross-domain access.

[0014] Trusted Data Space: Used for data storage, as a key entity for building a data circulation environment with mutual trust among multiple parties. In interactions with users and trusted data service providers, the Trusted Data Space must follow intra-domain authentication protocols and cross-domain authentication processes to conduct secure communication and collaboration between different domains.

[0015] Trusted data service provider: An entity that maintains and controls the trusted data space, ensuring the flow and value release of data throughout the entire data lifecycle; it also maintains an access control table as a blockchain node to manage user access permissions and provides authentication when registering for entry into the trusted data space and performing cross-domain operations;

[0016] Key Generation Organization: During system initialization, the key generation organization KGC generates a global master key and global parameters. This master key is used to derive user-specific private keys. When a trusted data space or user registers and provides their ID, the key generation organization uses the master key and ID to calculate and generate a private key, and securely distributes the generated private key to the corresponding entity.

[0017] Authentication server: This is an authentication entity within the domain, used to manage the trusted data space within the domain;

[0018] Blockchain: The distributed nature of blockchain is used for information sharing among authorized users. Each successful cross-domain authentication is a transaction, and the permission table stores {user, domain, remaining time}.

[0019] As a further preferred embodiment of the present invention, the initialization of the S2 system specifically includes the following steps:

[0020] KGC runs the initialization function, sets the security parameter λ, and generates the global parameter Pr and the master private key MK. The global parameter includes the pairing environment, a random integer t, and a generator g. t Let t represent the generator g raised to the power of t. KGC calculates the public key T corresponding to MK, i.e., T←g. t KGC publishes the public parameters {Pr,T,e} as public information for use by all participants; it also includes parameter initialization for intra-domain two-way authentication and initialization of the blockchain, including setting the consensus mechanism and selecting the blockchain platform.

[0021] As a further preferred embodiment of the present invention, system initialization further includes: during the system initialization phase, all trusted data service providers (TDSPs) in all domains jointly select a prime number q, and select G1 and G2 as a group of prime numbers of order q, where G1 and G2 represent a bilinear mapping, P is the generator of G1, h1 represents a hash encryption algorithm, and each trusted data service provider (TDSP) in each domain selects its own private key. in It is a multiplicative cyclic group consisting of all invertible elements modulo q, therefore the corresponding public key is... After initialization is complete, For all entities publicly accessible within the domain, after verification, the Trusted Data Service Provider (TDSP) will send a Certificate (Certificate) to the verified Trusted Data Space (TDS). TDS ={PID TDS TS4,PK TDS Sign TDS}, where PK TDS It is a public key generated by KGC for the Trusted Data Space (TDS), while Sign... TDS =s TDS ·h(PID TDS ||TS4||PK TDS ), s TDS It is the private key generated by the key generation organization KGC for the trusted data space. h() refers to the hash operation performed on it. PID TDS TS4 is the pseudo-identity of the Trusted Data Space (TDS), and TS4 is the timestamp for certificate generation.

[0022] As a further preferred embodiment of the present invention, the S3 trusted data space and user registration specifically include the following steps:

[0023] When a Trusted Data Space (TDS) enters the domain, it is first verified by the server (VS) and assigned a unique identifier (cID). TDS Then VS generates a random number r1 and uses a one-way hash function to generate the pseudo-identity PID for TDS. TDS Generation: PID TDS =h(CID) TDS ||r1), and pseudo-identity generation by trusted data service provider TDSP in To verify the unique identifier assigned by the Verification Server (VS) to the Trusted Data Service Provider (TDSP), the TDSP will subsequently use a pseudo-identity (PID) for communication with users. The Verification Server (VS) also generates an Entry Pass (EP) for the TDSP. TDS =h(TS) TDS ||CID TDS ||r1), where TS TDS This is the timestamp of the Trusted Data Space (TDS) application for domain entry, after which the Verification Server (VS) will... It is sent to the Trusted Data Space (TDS) via a secure channel, and also stored by itself. Locally;

[0024] The user registration process includes selecting a CID (User Node). Node And set the password PW node Users use sensors to record biometric data (BIO). i Calculate Gen(DB) j )=(σ i ,τ i ), where σ i It is a biometric key, τ i These are the reproduction parameters. Gen() is the core component of the fuzz extractor, and the input biometric data is DB. j Output a pair of keys (σ) i ,τ i ), calculate user pass PASS = h(CID) Node ||PW node ||τ i ), will {CID Node ,PASS,τ i The request is sent to the authentication server (VS), which then generates a PID for the user. Node , and EP Node The calculation is as follows:

[0025] PID Node =h(CID) Node ||τ i )

[0026]

[0027] PID Node It verifies the fake identity generated by the server (VS) for the user. It is the true identity of the trusted data service provider (TDSP) in the domain where the user registered. It is its TDSP pseudo-identity, EP Node This refers to the domain entry pass for user nodes, TS. Node The timestamp used during registration is used to verify the PID on the server VS. Node ,EP Node ,τ i ,TS Node Send to the user, store {PID} Node ,EP Node ,τ i ,TD Node Locally, users need to enter their CIS ID to log in. Node and PW node And the biometric data DB′ used for verification j The VS is given a new pass, which is generated through calculation. * :

[0028] Rep(DB′ j ,σ i )=τ′ i

[0029] PASS * =h(CID) Node ||PW Node ||τ i ′)

[0030] Where τ i ' is a fuzz extractor based on new biometric data DB' j Combining biometric key σ i The reproduction parameters are calculated using the Rep() function. Then, when a user logs in, the VS (Verification Server) verifies the user's pseudo-identity and calculates the verification parameters. If the conditions are met, login is successful;

[0031] After verification, the Trusted Data Service Provider (TDSP) will send a certificate (Certificate) to the verified Trusted Data Space (TDS). TDS ={PID TDS TS4,PK TDS Sign TDS}, where PK TDSIt is a public key generated by KGC for the Trusted Data Space (TDS), while Sign... TDS =s TDS ·h(PID TDS ||TS4||PK TDS ), s TDS This refers to the private key generated by the Key Generation Authority (KGC) for the trusted data space. `h()` indicates the hash operation performed on it, and `TS4` is for generating the certificate `Cert`. TDS Timestamp.

[0032] As a further preferred embodiment of the present invention, the intra-domain two-way authentication between the S4 trusted data space and the user specifically includes the following steps:

[0033] S41. The user initiates an authentication request and sends the message to the VS:

[0034] The user calculates parameters A, B, and C, and sends the message {A,B,C,TS1} to the authentication server VS, where TS1 is the timestamp of the authentication request initiated by the user. The calculation formulas for parameters A, B, and C are as follows:

[0035]

[0036] After receiving the authentication request, the authentication server (VS) first verifies the authenticity of the user's identity by calculating the user's pseudo-identity (PID). Node And the pseudo-identity PID of the Trusted Data Space (TDS) TDS The calculation formula is as follows:

[0037]

[0038] Finally, verify the correctness of the server's verification message and calculate parameter C. * The formula is as follows:

[0039]

[0040] If C * If C is true, the message is correct, and VS generates a request message and sends it to the Trusted Data Space (TDS). If C is false, the authentication is terminated.

[0041] S42. After VS accepts and verifies the authentication request from the user, VS begins to generate authentication information and sends it to the Trusted Data Space (TDS). The authentication message includes the new domain entry license. The parameters D, E, F, and G are calculated using the following formulas:

[0042]

[0043] Wherein, TS2 is the timestamp of the verification information generated by the verification server VS for the Trusted Data Space TDS, r4 is the random number generated by VS, and VS sends {D,E,F,G,TS2} to TDS;

[0044] S43. After receiving the verification information from the VS, the Trusted Data Space (TDS) begins to verify the received information:

[0045] First, the Trusted Data Space (TDS) calculates the pseudo-identity (PID) of the user node. Node The random number r4 verifies the new pass generated by the server VS for the user. And message G * :

[0046]

[0047] Trusted Data Space (TDS) Verification If they are equal, it indicates the authenticity of the information source and content; if they fail, the Trusted Data Space (TDS) will terminate the authentication process.

[0048] S44. After the Trusted Data Space (TDS) verifies the source and authenticity of the information, it selects the session key SK with the user to ensure secure communication with the user node. The Trusted Data Space (TDS) calculates the communication channel, including... TS3 is the timestamp for the returned information generated by the Trusted Data Space (TDS), and {H,I,TS3} is sent to the user. When the user receives {H,I,TS3}, they begin reverse verification of the Trusted Data Space (TDS) identity. The user first calculates:

[0049]

[0050] if SK is a verified and trusted communication key, and the trusted data space and users can begin reliable communication through SK.

[0051] As a further preferred embodiment of the present invention, the S5 trusted data space and user cross-domain authentication and key negotiation specifically include the following steps:

[0052] First, the user sends an application to the TDSP in this domain. i Send a cross-domain authentication request, including your own PID. Node and the PI D of the target trusted data space TDS And related security parameters, the trusted data service provider TDSP in this domain i The message is processed and forwarded to the Trusted Data Service Provider (TDSP) of the target Trusted Data Space (TDS) domain. j TDSP jThe TDSP checks whether the requesting user has been verified and is within the validity period by querying the authorization table maintained in the blockchain. If so, the TDSP is executed. j Generate a communication channel and send it to PID. Node and PID TDS Both parties can communicate through a pre-defined channel;

[0053] If not found, a complete verification process is required, i.e., TDSP. j First, the timestamp is verified to be within the time limit. Then, the correctness of the message is verified through calculation. After successful verification, a communication channel is generated, along with the cross-domain authentication information to be sent to the user. The cross-domain authentication information generated by the Trusted Data Space (TDS) is first sent back to the TDSP. i Then by TDSP i The message is sent back to the user, who then calculates the target channel, while the TDSP... j Will come from TDSP i The request message, along with the communication channel, is sent to the Trusted Data Space (TDS) in this domain that is requesting cross-domain authentication. After both parties obtain the communication channel, the user and the Trusted Data Space successfully interact and complete the cross-domain access operation.

[0054] The beneficial effects of this invention are as follows:

[0055] This invention employs a one-way hash function and XOR encryption technology to keep the computational cost of the intra-domain trusted data space authentication process low. To resist malicious attacks, timestamps are added to prevent replay attacks. In cross-domain trusted data space authentication, digital certificates are used to ensure algorithm security. The authentication efficiency of the protocol is improved by placing the main computational load on high-performance devices such as user mobile devices and trusted data service providers, reducing computational overhead at the trusted data space end. Blockchain technology is used to further reduce the protocol's computational cost, and a consensus mechanism simplifies the authentication process for certified entities. The addition of blockchain also prevents centralized authorization authorities across multiple domains, mitigating the risk of system paralysis due to a single point of failure. This invention proposes a cross-domain trusted data space authentication protocol based on digital certificates, combined with a lightweight algorithm, to achieve lightweight intra-domain authentication and secure cross-domain communication. Addressing the single point of failure problem in traditional authentication, a blockchain distributed verification mechanism is designed to avoid the system paralysis risk of a centralized trusted party. During the authentication process, the identity information of the trusted data space and the user is anonymized through pseudo-identity and hash processing, while location privacy and communication security are protected through timestamps and digital signature technology. By using blockchain to store permission tables, the cross-domain verification process for certified entities can be simplified, reducing system computing and communication costs.

[0056] Other advantages, objectives, and features of the invention will be set forth in the following description and will be apparent to those skilled in the art in some respects, or may be learned by practice of the invention. The objectives and other advantages of the invention can be realized and obtained through the following description. Attached Figure Description

[0057] To make the objectives, technical solutions, and beneficial effects of this invention clearer, the following figures are provided for illustration:

[0058] Figure 1 This is a schematic diagram of the structure of the trusted data space cross-domain authentication system in this invention;

[0059] Figure 2 This is a schematic diagram of the system initialization phase in this invention;

[0060] Figure 3 This is a schematic diagram of the user and trusted data space registration process in this invention;

[0061] Figure 4 This is a schematic diagram of the two-way authentication process between the user and the trusted data space domain in this invention;

[0062] Figure 5 This is a schematic diagram of the cross-domain communication and key negotiation phases in this invention. Detailed Implementation

[0063] like Figures 1-5 As shown, a cross-domain authentication method for trusted data spaces based on digital certificates is disclosed, including the following steps: S1, constructing a cross-domain authentication system for trusted data spaces; S2, system initialization; S3, trusted data space and user registration; S4, intra-domain two-way authentication between trusted data space and user; S5, cross-domain authentication and key negotiation between trusted data space and user.

[0064] S1. Construct a trusted cross-domain authentication system for data spaces: The overall architecture of the system model is as follows: Figure 1 As shown, it consists of six entities, including the user, the trusted data space, the trusted data service provider, the key generation authority, the verification server, and the blockchain:

[0065] 1) User: A user refers to a user who wants to access the Trusted Data Space. To obtain access or control permissions for the Trusted Data Space, a user must first register. In addition, when accessing or operating the Trusted Data Space of other domains, user nodes often need to perform cross-domain access.

[0066] 2) Trusted Data Space: As a key entity in building a data circulation environment based on mutual trust among multiple parties, the Trusted Data Space undertakes important tasks such as data storage. In its interactions with users and trusted data service providers, the Trusted Data Space must adhere to intra-domain authentication protocols and cross-domain authentication processes to achieve secure communication and collaboration between different domains.

[0067] 3) Trusted Data Service Provider: The primary role of a trusted data service provider is to maintain and control the trusted data space. Throughout the entire data lifecycle (collection, storage, processing, sharing, application, etc.), it ensures the secure, compliant, and reliable flow and value release of data through technical capabilities, compliance systems, and trusted mechanisms. Furthermore, it acts as a node in the blockchain, maintaining an access control table to manage user access permissions and providing authentication during trusted data space registration and cross-domain operations.

[0068] 4) Key Generation Authority: During system initialization, the key generation authority (KGC) generates a global master key and global parameters. This master key is used to derive user-specific private keys. When a trusted data space or user registers and provides their ID, the key generation authority uses the master key and ID to calculate and generate a private key. The generated private key is then securely distributed to the appropriate entity.

[0069] 5) Validation Server: The Validation Server (VS) is a high-performance validation entity within the domain. It is responsible for managing the trusted data space within the domain. It is honest and trustworthy towards the trusted data space within the domain and has a high level of security in domain authentication.

[0070] 6) Blockchain: This system leverages the distributed nature of blockchain to share information with authorized users. Each successful cross-domain authentication constitutes a transaction, and the permissions table stores {user, domain, remaining time}.

[0071] Based on the actual communication between users and the trusted data space, our proposed patent solution covers the needs of four different scenarios: (1) system initialization stage; (2) trusted data space and user registration and login stage; (3) intra-domain two-way authentication between trusted data space and users; (4) trusted data space and user cross-domain authentication and key negotiation stage.

[0072] S2. System Initialization: In this stage, the system performs necessary initializations, including KGC running the initialization function, setting security parameters (λ), and generating global parameters Pr (including pairing environment, random integer t, generator g, etc.) and the master private key MK. KGC calculates the public key T corresponding to MK, i.e., T←g. t g tThis represents the generator g raised to the power of t. KGC publishes the public parameters {Pr, T, e} as public information for use by all participants. This includes parameter initialization for domain-wide two-way authentication, and blockchain initialization, including setting the consensus mechanism and selecting the blockchain platform. See details in [link to documentation]. Figure 2 .

[0073] During system initialization, all Trusted Data Service Providers (TDSPs) in all domains jointly select a prime number q, and choose G1 and G2 as a set of prime numbers of order q, where G1 and G2 represent a bilinear mapping. P is the generator of G1, and each TDSP within a domain selects its own private key. in It is a multiplicative cyclic group consisting of all invertible elements modulo q, therefore the corresponding public key is... After initialization is complete, The hash encryption algorithm is publicly available to all entities within the domain. After verification, the Trusted Data Service Provider (TDSP) sends a certificate (Certificate) to the verified Trusted Data Space (TDS). TDS ={PID TDS TS4,PK TDS Sign TDS This will be needed in subsequent cross-domain authentication, where PK... TDS It is a public key generated by KGC for the Trusted Data Space (TDS), while Sign... TDS =s TDS ·h(PID TDS ||TS4||PK TDS ). s TDS It is the private key generated by the Key Generation Authority (KGC) for the trusted data space, PK. TDS For the public key, h() indicates that a hash operation is performed on it, PI D TDS TS4 is the pseudo-identity of the Trusted Data Space (TDS), and TS4 is the timestamp for certificate generation.

[0074] S3. Trusted Data Space and User Registration: To prevent unauthorized use of the Trusted Data Space and to facilitate data security and emergency response through the Trusted Data Space, each domain's Trusted Data Space (TDS) and users need to register.

[0075] When a Trusted Data Space (TDS) enters the domain, it is first verified by the VS server and assigned a unique identifier (CID). TDS Then VS generates a random number r1 and uses a one-way hash function to generate the pseudo-identity PID for TDS. TDS Generation of PID TDS =h(CID) TDS||r1), and pseudo-identity generation by trusted data service provider TDSP in To verify the unique identifier assigned by the Verification Server (VS) to the Trusted Data Service Provider (TDSP), and to ensure anonymity and enhance security, a pseudo-identity (PID) will be used in subsequent communications between the TDSP and the user. The Verification Server (VS) will generate an EntryPermit (EP) to verify the authenticity of the TDSP's identity. TDS =h(TS) TDS ||CID TDS ||r1), where TS TDS This is the timestamp of the Trusted Data Space (TDS) application for domain entry, after which the Verification Server (VS) will... It is sent back to the Trusted Data Space (TDS) via a secure channel, and also stored by itself. Locally. See details. Figure 3 .

[0076] The user registration algorithm is shown in Algorithm 1. The steps include user nodes selecting their own CID. Node And set the password PW node To ensure security, VS does not directly grant PW to users during registration. node Users use sensors to record biometric data (BIO). i Calculate Gen(DB) j )=(σ i ,τ i ), where σ i It is a biometric key, τ i These are the reproduction parameters. Gen() is the core component of the fuzz extractor, and the input biometric data is DB. j Output a pair of keys (σ) i ,τ i ). Calculate user pass PASS = h(CID) Node ||PW node ||τ i ), will {CID Node ,PASS,τ i The message is sent to the authentication server VS, which then generates the following for the user:

[0077] PID Node =h(CID) Node ||τ i )

[0078]

[0079] PID Node It verifies the fake identity generated by the server (VS) for the user. It is the true identity of the trusted data service provider (TDSP) in the domain where the user registered. It is a pseudo-identity of TDSP, a trusted data service provider in the domain where the user is registered, EP Node This refers to the EntryPermit of the user node, also known as the domain entry pass, TS. Node The timestamp used during registration is used to verify the PID on the server VS. Node ,EP Node ,τi,TS Node Send to the user, and store the PID yourself. Node ,EP Node ,τ i ,TS Node Locally, users need to enter their CID to log in. Node and PW node And the biometric data DB′ used for verification j Give VS, VS generates a new pass * :

[0080] Rep(DB′ j ,σ i )=τ i ′

[0081] PASS * =h(CID) Node ||PW Node ||τ i ′)

[0082] Where τ i ' is a fuzz extractor based on new biometric data DB' j Combining biometric key σ i The reproduction parameters are calculated using the Rep() function. Then, when a user logs in, the VS (Verification Server) calculates the verification PAS (Proof of Identity) based on the user's pseudo-identity. If the conditions are met, login is successful, and the registration and login phase for the Trusted Data Space (TDS) and the user is complete. (See Algorithm 2.)

[0083] This process concludes with the verification server (VS) obtaining information including the Trusted Data Space (TDS). and the user's {PID Node ,EP Node ,τi,TS Node After successful verification, the Trusted Data Service Provider (TDSP) will send a certificate (Certificate) to the verified Trusted Data Space (TDS). TDS ={PID TDS TS4,PKTDS Sign TDS This will be needed in subsequent cross-domain authentication, where PK... TDS It is a public key generated by KGC for the Trusted Data Space (TDS), while Sign... TDS =s TDS ·h(PID TDS ||TS4||PK TDS ). s TDS It is the private key generated by the Key Generation Authority (KGC) for the trusted data space, PK. TDS Here, h() is the public key, h() indicates the hash operation performed on it, and TS4 is the certificate generator. TDS Timestamp.

[0084]

[0085] Algorithm 1

[0086]

[0087]

[0088] Algorithm 2

[0089] S4. Intra-domain two-way authentication between users and the trusted data space:

[0090] This stage mainly introduces the two-way authentication process between registered users and the Trusted Data Space (TDS). To reduce the latency of TDS verification, we designed an authentication protocol using a full XOR operation to achieve two-way authentication within the domain. This part can be roughly divided into four steps.

[0091] Step 1: First, the user initiates an authentication request and sends a message to VS, including:

[0092]

[0093] The user sends {A,B,C,TS1} to the authentication server VS, where TS1 is the timestamp of the authentication request initiated by the user. After receiving the authentication request, the authentication server VS first verifies the authenticity of the user's identity and calculates the user's pseudo-identity PID. Node And the pseudo-identity PID of the Trusted Data Space (TDS) TDS :

[0094]

[0095] Finally, verify the correctness of the server's verification message and calculate:

[0096]

[0097] If C * If C is true, the message is correct, and VS generates a request message and sends it to the Trusted Data Space (TDS). If C is false, the authentication process terminates.

[0098] Step 2: After VS accepts and verifies the authentication request from the user, VS begins generating authentication information and sending it to the Trusted Data Space (TDS), which includes:

[0099]

[0100]

[0101] Where TS2 is the timestamp for the verification information generated by the verification server VS (Trusted Data Space TDS), and r4 is a random number generated by VS. For the new domain entry license, VS sends {D,E,F,G,TS2} to TDS.

[0102] Step 3: After receiving the verification information from the VS, the Trusted Data Space (TDS) begins to verify the received information. First, the TDS calculates the pseudo-identity (PID) of the user node. Node The random number r4 verifies the new pass generated by the server VS for the user. And message G * :

[0103]

[0104] Trusted Data Space (TDS) Verification If they are equal, it indicates the authenticity of the information source and content; if they fail, the Trusted Data Space (TDS) will terminate the authentication process.

[0105] Step 4: After the Trusted Data Space (TDS) verifies the authenticity of the information source and content, it selects the session key SK with the user to ensure secure communication with the user node. The Trusted Data Space (TDS) then calculates the communication channel. TS3 is the timestamp for the Trusted Data Space (TDS) to generate the returned information, and {H,I,TS3} is sent to the user. Upon receiving {H,I,TS3}, the user begins reverse verification of the Trusted Data Space (TDS) identity. The user first calculates:

[0106]

[0107] if This means that SK is a verified and trusted communication key, and trusted data spaces and users can initiate reliable communication through SK. See details below. Figure 4 .

[0108] S5, Cross-Domain Communication and Key Negotiation Phase: This phase involves the user initiating a cross-domain request to the Trusted Data Space (TDS) of another domain, and the request being handled by the TDSP of their own domain. i TDSP in the counterpart domain j After verification, cross-domain authentication is completed and the message is transmitted.

[0109] First, the user sends an application to the TDSP in this domain. i Send a cross-domain authentication request, including your own PID. Node and the PI D of the target trusted data space TDS And related security parameters, the trusted data service provider TDSP in this domain i The message is processed and forwarded to the Trusted Data Service Provider (TDSP) of the target Trusted Data Space (TDS) domain. j TDSP j The TDSP checks whether the requesting user has been verified and is within the validity period by querying the authorization table maintained in the blockchain. If so, the TDSP is executed. j Generate a communication channel and send it to PID. Node and PID TDS Both parties can communicate through the agreed-upon channel. If the query is not found, a complete verification process, namely TDSP, is required. j First, the timestamp is verified to be within the time limit. Then, the correctness of the message is verified through calculation. After successful verification, a communication channel is generated, along with the cross-domain authentication information to be sent to the user. Since the TDS and the user initiating cross-domain authentication have not yet established a communication channel at this time, the cross-domain authentication information generated by the Trusted Data Space (TDS) is first sent back to the TDSP. i Then by TDSP i The message is sent back to the user, who then calculates the target channel using the following steps, while TDSP... j Will come from TDSP i The request message, along with the communication channel, is sent to the Trusted Data Space (TDS) within this domain that is requesting cross-domain authentication. Once both parties have obtained the communication channel, the user and the Trusted Data Space can successfully interact, completing the cross-domain access operation. See details below. Figure 5 .

[0110] Step 1: User Node in Domain A i Trusted Data Service Provider (TDSP) in Domain B j Cross-domain authentication requests, as shown in Algorithm 3:

[0111] Node i Trusted Data Service Provider (TDSP) in this domain i Send {Require, TS5, PID} NodePID TDS Cert Node}, where Require is the request message, TS5 is the timestamp of the request message, and PID is the PID. Node and PID TDS Cert represents the pseudo-identity of the user and the trusted data space, respectively. Node It is a digital certificate generated by the verification server VS for each registered user during the registration process.

[0112] TDSP i Forward the message to the TDSP located in the domain of the target trusted data space. j TDSP j The PID is obtained by querying the authorization table maintained in the blockchain. Node Whether it has been verified and is within its validity period, if so, then TDSP j Generate a communication channel and send it to the PID. Node and PID TDS Both parties can communicate through the agreed-upon channel. If no match is found, a complete verification process is required, which is handled by TDSP. i Generate message{Require,PID Node TS5 Sign Node Cert Node Send to TDSP j TDSP j Upon receiving the message, first verify whether the timestamp TS5 is within the validity period, then calculate:

[0113]

[0114] Sign Node This is the signature generated by KGC for the node Node, where P is the generator of group G1, h() is the chosen hash algorithm, and PID is the hash function. Node For the user's pseudo-identity, TS5 is the timestamp for generating the request message, Require is the request message, PKI is the node's public key, and e(a,b) refers to the bilinear pairing operation on the two parameters a and b. If the equation holds, continue with TDSP. j The system then considers the information to have passed verification and generates a cross-domain confirmation message, which is sent back to the TDSP. i .

[0115]

[0116]

[0117] Algorithm 3

[0118] Step 2: TDSP in Domain Bj Send cross-domain confirmation information back to the user's Node. i As shown in Algorithm 4:

[0119] TDSP in Domain B j Verification from user Node i After confirming the cross-origin request information is correct, the generation of the confirmation message signature begins. and channel parameters Send back to the user Node i ,in For TDSP j private key, The timestamp used when the signature was generated. TDSP in Domain B j The message content being processed TDSP in Domain B j The fake identity, PK i Here, TS is the node's public key, and TS is the timestamp for generating the channel.

[0120]

[0121] Because at this time TDSP j and Node i Since a communication channel has not yet been established, cross-domain confirmation information is sent via the TDSP of domain A. i Return to the user Node via the original path i of which, Includes TDSP j The communication channel SC generated for the user and the Trusted Data Space (TDS) can only obtain the target channel parameters after the TDS confirms its successful authentication.

[0122] When user Node i Received from TDSP j After receiving confirmation, the target channel is obtained by calculating the following steps: First, verify whether the timestamp has expired; second, calculate:

[0123]

[0124] If the equation verification is successful, then it confirms that the message is indeed from the trusted data service provider TDSP. j Then, by calculating the parameters of the communication channel, the cross-domain access operation was completed. TDSP, a trusted data service provider j The generated channel parameters, SC, are provided to nodes and the Trusted Data Service Provider (TDSP). j Communication channels for cross-domain access:

[0125]

[0126]

[0127] This invention utilizes blockchain and smart contracts to achieve decentralized cross-domain authentication through on-chain verification and smart contracts, avoiding the single point of failure risk of centralized institutions while reducing the overall system's computational and communication costs. By designing a lightweight intra-domain authentication mechanism, employing only one-way hash functions and bitwise XOR operations, it significantly reduces the computational overhead of the trusted data space while ensuring authentication security. Through a blockchain-based on-chain verification strategy, combined with registration information maintained by trusted data service providers, it simplifies cross-domain authentication steps, reduces communication overhead during verification, uses a timestamp mechanism to resist replay attacks, and combines a two-way authentication process to ensure the authenticity of user node identities within the trusted data space. Based on a blockchain-based decentralized authentication architecture, a lightweight intra-domain XOR and hash authentication algorithm, combined with a blockchain-based cross-domain authentication process, and security mechanisms including timestamps to resist replay and man-in-the-middle attacks, it achieves lightweight intra-domain and secure cross-domain authentication within the trusted data space, reducing computational and communication costs. Furthermore, it offloads complex computations to high-performance devices such as user mobile devices or verification servers, making it friendly to trusted data space devices with limited computing resources.

[0128] Finally, it should be noted that the above preferred embodiments are only used to illustrate the technical solutions of the present invention and are not intended to limit it. Although the present invention has been described in detail through the above preferred embodiments, those skilled in the art should understand that various changes can be made to it in form and detail without departing from the scope defined by the claims of the present invention.

Claims

1. A trusted cross-domain authentication method for data spaces based on digital certificates, characterized in that, Includes the following steps: S1. Construct a cross-domain authentication system for a trusted data space: including users, Trusted Data Space (TDS), Trusted Data Service Provider (TDSP), Key Generation Organization (KGC), Verification Server (VS), and blockchain; S2. System Initialization: This includes the KGC runtime initialization function and setting security parameters. Generate global parameter Pr and initialize the blockchain; S3, Trusted Data Space and User Registration: When TDS enters the domain, VS generates the first verification information for TDS, stores the first verification information and returns it to TDS; when a user registers, the user sets the first password information, calculates the first password using the first password information, and sends the first password information and the first password to VS. VS generates the second password information for the user, sends the second password information to the user, and saves the user's information locally. S4. Intra-domain two-way authentication between the trusted data space and the user: The user initiates an authentication request and sends the message to the VS; after the VS accepts and verifies the authentication request from the user, the VS starts generating second verification information and sends it to the TDS; after receiving the second verification information from the VS, the TDS starts verifying the received information; after the TDS verifies the authenticity of the information source and content, the TDS calculates the communication channel and sends the communication channel to the user. After receiving the communication channel, the user starts to reverse verify the TDS identity. If trusted, the user uses the session key... Interact with TDS; S5. Trusted Data Space and User Cross-Domain Authentication and Key Negotiation: Users initiate cross-domain requests to TDS in other domains and pass the authentication and key negotiation through the local domain. and the other domain After verification, cross-domain authentication is completed and the message is transmitted. The S3 Trusted Data Space and user registration process includes the following steps: When a Trusted Data Space (TDS) enters the domain, it is first verified by the VS server and assigned a unique identifier. Then VS generates random numbers. Furthermore, a pseudo-identity for TDS is achieved through a one-way hash function. generate: And the generation of pseudo-identities by trusted data service provider TDSP. ,in To verify the unique identifier assigned by the Verification Server (VS) to the Trusted Data Service Provider (TDSP), the TDSP will subsequently use a pseudo-identity (PID) in communication with the user. The Verification Server (VS) also generates an entry pass for the TDSP. = ,in This is the timestamp of the Trusted Data Space (TDS) application for domain entry, after which the verification server (VS) will... , Send it to the Trusted Data Space (TDS) via a secure channel, and also save it yourself. , Locally; The user registration process includes user node selection. And setting a password Users use sensors to record biometric characteristics calculate ,in It is a biometric key. These are reproduction parameters. It is the core component of the fuzz extractor, which takes biometric data as input. Output a pair of keys Calculate user pass ,Will Verify the server VS, then VS generates for the user and The calculation is as follows: in It verifies the fake identity generated by the server (VS) for the user. It is the true identity of the trusted data service provider (TDSP) in the domain where the user registered. It is its TDSP pseudo-identity. This refers to the domain entry pass for user nodes. The timestamp used during registration will be used to verify the server VS. }Send to the user, store { Locally, user login requires entering... as well as And biometric data during verification Give it to VS, and VS will generate a new pass through calculation. : in It is a fuzz extractor based on new biometric data Combining biometric keys Use the recovery function The calculated reproduction parameters are then used by the server (VS) to verify the user's pseudo-identity during login and to calculate the verification parameters. If the conditions are met, the login is successful. After verification, the Trusted Data Service Provider (TDSP) will send a certificate to the verified Trusted Data Space (TDS). ,in It is a public key generated by KGC for the Trusted Data Space (TDS), and , It is a private key generated by the key generation organization KGC for the trusted data space. This refers to performing a hash operation on it. To generate a certificate timestamp; The intra-domain two-way authentication between the S4 Trusted Data Space and users specifically includes the following steps: S41. The user initiates an authentication request and sends the message to the VS: The user calculates parameters A, B, and C, and sends the message { } is sent to the verification server VS, where This is the timestamp when the user initiated the authentication request. The calculation formulas for parameters A, B, and C are as follows: After receiving the authentication request, the authentication server (VS) first verifies the authenticity of the user's identity and calculates the user's false identity. And the pseudo-identity of Trusted Data Space (TDS) The calculation formula is as follows: Finally, verify the correctness of the server's verification message and calculate the parameters. The formula is as follows: if If the message is valid, the VS generates a request message and sends it to the Trusted Data Space (TDS); otherwise, the authentication process terminates. S42. After VS accepts and verifies the authentication request from the user, VS begins to generate authentication information and sends it to the Trusted Data Space (TDS). The authentication message includes the new domain entry license. ,parameter E, F, and G are calculated using the following formulas: in, To verify the timestamps used by the server VS to generate verification information for the Trusted Data Space (TDS). For the random numbers generated by VS, VS will { Send to TDS; S43. After receiving the verification information from the VS, the Trusted Data Space (TDS) begins to verify the received information: First, the Trusted Data Space (TDS) calculates the pseudo-identity of user nodes. random numbers Verify the new pass generated by the server VS for the user. and messages : Trusted Data Space (TDS) Verification If they are equal, it indicates the authenticity of the information source and content; if they fail, the Trusted Data Space (TDS) will terminate the authentication process. S44. After the Trusted Data Space (TDS) verifies the source and authenticity of the information, it selects the session key SK with the user to ensure secure communication with the user node. The Trusted Data Space (TDS) calculates the communication channel, including... , , ,in Generate timestamps for returned information in the Trusted Data Space (TDS), and... Send to the user, when the user receives Then, the reverse verification of the Trusted Data Space (TDS) identity begins. The user first calculates: if ,but It is a verified trusted communication key, a trusted data space, and a user-provided trusted communication key. Reliable communication has commenced.

2. The cross-domain authentication method for trusted data spaces based on digital certificates according to claim 1, characterized in that: The specific functions of each module in the S1 Trusted Data Space Cross-Domain Authentication System include: User: refers to a node that needs to access the trusted data space. To obtain access or control permissions for the trusted data space, a user needs to register. When accessing or operating the trusted data space of other domains, the user node needs to perform cross-domain access. Trusted Data Space: Used for data storage, as a key entity for building a data circulation environment with mutual trust among multiple parties. In interactions with users and trusted data service providers, the Trusted Data Space must follow intra-domain authentication protocols and cross-domain authentication processes to conduct secure communication and collaboration between different domains. Trusted data service provider: An entity that maintains and controls the trusted data space, ensuring the flow and value release of data throughout the entire data lifecycle; it also maintains an access control table as a blockchain node to manage user access permissions and provides authentication when registering for entry into the trusted data space and performing cross-domain operations; Key Generation Organization: During system initialization, the key generation organization KGC generates a global master key and global parameters. This master key is used to derive user-specific private keys. When a trusted data space or user registers and provides their ID, the key generation organization uses the master key and ID to calculate and generate a private key, and securely distributes the generated private key to the corresponding entity. Authentication server: This is an authentication entity within the domain, used to manage the trusted data space within the domain; Blockchain: The distributed nature of blockchain is used for information sharing among authorized users. Each successful cross-domain authentication is a transaction, and the permission table stores {user, domain, remaining time}.

3. The cross-domain authentication method for trusted data spaces based on digital certificates according to claim 1, characterized in that: The S2 system initialization specifically includes the following steps: KGC runs the initialization function and sets security parameters. Generate global parameters Pr and master private key MK, where the global parameters include pairing environment and random integer. and generator g, Represents the generator g The power of 1, KGC calculates the public key corresponding to MK. ,Right now KGC releases public parameters It is public information available to all participants; it also includes parameter initialization for two-way authentication within the domain and initialization of the blockchain, including setting up the consensus mechanism and selecting the blockchain platform.

4. The cross-domain authentication method for trusted data spaces based on digital certificates according to claim 3, characterized in that: System initialization also includes: during the system initialization phase, the Trusted Data Service Providers (TDSPs) of all domains jointly select a prime number q, and select G1 and G2 as a group of prime numbers of order q, where G1 and G2 represent a bilinear mapping, and P is the generator of G1. This refers to a hash encryption algorithm, where each Trusted Data Service Provider (TDSP) within a domain chooses its own private key. ,in It is a multiplicative cyclic group consisting of all invertible elements modulo q, therefore the corresponding public key is... After initialization is complete, For all entities publicly accessible within the domain, after verification, the Trusted Data Service Provider (TDSP) will send a certificate to the verified Trusted Data Space (TDS). ,in It is a public key generated by KGC for the Trusted Data Space (TDS), and , It is a private key generated by the key generation organization KGC for the trusted data space. This refers to performing a hash operation on it. For the pseudo-identity of Trusted Data Space (TDS), This is the timestamp used to generate the certificate.

5. The cross-domain authentication method for trusted data spaces based on digital certificates according to claim 1, characterized in that: S5 Trusted Data Space and User Cross-Domain Authentication and Key Negotiation specifically include the following steps: First, the user requests this domain Send cross-domain authentication requests, including your own. and the target trusted data space And related security parameters, trusted data service providers in this domain The message is processed and forwarded to the target trusted data space. TDS Trusted data service providers in the domain , The authorization table maintained in the blockchain is queried to determine whether the requesting user has been verified and is within the validity period. If so, then... Generate a communication channel and send it to and Both parties can communicate through a pre-defined channel; If no results are found, a complete verification process is required. First, the timestamp is verified to be within the time limit. Then, the correctness of the message is verified through calculation. After successful verification, a communication channel is generated, along with the cross-domain authentication information to be sent to the user. The cross-domain authentication information generated by the Trusted Data Space (TDS) is first sent back to... Then by The message is sent back to the user, who then calculates the target channel. will come from The request message, along with the communication channel, is sent to the Trusted Data Space (TDS) in this domain that is requesting cross-domain authentication. After both parties obtain the communication channel, the user and the Trusted Data Space successfully interact and complete the cross-domain access operation.

Images