Certificate Based Security Mechanisms in Vehicular Ad-Hoc Networks based on IEC 61850 and IEEE WAVE Standards

When equipped with an on-board wireless kit, electric vehicles (EVs) can communicate with nearby entities, e.g., road side units (RSUs), via a vehicle ad-hoc network (VANET). More observability enables smart charging algorithms where charging stations (CSs) are allocated to EVs based on their current state of charge, destination, and urgency to charge. IEEE 1609 WAVE standard regulates VANETs, while IEC 61850 is emerging as the smart grid communication standard. In order to integrate these two domains of energy management, past research has focused on harmonizing these two standards for a full smart city solution. However, this solution requires very sensitive data to be transmitted, such as ownership of EV, owners’ personal details, and driving history. Therefore, data security in these networks is of prime concern and needs to be addressed. In this paper, different security mechanisms defined by the IEEE 1609 WAVE standard are applied for both vehicle-to-infrastructure (V2I) and vehicle-to-grid (V2G) communication. The former relates to EV–RSU, while the latter covers EV–CS communication. The implicit and explicit certificate mechanism processes proposed in IEEE 1609 WAVE for authentication are studied in great detail. Furthermore, a performance evaluation for these mechanisms is presented in terms of total time lapse for authentication, considering both the computational time and communication time delays. These results are very important in understanding the extra latency introduced by security mechanisms. Considering that VANETs may be volatile and may disappear as EVs drive away, overall timing performance becomes vital for operation. Reported results show the magnitude of this impact and compare different security mechanisms. These can be utilized to further develop VANET security approaches based on available time and the required security level.


Introduction
Intelligent transport systems (ITS) improve traveler safety, decrease traffic congestion, facilitate the reduction of air pollution, provide vehicle information, and contribute to protecting natural resources.The applications of ITS extend to incident management system processes, electronic road toll collection, and in-car navigation systems [1].The use of wireless technology fits well in providing the medium to connect any vehicle to the outside world [2].An electric vehicle (EV) integrated with wireless sensors and communication devices forms vehicle-to-infrastructure (V2I) and vehicle-to-vehicle (V2V) communication networks, which enable EVs to communicate with surroundings such as road side High communication overheads and computational latency, difficulty managing CRL.
[ 22,23] 2 ID-based signature RSU signs and authorize each of the messages.
If RSU is compromised, then entire system will be compromised.[24,25] 3 Group signature Privacy preservation by hiding the real identity of sender among the other group members.
If group administrator is compromised, then entire group will be compromised.[26,27] 4 ID-based group signature Generation of ID-based signature.
Does not work if RSU is not available in the vicinity or road side, and location of vehicle can be traced using RSU. [29] 6 Cooperative authentication Performs authentication by sending verification results to another vehicle cooperatively without the role of RSU.
Performance degrades in the case of low vehicle density and heavy revocation costs.
[ 25,28] 7 Ring signature No central administrator in the group of ring vehicles.
Communication efficiency may be hampered [30] All the above schemes do not consider the communication delay of checking the overall performance of the system.This paper analyzes the explicit and implicit certificate authentication mechanisms recommended by the IEEE WAVE 1609.2 standard.Performance evaluations of these mechanisms were carried out in terms of total time lapse for authentication, which includes communication latency and computational latency.

Cybersecurity Considerations of IEEE WAVE
EVs communicate through the WAVE protocol, which is an expansion of 802.11 with some additions to physical and data link layers.In order to understand security vulnerabilities and the solutions implemented in this paper, it is important to understand this standard's protocol stack and how it relates to other standards, as shown in Figure 1.IEEE 1609. 4  Communication efficiency may be hampered [30] All the above schemes do not consider the communication delay of checking the overall performance of the system.This paper analyzes the explicit and implicit certificate authentication mechanisms recommended by the IEEE WAVE 1609.2 standard.Performance evaluations of these mechanisms were carried out in terms of total time lapse for authentication, which includes communication latency and computational latency.

