Internet of vehicles cross-domain trust management method based on block chain

Abstract

The invention discloses an Internet of Vehicles cross-domain trust management method based on a block chain, and belongs to the technical field of Internet of Vehicles and block chains. For a vehicle reliability problem in cross-domain authentication, firstly, a device calculates a trust value, generates a trust rating and calculates a trust offset according to a trust management scheme; then generating a block chain, and chaining the offset of the vehicle trust rating; and secondly, the vehicle can evaluate the credibility of the vehicle message during cross-domain authentication by querying the trust value of the nearby to-be-authenticated vehicle, and finally, the authentication is completed through the trust value. According to the invention, the efficiency and reliability of the Internet of Vehicles are effectively ensured while the calculation overhead is reduced.

Description

Technical Field

[0001] The present invention relates to the fields of Internet of Vehicles, blockchain and federated learning, and in particular to a cross-domain trust management method for Internet of Vehicles based on blockchain. Background Art

[0002] The Internet of Vehicles (IoV) is one of the typical applications of the Internet of Things in the automotive industry. It builds a high-speed mobile broadband wireless network that supports various services, including driving safety and information services. At the same time, as a key component of the Intelligent Transportation System (ITS), the Internet of Vehicles uses advanced communication technology to connect vehicles, roads, traffic management facilities, and traffic participants (such as drivers and pedestrians). Through unified communication protocols and data interaction standards, real-time information exchange and interconnection between vehicles, between vehicles and infrastructure, and between vehicles and users are realized. This open and dynamic network can effectively alleviate vehicle congestion and reduce the probability of traffic accidents.

[0003] However, although the Internet of Vehicles has brought convenience to people, due to the openness and variability of its network topology, vehicle users need to frequently interact across domains. However, in the cross-domain process, malicious vehicles may deliberately spread false information, reducing the reliability of vehicles in the network, thereby reducing the reliability of the entire network and endangering traffic safety.

[0004] At the same time, the cross-domain information interaction process may contain sensitive vehicle information, such as identity information, location information, request information, etc., which may be maliciously tampered or intercepted by attackers during the transmission process, resulting in the vehicle information being invalid because it cannot be correctly verified by the receiver, reducing the security and efficiency of cross-domain authentication. In current research, the cross-domain authentication scheme of the Internet of Vehicles can effectively solve the above problems, but the centralized cross-domain authentication scheme often has a single point of failure problem.

[0005] The research on cross-domain authentication of Internet of Vehicles faces the challenge of insufficient vehicle reliability: cross-domain authentication of Internet of Vehicles involves information exchange across different regions and network environments, but there may be malicious vehicles in the network, and there will be security risks in the information exchange process, leading to various security issues. Therefore, it is urgent to find an effective solution to ensure the reliability of vehicles in cross-domain authentication. Summary of the invention

[0006] The present invention proposes a cross-domain trust management method for Internet of Vehicles based on blockchain, which aims to solve the problems raised in the above background technology and calculate the trust value of vehicles in the Internet of Vehicles network through a trust evaluation model. Then, the vehicle can evaluate the trust of the vehicle message during cross-domain authentication by querying the trust value of nearby vehicles to be authenticated, and finally complete the cross-domain authentication process, effectively curbing the malicious behavior of vehicles in the network and ensuring the efficient completion of cross-domain authentication.

[0007] The technical solution adopted by this method includes the following steps:

[0008] Step 1: Design a trust management scheme based on trust value offset aggregation to calculate the trust value of each vehicle and generate the corresponding trust rating, and then calculate the trust offset to reflect the change in vehicle trust.

[0009] Step 2: Generate a blockchain and upload the offset of the vehicle trust rating to the chain through a consensus algorithm to ensure the security and traceability of trust information.

[0010] Step 3: The vehicle can query the trust values ​​of nearby vehicles to be authenticated and use this to evaluate the credibility of the vehicle message in the cross-domain authentication.

[0011] Step 4: Design a cross-domain authentication scheme based on trust value, authenticate through the trust value of the vehicle, and thus achieve cross-domain trust management.

[0012] Step 1 specifically includes the following:

[0013] The trust value offset is generated based on the messages sent by the vehicle in the past. At the same time, the behavior in the subsequent authentication process is also regarded as the message interaction between vehicles, which will also affect the evaluation of the trust value offset. Then, the RSU (roadside unit) links the offsets of all vehicles for the same message set. Finally, the current trust value of the vehicle can be obtained by summing up all the offsets of the vehicle. The offset changes as the vehicle sends messages in interaction, and the trust value will also be adjusted with the offset.

