While key negotiation schemes, such as those based on Diffie–Hellman, have been the subject of ongoing research, designing an efficient and security scheme remains challenging. In this paper, we propose a novel key negotiation scheme based on blockchain, which can be deployed in blockchain-enabled contexts such as data sharing or facilitating electric transactions between vehicles (e.g., unmanned vehicles). We propose three candidates for flexible selection, namely, key exchanges via transaction currency values through value channels (such as the amount in transactions), automated key exchanges through static scripts,and dynamic scripts, which can not only guarantee key availability with timeliness but also defend against MITM (man-in-the-middle) attacks, packet-dropping attacks, and decryption failure attacks.
Key negotiation schemes have been extensively studied [
Although key negotiation is the core supporting technology of blockchain data encryption, it also has great significance for the practical application of blockchain technology. However, targeted research is still in the initial stage. At present, some of the Diffie–Hellman protocols faced with a multitude of problems for vehicular communications: they cannot resist man-in-the-middle (MITM) attacks because there are no certifications of the other side of the negotiation; they cannot resist packet-dropping attacks because the negotiation packages are discarded by enemies, which caused the negotiation to be incomplete; they cannot resist decryption failure attacks because keys were not confirmed and the parties do not know whether the other party has received the negotiated package.
In this paper, traceable and authenticated key negotiations via blockchain are proposed by exchanging the information about master keys; that is, they are embedded in the transaction currency value and can be exchanged through using value channels, static scripts, and dynamic scripts. Besides, our proposal solves transaction credit and security issues. Application of blockchain technology in the field of electric vehicle trading can effectively solve the problems of data security, data tampering, history tracking, effective monitoring, and trading trust. The contributions of the paper are listed as follows: We propose traceabe and authenticated key negotiation schemes based on blockchain that can guarantee key availability with timeliness in vehicular communications, which can defend against MITM attacks, packet-dropping attacks, and decryption failure attacks We propose to use value channels, static scripts, or dynamic scripts for fast, automatic, and confirmable delivery of key negotiation materials in vehicular communications, especially, piggyback with normal payments
The organization of this paper is as follows. Related work is introduced in Section
In recent years, a brief summary of the relevant concepts in key management was presented. Li et al. [
With the development of communications and social vehicles, many researchers have been studying and analyzing socially aware Internet of Vehicles with the assistance of an agent-based model intended to reveal hidden patterns behind superficial data. Malagund et al. [
In the scenario of vehicular communication, the communication between vehicles and between vehicles and people need to require low latency, high reliability, and traceability. In order to meet these requirements, we take the master key information on blockchain and realize the master key negotiation through the blockchain. Our scheme is suitable for the scenarios where there is a need for payment. When the master key (mk) needs to be changed, exchange the key information in a certain payment to establish the key for the next secure communication. The following are three options for implementing master key negotiation, including value channel, static script, and dynamic script. In this scheme, there are several parameters for generating the master key, which are shown in Table
Explanation of parameters in our scheme.
|
A large prime number |
|
A meta of |
|
The period of generating |
mk | Master key |
sk | Session key |
OP_Exponent | An exponential and modular operation we defined |
In this section, we identify five potential vulnerabilities that could be exploited by an adversary to undermine our scheme: key leakage, packet-dropping attack, decryption failure attack, and man-in-the-middle (MITM) attack.
(Packet-Dropping Attack). Key negotiation packets are dropped by attackers.
(Decryption Failure Attack). One peer of key negotiation peers decrypts encrypted data packets from the other peers. As the encrypted key is not acknowledged, it may be encrypted by a wrong key.
(Man-in-the-Middle (MITM) Attack). MITM attacks can intercept normal network communication, as well as sniff or tamper with data, while the communication parties are unaware of it. That is, attacker acts as an intermediary, forming two pairs of keys, decrypting, encrypting, and forwarding in the middle.
In addition, since our key negotiation scheme is public, the attacker can gain full knowledge of the procedures and methods of our scheme.
It is worth noted that there are many deficiencies in the traditional key negotiations: It is vulnerable to packet-dropping attacks because the swap part can be lost or dropped. Since there is no confirmation mechanism, whether the other party has successfully negotiated the key is uncertain. The key was not confirmed. The parties do not know whether the other party has received the negotiated package. Sending encrypted data may cause decrypting failure with high energy consumption. It is vulnerable to MITM attacks. The third party C acts as the receiver B when communicating with the sender A or acts as A when communicating with B. Both A and B negotiate a key with C; thus, C can monitor and transmit trade. A MITM attack is described as follows: B sends the public key in a message to A. C intercepts and analyses the message. Next, C saves the public key from B and sends a message to A by using the public key YC of C and disguises as B. After receiving the message from C, A stores B’s ID and YC together. Similarly, C uses YC to send a message to B and disguises as A. B calculates secret key K1 based on private key XB and YC. A calculates the secret key K2 based on the private key XA and YC. C uses private key XC and YB to compute K1 and uses XC and YA to compute K2. From now on, C can forward A’s message to B or B’s message to A and modify their ciphertext. Neither A nor B knows that they are sharing communication with C.
In this paper, we focus on the following security requirements: No password is stored in plaintext unless it is placed in a sufficiently secure cryptographic device. Besides, no operation on cryptographic devices can make keys appear outside the cryptographic devices as plaintext. To ensure the separation of keys, different communication entities use different keys, and they must be irrelevant. Keys need to have a certain backup mechanism. All transactions are recorded, and the above conditions can be met by adding a timestamp on blockchain. Keys must be valid. When the old key expires, it needs to be replaced in time. At the same time, the security of the new key and the old key should be separated. Even if the old key is leaked, the security of the new key should not be compromised.
The proposed scheme utilizes a transaction data structure to generate key pairs similar to the Diffie–Hellman key-exchange process, that is, the mk data exchange can be completed by embedding the data exchange process of the mk exchange into the currency value of the transaction and using the value channel (such as the amount in the transaction data structure). The mk negotiation process is shown in Figure The large prime number Alice reads blockhead and assigns to Alice publics broadcast ledger: picks an UTXO that someone else pays and pays for Bob: a cong, After the ledger is recorded in the public ledger, Bob selects Bob publics broadcast ledger: picks an UTXO that someone else pays and pays for Alice: B cong. The mk shared by Alice and Bob is A
Master key-exchange process.
The specific implementation algorithm is shown in Algorithms
Transaction ⟵ code( starttime ⟵ time();
A ⟵ ( Transaction ⟵ code(
Key initiator:
A ⟵ ( Transaction ⟵ code( Submit; Key receiver:
B ⟵ ( Transaction ⟵ code(B); Submit;
Key initiator:
A ⟵ ( Transaction ⟵ code( Submit; Key receiver:
B ⟵ ( Transaction ⟵ code(B);
A ⟵ B ⟵ mk = (A
In order to protect the security of the transaction, such as negotiating price and electricity sales, it is necessary to exchange mk-related information by using the value channel (for example, the amount in the transaction data structure) and embed the exchange process of mk-related information into the transaction currency value. In total, our proposal has the following advantages: The mk exchange process is publicly documented. There is a timestamp which can be traced. Since only A (sender) and B (receiver) can determine the negotiated mk, other users cannot interpret the message (confidentiality). A knows that only user B can use this mk to generate a message (authentication) which protects the security of the transaction and resists decryption failure attacks. It is characterized by the fact that the sk is generated only when needed, which is reducing the chance of attacks by storing sk for a long time.
In addition, the methods of electric trading in the existing technology are still faceing the defect of transaction security. In this paper, we provide a traceable and authenticated mk negotiation via blockchain for vehicular communications, which is ebbing the data exchange process of key exchange into transaction currency value, through the exchange of data which can be accomplished by using the value channel. It is worth to note that this method satisfies the following: The two parties which need secure communication can use this method to determine the negotiated mk. The key-exchange protocol can only be used for the exchange of mk, but cannot be used for the encryption and decryption of messages. After both parties determine the mk, the session key sk will be generated from the master key, sk = hash (mk, last block header hash).
In this section, we discuss the specific process of sharing information with static scripts. The specific model is shown in Figure Alice generates a transaction with two outputs: one is normal P2PKH script (Alice’s public key) with the number of bitcoins as input and the other is messageA with zero bitcoins, messageA = {A_len, 4 byte; Alice uses Bob’s public key to encrypt messageA and then regards it as the entire output script Bob confirms receipting the money, finds the transaction on blockchain, reads messageA, and parses messageA to get A, Bob generates a transaction with two outputs: one is normal P2PKH script (Bob’s public key) with the number of bitcoins as input and the other is messageB with zero bitcoins, messageB = {B_len, 4 byte; B, B_len byte; timestamp; type} Bob uses Alice’s public key to encrypt messageB and then regards it as the entire output script Alice confirms receipting of the money, finds the transaction on blockchain, reads messageB, and parses messageB to get B Alice and Bob use their private keys to generate redemption scripts to redeem bitcoins
Static scripts.
For the above process, we make the following explanations: since it would be costly to put all bitcoins in one script which contains the data to be exchanged and put them on blockchain, we design two output scripts. One is a valid output script that utilizes P2PKH transaction mode so that the traders can generate redemption scripts, and the other transaction output contains data which needs to be exchanged as an invalid output.
In this paper, the method we proposed has two main validations. The first is whether the public key can be converted to the correct address, and the second is whether signature is correct regardless of you are the owner of the public key. The main content of signature is calculating abstract (the hash of transaction information) by using the private key. In the case of verification, the signature and public key are computed. If the transaction abstract is correctly obtained, the transaction will be successful.
For bitcoin scripts, we customize a script operator OP_Exponent to implement exponential and modular operations in the stack so that the existence of timestamp can satisfy the traceability of exchanging mk. Since transactions are executed through bitcoin scripts, packet-dropping attackers cannot discard the negotiation package, which makes it impossible to complete the negotiation. In addition, the protocol can also be authenticated to ensure that the other party receives the information and gets the negotiated mk after passing the authentication correctly. In other words, our solution can defend against MITM attacks, packet-dropping attacks, and decryption failure attacks. Besides, dynamic scripts are more secure and flexible than static scripts.
Next, we discuss the specific implementation. Alice uses a UTXO, which has a locked script to set up the transaction. Besides, Alice puts
1–75
The comments of some script statements are shown in the Table
Comments on some statements in scripts.
1–75 | Put the next |
OP_Exponent | Implementing exponential and modular operations on stack data |
OP_DUP | Copy the top data and place it on the top of the stack |
OP_HASH | Perform ripemd160 (sha256 (data)) on top of the stack |
be10f0a... | Bob’s bitcoin address |
OP_EQUALVERIFY | Operation which terminates the script in failure unless the two entries below it on the stack are equivalent |
OP_CHECKSIG | Verified signature |
Bob gives an unlock script and combines unlock script with lock script to confirm that the transaction is valid; thus, Bob can get the required data (
However, this solution also faces two challenges. On the one hand, BVM keeps only the most basic instructions and extends them unless required. On the other hand, BVM upgrades require consensus across the bitcoin community which may cause bifurcations. There are also some problems we need to solve in future research.
Since the key information cannot be stored in the blockchain all the time, we propose to divide the key into the master key and the session key. The session key is abolished after use. After the master key is generated, in the subsequent communication, the session key (sk) is generated from the master key. sk = Hash (mk, last block header hash). Since the hash header is equivalent to a random number generator, sk can automatically change according to the latest block header. In this way, the times of generating keys through blockchain can be reduced to C (
The general vehicle network has two communication modes: communication between vehicle nodes and roadside infrastructures and communication between two vehicle nodes. One of the roadside infrastructures is roadside unit (RSU). Through these RSUs, such as 802.11 wireless access points, vehicles can access data stored in the roadside unit or upload their data. When a vehicle enters the communication range of the roadside node, it can access the wired network through the roadside node. On the other hand, the vehicle can also communicate with RSUs via multihop relay through other vehicles. For example, there are two cars with a certain distance which need to pass multiple RSUs, and they have to communicate with each other; thus, the transmitted information needs to be encrypted. In this scenario, if the traditional key negotiations are adopted, this transformation may be subjected to several attacks such as MITM attacks, packet-dropping attack, and decryption failure attack. However, those attacks can be avoided by packing them into the blockchain.
By combining key negotiations with blockchain, the key exchange process is publicly recorded and timestamped, which can be traced back to a long time ago.
Since only users and intelligent charging devices can determine the key, other users cannot interpret the message, which ensures the confidentiality of the message. In addition, users know that only intelligent charging devices can use negotiated keys to generate the message; thus, our proposal protects the security of electricity trading and resists decryption failure attacks.
Scenario 1: reservation maintenance.
Vehicles can negotiate keys to 4S stores, and 4S stores automatically distribute keys to vehicles. At the appointed time, 4S stores confirm the identity of the vehicle by searching the negotiated mk on the blockchain and generate sk based on the latest block header. After the key negotiation is completed, they can maintain vehicles. In this way, the workload of people can be reduced. Owing to the existence of timestamp, the records can be traced back, and the records can be prevented from being tampered with.
Scenario 2: remote fault diagnosis.
In the case of vehicle failure, it is worth discussing how to overcome the geographical and time constraints and achieve a collaborative diagnosis of remote experts. Our key negotiation can be used to find out the mk from blockchain and generate sk based on the latest block header to diagnose the vehicle when it fails.
Scene 3: rent a car (share car).
Recently, more and more shared cars are appearing in our life. Especially, sharing cars has certain risks because it needs to connect people, machines, systems, and so on, and the connection type and quantity are rich and varied. Attackers can destroy the in-vehicle network system and realize the possibility of remotely maneuvering cars to increase traffic accidents. To prevent this phenomenon, we can take advantage of the traceability of the blockchain. The user must negotiate the mk with the vehicle (which may be the transaction amount) and use the vehicle by the generated sk from mk at the agreed time. Since the usage record can be found in the ledger, the possibility of an attacker implementing the attack is reduced.
The scheme proposed in this paper can resist MITM attacks.
Diffie–Hellman key-exchange protocol exists MITM attacks, supposing there is a third party who desires to steal A and B’s messages. The third party can impersonate the receiver to get the sender’s A,
The MITM attack exists because initiators do not authenticate the other party, but they will authenticate the negotiating party due to the signature on blockchain. Therefore, our proposed scheme can resist MITM attacks.
Our proposed key negotiation scheme can resist packet-dropping attacks.
Diffie-Hellman key exchange protocol exists packet-dropping attacks, because the negotiated parts may be lost or dropped. Whether the other party has successfully received information about the negotiated key and whether two parties can successfully negotiate the key are uncertain because there is no confirmation mechanism. However, blockchain can guarantee the success of the negotiation, that is, each client can see all parts of the negotiation and both parties can certainly form a pair of key and confirm that the other party knows the negotiated key. In addition, due to the timestamp, our scheme can satisfy the traceability of the negotiated key.
The scheme we proposed in this paper can resist decryption failure attacks.
Diffie-Hellman key-exchange protocol exists decryption failure attacks because the key was not confirmed and the parties do not know whether the other party has received the negotiated package. If you send encrypted data, it may cause decrypting failure with high energy consumption. In this paper, since only the sender and receiver can determine the key, other demanders cannot interpret the message (confidentiality). The receiver knows that only the sender can use the key to generate the message to protect the transaction security and resist decryption failure attacks, which satisfies the authenticity of the negotiated key.
Assuming that the number
Even if you know
Based on the assumption that DHP is difficult, given the finite cyclic group G, the generator
Our proposed key negotiation scheme is correct; both sides of the transaction (Alice and Bob) get the same mk.
Alice randomly chooses large prime number
sk can automatically change based on the latest block header and can be traced.
Since the block header is equivalent to a pseudorandom number generator, the session key
The cost and time of cracking key negotiations are not feasible in calculation, so the provable safety is satisfied.
Due to the complexity of the algorithms involved, it is tricky to estimate the algorithm accurately, but our analysis gives some conservative estimates. For the most common strength of Diffie–Hellman (1024 bits), building a machine based on dedicated hardware which can crack one Diffie–Hellman prime every year costs hundreds of millions of dollars. Therefore, we conclude that the cost and time of cracking our key negotiations are not feasible in calculation.
The overhead of time and space is low.
Only mks are generated by the key information on the blockchain. In the case that the master key does not need to be changed, it only needs to be generated C (
Assuming the length of a large prime number is
Assuming the length of large prime number is
According to the comparison of three key negotiations in Table
Scheme comparison.
Proposed key negotiations | Lei et al. [ |
Our scheme | Park et al. [ |
Our scheme |
---|---|---|---|---|
A secure key management within the heterogeneous network | Three key negotiations via blockchain | RSU-based decentralized key negotiation | Three key negotiations via blockchain | |
Analyze the performance of proposed scheme | ✓ | ✓ | ✓ | ✓ |
Propose optimization algorithms | ✕ | Three steps to generate a key | Determine the design parameters | Three steps to generate a key |
Defend against MITM attacks | ✓ | ✓ | ✕ | ✓ |
Defend against packet-dropping attacks | ✓ | ✓ | ✕ | ✓ |
Defend against decryption failure attacks | ✕ | ✓ | ✕ | ✓ |
Satisfy traceability of key exchange | ✓ | ✓ | ✕ | ✓ |
In this paper, we propose a traceable and authenticated key negotiation scheme based on blockchain. Specifically, key exchanges rely on value channels, static scripts, or dynamic scripts. The key materials can be traced back publicly by timestamps upon request and can be confirmable to avoid decryption failure attacks. Negotiation peers can be authenticated to resist MITM attacks. The packet-dropping attacks are defended against as the timeliness of key negotiation can be guaranteed due to the availability of channels and scripts. Last but not least, the key negotiation process can be preconfigurable and automatically executed.
We mainly focus on theoretical analysis and do not refer to data.
The authors declare that they have no conflicts of interest.
The research was financially supported by the Major Scientific and Technological Special Project of Guizhou Province under grant no. 20183001, Open Funding of Guizhou Provincial Key Laboratory of Public Big Data under grant no. 2018BDKFJJ009, 2017BDKFJJ006, Open Funding of Hubei Provincial Key Laboratory of Intelligent Geo–Information Processing under grant no. KLIGIP2016A05, and National Natural Science Foundation of China, “Theory and Key Technologies of Distributed Autonomous Security Supervision for Data Opening and Sharing” (grant nos. 61962009 and 2020/01-2023/12).