Cybersecurity Considerations of IEEE WAVE
EVs communicate through the WAVE protocol, which is an expansion of 802.11 with some additions to physical and data link layers.In order to understand security vulnerabilities and the solutions implemented in this paper, it is important to understand this standard's protocol stack and how it relates to other standards, as shown in Figure 1  Due to high mobility and low communication latency in vehicular networks, it is highly likely that an intruder might gain access to a RSU or an EV.This may have severe consequences, such as infrastructure damage, road accidents, and loss of lives.Consider a scenario where an EV with low battery charge tries to get the information of a nearby CS.The EV establishes communication with a nearby RSU to get information regarding nearby available CSs.The information may include number of charging slots available, distance to the CSs, etc.If the RSU is compromised or impersonated, it may misguide the EV.The problem of impersonation arises due to authentication failure of the devices.
IEEE 1609.2 defines the security services and mechanisms needed to protect VANETs.In IEEE 1609.2, the issue of authentication is addressed through public key infrastructure (PKI) and CA mechanisms.Furthermore, IEEE 1609.2WAVE specifies the implicit or explicit certificate mechanisms for authentication of different entities in VANETs.However, IEEE 1609.2 does not specify a particular mechanism for authentication in VANET communication for a particular application.
Furthermore, the IEEE 1609.2 standard specifies some relevance conditions, based on which the validity of the received message can be verified.Relevance conditions are parameters, such as freshness, expiry, and reply, used to check for any security vulnerabilities.The freshness parameter ensures that the signature generation time is not too long for a service-that is, that the signature was generated recently.If freshness is compromised, then it may lead to reply attacks and masquerade attack using old credentials of the service.The expiry parameter ensures that received message is not expired.It can be checked either the certificate revocation list or by comparing the received time of Due to high mobility and low communication latency in vehicular networks, it is highly likely that an intruder might gain access to a RSU or an EV.This may have severe consequences, such as infrastructure damage, road accidents, and loss of lives.Consider a scenario where an EV with low battery charge tries to get the information of a nearby CS.The EV establishes communication with a nearby RSU to get information regarding nearby available CSs.The information may include number of charging slots available, distance to the CSs, etc.If the RSU is compromised or impersonated, it may misguide the EV.The problem of impersonation arises due to authentication failure of the devices.IEEE 1609.2 defines the security services and mechanisms needed to protect VANETs.In IEEE 1609.2, the issue of authentication is addressed through public key infrastructure (PKI) and CA mechanisms.Furthermore, IEEE 1609.2WAVE specifies the implicit or explicit certificate mechanisms for authentication of different entities in VANETs.However, IEEE 1609.2 does not specify a particular mechanism for authentication in VANET communication for a particular application.
Furthermore, the IEEE 1609.2 standard specifies some relevance conditions, based on which the validity of the received message can be verified.Relevance conditions are parameters, such as freshness, expiry, and reply, used to check for any security vulnerabilities.The freshness parameter ensures that the signature generation time is not too long for a service-that is, that the signature was generated recently.If freshness is compromised, then it may lead to reply attacks and masquerade attack using old credentials of the service.The expiry parameter ensures that received message is not expired.It can be checked either the certificate revocation list or by comparing the received time of message with the expiry time in the certificate field of message.The reply parameter ensures that the message received is not a duplicate one.
Charging management of EV applications requires minimum delays in communication between EVs and RSUs.Hence, it is required that the authentication mechanism for EV-RSU communication has a low computational time.In this paper, performance evaluations of both implicit and explicit certificate authentication mechanisms are carried out in terms of overall time required for authentication.

