Cross-domain data sharing method and system for internet of vehicles based on registered inner product property encryption

Abstract

This invention provides a cross-domain data sharing method for vehicle-to-everything (V2X) networks based on registration inner product attribute encryption, aiming to solve the problems of high key escrow risk and lack of bidirectional access control in existing solutions. This method adopts a decentralized registration encryption paradigm, where user terminals autonomously generate private keys, and domain administrators only verify the legality of public keys and aggregate parameters, eliminating key escrow and single points of failure at the source. During cross-domain sharing, the sender's ciphertext must simultaneously embed the attribute signatures of both the source and target domain administrators, and attach a non-interactive zero-knowledge proof to ensure consistency between the signature and ciphertext structure. Edge gateways verify the dual signatures in parallel; if either domain policy is not satisfied, the ciphertext is discarded, achieving mandatory dual-domain access control and preventing unilateral attribute forgery or cross-domain collusion to exceed authority. Simultaneously, the gateway does not hold any decryption materials; it only performs a purification operation after verifying the zero-knowledge proof, effectively replacing the original random number and cutting off the sender's controllable randomness channel, thereby eliminating covert channels. This invention combines decentralization, mandatory dual-domain control, and computational efficiency, making it suitable for secure cross-domain data sharing in V2X networks.

Description

Technical Field

[0001] This invention belongs to the fields of information security, cryptography, and vehicle networking technology, and specifically relates to a method and system for cross-domain data sharing in vehicle networking based on registration inner product attribute encryption. Background Technology

[0002] With the rapid development of digital interconnection technologies, cross-domain data sharing has become a core infrastructure in fields such as Intelligent Transportation Systems (ITS). In typical ITS application scenarios (such as vehicle-road-cloud integrated emergency response), traffic management departments, connected vehicles, and cloud service providers need to conduct high-frequency and sensitive data interactions. Such cross-domain collaboration typically requires the system to simultaneously meet three core security requirements: strict access control (only authorized entities can initiate or receive communication), end-to-end encryption protection (data remains encrypted throughout transmission and storage), and communication privacy protection (the encrypted data does not reveal the identities and attribute associations of the communicating parties).

[0003] Traditional access control mechanisms (such as role-based access control) typically rely on centralized decision points, making them ill-suited for the complex architectures of dynamic, multi-trust entities in cross-domain environments, and failing to provide end-to-end encryption guarantees. Therefore, cryptography-based access control technologies have become a research hotspot. Attribute-Based Encryption (ABE) achieves fine-grained "who can decrypt" control by embedding access policies into ciphertext or keys; cross-domain layered ABE schemes further support the fusion of multi-domain policies. However, ABE-like schemes only verify the static legitimacy of the receiver's permissions and cannot constrain the sender's behavior, resulting in a one-way flow control flaw where malicious senders intentionally construct policies to leak data to unauthorized entities.

[0004] To overcome these limitations, Access Control Encryption (ACE) was proposed. ACE introduces a "Sanitizer" entity (typically deployed on gateways or edge servers) that performs legitimacy verification and sanitization (re-randomization) on ciphertext without holding the user's decryption key. If the ciphertext conforms to the global access policy, the Sanitizer converts it into valid ciphertext and allows it to pass; if it violates the policy, it is blocked. This mechanism shifts the policy enforcement point from the key distribution center to the data transmission path, achieving bidirectional information flow control. Meanwhile, the Registration-Based Encryption (RBE) paradigm has gradually developed, allowing users to generate and store their private keys independently, only needing to submit their public keys to a key manager for registration and aggregation, fundamentally eliminating the key escrow risks of traditional schemes.

[0005] The closest existing technologies are a series of cross-domain access control encryption schemes, such as "Cross-domain access control encryption: Arbitrary-policy, constant-size, efficient" (CD-IBACE), "Cross-domain attribute-based access control encryption" (CD-ABACE), and "Cross-domain inner-product access control encryption for secure EMR flow incloud edge" (CD-IPACE).

[0006] In the existing solutions described above, the system architecture is typically divided into a sending domain and a receiving domain. Each domain independently deploys a domain authority, and an edge cleanup gateway is deployed between the two domains. When users in the two domains wish to send or receive data, the specific implementation process is as follows:

[0007] Key generation and distribution: When a user needs to participate in cross-domain communication, they must submit their identity or attribute credentials to the DA (Data Authority) of their respective domain. The DA, as a fully trusted centralized entity, is responsible for running the key generation algorithm, directly calculating the encryption public key and decryption private key for the user, and distributing them to the user through secure channels or online services.

[0008] Ciphertext generation and transmission: The sender uses the encryption key distributed by DA and the preset access policy to encrypt the plaintext, generating the original ciphertext carrying the policy attributes. The ciphertext is first sent to the edge cleanup gateway.

[0009] Sanitization and Cross-Domain Forwarding: The edge sanitization gateway uses the signature verification key or policy token issued by the DA to verify the attribute signature carried in the ciphertext. If the verification passes, the gateway performs a sanitization (re-randomization) operation to remove the hidden information in the ciphertext before forwarding it to the target domain, and finally delivers the sanitized ciphertext to the recipient.

[0010] Decryption: The receiver uses the decryption private key distributed by DA to decrypt the purified ciphertext. If its properties meet the policy set by the sender, the plaintext is restored.

[0011] While the aforementioned schemes theoretically achieve cross-domain access control, their technical implementation heavily relies on centralized key distribution mechanisms by domain authorities. For example, although CD-IPACE attempts to introduce multi-party threshold authorization to distribute trust, the generation of encryption and decryption keys and core computations are still dominated by the authoritative institution. This architecture leads to an inherent single point of failure risk in the system, and during dynamic user registration, it often requires a global key update or reinitialization of system parameters, making it difficult to meet the practical needs of low latency, decentralized trust, and efficient dynamic management in edge computing scenarios such as intelligent transportation.

[0012] The disadvantages of existing technologies are as follows: Key escrow poses a single point of failure risk: In existing cross-domain ACE schemes, users' encryption and decryption keys are generated and distributed by a domain authority. This highly centralized architecture has a serious key escrow problem; once the authority is compromised or used maliciously, the security of the entire system and user privacy will be completely compromised.

[0013] Cross-domain access control policies are easily circumvented: existing edge cleanup gateways are often only responsible for ensuring that policies comply with the access rules set by one of the two domains. When transmitting across domains, malicious users still have the opportunity to evade the supervision of a single domain by forging attributes.