[0014] Based on the distance from the event location and the interval between the message sending time and the current event, the trust value of a message is defined as:

[0015]

[0016] in, Send vehicle k to M j The trustworthiness of the messages in the message group, and It represents the distance between the sender of the message and the place where the event occurred. send -t occur represents the interval between the time when the vehicle sends a message and the time when the vehicle receives the message. x and y are predefined parameters about the distance, and γ is a predefined parameter about the time interval. b is used to control the upper and lower limits of the message trust and the rate of change.

[0017] Vehicle k will periodically upload its trust rating to nearby RSUs S , the format of trust rating is defined as Cre = {VIN i ,VIN j ,msg k, rating}. Among them, VIN i and VIN j Respectively represent the message receiving vehicle and the message sending vehicle, msg k It is the identifier of the message, and rating indicates the rating of the message, with a value of +1 (the message is credible) or -1 (the message is not credible).

[0018] The trust rating is aggregated to obtain the offset. The offset of the trust rating is obtained by weighted aggregation.

[0019]

[0020] in Represents vehicle k for message e j The trust rating aggregation value of The value range is [0,1]. m and n represent the number of positive trust ratings and negative trust ratings respectively, and their respective weights are represented by μ1 and μ2.

[0021]

[0022] In the above formula, the choice of function F() determines the sensitivity of the change of trust rating. For example, the function F(x) = x 2 , smaller offset changes will be reduced in the aggregation process, while larger offset changes will be amplified. When using F(x)=x, the offset directly affects the aggregation offset linearly, which is very sensitive to the score changes of the minority group. Finally, RSU S The calculated offset will be placed in set O, and attempts will be made to add it to the blockchain later so that it can be summed up and the trust value of the vehicle can be calculated.

[0023] Step 2 specifically includes the following:

[0024] A hybrid consensus mechanism combining PoW (proof of work) and PoS (proof of stake) is designed. This method uses the sum of absolute offsets as stake, and the difficulty of completing PoW depends on the stake. RSUs with more stake can more easily find nonce (generate random numbers) and win elections (i.e. publish their blocks faster), which ensures that data in the blockchain is updated in a timely manner. The proposed verifier election method is as follows:

[0025] Hash(ID RSU ,time,PreHash,nonce)≤D i

[0026] Where D i For RSU i PoW hash threshold, all RSU SConstantly change your nonce value according to the formula To calculate the hash value, the RSU that first satisfies the above conditions is selected as the verifier. At the same time, this paper also defines the sum of the absolute values ​​of the trust value offsets F i , which is related to D i Proportional, F i The calculation formula is as follows:

[0027]

[0028] Among them, Q i Represents the current trust value offset set. When F i When the value is larger, the probability of the RSU winning the election is greater. i Too many RSUs win continuously, which reduces the reliability of the system. In this paper, we set F max As its upper bound. In this way, RSU S The RSU that can fairly run for the verifier will add its offset set to the blockchain and clear the Q that has been successfully added to the blockchain. i To save resources.

[0029] D i The calculation formula is as follows:

[0030]

[0031] Where N m It is the number of bits of the hash value generated by the hash algorithm. It is usually a fixed value and depends on the hash algorithm used, such as the SHA-1 algorithm N m =160, SHA-256 algorithm N m =256. N z D i The number of consecutive 0 bits in the head determines the difficulty of the hash value.

[0032] Once a block is received from a validator, the RSU needs to verify the validity of the nonce and then add it to the blockchain. However, if multiple RSUs meet the validator election conditions at the same time, it may cause the blockchain to fork. The hybrid consensus mechanism proposed in this article can solve this problem. Under this mechanism, each RSU will choose a branch and continue to publish new blocks on that branch. Over time, the branches recognized by the most RSUs will grow faster, and eventually other branches will be discarded. In addition, each RSU also needs to collect the blocks it generates in the discarded forks and try to add them to the blockchain in the future. In this way, all RSUs store the same version of the blockchain, thereby ensuring the consistency of the network.

[0033] Step 3 specifically includes the following:

[0034] When a vehicle in one area of ​​the Internet of Vehicles network wants to obtain the trust value of a vehicle in another area, it needs to send a request message for vehicle trust value query to the nearby RSU. Among them, and are the vehicle identification numbers of the request sender and the target vehicle, respectively. After receiving the query request, the RSU first checks the identity of the request sender. Then, based on the offsets stored in the blockchain, the RSU adds up all the offsets to obtain the current trust value of vehicle j, and then encrypts the trust value with the vehicle's public key and sends it to the vehicle. Finally, the RSU sends the trust value of the target vehicle to the requester.