Certificate Based Authentication Mechanisms for EV-RSU Communication
The architectural model of EV communication in smart cities incorporates wireless ad-hoc communication among EVs, CSs, and RSUs. Figure 2 is an illustrative example of V2I and V2G communication.Here, as EVs are going through the same geographical area, they can form a wireless ad-hoc network with RSUs and CSs based on a cell layout: that is, EVs, RSUs, and CSs within a one square kilometer radius.
CSs share information about the type of charging they offer and the number of available charging slots to the RSUs.On request from an EV, RSUs will run the charging slot allocation algorithm and send information about the allotted slot at a particular CS.Random EV load connections to CS will have a major impact on power distribution networks in the form of load boosting and power imbalances.This problem can be mitigated by employing effective EV charge management schemes.In Reference [7], the authors proposed an EV charging allocation algorithm which allocates a specific slot for charging to each EV.While allocating the charging slot, the algorithm proposed in Reference [7] takes into account the load at different CSs as well as other factors like power outages and shortages at the location of the CSs, number of empty charging slots, etc. Further, while allocating charging slots to EVs, the algorithm gives priority to the EVs with low battery charges, to avoid the problem of being left stranded due to a flat battery.
Implementation of the above discussed EV charging slot algorithm requires message exchanges between EV-RSU and EV-CS.Furthermore, these message exchanges must be standardized in order to achieve interoperability and plug-and-play operation.Hence, in Reference [7], V2I communication is based on the IEEE WAVE 1609 standard, while the V2G communication is based on the IEC 61850 and ISO/IEC 15118 standards.CSs share information about the type of charging they offer and the number of available charging slots to the RSUs.On request from an EV, RSUs will run the charging slot allocation algorithm and send information about the allotted slot at a particular CS.Random EV load connections to CS will have a major impact on power distribution networks in the form of load boosting and power imbalances.This problem can be mitigated by employing effective EV charge management schemes.In Reference [7], the authors proposed an EV charging allocation algorithm which allocates a specific slot for charging to each EV.While allocating the charging slot, the algorithm proposed in Reference [7] takes into account the load at different CSs as well as other factors like power outages and shortages at the location of the CSs, number of empty charging slots, etc. Further, while allocating charging slots to EVs, the algorithm gives priority to the EVs with low battery charges, to avoid the problem of being left stranded due to a flat battery.
Implementation of the above discussed EV charging slot algorithm requires message exchanges between EV-RSU and EV-CS.Furthermore, these message exchanges must be standardized in order to achieve interoperability and plug-and-play operation.Hence, in Reference [7], V2I communication is based on the IEEE WAVE 1609 standard, while the V2G communication is based on the IEC 61850 and ISO/IEC 15118 standards.
For the purposes of this work, the security of the EV message exchanges is considered.Should there be an imposter acting as an RSU, it can receive all the sensitive information from EVs.Since no authentication scheme is implemented, EVs do not have the means to detect that the entity to which they are sending their private information is not legitimate.This work addresses this knowledge gap by implementing authentication mechanisms in VANETs based on IEC 61850 and IEEE WAVE standards.
The first step to achieve this is by implementing a certificate-based mechanism to authenticate entities that want to take part in communication networks.As shown in Figure 3, a certificate authority (CA) is needed to issue individual certificates to each entity, denoted as step 1.There are different ways to implement certificate acquisition.In this paper, two such mechanisms, explicit and implicit certificate mechanisms, are considered and discussed in Sections 4.1 and 4.2, respectively.After implementation, they are tested to compare their performances and assess their feasibility for VANETs.Once received, these certificates are exchanged between entities prior to establishing a communication link.Each entity sends its own certificate to the other party, denoted as step 2, and verifies the certificate it received from the other party.If both certificates are valid, then both entities are authenticated as legitimate, i.e., authentication with certificate.
Electronics 2018, 7, x FOR PEER REVIEW 6 of 17 For the purposes of this work, the security of the EV message exchanges is considered.Should there be an imposter acting as an RSU, it can receive all the sensitive information from EVs.Since no authentication scheme is implemented, EVs do not have the means to detect that the entity to which they are sending their private information is not legitimate.This work addresses this knowledge gap by implementing authentication mechanisms in VANETs based on IEC 61850 and IEEE WAVE standards.
The first step to achieve this is by implementing a certificate-based mechanism to authenticate entities that want to take part in communication networks.As shown in Figure 3, a certificate authority (CA) is needed to issue individual certificates to each entity, denoted as step 1.There are different ways to implement certificate acquisition.In this paper, two such mechanisms, explicit and implicit certificate mechanisms, are considered and discussed in Sections 4.1 and 4.2, respectively.After implementation, they are tested to compare their performances and assess their feasibility for VANETs.Once received, these certificates are exchanged between entities prior to establishing a communication link.Each entity sends its own certificate to the other party, denoted as step 2, and verifies the certificate it received from the other party.If both certificates are valid, then both entities are authenticated as legitimate, i.e., authentication with certificate.It is perfectly possible that a hacker eavesdrops, denoted as step 3, during steps 1 and/or 2. In this case, the hacker can snatch the certificate and use it as their own.In this fashion, they can authenticate themselves with other entities, as in step 2. In order to mitigate this, an additional security layer is required so that third parties cannot use other certificates, even if they could snatch them during communication.This is achieved by digital signatures and PKI.Since the certificates are signed by CA, the hacker will not be able to change the public key in the certificate.If the hacker changes the public key in the certificate, the certificate becomes invalid.Without the information of the private key associated with the public key in the certificate, the hacker cannot continue further communication.There are different signing algorithms that can be implemented for signing certificates.In this research, RSA and Elliptic Curve Digital Signature Algorithm (ECDSA) algorithms were implemented in explicit certificate mechanisms due to their strength.As discussed in Section 4, these different approaches were implemented, and their performances were studied for feasibility assessment.
In short, in the CA and PKI approach, certificates are used to identify legitimate nodes and keys are used to secure certificates, so that they are not stolen and used by unauthorized entities.The rest It is perfectly possible that a hacker eavesdrops, denoted as step 3, during steps 1 and/or 2. In this case, the hacker can snatch the certificate and use it as their own.In this fashion, they can authenticate themselves with other entities, as in step 2. In order to mitigate this, an additional security layer is required so that third parties cannot use other certificates, even if they could snatch them during communication.This is achieved by digital signatures and PKI.Since the certificates are signed by CA, the hacker will not be able to change the public key in the certificate.If the hacker changes the public key in the certificate, the certificate becomes invalid.Without the information of the private key associated with the public key in the certificate, the hacker cannot continue further communication.There are different signing algorithms that can be implemented for signing certificates.In this research, RSA and Elliptic Curve Digital Signature Algorithm (ECDSA) algorithms were implemented in explicit certificate mechanisms due to their strength.As discussed in Section 4, these different approaches were implemented, and their performances were studied for feasibility assessment.
In short, in the CA and PKI approach, certificates are used to identify legitimate nodes and keys are used to secure certificates, so that they are not stolen and used by unauthorized entities.The rest of the paper focuses on different implementation alternatives for CA and PKI, and investigates their feasibility for securing VANETs.