[0014] Excessive computational and operational overhead: Although some solutions attempt to use multi-party thresholding mechanisms to distribute trust, this increases the initialization, operational, and communication costs of the system, making it difficult to deploy on resource-constrained edge devices. Summary of the Invention

[0015] In view of this, the purpose of this invention is to provide a cross-domain data sharing method for vehicle networks based on registration inner product attribute encryption. This invention aims to solve the technical problems of "over-reliance on centralized authoritative institutions leading to key custody risks" and "lack of two-way access control mechanism" in existing cross-domain data sharing schemes, and proposes a decentralized (users generate their own keys), dual-domain mandatory access control capability and computationally efficient cross-domain data sharing method.

[0016] A cross-domain data sharing method for vehicle-to-everything (V2X) networks based on registration inner product attribute encryption is applied to a system including a source domain administrator, a target domain administrator, a cloud server, a source domain edge gateway, a target domain edge gateway, and registered users. The method includes: Step S1: System Initialization The source domain administrator and the target domain administrator generate their respective signing private keys and signing public keys based on the input security parameters, attribute vector dimensions, and maximum user capacity, and collaborate with the cloud server to initialize public parameters, system status, and the public reference string of the non-interactive zero-knowledge proof system. Step S2: User Local Key Generation and Dual-Domain Registration Each registered user independently generates a corresponding public key group and private key group for each subsystem of the system's preset level on their local machine, and submits the public key group, their own attribute vector, and the attribute declaration message generated based on the attribute vector as registration materials to the source domain administrator and the target domain administrator respectively. The source domain administrator and the target domain administrator each independently review the attribute policy and verify the attribute declaration of the registration materials. After the verification is successful, they each use their respective signature private keys to generate attribute signatures for the registered user and return them to the registered user. The cloud server receives the public key group of the registered user and verifies its legality. After the verification is successful, the public key group is bound and stored with the attribute vector of the registered user. Based on the number of currently registered users, it determines whether to trigger the aggregation operation of the public keys of all users in the corresponding subsystem to generate the master public key of the level and generate an auxiliary decryption key for each user in the level, while updating the system status. Step S3: Data Encryption and Zero-Knowledge Proof Generation The first registered user, acting as the sender, obtains the list of master public keys currently maintained by the cloud server, which includes master public keys at each level. Using its own attribute vector as an encryption strategy, it calls the inner product attribute encryption algorithm to encrypt the plaintext data and generate the original ciphertext. The first registered user uses the attribute signatures of the source domain administrator and the target domain administrator, the random number used for encryption, and its own attribute vector as evidence to call the proof algorithm of the non-interactive zero-knowledge proof system to generate a first zero-knowledge proof and a second zero-knowledge proof to prove that the original ciphertext has obtained a valid dual-domain signature and that the ciphertext structure is correct. The first registered user then assembles the original ciphertext, the first zero-knowledge proof, and the second zero-knowledge proof into a data packet and sends it to the source domain edge gateway. Step S4: Edge Gateway Encryption Filtering and Purification The source domain edge gateway and the target domain edge gateway respectively receive the data packet, call the verification algorithm of the non-interactive zero-knowledge proof system, and verify the legality of the data packet based on the first zero-knowledge proof and the second zero-knowledge proof; if any verification fails, the data packet is discarded; if both verifications pass, the gateway randomly selects a cleansing random number to perform a re-randomization operation on the original ciphertext to generate cleaned ciphertext, and forwards the data packet containing the cleaned ciphertext across domains. Step S5: Receiver auxiliary parameter update and decryption After receiving the purified ciphertext, the second registered user, as the recipient, determines the decryption level based on the version number in their own private key group and the version number in the purified ciphertext, and requests the cloud server to obtain the auxiliary decryption key corresponding to that level. The second registered user uses the private key component corresponding to that level in their private key group, their own attribute vector, and the obtained auxiliary decryption key to call the inner product attribute decryption algorithm to decrypt the cleaned ciphertext. The plaintext data is successfully recovered only when the inner product of the attribute vector of the second registered user and the encryption policy attribute vector of the first registered user is zero.

[0017] Preferably, the system initialization in step S1 specifically includes: Construct an asymmetric bilinear pairing system based on the aforementioned security parameters; The source domain administrator and the target domain administrator each generate their own signature key pair, which includes a signature private key vector and a signature public key vector. The cloud server calculates the number of levels based on the maximum user capacity, and independently generates a common reference string for each level, which includes single-element parameters, one-dimensional user parameters, two-dimensional attribute parameters, and three-dimensional association parameters. Initialize the system state, which includes a registered user counter, a first dictionary for storing user public keys and attribute vectors, a second dictionary for storing user auxiliary decryption keys, and a master public key list; Initialize the non-interactive zero-knowledge proof system and generate its public reference string.

[0018] Preferably, in step S2, the registered user independently generates a public key group and a private key group locally, specifically including: For each level, the registered user calculates the level index in that level based on the registered user counter value in the current system state; Randomly select an element from a large prime number field as the private key component for that level; Extract the two-dimensional attribute parameters and three-dimensional association parameters corresponding to the index of the level from the public reference string of the level, and calculate the public key component of the level based on the private key component; The private key components corresponding to each level are combined into a private key group, and the public key components corresponding to each level are combined into a public key group. Both the private key group and the public key group contain the value of the registered user counter as a version number.

[0019] Preferably, the aggregation operation performed by the cloud server in step S2 specifically includes: For any full level, bind the public key components of all registered users in that level with their respective attribute vectors to obtain the user public key components after incorporating attributes. Multiply all the user public key components after incorporating attributes to generate the master public key for this level. For each user within this level, an auxiliary decryption key is generated based on the public key components of other users and the parameters in the public reference string, and stored in the second dictionary.

[0020] Preferably, in step S3, the first registered user calls the inner product attribute encryption algorithm to generate the original ciphertext, specifically including: Expand its own attribute vector into a first expanded vector, the dimension of which is the dimension of the attribute vector plus two. For each non-empty master public key in the master public key list, a random encrypted number is randomly selected, and the ciphertext component of that level is calculated using the public parameters in that master public key. The ciphertext component includes a message-carrying ciphertext component and a cleanup component. Assemble all the ciphertext components at all levels with the current registered user counter value into the original ciphertext.

