A Secure and Traceable Vehicles and Parts System Based on Blockchain and Smart Contract

As society advances, so does the total number of vehicles on the road, creating a massive consumer market for automobiles. According to statistics, a major portion of today’s traffic difficulties are caused by accidents caused by subpar cars and auto parts. As a result, each country has, over time, enacted equivalent rules and regulations to prevent such tragedies. However, in the face of profit, some people are desperate enough to employ illegal parts and illegally modified cars, and auto fraud is rampant. As a result, we employ the blockchain of the symmetrical Blockchain’s digital ledger and smart contract technology to build a decentralized supply chain system that can identify specific parts. In this study, we design and discuss the proposed system framework by user functions and the flow of parts based on blockchain, and we discuss communication protocols that use the symmetry and asymmetry cryptography, algorithms, properties, and security of the mechanism while providing related analysis and comparing the properties and costs of the system with other studies. Overall, the proposed method has the potential to successfully address the issue of automobile fraud.


Background
As of 2020, according to the Bureau of Transportation Statistics (BTS) and National Bureau of Statistics of China statistics, the total number of vehicles in the US is about 276 million, and 280 million in China. In 2020, the world car production grew to 76 million [1][2][3].
With that many vehicles, a huge vehicle consumer market is produced, and the same with many traffic problems that are due to the vehicles and parts themselves. For example, in the National Motor Vehicle Crash Causation Survey (NMVCCS) [4], an estimated 44,000 crashes are caused by vehicles, which is about 2% of the crashes counted by NMVCSS; additionally, the National Highway Traffic Safety Administration in the literature [5] stated that the critical causes in 10.5% of crashes are steering, suspension, transmission, and engine failures, while about 21% of crashes are caused by various other vehicle failures or defects. Hoque and Hasan [6] stated that: as a percentage of the total number of crashes, vehicle defects caused 16.0% of the crashes and 29.0% of the total casualties by the same factor. It can be seen that unqualified parts would reduce the stability of the car, and then lead to the occurrence of traffic accidents.
The automotive supply chain (ASC) has been an intricate system due to the various parts used in each vehicle, the need for many part supplies, and the many stakeholders that exist in the ASC. Before this study, lots of scholars on the issue have also combined blockchain with supply chain, as sown in Table 1.
Chen et al. [16] proposed a relatively complete theoretical framework for blockchainbased supply chains by elaborating on their proposed Supply Chain Quality Management (SCQI) and briefly discussing the issues that arise in the context of the case, but there is no mention of arbitration in the study. Sharma et al. [17] proposed a blockchain-based distributed architecture for the smart city automobile industry that examines the entire process from many perspectives and suggests a practical strategy. However, the research does not elaborate on the circulation process of parts and does not address the algorithms necessary to carry out the suggested circulation process. Kim et al. [18] handle the authentication of genuine vehicle parts via both Blockchain Governance Game (BGG) [19] and Fog Computing [20] techniques. However, the studies lack a thorough examination of the roles of the various blockchain tasks and do not suggest a comprehensive service structure. In the study by Miehle et al. [21], the authenticity and tracking and tracing of the source of parts are addressed, access control and licensing systems to secure private license chains are introduced, archiving using external chains and external databases is enabled, and the entry barrier for SMEs to the alliance chain is lowered, thereby effectively improving the supply chain's comprehensiveness and integrity, but the regulation and the stalemate are not addressed. Hao developed a Blockchain-based logistics monitoring system (BLMS) in the study [22], which allows customers, logistics operators, and all other parties in the supply chain to track their parcels and information to ensure fairness and transparency, but not enough for the subsequent regulation of automotive services. Yahiaoui's paper [23] describes a blockchain-based supply chain system and briefly explores the integration of its blockchain supply chain. Li and Ye [24] integrated blockchain technology into the ASC, customizing smart contracts to meet functional requirements, and demonstrating product traceability to consumers and regulators. Wang et al. [25] applied blockchain to auto service to emphasize the importance of component supply chain management, and subsequent service assurance, and offered a blockchain-based Product-Service System (PSS) framework for vehicles and several other application frameworks, but no privacy protection is provided for transactions between supply chain parties, and no specific algorithm or implementation is proposed. There is no discussion on the regulation and analysis of services outside the supply chain.
Sharma et al. [17] 2018 a distributed framework model for the entire life cycle phases of the automotive industry blockchain-based Blockchain Analyzing the processes of the automotive industry from multiple perspectives and provided a miner node algorithm.
There is no elaboration on the flow process of the parts and no proposed algorithm to be implemented for the flow process.
Kim et al. [ In this paper, we use a symmetrical copy of the decentralized ledger for all users under the security of asymmetric cryptography. the contents of the other sections are as follows: Section 2 involves some related knowledge of this study. Section 3 describes the communication protocol and algorithm of each phase. We analyzed the characteristics and security issues in Section 4. In Section 5, we make some evaluations for communication costs and computation costs. Lastly, we conclude this paper in Section 6.

Blockchain and Smart Contracts
Blockchain Technology systems came from a paper on the cryptocurrency Bitcoin, "Bitcoin: A Peer-to-Peer Electronic Cash System" [26], proposed by a named Satoshi Nakamoto in 2008. It involves many disciplines, such as mathematics, cryptography, and computer science. In the blockchain, distributed computational storage, public and private keys, real-time broadcasting, and timestamping bring the characteristics of being decentralized, transparently developed, and tamper-proof, and the data structure Merkle tree is used to ensure the traceability of the blockchain. These features make blockchain that can be integrated with various fields.
Smart contacts were proposed by Nick Szabo, a well-known American computer scientist [27]. Smart contacts are codes that run on the blockchain are and automatically executed on the blockchain when conditions are met and cannot be accessed by anyone for execution [28,29]. It is the digital equivalent of traditional contracts, and combined with these blockchains, such as decentralization, tamper-evident, transparent traceability, perpetual operation, and mutual corroboration, smart contracts achieve the effect of decentralization from trusting third-party institutions to trusting the contract itself.

ECDSA
ECDSA was proposed by Rivest et al. It combines Digital Signature Algorithm (DSA) and Elliptic Curve Cryptography (ECC). Compared with traditional encryption methods, ECDSA has the characteristics of smaller parameters, keys and certificates, stronger key bit strength, and faster operating speed [15,[30][31][32].
Suppose that A wants to send a message M to B. The signature is generated by sender A and verified by receiver B. Firstly, both parties must agree on the elliptic curve (CURVE, G, n), where G is the base point on the curve, n is the order of G, and H is the hash function.
Signature: A chooses a random integer d A as a private key with values in the range [0, n − 1], and generates the public key Q A = d A G.Computing: z = h(m), kG = (x 1 , y 1 ), r = x 1 mod n and s = k −1 (z + rd A ) mod n. Then, the message m and the signature value (r, s) are sent to B.
Verification: B verifies the correctness of the message after receiving the signature value and message m from A. B calculates: z = h(m), a 1 = z s −1 mod n, a 2 = rs −1 mod n, (x , y ) = a 1 G + a 2 Q A . If the equation r = x modn holds, the verification passes.

Hyperleader Fabric
Hyperleader Fabric was led by IBM and Linux, a blockchain-based open-source project. It is mainly to establish an enterprise-class distributed ledger system compatible with pluggable consensus mechanisms and supporting identity authentication, which is typical of current federated chains. Additionally, Hyperleader Fabric is modular, scalable, and provides privacy and confidentiality features to enable the platform to give social good, insurance, and finance, as well as supply chain logistics and other industry use cases to provide more effective and novel features.

Proposed Scheme
This study uses a symmetrical copy of the blockchain-based ledger technology to build a new automotive parts traceability system by building a Hyperleader Fabric federated chain to implement some functions following text. (CA) and Arbitrator (AB) and Blockchain Center (BCC). The system framework is shown in Figure 1.

Proposed Scheme
This study uses a symmetrical copy of the blockchain-based ledger technolo build a new automotive parts traceability system by building a Hyperleader Fabric f ated chain to implement some functions following text. The system consists of the s holder's members of the federated chain Parts Manufacturer (PM), Automobile Man turer (AM), Car Dealer (CD), Car Owner (CO), and Repair Shop (RS), as well as Co tent Authorities (CA) and Arbitrator (AB) and Blockchain Center (BCC). The sy framework is shown in Figure 1. (2) Automobile Manufacturer (AM): AM is responsible for the production of res and development of cars, ordering parts from PM for car production. In the mean AM also is the seller of car dealers.
(3) Car Dealer (CD): CD is the wholesale vehicle from AM and will sell the vehi the consumer (also known as the car owner (CO)).
(4) Car Owner (CO): The end-user of the car, who needs to buy the car from C also the consumer of the Repair Shop (RS) and can go to RS for vehicle repair and replacement.
(5) Repair Shop (RS): Order parts from PM to repair the consumer's vehicle.

System Architecture
(1) Parts Manufacturer (PM): PM obtains orders from automobile manufacturers (AM) and Repairers Shop (RS), and then produces the corresponding parts according to the order information and sells them to AM and RS.
(2) Automobile Manufacturer (AM): AM is responsible for the production of research and development of cars, ordering parts from PM for car production. In the meantime, AM also is the seller of car dealers.
(3) Car Dealer (CD): CD is the wholesale vehicle from AM and will sell the vehicle to the consumer (also known as the car owner (CO)).
(4) Car Owner (CO): The end-user of the car, who needs to buy the car from CD, is also the consumer of the Repair Shop (RS) and can go to RS for vehicle repair and parts replacement.
(5) Repair Shop (RS): Order parts from PM to repair the consumer's vehicle. (6) Competent Authorities (CA): If a member of the alliance chain is unsure of the legitimate source of a part, the auditor has the right to certify any problems with the flow of the part.
(7) Arbitrator (AB): A third-party arbitrator that receives complaints from members of the alliance chain, can find the flow of parts for cars via the Internet, and can find broken parts that are in circulation on the market.
(8) Blockchain Center (BCC): A blockchain that records key information about parts and vehicles as well as information about the distribution process, and the blockchain associates the ID of the recorded part or vehicle with the vehicle or part. The chain code in the BCC can check the status of the part during the transaction. At the same time, each member needs to register with the blockchain center and request a unique ID to be added to the blockchain. Figure 1 shows the process of a car part passing through the manufacturer of the part to the car manufacturer, then the car manufacturer agrees to assemble it, then it passes through the dealership, the owner, and through the manufacturer of the part to the repair shop and then to the owner. Of course, in reality, there is more than one member in the alliance chain, and the diagram only shows the flow of parts or cars. And the numbers 1-9 of the Figure 1 is correspond to step 1-9. A description of the specific distribution process is as follows.
Step 1. Each role must register an account on BCC; simultaneously, BBC records the specific information of each member and returns a pair of public and private keys. Step 2. When AM needs to produce a batch of cars or RS needs to receive a batch of parts, it needs to order parts from PM and send the order information to PM. Step 3. When PM receives the order information, it will produce the parts and engrave the ID number of each part on the part, and send the parts to AM or RS.
Step 4. If the CD is obtaining a batch of cars from the AM, it needs to send the order information to the AM.
Step 5. AM receives the order and delivers the products to CD.
Step 6. CO goes to CD to buy the vehicle and CO needs to provide the identity for the transaction.
Step 7. CO goes to RS to repair the vehicle.
Step 8. If either party disputes the quality or origin of the parts, they may submit a request for arbitration to the AB. Step 9. Parts and vehicle-related information and circulation process information are recorded on BCC, AB can retrieve and verify the parts and vehicle-related records through BCC.

Data Definition
Figures 2 and 3 are the basic structure of chain code in our designation. Figure 2 shows the product message structure of parts and vehicles. When the product of a vehicle or a part circulates in every Access Party (AP), its details will disclose this structure. In Figure 3, the left shows the storage structure of AP, and the right shows the definition of roles. Figure 1 is correspond to step 1-9. A description of the specific distribution process is as follows.

of the
Step 1. Each role must register an account on BCC; simultaneously, BBC records the specific information of each member and returns a pair of public and private keys. Step 2. When PM receives the order information, it will produce the parts and engrave the ID number of each part on the part, and send the parts to AM or RS.
Step 3. When PM receives the order information, it will produce the parts and engrave the ID number of each part on the part, and send the parts to AM or RS.
Step 4. If the CD is obtaining a batch of cars from the AM, it needs to send the order information to the AM.
Step 5. AM receives the order and delivers the products to CD.
Step 6. CO goes to CD to buy the vehicle and CO needs to provide the identity for the transaction.
Step 7. CO goes to RS to repair the vehicle.
Step 8. If either party disputes the quality or origin of the parts, they may submit a request for arbitration to the AB. Step 9. Parts and vehicle-related information and circulation process information are recorded on BCC, AB can retrieve and verify the parts and vehicle-related records through BCC.

Data Definition
Figures 2 and 3 are the basic structure of chain code in our designation. Figure 2 shows the product message structure of parts and vehicles. When the product of a vehicle or a part circulates in every Access Party (AP), its details will disclose this structure. In Figure 3, the left shows the storage structure of AP, and the right shows the definition of roles.

Registration Phase
All parties who join the system must register an account with BCC. When registration is successful, BCC records its message and returns a pair of public key and private key to the member of the register. The specific registration process is shown in Figure 4.
Step 1. AP sends its message AP Info M (e.g., name, role type, etc.) to the blockchain center for the registration request.
Step 2. BCC uses ECDSA to create a private key AP d using the key to calculate the public key AP Q :

Registration Phase
All parties who join the system must register an account with BCC. When registration is successful, BCC records its message and returns a pair of public key and private key to the member of the register. The specific registration process is shown in Figure 4.
If the creation is successful, add the role and trigger smart contact. The algorithm of the smart contract is as follows: Algorithm 1. Then, BCC sends ( ) , , Step 3. AP receive and storage ( ) , ,  Step 1. AP sends its message M In f o AP (e.g., name, role type, etc.) to the blockchain center for the registration request.
Step 2. BCC uses ECDSA to create a private key d AP using the key to calculate the public key Q AP : If the creation is successful, add the role and trigger smart contact. The algorithm of the smart contract is as follows: Algorithm 1. Then, BCC sends (ID AP , d AP , Q AP ) to AP.
Step 3. AP receive and storage (ID AP , d AP , Q AP ).

Authentication Phase
Since the actors in the initial stage of the blockchain cannot verify each other's true identity, both parties who need to perform actions need to be authenticated. The "signature" and "verification" are required when using the algorithm ECDSA implemented for authentication. We assume both users A and B need to authenticate. The specific implementation flow is shown in Figure 5. User A generates a random number k 1 and a message M A1 and calculates h A1 : Then, User A calculates the parameter of ECDSA and through "Sign" of Algorithm 2 generates a signature. The specific process of signature shows in Equations (4)- (6): Then, A uses B's public key Puk B to encrypt a message M A1 : Finally, A sends the information that is A generating C A1 , (r A1 , s A1 ) to B.  Step 1. User B receives a message from A and uses B's private key Prk B deciphering C A1 to acquire the data (ID A , ID B , TS A1 , In f o A ) within the message M A1 . In the meantime, determine whether the timestamp is legal or not: If Equation (9) is true, the smart contract "Verify" of Algorithm 2 will trigger and verify the signature of ECDSA. The specific process of verification is shown in Equations (10)-(14): If Equation (14) is true, the message is from A, which can be confirmed. Then, B generates a random number k 2 and a message M B1 and calculates h B1 : Then, B calculates the parameter of ECDSA and generates a signature through the "Sign" of Algorithm 2. The specific process of signature is shown in (17)-(19).
Then, B using the public key Puk A of A encrypts a message M B1 : Finally, B sends information C B1 , (r B1 , s B1 ) to A.
Step 2. When A receives a message from B, it uses its own private key Prk A to decode C B1 and acquire information (ID B , ID A , TS B1 , In f o B ) within M B1 . In the meantime, it is verified whether the following timestamp is true or not true: If Equation (22) passes, the smart contract "Verify" of Algorithm 2 will trigger and verify the signature of ECDSA. The specific process of verification shows in Equations (23)-(27): If Equation (35) passes, we can confirm the message is A sending to B. The authentication between user A and user B is successful.

Order and Transaction Phase
In the phase, we assume both roles that are User A and User B to simulate order and transaction actions. In this phase, A is the buyer purchasing products, and B is the seller. If the AM needs to perform car production and RS is short of parts for vehicle repair and needs to order parts from PM, then User A is AM and RS and User B is PM. If CD needs to order vehicles for sales activities, then User A is CD, and User B is AM at this time. The flowchart is as follows in Figure 6.  If Equation (34) is established, the smart contract "Verify" of Algorithm 2 is triggered to verify that the ECDSA signature is correct: Step 1. User A generates a random number k 3 and message M A1 and calculates h A1 : Then, User A calculates the parameters of ECDSA, and uses the "Sign" of Algorithm 2 to generate the signature: Afterward, User A uploads the order to the blockchain; in the meantime, it uses the public key Puk B of User B to encrypt a message M A1 : Finally, User A delivers C A1 , (r A1 , s A1 ), which is A generated to User B.
Step 2. User B receives the message from User A and using its private key Prk B to decrypt C A1 to acquire data (ID A , ID B , TS A1 , M OrdA1 ) of M A1 , and verifies that the timestamp holds: If Equation (34) is established, the smart contract "Verify" of Algorithm 2 is triggered to verify that the ECDSA signature is correct: Veri f y h A1 , r A1 , s A1 If it is correct, we can testify the message is from User A, and then User B generates a random number k 4 and uses order request information M con f and order information M OrdA1 to generate a message M B1 . The message is sent to A and User B calculates h B1 : Then, User B calculates the parameters of the ECDSA and generates a signature by "Sign" of Algorithm 2: Afterward, User A encrypts a message M B1 by the public key Puk A of User B: Finally, B sends C B1 , (r B1 , s B1 ) to User A.
Step 3. User A receives the message from User B and uses his private key Prk A to decrypt C B1 to acquire data (ID B , ID B , TS B1 , M OrdA1 , M con f ) within the message M B1 , and verifies that the timestamp holds: If Equation (42) is established, the smart contract "Verify" of Algorithm 2 is triggered to verify the signature of ECDSA that is correct: If it is correct, the message is proved to have been sent by User B. Otherwise, the order is voided. At this point, the order is confirmed.
After the order phase mentioned above, both parties to the transaction have completed the task of placing and finalizing the order. In this phase, User B uploads the key information of the generated product to the blockchain. User A receives the product and information from User B and decrypts and verifies the correctness of the information. If it is accurate, the transaction is completed. The specific flowchart is as follows in Figure 7.  Step 1. User A generates a random number k 5 , receives the product confirmation M con f , and creates a message M A2 . Calculating h A2 : Then, User A calculates the parameter of ECDSA and generates the signature by "Sign" of Algorithm 2: (r A2 , s A2 ) = Sign(k 5 , h A2 , d A2 ) After User A uses the public key Puk B of User B to encrypt M A1 : At last, User A sends C A2 , (r A2 , s A2 ) to User B.
Step 2. User B receives the message from User A and using his private key Prk B decrypts C A1 to acquire the data (ID A , ID B , TS A2 , M OrdA1 , M con f ) within M A2 , in the meantime verifying if the timestamp is legal: If (50) is established, the smart contract "Verify" of Algorithm 2 is triggered to verify that the signature of ECDSA is correct: If Equation (52) is correct, it proves that the order information is sent by User A, triggering smart contacts UploadParts or UploadVehicles within Algorithm 3 or Algorithm 4 to upload the information of products. If it is a transaction among AM, RS, and PM, UploadParts is triggered, and if it is a transaction between CD and AM, U ploadVehicles is triggered. In the meantime, the functions List < U ID > (U ID symbol ID Car or ID Part ). Then, User B generates a random number k 6 and uses List < U ID >, and Order A1 generates M B1 , which is returned with information of the order. Calculating h B1 : Then, User B calculates the parameter of ECDSA and generates a signature by "Sign" of Algorithm 2.
If the verification passes the above, if the above verification holds, "Verify" of Algorithm 2 is triggered and checking if the signature of ECDSA is correct: If it is true, the system triggers the smart contract Algorithm 5 and proves the information of the product. If it is successful, the transaction finishes.

Sale Phase
In the phase, CO purchases vehicle in the CD. The specific process is as following Figure 8.   Step 1. CO choices a product and sends M ReqCO to a CD. First, CO generates a random number k 7 and generates M CO . Calculating h CO : Then, CO calculates the parameter of ECDSA and generates a signature by "Sign" of Algorithm 2, and uses the public key of CD to encrypt: At last, CO sends C CO , (r CO , s CO ) to CD.
Step 2. CD receives data (ID CO , ID CO , TS CO , M ReqCO ) from C CO , and verifies if the timestamp is correct: If (74) is correct, the smart contract "Verify" of Algorithm 2 is triggered to verify if the signature of ECDSA is legal or not: Veri f y h CO , r CO , s CO If it is true, it proves the information of the order that sends from CO. Additionally, the system finds the vehicle of the request of the order. CD sends ID Car to CO and a random number k 8 is generated by CD. In the meantime, according to U ID part and M OrdCO1 , which are created by CO, message M CD is generated. Returning the information of the order to CO calculate h CD : Additionally, then CD calculates the parameter of ECDSA and generates a signature by "Sign" of Algorithm 2: Afterward, the CD using the public key Puk CO of CO encrypts M CD : At last, CD sends C CD , (r CD , s CD ) to CO.
Step 3. CO receiving the message from CD, using its private key Prk CO , decrypts C CD to acquire data (ID CD , ID CO , TS CD , M OrdCO1 ) within M CD , and it verifies if the timestamp is correct: If (72) is established, the smart contract "Verify" of Algorithm 2 is triggered, in the meantime verifying if the signature of ECDSA is correct or not: If it is correct, Algorithm 6 is triggered, and the transaction is finished.

Repair Phase
At this stage, CO goes to RS for vehicle maintenance. The specific process is shown in Figure 9.
Step 1. RS sends ID part1 of the old parts and ID part2 of new parts that need to be replaced to the CO, and generates random numbers k 9 : Then, the user CO calculates the parameters of ECDSA, generates a signature through "Sign" of Algorithm 2, and then encrypts it with the CO's public key: (r RS , s RS ) = Sign(k 9 , h RS , d RS ) (77) Finally, RS sends C RS , (r RS , s RS ), which is generated and sent to CO.  Step 2. CO receives the data If established, it triggers the smart contract "Verify" of Algorithm 2 to verify that the ECDSA signature is correct: Step 2. CO receives the data (ID RS , ID CO , TS RS , ID part1 , ID part2 ) of the message M RS from RS and verifies whether the timestamp holds: If established, it triggers the smart contract "Verify" of Algorithm 2 to verify that the ECDSA signature is correct: If the verification is passed, a random number k 10 is generated after confirming the information M CO , a message is generated, and then the maintenance message is signed and uploaded.
Trigger the smart contract after uploading Algorithm 6.

Arbitration Phase
When either party doubts the validity of a part, they can arbitrate its legitimacy through Arbitration. The process of arbitration is shown in Figure 10, and the numbers 1-4 correspond to step 1-4. The precise details of this process are as follows:

Data Integrity
We use ECDSA and hash functions to ensure data integrity. In a blockchain, each Step 1. AP provides the UID of a specific part to AB.
Step 2. AB sends a TID request message with its signature to BCC.
Step 3. BCC checks the signature of AB, and if the signature is valid, BBC delivers the signature list to AB. Step 4. AB checks the validity of each signature in the signature list. The order of the checks is as follows.
(a) Verify the signature of PM, if it is not legal, the record is proved to be forged by PM.
Otherwise Verify the signature of AM, if it is not legitimate, the record is forged by AM. (c) Verify the signature of the CD, if it is not legal, the record is proved to be forged by the CD.
Verify the signature of RS, if it is not legal, the record is proved to be forged by RS. (e) Verify the signature of CO, if it is not legal, the record is proved to be forged by CO. (f) If all the above signature is valid, then the process of circulation of the part is proven and verified by AU.

Data Integrity
We use ECDSA and hash functions to ensure data integrity. In a blockchain, each participant has a pair of public and private keys. The sender must compute a hash and generate a set of signatures using the receiver's public key before sending the message, and the receiver needs to verify the message and the signatures using his private key to ensure the validity of the message. If the attacker tampers with the data to send to the receiver, then the receiver will verify if the hash value and signature are not passed. All phases' detailed information is listed in Table 2.
Order and Transaction phase

Non-Repudiation
In this paper, we use Verify of ECDSA to resolve the repudiation issue. In the blockchain mechanism, all messages transmitted by the sender must sign with their private key, and the receiver using the sender's public key verifies the messages. That ensures messages cannot be denied. Table 3 is the non-repudiation verification of the proposed scheme.

Traceability and Unforgeability
Based on blockchain characteristics, we learn that all transaction records are stored and chained to the ledger of every peer, and the records are traceable and unforgeable. In the meantime, data can be verified and transparent. For example, AB can trace records to verify whether blockchain data are legal or not. In Figure 10, if the signature cannot pass the verification, the signatures are forged. Table 3. Non-repudiation verification of the proposed scheme.

Party
Message Signature Verification Sender Receiver Order and Transaction phase

Man-in-the-Middle Attack
Man-in-the-middle attack (MIMT) generally refers to the attacker intercepting the normal network communication data between the client and the server [33]. In the communication protocol, each communication message on the blockchain uses asymmetric encryption for defense against MIMT, i.e., the receiver's public key encrypts the message when it is sent, and the receiver decrypts the message with his or her private key to ensure that the source of the message is correct.
Scenario: An attacker tampers with the communication messages or eavesdrops between the communicating parties.
Analysis: In the blockchain, the sender uses the public key of the receiver to encrypt messages. Additionally, if the attacker did not use a match private key to decrypt, it did not learn the content of the message. The private key only is known to the receiver.
For example, in the authentication phase, User A encrypts the message M A1 with User B's public key Puk B , then generates a ciphertext C A1 and sends it to User B. B then uses his private key Prk B to decrypt the ciphertext to obtain the original message M A1 . The related details are shown as follows: Therefore, it is guaranteed that the attacker cannot decrypt the message without the receiver's private key. Each stage of asymmetric encryption and decryption is shown in Table 4. Table 4. Encryption and decryption to prevent a man-in-the-middle attack.

Party
Encryption Decryption Sender Receiver Car Owner (CO) Car Dealer (CO) Car Dealer (CD) Car Owner (CD)

Replay Attack
A replay attack is a type of network attack that uses malicious or fraudulent ways to repeat or delay valid data and the attacker intercepts the message of the communication and retransmits the data to the receiver [34]. In this study, to prevent the replay attack, we add a timestamp to each message, and the receiver needs to calculate the difference of the timestamp when receiving the corresponding message and compare it with the set threshold value, and if the time difference exceeds the threshold value it identifies that the message is being replayed.
Scenario: An attracter listens to messages between sender and receiver and, after that, it re-sends the same message to the receiver.
Analysis: If the receiver receives the ciphertext and decrypts it to acquire the timestamp TS X of the sender, the receiver verifies that the difference between the current timestamp TS NOW and the timestamp in the message is less than a threshold ∆T. When this does not hold, the communication that suffered a replay attack is confirmed.
For example, in the verification phase, the timestamp TS A1 when User A sends the data will be detected TS NOW − TS A1 ? ≤ ∆T when User B receives the data, and if it passes, it proves that the data are not under replay attack. Table 5 is the timestamp verification for each stage, where the timestamp after the receiver receives the data is collectively called.

Counterfeiting Attack
In this paper, the counterfeiting attack is the behavior of an attacker using falsified and uploaded fake parts' information or disguising as a parts owner to trade on the system. We verify the legitimacy of the data during the transaction process to prevent this attack.
Scenario 1: The attacker fakes and uploads fake parts' information, and uses these parts to trade.
Analysis 1: Uploading parts' information is a unique function of PM. Other users cannot sign and upload parts without a PM private key. Additionally, because the alliance chain is used, each role needs to be authenticated, and the chances of an attacker disguising PM successfully are not possible. At the same time, based on the characteristics of the blockchain, the source of the parts can be traced. Therefore, when that counterfeit part appears on the blockchain, we can quickly locate the attacker. Scenario 2: Malicious RS or rental car users replace expensive parts with low-cost fake parts. Analysis 2: In our proposal, the part and the vehicle to which it belongs are bound together and belong to the same owner. As shown in Figure 11, when malicious RS replaced expensive parts reappear on the supply chain and conduct transactions, the buyer of the part will check again whether the source of the part is legitimate. If not, the system will notify the original owner of the part, who can quickly apply for arbitration with an arbitration institution.
blockchain, the source of the parts can be traced. Therefore, when that counterfeit part appears on the blockchain, we can quickly locate the attacker. Scenario 2: Malicious RS or rental car users replace expensive parts with low-cost fake parts.
Analysis 2: In our proposal, the part and the vehicle to which it belongs are bound together and belong to the same owner. As shown in Figure 11, when malicious RS replaced expensive parts reappear on the supply chain and conduct transactions, the buyer of the part will check again whether the source of the part is legitimate. If not, the system will notify the original owner of the part, who can quickly apply for arbitration with an arbitration institution.

Communication Cost
In this section, we calculate the different communication costs for different network rates as shown in Table 6. Firstly, we assume that the length of the ECDSA key and signature is 160 bits, the length of asymmetrically encrypted data is 1024 bits, and other information (ID, timestamp, etc.) is 80 bits. The total size is 160 bits × 2 + 80 bits × 2 + 1024 bits × 2 = 2588 bits. It takes 0.431 ms in 3G (6 Mpbs), communication environment, 0.026 ms in 4G (100 Mpbs) communication environment, and 0.129 us in 5G (20 Gpbs) communication environment [35].  Table 7 shows the computational cost analysis of the roles in each phase. Taking the authentication phase as an example, in this phase both User A and User B need to perform the signature operation, verification operation, encryption, and decryption operation, comparison operation once each, and hash operation twice.

Communication Cost
In this section, we calculate the different communication costs for different network rates as shown in Table 6. Firstly, we assume that the length of the ECDSA key and signature is 160 bits, the length of asymmetrically encrypted data is 1024 bits, and other information (ID, timestamp, etc.) is 80 bits. The total size is 160 bits × 2 + 80 bits × 2 + 1024 bits × 2 = 2588 bits. It takes 0.431 ms in 3G (6 Mpbs), communication environment, 0.026 ms in 4G (100 Mpbs) communication environment, and 0.129 us in 5G (20 Gpbs) communication environment [35].  Table 7 shows the computational cost analysis of the roles in each phase. Taking the authentication phase as an example, in this phase both User A and User B need to perform the signature operation, verification operation, encryption, and decryption operation, comparison operation once each, and hash operation twice.

Computation Cost
Car Owner( CO) Car Dealer (CO)

Repair Repair Shop (RS) Car Owner (CO)
T sig + T hash + T E/D T sig + T hash + T E/D Note: T sig : Signature operation; T ver : Verify operation; T E/D : Encryption/Decryption operation; T hash : Hash function operation; T cmp : Comparison operation; T chd : Check data function; T upload : Upload data operation. Table 8 shows the comparison with the previous researchers. In this paper, we proposed a blockchain-based automotive and parts supply chain service framework, related algorithm, and communication protocol and analyzed related cost and security.

Conclusions
The quality of vehicles and parts is closely related to traffic safety. To solve safety hazards caused by flaws in vehicles and parts and information asymmetry between providers and consumers, we proposed an automotive supply chain framework that is based on blockchain and smart contracts, in the meantime also designing communication flows and algorithms in the blockchain. In our analysis and discussion, this study-proposed system has excellent performance and security. In this blockchain system, all access parties must register with BC to require a pair of public-private keys and a unique ID; in the meantime, both communicating parties should authenticate each other's identities before communicating. In addition, during communication, each role signs and encrypts the information to be sent and uploads it to the chain, and decrypts and verifies the validity of the received message. Furthermore, when a dispute arises with a participant in the system, the participant can apply for arbitration by AB. Additionally, then AB, using the participant, provides a message to acquire blockchain information, confirming the legality.
By the proposed method and framework, we accomplish the features as follows: (1) Proposed a completely auto supply framework based-blockchain.
(3) Design some algorithms for simple quality identification of cars and parts.

Institutional Review Board Statement: Not applicable.
Informed Consent Statement: Not applicable.

Data Availability Statement:
The data used to support the findings of this study are available from the corresponding author upon request.

Conflicts of Interest:
The authors declare no conflict of interest.

Notations q
A k bit prime number GF(q) Finite group of q E Elliptic Curves Defined on Finite Groups q G A generating points based on Elliptic Curve E k i The ith random value on the elliptic curve d X /Q X The ECDSA's private key/public key of the party X (x Ai , y Ai )/(r Ai , s Ai ) The ith ECDSA/Elliptic curve signature value of User A TS Xi /TS NOW The ith timestamp of X/current timestamp

M Xi
The ith message is generated by X M In f o X /M BC X User Info of X/Blockchain Message for X M Con f /M OrdXi order Confirmation/The ith order information from X C Xi The ith encrypted ciphertext is generated by X ID X Unique ID of User X ID Car /ID Part /ID Order /ID repair Unique identification code of the vehicle/part/Order/Repair H(M) One-way hash function h Xi The ith hash value of X Puk X /Prk X X own public/private key that issued by BCC E Puk X (M)/D Prk X (M) Encrypt/Decrypt message M using X public/private key Verify that A is equal to B/Check if A is less than B