Explicit Certificate Mechanism
In this approach, the CA issues a certificate, which is a type of endorsement of a user with a unique public key.It contains a format specified by X.509 [31].The process of issuing a certificate is binding a public key to a user's identity.The X.509 certificate format includes name, serial number, issuer signature value, and time of expiry.The authors in Reference [31] define terms such as certificate, end entity, CA, and revocation service.A certificate contains information that binds a public key to the identity of an end entity.This type of certificate is called an explicit certificate, where the public key of the subject is explicitly specified, hence the name.The explicit certificate contains additional information as specified in X.509.The CA also maintains a certificate revocation list (CRL), which is helpful in the certificate verification process.
Figure 4 explains the process of certificate signing by a CA.The EV constructs a certificate request with all the credentials required by the X.509 format and sends it to CA.The CA has its pair of public and private keys.The private key is only known to CA, whereas the public key is known to everyone.The CA signs the credentials of the certificate request, as shown in Figure 4, with a message digest algorithm (MDA), and generates a message digest (MD1).The MD1 is a hash value which is further encrypted with CA's private key to generate an encrypted digest (ED), also known as a signature.This process is called signing the certificate by CA.This paper uses the secure hash algorithm (SHA256) as the MDA and RSA for public key encryption.The signed certificates are loaded in tamper-free onboard units of EVs.
Electronics 2018, 7, x FOR PEER REVIEW 7 of 17 of the paper focuses on different implementation alternatives for CA and PKI, and investigates their feasibility for securing VANETs.