[0021] Preferably, in step S4, the edge gateway performs a re-randomization operation on the original ciphertext, specifically including: For each non-empty level of ciphertext component in the original ciphertext, the message-bearing ciphertext component in the ciphertext component is updated using the cleaned component in the ciphertext component and the randomly selected cleaned random number, so as to generate the cleaned ciphertext component of that level. The original ciphertext component is replaced with the purified ciphertext component to generate the purified ciphertext.

[0022] Preferably, the method for the second registered user to determine the decryption level in step S5 is as follows: compare the version number in the private key group of the second registered user with the binary representation of the version number in the cleaned ciphertext, and find the level where the highest different bit is located. This level is the level corresponding to decryption.

[0023] Preferably, in step S5, the second registered user requests the auxiliary decryption key from the cloud server, specifically including: The second registered user submits their public key set to the cloud server; The cloud server compares the version number in the public key group with the registered user counter value in the current system status. If the version number is less than the registered user counter value, the cloud server retrieves the auxiliary decryption key corresponding to the user from the second dictionary and returns it; otherwise, it returns empty.

[0024] A cross-domain data sharing system for vehicle-to-everything (V2X) networks based on registration inner product attribute encryption includes: The source domain administrator and the target domain administrator are respectively used to generate their own signature key pairs based on security parameters, review and verify the attribute information submitted by registered users, and issue attribute signatures for registered users who pass the verification. The cloud server is used to collaboratively complete system initialization, maintain public parameters and system status, verify the legality of registered user public keys, manage user registration information, perform aggregation of user public keys to generate master public keys at each level and user auxiliary decryption keys, and respond to user auxiliary key update requests. The source domain edge gateway and the destination domain edge gateway are used to receive and verify the zero-knowledge proof carried in the data packet, perform a re-randomization purification operation on the verified ciphertext, and forward the purified ciphertext to achieve keyless bidirectional access control. Registered users, acting as senders or receivers of shared data, are responsible for generating public-private key pairs locally, registering attributes with the domain administrator and obtaining attribute signatures, encrypting data using the master public key list and their own attribute vectors to generate zero-knowledge proofs, and decrypting and purifying ciphertext using their own private key and auxiliary decryption keys.

[0025] A computer-readable storage medium having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the cross-domain data sharing method for vehicle networking based on registration inner product attribute encryption as described in any one of claims 1 to 8.

[0026] The present invention has the following beneficial effects: Eliminating key escrow and single points of failure: A registration-based encryption paradigm is adopted, where user terminals generate their own private keys, and domain administrators only perform public key verification and parameter aggregation. Even or Even if the system is compromised, attackers will not be able to reverse-engineer the user's private key, thus eliminating the risk of centralized key leakage at its source.

[0027] Dual-domain mandatory access control prevents collusion: requires the sender's ciphertext to be embedded simultaneously. and The attribute signature is verified, and the consistency between the signature and the ciphertext structure is proven via NIZKP. The gateway verifies the dual signatures in parallel, and discards the signature if either domain policy is not met, thus completely preventing unilateral forgery of attributes or cross-domain collusion to exceed authority.

[0028] Keyless purification cuts off covert channels: The edge gateway does not hold any decryption materials; it only performs purification operations after verifying compliance through zero-knowledge proofs. This operation is computationally equivalent to replacing the original random number, eliminating the sender's controllable randomness in the ciphertext. Attached Figure Description

[0029] Figure 1 This is an architectural model diagram of the cross-domain data sharing system of the present invention.

[0030] like Figure 1 As shown, the system is divided into a source domain (domain A) and a target domain (domain B). Core entities include cloud servers and domain administrators. ), edge gateway ( ) as well as various underlying registered users (RUs, such as vehicle terminals, control centers, etc.). Figure 1 This intuitively demonstrates the "dual-domain communication" and "edge purification" logic of the present invention: the original ciphertext generated by the sender RU must first pass through the source domain edge gateway ( The legitimacy verification and re-randomization operation generate "purified ciphertext," which is then transmitted across domains to the target domain edge gateway. It undergoes a second interception / verification process before it can be received and decrypted by the legitimate receiver (RU). Meanwhile, Figure 1 It also demonstrates the preliminary process that user terminals need to cooperate with domain administrators and cloud servers to complete registration and aggregation.

[0031] Figure 2 The diagram shows the simulation results of the encryption algorithm performance of this invention.

[0032] Figure 2 The horizontal axis represents the attribute vector dimension of the policy, and the vertical axis represents the encryption operation time (s). Figure 2 It can be seen that, compared with the existing mainstream cross-domain access control schemes (CD-IBACE, CD-ABACE, CD-IPACE), the encryption time of the present invention is significantly lower than that of other comparative schemes; and as the dimension of the attribute vector continues to increase, the encryption overhead of the present invention grows extremely slowly, showing extremely high encryption computation efficiency, which is especially suitable for intelligent transportation edge terminals with limited computing power.

[0033] Figure 3 The simulation results show the performance of the decryption algorithm.

[0034] Figure 3 The horizontal axis represents the attribute vector dimension of the strategy, and the vertical axis represents the terminal decryption operation time (s). Figure 3It is known that the decryption time of existing mainstream solutions tends to increase linearly with the increase of attribute dimensions. However, the terminal decryption time of this invention is compressed to an extremely low constant level, and its overhead hardly changes with the increase of attribute vector dimensions (it is a horizontal straight line), which greatly reduces the computational pressure on the data receiving end. Detailed Implementation

[0035] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0036] This invention proposes a cross-domain data sharing method for vehicle networks based on registration inner product attribute encryption.

[0037] (1) System composition and module functions: This system is suitable for cross-domain data sharing scenarios and includes the following entity modules: Domain Administrator (DA): The source domain administrator responsible for sending data in this system (denoted as...). ) and the target domain administrator (denoted as) of the data reception The domain administrator is responsible for verifying whether a user's identity and attributes comply with the domain's access control policies when the user submits their identity information, and for deciding whether to issue a digital signature for the user's attributes based on the results.

[0038] Cloud Server (CS): An honest and curious entity responsible for assisting domain administrators in handling registration requests and forwarding encrypted data, and calculating and maintaining three key system parameters: Public parameters : A series of publicly available parameters used for key generation, encryption, decryption, and other steps.

[0039] Master public key list (master publickey, ): A set of master public keys used for encryption.

[0040] Help secret key ): A series of parameters used for decryption.