[0035] Step 4 specifically includes the following:

[0036] First, determine the access trust threshold based on the current system's actual situation and access policy. When the system is too crowded, increase the threshold appropriately to improve system reliability. When the system needs it, lower the trust threshold appropriately to meet the requirements. The entire process of the solution is divided into the registration phase and the cross-domain authentication phase.

[0037] Vehicle registration phase: After the vehicle enters the RSU coverage area, the vehicle generates a temporary public key by itself and private key The Elgamal algorithm is used in this process. g and p are prime numbers selected by the system. The temporary public and private key pair of the OBU (roadside unit) is generated as follows:

[0038]

[0039]

[0040] The vehicle then uses the generated private key Sign the registration request message msg and use the public key Pk of the trust center TA After encryption, it is sent to the trust center through RSU.

[0041] After receiving the vehicle registration request, the trust center uses the private key Sk TA Decrypt the registration request using the public key right The signature is verified to ensure that this is a registration request from the owner of the public key. After verification, the result returned by the request is signed with the private key. After successful verification, the registration information, including the vehicle ID, is issued to the vehicle through a secret channel. i , Vehicle private key and RSU public key Pk RSU . Vehicle uses temporary private key Decrypt the returned message, verify its signature, and determine whether the registration is successful based on the result. If the registration is successful, destroy the temporary public-private key pair and use the private key returned by the trust center. Generate a new public key

[0042] Cross-domain authentication phase: divided into 7 steps, 1) First, V a The signed public key Pk a Send to V b : Req a→b ={signS a (Pk a )}

[0043] 2) V b Request the RSU in this domain to help it complete the V a It sends a request message to the RSU, which includes V a The trust value query request sent is query=(Query, VIN a ,VIN b ), public key Pk b and a random number r1, which is encrypted with the RSU public key and sent to the RSU, where Enc(·) is the signature algorithm:

[0044] Req b→RSU =EnP RSU (query,Pk b ,r1)

[0045] 3) RSU uses the private key Sk RSU After decryption, call the smart contract deployed on the chain to obtain the current vehicle V b Trust value Tr b and vehicle V a Trust value Tr a ,Finally, the access trust threshold is determined based on the actual situation and access ,policy, and the respective trust values ​​are compared with the threshold.

[0046] 4) After the comparison is completed, the corresponding result is returned to V b If the trust values ​​of both parties are higher than the threshold, only the subsequent key negotiation steps need to be completed.

[0047]

[0048] 5) V b After decrypting the message returned by RSU, if the True message is obtained, the symmetric key K is generated. b Pk bHash the temporary session key K and r1, and record the result as H, which is used as the encryption key of K. Encapsulate the encrypted temporary session key K and use K to encrypt the random number r2, and then use the public key Pk a After encryption, send to V a :

[0049] H=hash(Pk b |r1)

[0050] Content = {EnH(K),T,EnK(r2)}

[0051] Req b→a =EnPk a (Content)

[0052] 6) V a Decrypt the message sent by RSU. Then, use Pk b The encryption key H is calculated by hashing r1, decrypting it to get K, and then decrypting it with K to get the random number r2. Then a random number r3 is generated, and the communication data is encapsulated with random numbers r2 and r3, and encrypted with the temporary session key K and sent to V b :

[0053] Msg a→b =EnK(r2|r3|Data)

[0054] 7) V b Decrypt the message and verify the signature, detect the random number r2, ensure that the other party's identity is trusted and has the key K, and if the verification is successful, the information is received, indicating that the vehicle V a and V b Cross-domain authentication is successful. Otherwise, cross-domain authentication fails and the two vehicles cannot establish a connection. At the same time, whether it succeeds or fails, the result needs to be fed back to the nearby RSU, because each cross-domain interaction of the vehicle will directly affect the trust of the next cross-domain access.

[0055] Compared with the prior art, the present invention has the following beneficial effects:

[0056] The present invention discloses a cross-domain trust management method for Internet of Vehicles based on blockchain, and belongs to the technical field of Internet of Vehicles and blockchain. In view of the problem of vehicle reliability in cross-domain authentication, first, the device calculates the trust value according to the trust management scheme, generates the trust rating, and calculates the trust offset; then generates a blockchain, and uploads the offset of the vehicle trust rating to the chain; secondly, the vehicle can query the trust value of the nearby vehicles to be authenticated, and then evaluate the trust of the vehicle message during cross-domain authentication, and finally, complete the authentication through the trust value. The present invention effectively guarantees the efficiency and reliability of the Internet of Vehicles while reducing the computing overhead. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 It is a step diagram of the present invention. Figure 2 This is a cross-domain authentication flow chart of the present invention. DETAILED DESCRIPTION

[0057] In order to clarify the technical problems, technical solutions, implementation processes and performance demonstrations, the present invention is further described in detail below in conjunction with embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention. Various exemplary embodiments, features and aspects of the present disclosure will be described in detail below with reference to the accompanying drawings. The same reference numerals in the accompanying drawings represent elements with the same or similar functions. Although various aspects of the embodiments are shown in the accompanying drawings, the drawings do not have to be drawn to scale unless otherwise specified.

[0058] This embodiment proposes a federated learning data sharing method based on blockchain and teacher-student model, including the following steps:

[0059] Step 1: Design a trust management scheme based on trust value offset aggregation to calculate the trust value of each vehicle and generate the corresponding trust rating, and then calculate the trust offset to reflect the change in vehicle trust.

[0060] Step 2: Generate a blockchain and upload the offset of the vehicle trust rating to the chain through a consensus algorithm to ensure the security and traceability of trust information.

[0061] Step 3: The vehicle can query the trust values ​​of nearby vehicles to be authenticated and use this to evaluate the credibility of the vehicle message in the cross-domain authentication.

[0062] Step 4: Design a cross-domain authentication scheme based on trust value, authenticate through the trust value of the vehicle, and thus achieve cross-domain trust management.

[0063] Step 1 specifically includes the following:

[0064] The trust value offset is generated based on the messages sent by the vehicle in the past. At the same time, the behavior in the subsequent authentication process is also regarded as the message interaction between vehicles, which will also affect the evaluation of the trust value offset. Then, the RSU will chain the offsets of all vehicles for the same message set. Finally, the current trust value of the vehicle can be obtained by summing up all the offsets of the vehicle. The offset changes as the vehicle sends messages in interaction, and the trust value will also be adjusted with the offset.

[0065] Based on the distance from the event location and the interval between the message sending time and the current event, the trust value of a message is defined as:

[0066]

[0067] in, Send vehicle k to M j The trustworthiness of the messages in the message group, and It represents the distance between the sender of the message and the place where the event occurred. send -t occur represents the interval between the time when the vehicle sends a message and the time when the vehicle receives the message. x and y are predefined parameters about the distance, and γ is a predefined parameter about the time interval. b is used to control the upper and lower limits of the message trust and the rate of change.

[0068] Vehicle k will periodically upload its trust rating to nearby RSUs S , the format of the trust rating is defined as

[0069] Cre={VIN i ,VIN j ,msg k , rating}. Among them, VIN i and VIN j Respectively represent the message receiving vehicle and the message sending vehicle, msg k It is the identifier of the message, and rating indicates the rating of the message, with a value of +1 (the message is credible) or -1 (the message is not credible).

[0070] The trust rating is aggregated to obtain the offset. The offset of the trust rating is obtained by weighted aggregation.

[0071]

[0072] in Represents vehicle k for message e j The trust rating aggregation value of The value range is [0,1]. m and n represent the number of positive trust ratings and negative trust ratings respectively, and their respective weights are represented by μ1 and μ2.

[0073]

[0074] In the above formula, the choice of function F() determines the sensitivity of the change of trust rating. For example, the function F(x) = x 2 , smaller offset changes will be reduced in the aggregation process, while larger offset changes will be amplified. When using F(x)=x, the offset directly affects the aggregation offset linearly, which is very sensitive to the score changes of the minority group. Finally, RSU S The calculated offset will be placed in set O, and attempts will be made to add it to the blockchain later so that it can be summed up and the trust value of the vehicle can be calculated.

[0075] Step 2 specifically includes the following:

[0076] A hybrid consensus mechanism combining PoW and PoS is designed. This method uses the sum of absolute offsets as the stake, and the difficulty of completing PoW depends on the stake. RSUs with more stake can more easily find nonce and win the election (i.e. publish their blocks faster), which ensures that the data in the blockchain is updated in a timely manner. The proposed verifier election method is as follows:

[0077] Hash(ID RSU ,time,PreHash,nonce)≤D i