Explicit Certificate Mechanism
In this approach, the CA issues a certificate, which is a type of endorsement of a user with a unique public key.It contains a format specified by X.509 [31].The process of issuing a certificate is binding a public key to a user's identity.The X.509 certificate format includes name, serial number, issuer signature value, and time of expiry.The authors in Reference [31] define terms such as certificate, end entity, CA, and revocation service.A certificate contains information that binds a public key to the identity of an end entity.This type of certificate is called an explicit certificate, where the public key of the subject is explicitly specified, hence the name.The explicit certificate contains additional information as specified in X.509.The CA also maintains a certificate revocation list (CRL), which is helpful in the certificate verification process.
Figure 4 explains the process of certificate signing by a CA.The EV constructs a certificate request with all the credentials required by the X.509 format and sends it to CA.The CA has its pair of public and private keys.The private key is only known to CA, whereas the public key is known to everyone.The CA signs the credentials of the certificate request, as shown in Figure 4, with a message digest algorithm (MDA), and generates a message digest (MD1).The MD1 is a hash value which is further encrypted with CA's private key to generate an encrypted digest (ED), also known as a signature.This process is called signing the certificate by CA.This paper uses the secure hash algorithm (SHA256) as the MDA and RSA for public key encryption.The signed certificates are loaded in tamper-free onboard units of EVs.Algorithm 1 describes the certificate signing mechanism.The certificate request (X509Cert) received from the EV contains credentials such as the vehicle identity (ID), EV public key, etc.The CA first generates the hash value (h1) of the certificate request, using any hash algorithm such as SHA256.The generated hash value h1 is further encrypted with the public key cryptography algorithm (ENCCAPrKey(h1)) using the CA's private key (CAPrKey).The encrypted value (x) is stored in the signature field (X509Cert.Signature) of the certificate.Once the signing process is complete, the resulting format is a signed certificate (SX509Cert).

Algorithm 1. Signing (X509Cert) 1:
ID ← X509Cert.credentials2: h1 ← H(ID) Algorithm 1 describes the certificate signing mechanism.The certificate request (X509Cert) received from the EV contains credentials such as the vehicle identity (ID), EV public key, etc.The CA first generates the hash value (h1) of the certificate request, using any hash algorithm such as SHA256.The generated hash value h1 is further encrypted with the public key cryptography algorithm (ENCCAPrKey(h1)) using the CA's private key (CAPrKey).The encrypted value (x) is stored in the signature field (X509Cert.Signature) of the certificate.Once the signing process is complete, the resulting format is a signed certificate (SX509Cert).
When an EV wants to communicate with a RSU, it first sends its signed certificate, wherein the certificate credentials are encrypted with the EV's private key, to the RSU for authentication.The signed certificate consists of encrypted credentials of the EV and a signature signed by the CA.The RSU picks up the signature from the certificate and performs decryption with the RSA public key algorithm.The public key of the CA is used in the decryption process.The output of the decryption is the message digest (MD1), which is generated by the CA.Following on, the RSU decrypts the certificate credentials of the EV with the EVs public key and generates a new message digest (MD2) using the MDA.If the newly generated digest MD2 is the same as MD1, then RSU confirms the authenticity of the EV.The entire process is to verify whether the signature is signed by the CA or not. Figure 5 illustrates this verification process.3: x ← ENCCAPrKey (h1) 4: X509Cert.Signature ← x 5: return SX509Cert When an EV wants to communicate with a RSU, it first sends its signed certificate, wherein the certificate credentials are encrypted with the EV's private key, to the RSU for authentication.The signed certificate consists of encrypted credentials of the EV and a signature signed by the CA.The RSU picks up the signature from the certificate and performs decryption with the RSA public key algorithm.The public key of the CA is used in the decryption process.The output of the decryption is the message digest (MD1), which is generated by the CA.Following on, the RSU decrypts the certificate credentials of the EV with the EVs public key and generates a new message digest (MD2) using the MDA.If the newly generated digest MD2 is the same as MD1, then RSU confirms the authenticity of the EV.The entire process is to verify whether the signature is signed by the CA or not. Figure 5  Algorithm 2 describes the certificate verification mechanism.Algorithm 2 essentially checks whether a certificate that is sent to a RSU is original or not.The signed certificate (SX509Cert) is received by a peer, such as a RSU.After receiving the signed certificate at the RSU, the certificate credentials part of the signed certificate is decrypted with the public key of the CA.The signature field of the signed certificate (SX509Cert) is first decrypted with a public key cryptographic algorithm (DEC(x)) using the public key of the CA (CAPubKey).Thereafter, the RSU hashes the credentials part of the certificate to generate digest h2.The decrypted signature value, h1, is compared with the newly generated hash value, h2.The original hash value (h1) cannot be changed as it can only be created and encrypted by the CA.If the original hash value is tampered with, it already shows the certificate is not authentic.If both hash values are identical, then authentication is successful, otherwise, authentication fails.Once the process of authentication is complete, data will be exchanged between the EV and the RSU.