[0041] Edge Gateway (EG): This system includes the source domain edge network management (denoted as...) for data transmission. ) and the target domain edge gateway for data reception (denoted as The edge gateway does not hold any private keys. It is responsible for monitoring encrypted data entering and leaving the domain, verifying the legitimacy of the encrypted data using non-interactive zero-knowledge proof (NIZKP), filtering out illegal encrypted data, and purifying (re-randomizing) legitimate encrypted data to prevent covert channel attacks.

[0042] Registered User (RU): The sender and receiver for cross-domain communication. Registered users are distinguished by their identity identifier and attribute vector. They generate their own public and private keys locally and submit them to the domain administrator for registration. When sharing data across domains, plaintext data is encrypted using the publicly available master public key list on the cloud server and the user's own attribute vector to obtain ciphertext data. The ciphertext data is then decrypted using the private key and an auxiliary decryption key maintained by the cloud server to obtain the original plaintext data.

[0043] The overall system architecture model of this invention is as follows: Figure 1 As shown. The sender's registered user (RU) encrypts and generates ciphertext, which is then transmitted through the source domain edge gateway (…). Zero-knowledge proofs are used for verification and filtering, and the data is then re-randomized into cleaned ciphertext before being forwarded across domains to the target domain's edge gateway. After verification, the message was finally delivered to the recipient, RU. Meanwhile, Figure 1 This also reflects that users need to notify their respective domain administrators in advance for cross-domain communication. / The system and cloud server complete dual-domain joint authentication and public key aggregation.

[0044] (2) The working principle and steps of the method of the present invention: The cross-domain data sharing method of the present invention includes the following key steps: Step 1: System Initialization Domain administrator ( , Based on the input security parameters (The difficulty of breaking a cryptographic algorithm is usually represented by the number of bits in the large prime number used to construct the system parameters), attribute vector dimension. (The number of user identification tags, such as "department, position, status") and maximum user capacity. (The maximum number of users supported by the system, of which) (For the hierarchical parameters used to organize and locate user registration information), execute the initialization algorithm: 1.1: Constructing the bilinear mapping group and fundamental parameters: According to safety parameters Initialize the asymmetric bilinear pairing system ,in , , These represent three different mathematical groups, each with the same number of elements, all of which are large prime numbers. ; , They are groups , generator, This is called a bilinear mapping ( It is a special mathematical mapping function that can map a set of groups , The element mapping is a group (elements); select a collision-resistant hash function. This hash function is used to identify the user. Mapped to a unique group element.

[0045] 1.2: Domain Administrator Signature Key Generation: Domain administrator and Execute independently: (1) Calculate the signature private key: from 1 to Random numbers are randomly and independently selected from integers of -1. This forms the signature private key (vector). , recorded as ,in This represents the dimension of the input attribute vector. Both the source and target domain administrators must securely store their respective signing private keys locally. , , used for subsequent signing.

[0046] (2) Calculate the signature public key (vector) , recorded as Domain administrators need to share their respective signing public keys. , It is disclosed as part of the public parameters.

[0047] 1.3: Initialization of common reference strings: To clearly maintain a set of public reference strings Domain administrator , Computation and maintenance are jointly performed through cloud servers. Parameters at each level (where By inputting the system's maximum user capacity (Calculated using a base-2 logarithm). The letter 'k' is used as the level index to represent the parameter of the k-th level. Each level contains a single-element parameter associated with that level. Each level can be considered as a space that can accommodate... A subsystem of users is defined, using the letter 'i' as the user index representing the parameter of the i-th user in that subsystem. Each level contains a one-dimensional parameter associated with each user in that level. Each level also includes two-dimensional parameters associated with each attribute component of each user. The letter 'w' is used as the attribute index to represent the w-th attribute component; each level also includes three-dimensional parameters representing the associations between different users and related to each attribute component. The letter 'j' is used as the user index in this hierarchical subsystem to represent the parameter associated with the i-th user. Here, k takes values... The values ​​of i and j Furthermore, j is not equal to i, and w takes its value during the initialization step. (remember Let w be the dimension after the vector is expanded, and in subsequent steps, as the attribute vector expands, w can take different values. ), k, i, j, and w are all integers.

[0048] For each level Calculate once the common reference string of this level, which contains single-element, one-dimensional, two-dimensional, and three-dimensional parameters. ,in That is, the bilinear pairing system parameters described in step 1.1, with each level sharing the same group environment.

[0049] The specific calculation method is as follows: Single-element parameter: from 1 to Random numbers are randomly and independently selected from integers of -1. Calculate single-element parameters .

[0050] One-dimensional parameter: from 1 to Random numbers are randomly and independently selected from integers of -1. Calculate one-dimensional parameters where i takes the value .

[0051] Two-dimensional parameters: from 1 to Random numbers are randomly and independently selected from integers of -1. Calculate two-dimensional parameters where i takes the value w takes the value .

[0052] 3D parameters: Calculate 3D parameters where i takes the value j takes the value And j≠i, w takes the value .

[0053] The final calculation yields a common reference string containing all k levels. and initialize the system state. Among them, the counter This represents the number of registered users in the current system; a dictionary (a type of data structure). and These are used to store the registered user's public key and attribute vector, as well as the registered user's auxiliary decryption key and master public key list, respectively, in subsequent steps. This includes a counter and the master public key for all k hierarchical sub-schemes, which are initialized to 0 and empty, respectively. ).

[0054] 1.4: Zero-knowledge proof system initialization: This scheme utilizes non-interactive zero-knowledge proof (NIZKP) technology, enabling the sender to prove to the edge gateway that "my ciphertext is compliant" without exposing privacy information such as signatures, attribute vectors, and encrypted random numbers. The gateway also does not need to possess the decryption private key to complete the verification.

[0055] First, define a class of statements (denoted as a language) that zero-knowledge proofs need to process in this system. ) and the rules for determining whether a statement is true (denoted as relations) In this scheme, such a statement can be simply described as: "The sender claims that the attribute vector used for encryption has obtained legitimate signatures from the source and target domain administrators, and that the ciphertext structure is completely correct." The corresponding judgment rule is: when the sender can simultaneously present legitimate signatures from both domain administrators, the original message, the attribute vector, and the random number used for encryption, these materials can be used to verify the authenticity of this claim through signature verification and ciphertext structure verification.

[0056] Subsequently, the initialization algorithm of the zero-knowledge proof system is invoked to generate the system's public reference string. Since non-interactive zero-knowledge proofs are mature cryptographic tools already existing in this field, this invention does not involve improvements to their internal structure. Therefore, the specific operational steps of their initialization algorithm, proof algorithm, and verification algorithm will not be described in detail, but they will only be used as a whole as a functional module.

[0057] 1.5: Output common parameters: Finally, all the publicly available information above is combined to form the global common parameters for the entire system:

[0058] Step 2: User Local Key Generation and Dual-Domain Registration To eliminate centralized key escrow, user terminals independently generate public and private keys locally, and generate parameters such as the master public key via the cloud: 2.1: Local Key Generation: user (Identification identifier) For each subsystem at each level maintained by the system, a corresponding public-private key pair needs to be generated independently. Specifically, for the first... Each level ( ,common (Levels) (1) Calculate users In the Hierarchical index in each level That is: to set the current system's registered user counter. The value divided by the total number of users that the subsystem at that level can accommodate. Take the remainder obtained from this division, and then add 1 to the remainder.

[0059] (2) From 1 to Random numbers are randomly and independently selected from integers of -1. , as the private key for this level ; (3) From public reference strings Extracting elements and , compute public key component and ,in , as the public key of this level

[0060] Ultimately, the user Obtain the public key group With private key group ,in User The key version number indicates "how many users this user's key was generated after the system registered".

[0061] 2.2: Two-Domain Attribute Authentication and Signature: user Submit the following registration materials to the domain administrator. , (1) Public key group (2) Attribute vector (3) Attribute declaration message The attribute declaration message is generated using a hash function. User identification Mapping to a group elements in Then respectively Group generators Using the base as the attribute vector Each component is raised to a power of another, resulting in... , .

[0062] The two domain administrators execute the commands independently: (1) Attribute policy auditing: Checking the user's attributes ( Check if the registration complies with the domain's access control policy; if not, registration will be refused. (2) Attribute declaration verification: verification Whether by and Correctly calculate the generation, that is, for each component of the attribute vector, record the index. Check the equation Whether it is valid, among which Indicates user The property declaration vector in the property declaration message The One portion, Similarly; (3) Generate attribute signature: If the verification is successful, the administrator uses the signature private key. Generate attribute signatures for users ,in .

[0063] user Must be obtained simultaneously and Only with a signature can subsequent cross-domain communication be carried out.

[0064] 2.3: Registration Parameter Generation: cloud server Received from user After receiving the registration request, perform the following operations: (1) Public key validity verification: for each level Check the equation Whether it is true or not. This equation is used to verify the public key component submitted by the user. and ) and public reference strings The corresponding parameters in ( and Check if the bilinear pairing calculation results are consistent. If the equations for all levels are true, then it indicates that the user's public key... If the valid public key is correctly constructed and generated according to the steps, proceed to the next step; (2) Attribute Vector Integration and Aggregation: Integrating the public key and attributes of each user at each corresponding level. Save to dictionary For each level To determine whether the number of users in this subsystem has reached its maximum capacity when the current user registers: ①If it has been achieved (i.e.) If the public keys of all users in that subsystem are aggregated into a master public key, then the aggregation algorithm is executed. And generate a corresponding auxiliary decryption key for each user in this subsystem. Store the auxiliary decryption key component in a dictionary. The index is (in This is the system's registered user counter value prior to this registration process. This index value indicates which registered user is at this level (used to locate their unique auxiliary decryption key), i.e. This information is provided to the relevant users during the decryption phase based on their system version number at the time of registration. The aggregation algorithm is calculated as follows: i) For each ,use The public parameters in the hierarchy will be used to define the parameters for each user in that hierarchy. attribute vector Bind it to its public key component using the following calculation method:

[0065] in User The attribute vector of the first One portion, and yes Two-dimensional and three-dimensional parameters in the model.

[0066] ii) Multiply all user public key components after incorporating attributes to calculate the parameters in the master key: The master key for this level is obtained as follows ,in , , , yes The publicly available parameters.

[0067] iii) For each Generate the parameters in the auxiliary decryption key:

[0068] The obtained auxiliary decryption key ,in , , yes The publicly available parameters.

[0069] ②If not achieved (i.e. If so, the master public key will remain unchanged at its initial value; (3) System status update: After completing the above verification and aggregation, increment the global counter by 1 (i.e., ), and with the updated The two dictionaries at present And a new list of master public keys Assemble into a new system state The list of master and public keys Its first digit is the updated counter value (as the version number), and the subsequent components correspond to the master public key of each level: if a level has just completed aggregation, the newly generated one is used. Otherwise, the original value is used (i.e., the master public key at this level has not changed). Then use... Replace the original system state, user Registration complete.

[0070] Step 3: Data Encryption and Zero-Knowledge Proof Generation Sender transmits plaintext data across domains At that time, it uses the attribute vector that it submitted during registration and signed by both domain administrators for encryption. This is used in the decryption conditions to compare the attribute vector with the recipient user's. Clearly distinguish, and denote the sender user attribute vector as Perform the following actions to ensure data privacy and policy enforcement: 3.1: Vectorized Attribute Encryption: To ensure that the recipient's private key and constant terms are included in the inner product calculation during decryption, the sender user needs to first include their attribute vector. Add two dimensions and fill them with 0, thus expanding to... Then for each level k: If the public key at this level Then record the ciphertext at that level. If the public key at this level If not initially null, then from 1 to... Random numbers are randomly and independently selected from integers of -1. Using the master public key at this level The publicly available parameters are used to calculate the ciphertext at that level. Quantity: , , , , , , .in ~ To carry ciphertext components for the message, , , The purification component is used for subsequent purification of the ciphertext.

[0071] Output ciphertext group ,in , This is the first parameter in the current system status st, representing the number of currently registered users.

[0072] 3.2: Zero-knowledge proof construction: The sender invokes the zero-knowledge proof algorithm, based on the language described in step 1.4. With Relationship Based on public information For the purpose of statements and privacy information As evidence, generate two proofs corresponding to the source domain and the target domain, respectively. and This proof mathematically promises to the verifier (edge ​​gateway) that the following relations hold simultaneously: Valid signature: This equation proves that the attribute signature provided by the sender and the verification public key published by the dual-domain administrators can pass bilinear pairing verification (i.e., prove that 'my attribute was indeed jointly signed by the administrators of both domains').

[0073] The ciphertext structure is correct: This means proving that the mathematical relationships between the components of the ciphertext perfectly match the master public key and the encrypted random number (i.e., proving that 'the ciphertext I sent was generated according to the rules and did not contain any hidden agendas').

[0074] Subsequently, the sender will send the original ciphertext. Source domain proof Proof with the target domain Assemble into data packets It is sent to the source domain edge gateway via a secure channel. The data packet was transmitted via After verification and purification, it will be transmitted via cloud server. Cross-domain forwarding to the target domain edge gateway ,Depend on A second verification is performed before the data is entered into the domain. Once the verification is successful, the data is finally delivered to the recipient.

[0075] Step 4: Edge Gateway Encryption Filtering and Purification Edge gateway ( , As a cross-system security control node, execute: 4.1: Cross-domain validity verification: Edge gateway and For each encrypted data packet The corresponding proof in the code is verified using a zero-knowledge proof verification algorithm. If verification fails, the ciphertext data packet is discarded. .

[0076] 4.2: Encryption Cleansing: If the verification passes, the gateway will be in position 1 to... Random numbers are randomly and independently selected from integers of -1. Perform a cleanup operation, removing non-empty ciphertext values ​​from each level of the ciphertext data packet. Calculate its purified ciphertext Quantity: And finally obtained the purified ciphertext group. The final output is the purified ciphertext. .

[0077] Step 5: Update and decrypt auxiliary parameters for the receiver The receiving terminal obtains the purified ciphertext Then, the recipient first determines the level of ciphertext to be used for decryption. This involves comparing and cleaning the ciphertext group. First parameter counter in The first counter in its own private key group Find the level at which the highest difference bit exists in the binary representations of the two binary representations. (with the least significant bit as bit 0), this level This refers to the level corresponding to this decryption. For example: the registration counter (i.e., ... The value of ) is 3 (binary 011), and the current ciphertext counter (i.e. The value is 5 (binary 101), and the highest different bit is the 2nd bit. Therefore, the ciphertext and key corresponding to the 2nd level are used for decryption.

[0078] 5.1: Obtaining Auxiliary Decryption Parameters: Recipient Send a helper key update request to the cloud server and submit your public key set. The cloud server compares the first digit of the user's public key with a counter. Counters in the current system state : (1) If This indicates that new users joined after user registration, causing the primary public key to be updated. The user's current secondary key is outdated, and the cloud server is retrieving it from the dictionary. Extract the corresponding user's auxiliary decryption keys, including those for each level. Return to the user; (2) If If this indicates that the system status has not changed and no update is needed, return empty (or directly inform the user to use the locally stored auxiliary key).

[0079] 5.2: Attribute Matching and Decryption: The receiver retrieves the corresponding decryption level from the private key group. Private key component Extract the corresponding decryption level from the auxiliary decryption key. Auxiliary decryption parameters Combine its own attribute vector with the private key component to form an extended vector. ( (Dimension), and calculate the normalization factor by summing the vector components. ,implement:

[0080] The mathematical correctness of the above decryption process depends on a key condition: the attribute vector used by the sender during encryption. With the receiver's own attribute vector The inner product must be zero. If Then the formula is related to The relevant pairs will cancel each other out due to the algebraic structure, thus successfully recovering the plaintext. .like If the above cancellation cannot be completed, the calculation result will be meaningless random group elements, and the output will be... (Decryption failed), thus implementing access control based on attribute inner product.

[0081] Example 1: This embodiment uses the cross-domain transmission of sensitive accident data from an "accident emergency vehicle" to a "traffic control center" in an Intelligent Transportation System (ITS) as a specific application scenario. Assume the system security parameters... Attribute vector dimension The system has a preset maximum capacity of registered users. (Corresponding number of slot layers) The specific implementation process is as follows: Step 1: System Initialization Domain administrator and Input parameters Generate an asymmetric bilinear pairing system Choose a collision-resistant hash function. . Generate signature key pairs separately: randomly selected Preserve the signing private key Publicly verify public key Initialize system state. and make public reference strings and zero-knowledge proof parameters Final system common parameters Broadcast to the entire network.

[0082] Step 2: User Local Key Generation and Dual-Domain Registration Assuming registered users (Accident vehicle, identification) )and (Traffic control terminal, identification tag) Join the system. Current maximum user capacity of the system. ,correspond maintenance The system has several levels of subsystems (each subsystem supports a maximum user capacity of [number]). (Based on the users who first registered with the system) For example: 2.1: Local Key Generation: The key generation algorithm is executed independently on a local basis to generate corresponding key pairs for each level: For level 0 ( ): Compute hierarchical index

[0083] Random selection As the private key component of this level from Selected from and

[0084] Compute public key component ,

[0085] Output the key pair for level 0: ,

[0086] For the first level ( ): Compute hierarchical index

[0087] Random selection

[0088] from Select the corresponding element and calculate ,

[0089] Output the first-level key pair: ,

[0090] For the second level scheme ( ): Compute hierarchical index

[0091] Random selection

[0092] from Select elements from the list and calculate. , ( ) Output the second-level key pair: ,

[0093] final, Assemble the public key set With private key group The private key is securely stored locally by the user and will never be disclosed to any entity.

[0094] 2.2: Two-Domain Attribute Authentication and Signature: Submit the following materials to the dual-domain administrator. : Public key group

[0095] Local attribute vector (Represents "Advanced Permission Node in Control Center") Property declaration message ,in

[0096] and Execute separately: Attribute strategy review: inspection Does it comply with the access control policy of this domain? Assume both domain policies require the first dimension of the attribute vector to be... And the second dimension ",but Approved.

[0097] Property declaration validation: Validation Whether by and Accurate calculation and generation prevent users from forging attributes.

[0098] Generate attribute signatures: calculate Using private key Generate signature:

[0099] Similarly, generate signatures.

[0100] 2.3: Registration Parameter Generation: Cloud Server receive After receiving the registration request, execute: Public key validity verification: for each level Check if the bilinear pairing relation holds: If all levels of validation pass, confirm. It was legally generated.

[0101] Attribute vector integration and aggregation: Will Save to dictionary

[0102] Check if the current level is full: For Hierarchical index None of them are equal to their upper limit. Therefore, aggregation will not be performed for the time being, and the master public key will remain in use. It remains unchanged.

[0103] System status update: Counter update:

[0104] Update system status

[0105] Since only one user has registered so far, the tier has not yet reached its maximum capacity. Only level 1 of the markers is currently occupied. Registration complete: dual-domain signature Return to

[0106] Obtaining complete registration credentials enables cross-domain encrypted communication. System common parameters With the master key Broadcast to the entire network Step 3: Data Encryption and Zero-Knowledge Proof Generation An incident message needs to be sent. Define the policy attribute vector that the receiver must satisfy. . Will Expanded to Randomly select encrypted random numbers . use Calculate the core component of the ciphertext:

[0107]

[0108] ( )

[0109] With signature and encrypted random numbers Using these as evidence, a proof algorithm for zero-knowledge proofs is invoked to generate a two-domain zero-knowledge proof. The proof makes a mathematical commitment to the outside world: (1) Ciphertext policy properties. (1) Dual-domain valid authentication has been obtained; (2) The generated ciphertext structure correctly embeds the valid policy signed by the domain administrator. Finally, the original data packet is assembled. Send to source domain edge gateway .

[0110] Step 4: Edge Gateway Encryption Filtering and Purification Edge gateway take over Then, only the zero-knowledge proof verification algorithm is invoked. Assuming all verifications pass, the edge gateway... Randomly select fresh random numbers Perform a rerandomization (purification) operation on the ciphertext: This operation is mathematically equivalent to overwriting the original encryption randomness, thus erasing the sender's randomness. Controllable randomness cuts off potential covert channels. Output cleaned ciphertext. through Forward to target domain gateway , After performing the same verification, the application is allowed to enter the domain.

[0111] Step 5: Update and decrypt auxiliary parameters for the receiver receive ,Towards Initiate an update request to obtain Extract the local private key for the level used for decryption. With auxiliary key Calculate the inner product: The decryption conditions are met. Substitute into the decryption formula:

[0112] Successfully restored plaintext .

[0113] Scenario 1: Assuming there is a malicious receiver Its local attributes are (Ordinary social vehicles). Its internal volume .even though Intercepting the purified ciphertext When substituting into the decryption formula, Item cannot be matched Pairwise elimination occurs, and the result degenerates into random group elements. It is impossible to recover any valid information, thus achieving strict access control and anti-collusion interception of attribute inner product.

[0114] Scenario 2: Attempting to construct a policy attribute vector (Intent attributes and) (An unauthorized entity sends data with an inner product of 0), but the attribute vector has not been properly signed by the dual-domain administrator. Forcibly during encryption Embedded ciphertext and attempts to forge zero-knowledge proofs. When the ciphertext Reaching the source domain edge gateway hour, Execute the verification algorithm: .because Unable to obtain right Valid signature Its forged certificate The NIZKP verification equation cannot be satisfied: Verification results , Discard the encrypted message immediately to prevent unauthorized transmission by the malicious sender. Even if Even conspiring with an unauthorized recipient cannot breach the first line of defense of the edge gateway.

[0115] Scenario 3: Assumption It is a legitimate registered user with dual-domain signatures. However, it attempted to manipulate the randomness of encryption to mislead the colluding recipient. To convey additional information. Choose a special random number during encryption. This makes the ciphertext component It contains additional bits of information (e.g., through...) Parity encoding of 1 bit secret). Original ciphertext. able to pass NIZK verification (because the attribute is valid and the signature is effective). However, when When performing a purification operation: ,in The gateway independently selects a random number. This operation is mathematically equivalent to overwriting the original encryption randomness, because... For the sender Completely unknown and uncontrollable, the randomness was completely eliminated after purification. In the original random number Any hidden information embedded within. Even if the conspiring recipient... Successfully decrypted and obtained purified ciphertext What it obtains is only the group elements that have been randomly overwritten, and it cannot extract the group elements. Additional bits that are attempted to be transmitted through a covert channel.

[0116] Note: Specific values ​​(e.g.) (This is just an example to aid understanding; in actual implementation, it should be a randomly selected large prime number field element.)

[0117] (3) Performance simulation and comparative testing To further verify the efficiency of this invention in practical engineering applications, performance simulations of the cryptographic algorithm were conducted based on the embodiments, and compared with existing mainstream schemes (CD-IBACE, CD-ABACE, CD-IPACE). The simulation results are as follows: Figure 2 and Figure 3 As shown.

[0118] like Figure 2 As shown, the encryption computational overhead of this invention is significantly lower than that of the comparative schemes, and its growth rate with increasing attribute vector dimension is the slowest. This indicates that the encryption stage of this invention is suitable for deployment on edge devices such as vehicle-to-everything (V2X) sensors where computing resources are limited.

[0119] like Figure 3 As shown, the actual decryption overhead for end users in this invention is not only significantly lower than that of the comparative schemes, but also exhibits excellent "constant" characteristics (the time consumption hardly increases with the increase of attribute dimensions). This indicates that the decryption of this invention meets the stringent requirements for low latency in cross-domain data sharing in the context of vehicle networking and intelligent transportation.

[0120] In summary, the above are merely preferred 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-domain data sharing in vehicle-to-everything (V2X) networks based on registration inner product attribute encryption, characterized in that, Applied to a system including a source domain administrator, a target domain administrator, a cloud server, a source domain edge gateway, a target domain edge gateway, and registered users, the method includes: Step S1: System Initialization The source domain administrator and the target domain administrator generate their respective signing private keys and signing public keys based on the input security parameters, attribute vector dimensions, and maximum user capacity, and collaborate with the cloud server to initialize public parameters, system status, and the public reference string of the non-interactive zero-knowledge proof system. Step S2: User Local Key Generation and Dual-Domain Registration Each registered user independently generates a corresponding public key group and private key group for each subsystem of the system's preset level on their local machine, and submits the public key group, their own attribute vector, and the attribute declaration message generated based on the attribute vector as registration materials to the source domain administrator and the target domain administrator respectively. The source domain administrator and the target domain administrator each independently review the attribute policy and verify the attribute declaration of the registration materials. After the verification is successful, they each use their respective signature private keys to generate attribute signatures for the registered user and return them to the registered user. The cloud server receives the public key group of the registered user and verifies its legality. After the verification is successful, the public key group is bound and stored with the attribute vector of the registered user. Based on the number of currently registered users, it determines whether to trigger the aggregation operation of the public keys of all users in the corresponding subsystem to generate the master public key of the level and generate an auxiliary decryption key for each user in the level, while updating the system status. Step S3: Data Encryption and Zero-Knowledge Proof Generation The first registered user, acting as the sender, obtains the list of master public keys currently maintained by the cloud server, which includes master public keys at each level. Using its own attribute vector as an encryption strategy, it calls the inner product attribute encryption algorithm to encrypt the plaintext data and generate the original ciphertext. The first registered user uses the attribute signatures of the source domain administrator and the target domain administrator, the random number used for encryption, and its own attribute vector as evidence to call the proof algorithm of the non-interactive zero-knowledge proof system to generate a first zero-knowledge proof and a second zero-knowledge proof to prove that the original ciphertext has obtained a valid dual-domain signature and that the ciphertext structure is correct. The first registered user then assembles the original ciphertext, the first zero-knowledge proof, and the second zero-knowledge proof into a data packet and sends it to the source domain edge gateway. Step S4: Edge Gateway Encryption Filtering and Purification The source domain edge gateway and the target domain edge gateway respectively receive the data packet, call the verification algorithm of the non-interactive zero-knowledge proof system, and verify the legality of the data packet based on the first zero-knowledge proof and the second zero-knowledge proof; if any verification fails, the data packet is discarded; if both verifications pass, the gateway randomly selects a cleansing random number to perform a re-randomization operation on the original ciphertext to generate cleaned ciphertext, and forwards the data packet containing the cleaned ciphertext across domains. Step S5: Receiver auxiliary parameter update and decryption After receiving the purified ciphertext, the second registered user, as the recipient, determines the decryption level based on the version number in their own private key group and the version number in the purified ciphertext, and requests the cloud server to obtain the auxiliary decryption key corresponding to that level. The second registered user uses the private key component corresponding to that level in their private key group, their own attribute vector, and the obtained auxiliary decryption key to call the inner product attribute decryption algorithm to decrypt the cleaned ciphertext. The plaintext data is successfully recovered only when the inner product of the attribute vector of the second registered user and the encryption policy attribute vector of the first registered user is zero.

2. The method according to claim 1, characterized in that, The system initialization in step S1 specifically includes: Construct an asymmetric bilinear pairing system based on the aforementioned security parameters; The source domain administrator and the target domain administrator each generate their own signature key pair, which includes a signature private key vector and a signature public key vector. The cloud server calculates the number of levels based on the maximum user capacity, and independently generates a common reference string for each level, which includes single-element parameters, one-dimensional user parameters, two-dimensional attribute parameters, and three-dimensional association parameters. Initialize the system state, which includes a registered user counter, a first dictionary for storing user public keys and attribute vectors, a second dictionary for storing user auxiliary decryption keys, and a master public key list; Initialize the non-interactive zero-knowledge proof system and generate its public reference string.

3. The method according to claim 1, characterized in that, In step S2, the registered user independently generates a public key group and a private key group locally, specifically including: For each level, the registered user calculates the level index in that level based on the registered user counter value in the current system state; Randomly select an element from a large prime number field as the private key component for that level; Extract the two-dimensional attribute parameters and three-dimensional association parameters corresponding to the index of the level from the public reference string of the level, and calculate the public key component of the level based on the private key component; The private key components corresponding to each level are combined into a private key group, and the public key components corresponding to each level are combined into a public key group. Both the private key group and the public key group contain the value of the registered user counter as a version number.

4. The method according to claim 1, characterized in that, The aggregation operation performed by the cloud server in step S2 specifically includes: For any full level, bind the public key components of all registered users in that level with their respective attribute vectors to obtain the user public key components after incorporating attributes. Multiply all the user public key components after incorporating attributes to generate the master public key for this level. For each user within this level, an auxiliary decryption key is generated based on the public key components of other users and the parameters in the public reference string, and stored in the second dictionary.

5. The method according to claim 1, characterized in that, In step S3, the first registered user calls the inner product attribute encryption algorithm to generate the original ciphertext, specifically including: Expand its own attribute vector into a first expanded vector, the dimension of which is the dimension of the attribute vector plus two. For each non-empty master public key in the master public key list, a random encrypted number is randomly selected, and the ciphertext component of that level is calculated using the public parameters in that master public key. The ciphertext component includes a message-carrying ciphertext component and a cleanup component. Assemble all the ciphertext components at all levels with the current registered user counter value into the original ciphertext.

6. The method according to claim 1, characterized in that, In step S4, the edge gateway performs a re-randomization operation on the original ciphertext, specifically including: For each non-empty level of ciphertext component in the original ciphertext, the message-bearing ciphertext component in the ciphertext component is updated using the cleaned component in the ciphertext component and the randomly selected cleaned random number, so as to generate the cleaned ciphertext component of that level. The original ciphertext component is replaced with the purified ciphertext component to generate the purified ciphertext.

7. The method according to claim 1, characterized in that, The method for the second registered user to determine the decryption level in step S5 is as follows: compare the version number in the private key group of the second registered user with the binary representation of the version number in the cleaned ciphertext, find the level where the highest different bit is located, and this level is the level corresponding to decryption.

8. The method according to claim 1, characterized in that, In step S5, the second registered user requests the auxiliary decryption key from the cloud server, specifically including: The second registered user submits their public key set to the cloud server; The cloud server compares the version number in the public key group with the registered user counter value in the current system status. If the version number is less than the registered user counter value, the cloud server retrieves the auxiliary decryption key corresponding to the user from the second dictionary and returns it; otherwise, it returns empty.

9. A cross-domain data sharing system for vehicle networks based on registration inner product attribute encryption, used to execute the method of any one of claims 1 to 8, characterized in that, include: The source domain administrator and the target domain administrator are respectively used to generate their own signature key pairs based on security parameters, review and verify the attribute information submitted by registered users, and issue attribute signatures for registered users who pass the verification. The cloud server is used to collaboratively complete system initialization, maintain public parameters and system status, verify the legality of registered user public keys, manage user registration information, perform aggregation of user public keys to generate master public keys at each level and user auxiliary decryption keys, and respond to user auxiliary key update requests. The source domain edge gateway and the destination domain edge gateway are used to receive and verify the zero-knowledge proof carried in the data packet, perform a re-randomization purification operation on the verified ciphertext, and forward the purified ciphertext to achieve keyless bidirectional access control. Registered users, acting as senders or receivers of shared data, are responsible for generating public-private key pairs locally, registering attributes with the domain administrator and obtaining attribute signatures, encrypting data using the master public key list and their own attribute vectors to generate zero-knowledge proofs, and decrypting and purifying ciphertext using their own private key and auxiliary decryption keys.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the cross-domain data sharing method for vehicle networking based on registration inner product attribute encryption as described in any one of claims 1 to 8.

Images