[0078] Where D i For RSU i PoW hash threshold, all RSU S Constantly change your nonce value according to the formula To calculate the hash value, the RSU that first satisfies the above conditions is selected as the verifier. At the same time, this paper also defines the sum of the absolute values ​​of the trust value offsets F i , which is related to D i Proportional, F i The calculation formula is as follows:

[0079]

[0080] Among them, Q i Represents the current trust value offset set. When F i When the value is larger, the probability of the RSU winning the election is greater. i Too many RSUs win continuously, which reduces the reliability of the system. In this paper, we set F max As its upper bound. This way, RSU S The RSU that can fairly run for the verifier will add its offset set to the blockchain and clear the Q that has been successfully added to the blockchain. i To save resources. i The calculation formula is as follows:

[0081]

[0082] Where N m It is the number of bits of the hash value generated by the hash algorithm. It is usually a fixed value and depends on the hash algorithm used, such as the SHA-1 algorithm N m =160, SHA-256 algorithm N m =256. N z D i The number of consecutive 0 bits in the head determines the difficulty of the hash value.

[0083] Once a block is received from a validator, the RSU needs to verify the validity of the nonce and then add it to the blockchain. However, if multiple RSUs meet the validator election conditions at the same time, it may cause the blockchain to fork. The hybrid consensus mechanism proposed in this article can solve this problem. Under this mechanism, each RSU will choose a branch and continue to publish new blocks on that branch. Over time, the branches recognized by the most RSUs will grow faster, and eventually other branches will be discarded. In addition, each RSU also needs to collect the blocks it generates in the discarded forks and try to add them to the blockchain in the future. In this way, all RSUs store the same version of the blockchain, thereby ensuring the consistency of the network.

[0084] Step 3 specifically includes the following:

[0085] When a vehicle in one area of ​​the Internet of Vehicles network wants to obtain the trust value of a vehicle in another area, it needs to send a request message for vehicle trust value query to the nearby RSU. Among them, and are the vehicle identification numbers of the request sender and the target vehicle, respectively. After receiving the query request, the RSU first checks the identity of the request sender. Then, based on the offsets stored in the blockchain, the RSU adds up all the offsets to obtain the current trust value of vehicle j, and then encrypts the trust value with the vehicle's public key and sends it to the vehicle. Finally, the RSU sends the trust value of the target vehicle to the requester.

[0086] Step 4 specifically includes the following:

[0087] First, determine the access trust threshold based on the current system's actual situation and access policy. When the system is too crowded, increase the threshold appropriately to improve system reliability. When the system needs it, lower the trust threshold appropriately to meet the requirements. The entire process of the solution is divided into the registration phase and the cross-domain authentication phase.

[0088] Vehicle registration phase: After the vehicle enters the RSU coverage area, the vehicle generates a temporary public key by itself and private key The Elgamal algorithm is used in this process. g and p are prime numbers selected by the system. The temporary public and private key pair of the OBU is generated as follows:

[0089]

[0090]

[0091] The vehicle then uses the generated private key Sign the registration request message msg and use the public key Pk of the trust center TA After encryption, it is sent to the trust center through RSU.

[0092] After receiving the vehicle registration request, the trust center uses the private key Sk TA Decrypt the registration request using the public key right The signature is verified to ensure that this is a registration request from the owner of the public key. After verification, the result returned by the request is signed with the private key. After successful verification, the registration information, including the vehicle ID, is issued to the vehicle through a secret channel. i , Vehicle private key and RSU public key Pk RSU .

[0093] Vehicle uses temporary private key Decrypt the returned message, verify its signature, and determine whether the registration is successful based on the result. If the registration is successful, destroy the temporary public-private key pair and use the private key returned by the trust center. Generate a new public key

[0094] Cross-domain authentication phase: divided into 7 steps, 1) First, V a The signed public key Pk a Send to V b :

[0095] Req a→b ={signS a (Pk a )}

[0096] 2) V b Request the RSU in this domain to help it complete the V a It sends a request message to the RSU, which includes V a The trust value query request sent is query=(Query, VIN a ,VIN b ), public key Pk b And the random number r1, which is encrypted with the RSU public key and sent to the RSU:

[0097] Req b→RSU =EnP RSU (query,Pk b ,r1)

[0098] 3) RSU uses the private key Sk RSU After decryption, call the smart contract deployed on the chain to obtain the current vehicle V b Trust value Tr b and vehicle V a Trust value Tr a,Finally, the access trust threshold is determined based on the actual situation and access ,policy, and the respective trust values ​​are compared with the threshold.