Algorithm 2. Verify(SX509Cert) 1:
x ← SX509Cert.Signature 2: h1 ← DECCAPubKey (x) 3: h2 ← H(ID) 5: if h1 = h2 then 6: return True 7: else Algorithm 2 describes the certificate verification mechanism.Algorithm 2 essentially checks whether a certificate that is sent to a RSU is original or not.The signed certificate (SX509Cert) is received by a peer, such as a RSU.After receiving the signed certificate at the RSU, the certificate credentials part of the signed certificate is decrypted with the public key of the CA.The signature field of the signed certificate (SX509Cert) is first decrypted with a public key cryptographic algorithm (DEC(x)) using the public key of the CA (CAPubKey).Thereafter, the RSU hashes the credentials part of the certificate to generate digest h2.The decrypted signature value, h1, is compared with the newly generated hash value, h2.The original hash value (h1) cannot be changed as it can only be created and encrypted by the CA.If the original hash value is tampered with, it already shows the certificate is not authentic.If both hash values are identical, then authentication is successful, otherwise, authentication fails.Once the process of authentication is complete, data will be exchanged between the EV and the RSU.return False 9: end if Sometimes, a CA can be a subordinate of a parent CA.The subordinate CA's certificate is signed by the parent CA, while the parent CA's certificate is self-signed.Figure 6 depicts a scenario where there is more than one CA.EV1 has a certificate signed by Subordinate CA (Y1).Subordinate CA (Y1)'s identity is recognized by X1, which is in turn recognized by the Root CA.The Root CA is also called a trust anchor.The trust anchor has a self-signed certificate.
the EV communicates with a nearby RSU to get charging station information.The RSU first verifies the received certificate through the CA.If the certificate is valid and not revoked, then communication is initiated.The charging station information is transmitted between the EV and the RSU through WSMP (wireless short message protocol) messages, as specified in Reference [7].
Another significant functionality of the CA is the revocation service.An intruder EV can send a revoked certificate and try to establish communication with other entities on VANET.The revocation service keeps a list of revoked certificates inside CA.Whenever an EV sends its certificate to a RSU, the RSU verifies the certificate credentials with the CA.The CA checks this certificate against the revocation list, and notifies the RSU of the result.This feature is very important in mitigating security attacks.Any anomalies found in the certificate are reported by the CA to the RSU, hence, the intruder EV can be identified.IEEE WAVE specifies the mechanism of revocation of certificates by maintaining parameters of relevance conditions such as freshness, expiry, and reply, as discussed in section 3.  The authentication process through the explicit certificate mechanism between EV, RSU, and CS is shown in Figure 7. Initially EV, RSU, and CS receives their signed certificates from the CA.Next, the EV communicates with a nearby RSU to get charging station information.The RSU first verifies the received certificate through the CA.If the certificate is valid and not revoked, then communication is initiated.The charging station information is transmitted between the EV and the RSU through WSMP (wireless short message protocol) messages, as specified in Reference [7].

Implicit Certificate Mechanism
Another kind of certificate is the implicit certificate [32], which does not contain a user's public key inside.The implicit certificate mechanism is a concept, and Elliptic Curve Qu-Vanstone (ECQV) is a mathematical incarnation of this concept [33].An ECQV certificate contains a user's identity and public key reconstruction data, along with the CA's public key.When an RSU receives a certificate from an EV for establishment of communication, the RSU constructs the transmitter's public key from the user identity, the CA's public key, and the public parameter.The user's public key is not explicitly contained in the implicit certificate.It is computationally infeasible for an intruder to compute a Another significant functionality of the CA is the revocation service.An intruder EV can send a revoked certificate and try to establish communication with other entities on VANET.The revocation service keeps a list of revoked certificates inside CA.Whenever an EV sends its certificate to a RSU, the RSU verifies the certificate credentials with the CA.The CA checks this certificate against the revocation list, and notifies the RSU of the result.This feature is very important in mitigating security attacks.Any anomalies found in the certificate are reported by the CA to the RSU, hence, the intruder EV can be identified.IEEE WAVE specifies the mechanism of revocation of certificates by maintaining parameters of relevance conditions such as freshness, expiry, and reply, as discussed in Section 3.

