3. Proposed Solution
3.2 Message Transmission
As can be seen in the figure above, Alice‟s proxy initially wraps her source authenticator and the pseudonym information (pseudonym public key, lifetime and timestamp) with the CA‟s secondary private key. This is transmitted, as the proxy‟s certificate. At Bob‟s node, the CA‟s secondary public key is used to verify the signature and upon verification Bob has access to the pseudonym information (pseudonym public key, lifetime and timestamp) and Alice‟s source authenticator. The source authenticator appears as unintelligible information.
If one signs the message by encrypting the entire message, it is expensive to do at the sender. All receivers will need to unpack the certificate and then decrypt the whole message before they can read it. It would be wiser to merely sign a hash of the message (which is a shortened form of the message, calculated using some hash function [112]) and send it. A hash is commonly used to verify the integrity of a message. The resultant hash is signed (shown below was „signed hash‟) and sent together with the message to the recipient:
ℎ ℎ (ℎ ) (5) Where:
- = Encryption with pseudonym private key, - ℎ = the hash function
- = the message in plaintext
The recipient verifies the signature on the signed hash and calculates the hash of the received message. If the signed hash matches with the calculated hash then the message is considered authentic and to have not been altered.
When compared to dividing the entire message into blocks and signing individually, this saves computation time and space [112]. There is therefore less work at the sender and every receiver is able to read the message directly and need only check certification. Many messages may never need to be checked as they will be self-evident quite shortly after reception and not dangerous or prone to malic.
In another scenario, if a Carol needs to send a message specifically to Dale (Bob‟s pseudonym) the message must be encrypted with Dale‟s public key, so that only Dale can unwrap it. The message hash and timestamp should thereafter be signed with Carol‟s private key to confirm Carol created the message and that it is valid. Confidentiality of the message is required here because the message is meant for only Dale, and it is undesirable for other nodes to view it. This structure of the transmitted message is shown below:
|| ℎ || || (6) Where:
- = defined in equation (3) above - = Encryption with Carol‟s private key, - ℎ = Hash of the message
- = the message that has been sent, in plaintext - = the time that the message was created - = Encryption with Dale‟s public key,
As in the broadcast case, the proxy‟s certificate can be easily verified. The message hash and timestamp is signed by Carol and can be verified upon applying Carol‟s public key.
The message has been wrapped using Dale‟s public key and this ensures that only Dale can unwrap the message, guaranteeing confidentiality. Confirming that the message hash signed by Carol matches a message hash calculated by Dale proves that the message is from Carol. Further, being able to verify the signature made with confirms that the message was produced by Carol (who is registered in the network and who can be traced to Alice by the CA if needed); guaranteeing integrity and authentication. If the message hash was altered after Carol signed it, it will no longer carry Carol‟s signature and will not be authentic or carry integrity.
3.2.1 Protocol Transaction
Transactions using the proposed protocol and demonstration of its effectiveness in achieving authentication and privacy are provided in this section.
Considering the scenario where a message from Carol is broadcast to other nodes and Dale chooses to reply to Carol, the following transactions will take place:
The OBU generates Alice‟s pseudonym (Carol) and a public-private key pair for Carol ( , ). The proxy thereafter creates an authenticator for Alice; a timestamp is combined with Alice‟s permanent certificate and both are encrypted using the CA‟s primary public key, as shown below:
ℎ || (7) The proxy generates validity information ( ) for the proxy certificate. This is made up of and . The CA‟s secondary private key is used
to produce Carol‟s certificate by wrapping , Carol‟s public key ( ) and Alice‟s Authenticator:
|| || ℎ (8) Carol‟s certificate follows the same structure as the proxy certificate defined in equation (3). The message hash is calculated, combined with the message timestamp and signed with to produce Carol‟s message signature:
ℎ || (9) Carol‟s certificate, message signature and original message are combined and transmitted:
|| || (10) This transmitted message is broadcast to each node in the area. Since all nodes have access to Carol‟s certificate can be verified.
Upon receiving the transited message, Bob does the following:
Bob uses to verify the signature on Carol‟s certificate. Upon verification, Bob can see the following:
|| || ℎ (11) Where:
- = Performing a decryption or „unwrapping‟ operation (in this case verifying the proxy‟s signature), using
Only and can be read by Bob. Bob verifies that Carol‟s certificate is still valid using . If Carol‟s certificate is valid, is considered authentic and valid and is used to verify the signature on Carol‟s message signature:
ℎ || (12)
Bob can then read Carol‟s message signature and view the message timestamp. If the message timestamp proves that the message was created within the valid time period, then the message is valid. He calculates the hash of the message, which has been sent in plaintext and if it matches the hash signed by Carol then it is certain Carol sent the message.
Thereafter assume Bob wants to respond to Carol regarding the broadcast message.
Bob‟s OBU generates a public private key pair for Dale ( , ). The proxy creates a certificate for Dale by combining a timestamp with Bob‟s permanent certificate and encrypting it using the CA‟s primary public key, as shown below:
ℎ || (13) The proxy generates validity information ( ) for Dale‟s certificate. This is made up of and . The CA‟s secondary private key is then applied to , Dale‟s public key ( ) and Bob‟s Authenticator to produce a certificate for Dale:
|| || ℎ (14) Dale wraps the message such that it is visible to Carol only:
(15) A hash of the message is then calculated. The message hash and a message timestamp are signed by Dale, producing Dale's message signature:
ℎ || (16) This result is combined with Dale‟s certificate and the encrypted message and transmitted:
|| || (17) The message is thereafter sent to Carol; the outcome is shown below:
Carol verifies Dale‟s certificate and can see the following:
|| || ℎ (18) Only and can be read by Carol. Carol verifies that Dale‟s certificate is still valid using . If Dale‟s certificate is valid, is considered authentic and valid, and can be used as follows:
ℎ || (19) The message wrapped with can then be easily unwrapped by Carol using . The message hash is calculated, and as before, if both hashes match then the message did indeed come from Dale. This guarantees confidentiality and authentication.
The steps above demonstrate that the protocol caters for both authentication and privacy.
Since the proxy is always available, this guarantees that authentic certificates are also always available. All proxies are considered trusted and are able to provide authentic pseudonyms that protect the user‟s real identity, while also ensuring that the CA can trace the vehicle if necessary.
Looking at the sequence of events above, this solution still keeps the PKI structure intact;
there is a TTP (the CA), and nodes only accept certificates signed by the CA (a proxy to the CA in this case, which is trusted). Even though each node creates and signs their own certificates, this is not a distributed authority network, but rather one with a TTP, which ensures that the network is trusted.