[0099] 4) After the comparison is completed, the corresponding result is returned to V b If the trust values ​​of both parties are higher than the threshold, only the subsequent key negotiation steps need to be completed.

[0100]

[0101] 5) V b After decrypting the message returned by RSU, if the True message is obtained, the symmetric key K is generated. b Pk b Hash the temporary session key K and r1, and record the result as H, which is used as the encryption key of K. Encapsulate the encrypted temporary session key K and use K to encrypt the random number r2, and then use the public key Pk a After encryption, send to V a :

[0102] H=hash(Pk b |r1)

[0103] Content = {EnH(K),T,EnK(r2)}

[0104] Req b→a =EnPk a (Content)

[0105] 6) V a Decrypt the message sent by RSU. Then, use Pk b The encryption key H is calculated by hashing r1, decrypting it to get K, and then decrypting it with K to get the random number r2. Then a random number r3 is generated, and the communication data is encapsulated with random numbers r2 and r3, and encrypted with the temporary session key K and sent to V b :

[0106] Msg a→b =EnK(r2|r3|Data)

[0107] 7) V b Decrypt the message and verify the signature, detect the random number r2, ensure that the other party's identity is trusted and has the key K, and if the verification is successful, the information is received, indicating that the vehicle V a and V b Cross-domain authentication is successful. Otherwise, cross-domain authentication fails and the two vehicles cannot establish a connection. At the same time, whether it succeeds or fails, the result needs to be fed back to the nearby RSU, because each cross-domain interaction of the vehicle will directly affect the trust of the next cross-domain access.

[0108] What is disclosed above is only a preferred embodiment of the present invention, and it certainly cannot be used to limit the scope of rights of the present invention. Ordinary technicians in this field can understand that all or part of the processes of the above embodiment and equivalent changes made according to the claims of the present invention still fall within the scope of the invention.

Claims

1. A cross-domain trust management method for Internet of Vehicles based on blockchain, characterized in that The specific steps include: step 1: Design a trust management scheme based on trust value offset aggregation to calculate the trust value of each vehicle and generate the corresponding trust rating, and then calculate the trust offset to reflect the change in vehicle trust. Step 2: Generate a blockchain and upload the offset of the vehicle trust rating to the chain through a consensus algorithm to ensure the security and traceability of trust information. Step 3: The vehicle can query the trust values ​​of nearby vehicles to be authenticated and use this to evaluate the credibility of the vehicle message in the cross-domain authentication. Step 4: Design a cross-domain authentication scheme based on trust value, authenticate through the trust value of the vehicle, and thus achieve cross-domain trust management.

2. The cross-domain trust management method for Internet of Vehicles based on blockchain as claimed in claim 1, characterized in that: The trust value offset is generated through the historical messages of the vehicle, and the interactive behaviors in the authentication process are regarded as message interactions to dynamically affect the trust value offset. RSU uploads the offset of each vehicle to the same message set, and derives the current trust value by accumulating all the offsets of the vehicle. The offset is updated with the vehicle message interaction, so as to adjust the trust value accordingly.

3. The cross-domain trust management method for Internet of Vehicles based on blockchain as claimed in claim 1, characterized in that: The alliance chain is composed of multiple RSUs, and a verifier is regularly selected to put the vehicle trust offset on the chain. The alliance chain uses the total trust offset as the equity through the consensus algorithm. When completing PoW, the difficulty is adjusted according to the current equity of the node, making it easier for RSUs with higher equity to find nonce and become verifiers, thereby ensuring the timely update of blockchain data.

4. The cross-domain trust management method for Internet of Vehicles based on blockchain as claimed in claim 1, characterized in that: If a vehicle in a certain area needs to query the trust value of vehicles in other areas, it needs to send a query request to the nearby RSU, including the identification number of the requester and the target vehicle. After receiving the request, the RSU first verifies the identity of the requester, then summarizes the offset from the blockchain and calculates the current trust value of the target vehicle, encrypts the trust value with the public key of the target vehicle, and sends it to the requester.

5. The cross-domain trust management method for Internet of Vehicles based on blockchain as claimed in claim 1, characterized in that: The access trust threshold is set according to the actual system situation and access policy; when the system is congested, the threshold is appropriately increased to ensure system reliability, and when necessary, the threshold is lowered to meet the needs. This method is divided into two stages: vehicle registration and cross-domain authentication.

Images