Implicit Certificate Mechanism
Another kind of certificate is the implicit certificate [32], which does not contain a user's public key inside.The implicit certificate mechanism is a concept, and Elliptic Curve Qu-Vanstone (ECQV) is a mathematical incarnation of this concept [33].An ECQV certificate contains a user's identity and public key reconstruction data, along with the CA's public key.When an RSU receives a certificate from an EV for establishment of communication, the RSU constructs the transmitter's public key from the user identity, the CA's public key, and the public parameter.The user's public key is not explicitly contained in the implicit certificate.It is computationally infeasible for an intruder to compute a private key corresponding to an EV's public key, or to construct a matching EV identity and reconstruct data for which a corresponding private key may also be computed [34].
Figure 8 explains the steps involved in implicit certificate generation process.Elliptic curve domain parameters are defined as per Reference [35].Let q be the order of finite field Fq, E is elliptic curve defined over Fq, and G is a generator point in E(Fq).The prime number n denotes the order of G.The CA picks its private key t ∈ [1, n − 1] and computes the public key C = c*G.In the same way, the EV picks its private key v ∈ [1, n − 1] and computes the public key V = v*G.ID EV is information related to the EV, which consists of the EVs identifier and the CA identifier, serial number, and validity period included in EV's certificate, and P denotes the EV's reconstruction public data.H is a hash function, such as SHA256.IEEE1609.2recommends the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Integrated Encryption Standard (ECIES) for generating signature and encryption operations, respectively.The standard also specifies the use of two NIST-approved elliptic curves: P-224 and P-256.When a data packet is received, say, from an EV to a nearby RSU, the authentication process using the implicit certificate mechanism takes place as follows.
Initially, the EV and the CA compute their private and public key pairs ((v, V), (t, T)).The EV IEEE1609.2recommends the use of the Elliptic Curve Digital Signature Algorithm (ECDSA) and Elliptic Curve Integrated Encryption Standard (ECIES) for generating signature and encryption operations, respectively.The standard also specifies the use of two NIST-approved elliptic curves: P-224 and P-256.When a data packet is received, say, from an EV to a nearby RSU, the authentication process using the implicit certificate mechanism takes place as follows.
Initially, the EV and the CA compute their private and public key pairs ((v, V), (t, T)).The EV then picks a random number, r, between 1 and n, computes R = r*G and sends it to the CA along with its identification data, ID EA .The CA also picks a random number, q, between 1 and n, and computes the EV's reconstruction public data D = q*G + D. The CA computes h = H (ID EA , D) and s = h*q + t mod n.Finally, the CA sends (D, ID EA , s) to the EV.The EV sets its private key to v = h*r + s mod n, where h = H (ID EA , D).The EV's public key, V [V = v* G], can be reconstructed by the RSU from the the implicit certificate (ID EA , D) using the equation: where T = t*G, which is the public key of the CA.The equation holds, since:

Performance Evaluation
In order to assess the suitability of these different mechanisms for VANETs, the total time lapse for authentication was calculated.The total authentication time is the combined time required for transmission of certificate from EV to RSU, and computational time to verify the certificate at the RSU.A combinational approach, depicted in Figure 9, was used.As shown, authentication mechanisms were implemented using Python OpenSSL library.Through these implementations two parameters were acquired.The first is the certificate size for each individual implementation, and the second is the computational time required to verify a certificate.These parameters are given in Tables 2 and 3, third and fourth columns from the right.= ℎ ( , ) *  +

Performance Evaluation
In order to assess the suitability of these different mechanisms for VANETs, the total time lapse for authentication was calculated.The total authentication time is the combined time required for transmission of certificate from EV to RSU, and computational time to verify the certificate at the RSU.A combinational approach, depicted in Figure 9, was used.As shown, authentication mechanisms were implemented using Python OpenSSL library.Through these implementations two parameters were acquired.The first is the certificate size for each individual implementation, and the second is the computational time required to verify a certificate.These parameters are given in Tables 2 and 3, third and fourth columns from the right.To study the impact of the communication network on the time lapse, Riverbed Modeler simulations were performed to calculate the time delays for transmission of certificates from EV to RSU.This heavily depends on the size of the packet that is transmitted.Therefore, certificate sizes obtained from OpenSSL implementations were inputted to Riverbed Simulations.All other  and thus, larger verification computational time and transmission time.Therefore, it can be concluded that ECDSA algorithm-based authentication results in lower certificate sizes and reduces overall time required for authentication in an EV communication environment.Similarly, as discussed above for the explicit certificate mechanism, the performance evaluation of implicit mechanism was carried out with Python and Riverbed Modeler implementations.ECQV is an implementation of implicit certificate mechanism, as discussed in Section 4.2.ECQV has reduced key size as compared to the X.509 certificate mechanism developed by RSA.For different elliptic curves of ECQV, implicit certificates were generated, and the computational time required for verification of certificate was calculated through Python implementations.Next, the certificate transmission time for different ECQV curves was obtained through the Riverbed Modeler simulations, as discussed for the explicit mechanisms.It is clearly evident from Tables 2 and 3 that curves with less key size generate smaller certificates and, consequently, result in smaller certificate transmission and computational times.Furthermore, it was noted that the ECQV curve 'secp256k1' gave the best time performance and provided optimum security.Since 'secp256k1' gave the best time performance and provided the same level of security as other curves, it turned out to be the most optimum solution for implementing certificate-based authentication.
It is observed from the obtained results that implicit certificate mechanisms for authentication are well suited to EV-RSU communications for functions such as charging management.Explicit certificate mechanisms with RSA and ECDSA algorithms need longer times for overall communication.They can still be used for many other network applications where vehicles travel slower, such as electronic toll collection points.For EV-CS communication, time performance is not crucial and either of the mechanisms can be implemented.

Conclusions
EVs are increasingly becoming popular due to environmental concerns.Their interaction with the power grid creates opportunities for better grid operation and more renewable energy use.Achieving this is dependent on providing a robust communication network between EVs and the infrastructure surrounding them.Smart city concepts make use of the increased connectivity and observability provided by V2V and V2I communication.
Security is the major concern in these VANETs.IEEE 1609.2WAVE specifies different security mechanisms for secure data transmission.This paper analyses the use of different certificate-based authentication mechanisms in VANETs, and studies their performances in realistic network traffic conditions.Performance calculations include the certificate transmission time and certificate verification time, leading to computation of total authentication time.In computing total authentication time, communication overheads of keys, CSRs, Certificates for different algorithms were considered.From the results it was observed that in both implicit and explicit certificate mechanisms, the curves with larger key sizes had slightly more computational time compared to curves with smaller key sizes.While explicit certificate mechanisms showed slow performance, implicit certificate-based authentication mechanism were found to be well-suited for EV-RSU and EV-EV communication.

Figure 1 .
Figure 1.WAVE protocol stack and different standards.

Figure 1 .
Figure 1.WAVE protocol stack and different standards.

Figure 5 .
Figure 5. Certificate verification of EV by road side unit (RSU).

Figure 6 .
Figure 6.Digital certificate hierarchy for verification.Figure 6.Digital certificate hierarchy for verification.

Figure 6 .
Figure 6.Digital certificate hierarchy for verification.Figure 6.Digital certificate hierarchy for verification.

Figure 7 .
Figure 7. Message exchanges for explicit certificate-based authentication process.

Figure 7 .
Figure 7. Message exchanges for explicit certificate-based authentication process.

Figure 9 .
Figure 9. Timing performance with OpenSSL implementation and Riverbed Simulations.

Figure 9 .
Figure 9. Timing performance with OpenSSL implementation and Riverbed Simulations.

Table 1 .
Authentication mechanisms in the literature.
defines multichannel operation that specifies extensions to the IEEE 802.11MAC layer protocol.IEEE 1609.3 defines networking services such as service advertisements, channel scheduling, and WAVE short message protocol (WSMP).IEEE 1609.2 defines security services for application and management of messages.
. IEEE 1609.4 defines multichannel operation that specifies extensions to the IEEE 802.11MAC layer protocol.IEEE 1609.3 defines networking services such as service advertisements, channel scheduling, and WAVE short message protocol (WSMP).IEEE 1609.2 defines security services for application and management of messages.
illustrates this verification process.
Vehicle CredentialsFigure 5. Certificate verification of EV by road side unit (RSU).

Table 2 .
Computational times for explicit certificate verification with different key sizes of RSA and ECDSA.

Table 3 .
Computational times for ECQV implicit certificate verification for authentication.