Badis Hammi
email: badis.hammi@epita.fr

Jean-Philippe Monteuuis
email: jmonteuu@qualcomm.com

Jonathan Petit
email: petit@qualcomm.com

PKIs in C-ITS: security functions, architectures and projects: a survey

Keywords: Terms-Certificate, ETSI, IEEE, Intelligent Transportation Systems, Privacy, Public Key Infrastructure, Security

In the smart cities context, Cooperative Intelligent Transportation Systems (C-ITS) represent one of the main use cases that aim to improve peoples' daily lives. Within these environments, messages are exchanged continuously. The latter must be secure and must ensure users' privacy. In this regard, Public Key Infrastructures (PKIs) represent the major solution to meet security needs. In this work, we present a holistic survey that describes all the different functions and services of a C-ITS PKI and focus on the different standards and consortia works that have been adopted to regulate such PKIs. Relying on the survey, we highlight the main research problems and open challenges for ITS PKIs. Then, we propose a generic model for a C-ITS PKI architecture.

I. INTRODUCTION

In the current smart cities context, Cooperative Intelligent Transportation Systems (C-ITS) represent one of the main use cases that aim to improve peoples' daily life [1]. A C-ITS is primarily composed of vehicles (called Intelligent Transportation System's Station-Vehicle (ITSS-V) in the C-ITS context) 1 and road side infrastructure (Intelligent Transportation System's Station-Road Side Unit (ITSS-R)) 2 , and a traffic management centre.

C-ITS technologies aim at increasing road safety, efficiency and comfort by sensing, communicating, deciding, and acting based on the surrounding road environment. As Figure 1 shows, there are numerous types of communication modes (mainly ad hoc communications) like (1) Vehicle-to-Vehicle (V2V) mode, (2) Vehicle-to-Infrastructure (V2I) mode and (3) Vehicle-to-Pedestrian (V2P) mode. In the remainder of this paper, we define this set of vehicular communication modes as Vehicle-to-Everything (V2X) communication.

C-ITS components communicate using wireless communication standards/protocols that will determine the various aspects of communication such as data transmission range and rate, latency and security. Data delivery is considered among the key challenges due to the fast topology change, frequent signal disruptions, and contact opportunities of stations [2]. In C-ITS context, multiple networking technologies can be used 1 In the remaining of this paper, we use the terms vehicle, node, and ITSS-V to refer to a connected vehicle. 2 In the rest of this paper, we use the terms RSU and ITSS-R interchangeably to refer to a connected road side unit. according to the scenario and the deployment constraints and policies [3]. Indeed, along the use of cellular networks for some specific scenarios, two main vehicular communication standards using the specially allocated 5.9GHz unlicensed band have emerged in recent years: (1) Dedicated Short-Range Communications (DSRC) protocol developed in the US [4] and (2) the Intelligent Transportation System (ITS)-G5 protocol developed by the European Telecommunications Standards Institute (ETSI) [START_REF] Ribal F Atallah | Vehicular networking: A survey on spectrum access technologies and persisting challenges[END_REF]. These standards are based on the IEEE 802.11p access layer developed for vehicular networks. A competing alternative commonly called C-V2X has recently emerged with the introduction of Proximity Services (ProSe) in 3GPP LongTerm Evolution (LTE) Release 14 and evolved in Release 15 [START_REF] Molina | Lte-v for sidelink 5g v2x vehicular communications: A new 5g technology for short-range vehicle-to-everything communications[END_REF]. The latter has been designed to satisfy bounded low latency requirements and accommodate a given levels of density of vehicles for V2X communications combined with the support of high speed [3]. Within a C-ITS, large amounts of data are continuously exchanged in order to ensure proper functioning of the different C-ITS applications. In ETSI-based infrastructures/projects, ITSS-Vs use Cooperative Awareness Messages (CAM) and Decentralized Environmental Notification Messages (DENM). In IEEE-based projects, ITSS-Vs use Basic Safety Messages (BSM). As an example of the importance of these messages, BSM has the potential to prevent up to 75% of all roadway crashes according to [START_REF] Whyte | A security credential management system for v2v communications[END_REF] and [START_REF]Vehicle-to-Vehicle (V2V) Communications for Safety[END_REF]. Thus, the correctness and reliability of the exchanged messages have a direct impact on the efficiency and effectiveness of the deployed applications. Moreover, due to their spatio-temporal nature, broadcast messages must be protected such that to protect users' privacy. For these reasons, most of the exchanged messages must be secured.

In order to handle these security requirements, multiple mechanisms were proposed [START_REF] Gilles Engoulou | Vanet security surveys[END_REF], and the most common solution is the use of a Public Key Infrastructure (PKI). A PKI represents a set of authorities and protocols that binds public keys with respective identities of entities. The binding is established through a process of registration and issuance of cryptographic materials. Thus, a PKI creates, manages, distributes, uses, stores, and revokes these security credentials [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF].

C-ITS PKIs are very different from traditional Information Technology (IT) systems' PKIs. Indeed, in traditional IT systems, PKI implementations follow the same schema. They only differ in the size and the hierarchy depth. However, due to C-ITS security requirements, a C-ITS PKI comprises other authorities, and can be implemented through different architectures. Consequently, there exists multiple proposals and implementations of C-ITS PKIs.

A. Related work and motivations

In this section we highlight the need for a survey on PKIs in C-ITS. Indeed, a search of the major scientific databases IEEE, ACM, Elsevier and others, reveals the lack of a survey devoted exclusively to the topic of PKIs in C-ITS, their architectures, their security functions and how the different projects used them. In the following, we describe the related works in the area of C-ITS security. We classify them according to their contribution similarity, and demonstrate that they do not treat PKIs or consider them as a blackbox and not as a research topic. Hence, the need for a holistic survey dedicated to C-ITS PKI.

Security in C-ITS and Vehicular Ad-hoc Networks (VANET) have been extensively studied over the last years. Numerous surveys such as [START_REF] Gilles Engoulou | Vanet security surveys[END_REF], [START_REF] Patil | Survey of privacy preservation in vanets[END_REF]- [START_REF] Nidhal Mejri | Survey on vanet security challenges and possible cryptographic solutions[END_REF] studied and discussed security issues and challenges in C-ITS environments as well as possible cryptographic solutions. Almost all studies agreed that network size, trust and information verification, key distribution, anonymity, privacy and liability are the top security challenges. They also agreed that authentication, confidentiality, integrity, privacy, data verification and revocability are the security requirements in VANETs. In the same context, Sumanth et al. [START_REF] Sumanth | A survey on security in vanets and applications[END_REF] focuses on the security challenges and solutions at the application level.

In order to address the aforementioned challenges and to ensure the security requirements needed, multiple protocols and frameworks were proposed, e.g., [START_REF] Wasef | Emap: Expedite message authentication protocol for vehicular ad hoc networks[END_REF]- [START_REF] Javaid | Driv-Man: Driving trust management and data sharing in VANETS with blockchain and smart contracts[END_REF]. Multiple surveys were conducted to analyse the different security solutions proposed over the literature. For instance, [START_REF] Sunilkumar | A survey on authentication schemes in vanets for secured communication[END_REF]- [START_REF] Afzal | Security of vehicular Ad-hoc networks (VANET): A survey[END_REF] provided a detailed description and a taxonomy of authentication schemes, and discussed their mechanisms, advantages, disadvantages and performance. Dahiya et al. [START_REF] Dahiya | A survey on securing user authentication in vehicular ad hoc networks[END_REF] surveyed various user authentication protocols in VANETs and described the efficiency of user verification algorithms. Also, [START_REF] Christilda | Reconstruction of a secure authentication scheme for vehicular ad hoc networks[END_REF]- [START_REF] Studer | TACKing together efficient authentication, revocation, and privacy in vanets[END_REF] provided a quick description of authentication techniques and protocols. In [START_REF] Riley | A survey of authentication schemes for vehicular ad hoc networks[END_REF], Riley et al. provided a survey and categorization of authentication mechanisms in VANETs according to three criteria: asymmetric, symmetric, and infrastructure requirement, in order to identify their suitability under various conditions. [START_REF] Zhang | A survey on trust management for vanets[END_REF] discussed the challenges for trust management caused by the highly dynamic nature of VANET environments. Then, the authors analyzed the existing trust models and summarized their key issues. They identified decentralization, sparsity, scalability, confidence, security, privacy and robustness as key properties that a trust management system should incorporate. However, this study focused on multi-agent based approaches. [START_REF] Vaibhav | Security challenges, authentication, application and trust models for vehicular ad hoc network-a survey[END_REF], [START_REF] Ali | Authentication and privacy schemes for vehicular ad hoc networks (VANETs): A survey[END_REF] also surveyed trust models and provided the same conclusions as [START_REF] Zhang | A survey on trust management for vanets[END_REF].

[50]- [START_REF] Sharma | A detailed tutorial survey on VANETs: Emerging architectures, applications, security issues, and solutions[END_REF] identified the requirements to secure VANETs. [START_REF] Wasef | Complementing public key infrastructure to secure vehicular ad hoc networks [security and privacy in emerging wireless networks[END_REF] argued that PKI is the most viable solution to secure them. Furthermore, it pointed out some PKI's limitations such as location privacy and revocation delays. Finally, it introduced a set of mechanisms to mitigate revocation problem through distributed and fine grained revocation. Khandelwal et al. [START_REF] Jawandhiya | Safe geo graphic location privacy scheme in the vanets-survey methods and its limitation[END_REF] surveyed location privacy problem and the limitation of proposed approaches. [START_REF] Singla | A survey on data routing and security aspects in vanets[END_REF], [START_REF] Nirav | Trust based approaches for secure routing in vanet: A survey[END_REF] surveyed various mechanisms to improve different ad-hoc routing protocols for secure routing process by enhancing the trust among the different nodes in VANETs. They proposed PKI as a possible option rather than past interaction experience based approaches [START_REF] Singla | A survey on data routing and security aspects in vanets[END_REF], incident reports based approaches [START_REF] Liao | A trust model for vehicular network-based incident reports[END_REF], symmetric cryptography based approaches [START_REF] Wang | Countermeasure uncooperative behaviors with dynamic trust-token in vanets[END_REF] or the use of public cryptography without certificates [START_REF] Biswas | Id-based safety message authentication for security and trust in vehicular networks[END_REF] . In [START_REF] Li | A survey on data dissemination in vanets[END_REF], [START_REF] Kiruthika | A survey on security based data dissemination for vanets[END_REF] authors surveyed security problems and threats regarding data dissemination. They also discussed different solutions and trust-based approaches to ensure data dissemination in VANETs.

[63]- [START_REF] Islam | A Comprehensive Survey on Attacks and Security Protocols for VANETs[END_REF] focused on security and privacy issues and cyberattacks in VANET. They also discussed some proposed solutions. But, did not focused on PKIs.

[72], [START_REF] David Antolino Rivas | Security on vanets: Privacy, misbehaving nodes, false information and secure data aggregation[END_REF] discussed privacy of VANET data aggregation techniques and concluded that PKI and pseudonym certificates are the best ways to achieve this goal. Also, Gupta et al. [START_REF] Gupta | Apda with data collective: A survey to prevent attacks in vanet[END_REF] surveyed approaches that rely on data aggregation to ensure security features using the data collected. But, did not focused on PKIs.

[75] provided a quick description of some frameworks that ensure encryption and authentication of nodes in a VANET environment and proposed Signcryption Message Authentication Protocol (SMAP), which combines digital signature and encryption functions. [START_REF] Ibrahim | A comparison on vanet authentication schemes: Public key vs. symmetric key[END_REF] presented a comparison of asymmetric-based and symmetric-based encryption solutions in a VANET context regarding average loss ratio, communication overhead ratio and traffic load. However, no details about the algorithms studied were given. [START_REF] Whaiduzzaman | A survey on vehicular cloud computing[END_REF] surveyed vehicular clouds and described how a PKI can ensure C-ITS security requirements.

Petit et al. [START_REF] Petit | Pseudonym schemes in vehicular networks: A survey[END_REF] focused on the pseudonymity requirements. Van Huynh et al. [START_REF] Van Huynh Le | Security and privacy for innovative automotive applications: A survey[END_REF] investigated the main security and privacy challenges for the design of automotive applications and platforms. Then, they reviewed existing protection mechanisms. However, none of these works discussed PKI architectures.

Despite the large body of literature on C-ITS security, there is so far no comprehensive survey specifically on vehicular PKIs. Table I summarizes the majority of the existing related surveys. It is worth noting that the existing works are mainly focused on academic research, and do not discuss or analyze standards and consortia efforts. This is a significant gap we propose to fill in order to help adoption and deployment of C-ITS. Finally, none of the existing works is interested in the different PKI architectures, standards, deployment projects and the certificates lifecycle such as the certificate's request mechanisms, intra PKI trust mechanisms and so on. To the best of our knowledge, the only works that were interested in standardization works and consider PKI as a set of functions and not as a blackbox tool are [START_REF] Hasrouny | Vanet security challenges and solutions: A survey[END_REF] [80] and [START_REF] Van Huynh Le | Security and privacy for innovative automotive applications: A survey[END_REF]. However, [START_REF] Hasrouny | Vanet security challenges and solutions: A survey[END_REF] only introduced Security Credential Management System (SCMS) PKI [START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF], since, its main contribution is the proposal of a new taxonomy of the different attacks.

In summary, our paper is carefully positioned to avoid overlap with existing surveys by filling the gaps and reporting the latest advances regarding C-ITS PKI. However, in this work, we do not perform a formal safety analysis.

B. Contributions of this work

This survey is intended for researchers from industry and academia interested in the field of privacy and security man-agement in C-ITS which will provide them with a good understanding of such an ecosystem. To the best of our knowledge, this is the first survey that analyses standards and consortia work related to C-ITS PKI architectures. We highlight the contributions of this paper as follows:

• We provide an extensive survey of the different PKI architectures used in C-ITS environments and deployment projects.

• We provide an extensive survey of the different privacy management/lifecycles in the C-ITS environments.

II. PUBLIC KEY INFRASTRUCTURE REQUIREMENTS

In this section, we describe the requirements needed for PKIs in the C-ITS domain. We present the requirements according to three categories as highlighted in Table II: • Organizational requirements The policy enforcement aims to foster the interoperability between the organizations involved in the C-ITS PKI, as well as the technical and legal supervision of the PKI. Indeed, a PKI requires the cooperation of dozens of organizations such as internal and national governmental agencies, car manufacturers, road operators, suppliers, IT and security solution providers. This cooperation has its pros and cons. Indeed, in order to ensure the cooperation resilience, all the involved organizations must meet a minimal set of requirements, which are defined in a set of documents (e.g., certificate policy, security policy).

2) Flexibility: Each organization must fulfill different levels and ranges of requirements. For instance, governmental agencies do not have to ensure the constant technical availability of the PKI services, but will focus on the policies used by the PKI. Moreover, a national organization might prefer the use of security algorithms recommended by its national security agency instead of other security algorithm. Therefore the PKI requirements need to be flexible while ensuring security and performance.

3) Interoperability: The PKI must be interoperable between the different organizations involved. In the following, we consider a geographical taxonomy: (1) at the national level, an ITSS manufacturer can choose a security supplier different from his national competitor. However, the two security solutions must interface with each other. A common standard for the country forces suppliers to be interoperable, making the different ITSS produced by the different manufacturers communicate with each other. (2) at international level, an ITSS entering a foreign country, must be interoperable with local ITSS and with local PKI. Indeed, an ITSS of a foreign country, will probably use certificates provided by another PKI. If no interoperability between different ITSSs and between PKIs is supported, the messages sent by foreign ITSS will not be accepted, which implies a deny of the C-ITS services. Thus, it is mandatory that international organizations must find common requirements. For example the European projects C-Roads and InterCor [START_REF]An overview of harmonised C-ITS deployment in Europe[END_REF] used the mechanism of Trusted Status List (explained in more details in Section VI-B) in order to ensure this interoperability of ITSS and PKIs among the different participating countries in Europe.

4) Naming convention: The C-ITS PKI should support a standard naming convention. Indeed, there will be millions of entities used in the C-ITS ecosystem that need to be identified. Without a naming convention, numerous problems can occur, e.g., the collision of identifiers.

5) Legacy support: The PKI must ensure legacy support. That is, it must allow an ITSS working with an ancient version of one or more components of the ecosystem (e.g., certificate, secured message format) being able to communicate in order to update its version and thus comply with the C-ITS ecosystem.

6) Scalability: The number of ITSS is continuously increasing. Therefore, the PKI that manages them must be scalable to ensure system's continuity and operation. Moreover, the C-ITS PKI rely on multiple organizations. One difficulty is to manage all the organizations involved according to a scalability policy. Indeed, if there is no agreement on the scalability strategy, the divergent organizations may jeopardize the organizational system of the PKI.

7) Hierarchical organization:

A PKI by definition is hierarchical [START_REF] Jancic | Pki-advantages and obstacles[END_REF] due to the different trust levels and responsibilities of the authorities. Also, due to the increasing number of ITSS it must be scalable. However, a high level of hierarchy limits scalability because some services (e.g., authorities) can represent a bottleneck and a single point of failure. Therefore, C-ITS PKIs must find a tradeoff between hierarchy and decentralization.

B. Security requirements

C-ITS security requirements have been largely studied and discussed in literature [START_REF] Mishra | Security in vehicular adhoc networks: a survey[END_REF], [START_REF] Nidhal Mejri | Survey on vanet security challenges and possible cryptographic solutions[END_REF], [START_REF] Riley | A survey of authentication schemes for vehicular ad hoc networks[END_REF], [START_REF] Zhang | A survey on trust management for vanets[END_REF], [START_REF] Petit | Pseudonym schemes in vehicular networks: A survey[END_REF]. Thus, in the following we will not focus on their description, but on how, the most important ones, are accomplished.

1) Confidentiality: Some C-ITS applications require that the content of a message must be accessible only by the sender and the receiver. Confidentiality is performed through encryption [START_REF] Alfred J Menezes | Handbook of applied cryptography[END_REF]. Due to C-ITS environment features, only few types of messages are encrypted. Indeed, C-ITS environment is characterized by the high speed of nodes (e.g., vehicles). Therefore, in order to achieve an efficient service, the processing of messages must be fully optimized. For example, messages' encryption induces to additional processing costs and is avoided as much as possible. Nonetheless, encryption still be mandatory for some scenarios, such as for certificate requests for example [START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF] [START_REF]IEEE Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages[END_REF].

Symmetric-key encryption field was extensively studied and many algorithms were developed. [START_REF] Daemen | The design of Rijndael: AES-the advanced encryption standard[END_REF]- [START_REF] Daemen | The block cipher rijndael[END_REF]).In C-ITS, the [START_REF] Slagell | A survey of PKI components and scalability issues[END_REF]. In order to address this issue, asymmetric cryptography was proposed.

Public key cryptography area was extensively studied and numerous algorithms were proposed, e.g., Rivest-Shamir-Adleman (RSA) [START_REF] Ronald L Rivest | A method for obtaining digital signatures and public-key cryptosystems[END_REF]-[102] which represents the most widely deployed public key cryptosystem [START_REF] Boneh | Fast variants of RSA[END_REF], El-Gamal [START_REF]A public key cryptosystem and a signature scheme based on discrete logarithms[END_REF], Elliptic Curve Cryptography (ECC) algorithms [START_REF] Lopez | An overview of elliptic curve cryptography[END_REF] [106]. In C-ITS environments, only elliptic curve based asymmetric algorithms are used. More precisely, the Elliptic Curve Integrated Encryption Scheme for encryption [106]- [START_REF] Víctor | Analysis of ecies and other cryptosystems based on elliptic curves[END_REF] and Elliptic Curve Digital Signature Algorithm for signature [START_REF] Johnson | The elliptic curve digital signature algorithm (ECDSA)[END_REF] [106].

Elliptic curve cryptography (ECC) was introduced by Victor Miller and Neil Koblitz in 1985 [START_REF] Koblitz | Elliptic curve cryptosystems[END_REF] [START_REF] Victor | Use of elliptic curves in cryptography[END_REF]. The aim was to create an alternative mechanism for public key cryptography. ECC is based on the elliptic curve discrete logarithm problem. The advantage of such algorithms is that they require smaller keys compared to other algorithms such as RSA, in order to provide equivalent security. A shorter key implies lesser powerful hardware, easier data management and storage and a longer battery life in devices. authentic. The integrity ensures that the information exchanged are not altered between sender and receiver, and the non repudiation ensures that a station cannot deny having sent a message (e.g a wrong warning).

All the described requirements are fulfilled using signature algorithms which rely on cryptographic hash functions. Hash functions are primarily used to insure messages' integrity. Hash functions are combined with encryption functions in order to provide digital signatures. A digital signature is a mathematical scheme that proves the sender's authentication, message's integrity and non repudiation.

IEEE, ETSI and ISO ITS standards require the sole usage of Elliptic Curve Digital Signature Algorithm (ECDSA) for digital signature. ECDSA [START_REF] Hankerson | Guide to elliptic curve cryptography[END_REF] is the elliptic curve analogue of the DSA algorithm. It was first proposed by Scott Vanstone in 1992 [START_REF] Rivest | Responses to NIST's Proposal[END_REF]. It was accepted in 1998 as an ISO standard in ISO/IEC 14888 [START_REF]Information technology -Security techniques -Digital signatures with appendix -Part 3: Discrete logarithm based mechanisms[END_REF], accepted in 1999 as an ANSI standard in ANSI X9.62 [START_REF]X9.62[END_REF], and accepted in 2000 as an IEEE standard in IEEE 1363-2000 [START_REF]Ieee standard specifications for public-key cryptography[END_REF] [118] and a FIPS standard in FIPS 186- [START_REF] Bi | The performance analysis of two digital signature schemes based on secure charging protocol[END_REF]. It is worth to note that ECDSA have shorter keys and better signature generation time. However, it takes more time to verify a signature compared to DSA.

3) Privacy and Pseudonymity: ITSS diffuse periodically messages which contain -among others-information about their position and localization. Using these information, an attacker can track the station or create detailed mobility patterns of individual drivers [START_REF] Petit | Pseudonym schemes in vehicular networks: A survey[END_REF]. This problem can be addressed by providing a vehicle with a set of pseudonyms, where it uses each pseudonym for a limited duration. More precisely, [124] recommends that this is done every 120 seconds or 1 km, whichever occurs last. For example in SCMS project, an ITSS uses more than 1000 PCs per year [START_REF] Whyte | A security credential management system for v2v communications[END_REF] and this number can even reach 100000 according to [START_REF] Kumar | Special Cryptographic Primitives in SCMS[END_REF]. In SCOOP@F project an ITSS uses 520 PCs per year [START_REF]Security system: Integration guide v4[END_REF].

During one journey, an ITSS can change many times its PC. However, due to C-ITS communication constraints, like vehicles' speed and the use of wireless technologies (e.g., ITS-G5/802.11p), an ITSS can not always successfully realize a PC request. To resolve this problem, the common solution is to preload multiple certificates and to store them locally. Then, when an ITSS needs to change its PC, it draws from its stock of preloaded PCs.

4) Authorization: In C-ITS context, authorization requirement is the process of giving an entity the permission to access some services, to receive some information or to diffuse some information.

Generally, the set of these permissions is included in the station's certificate. More precisely, the ITS certificates include one (or more) field called Service Specific Permissions (SSP) [127] [128] [89], which represents the list of the services that the station is authorized to access and use. For example, an ITSS can have the permission to broadcast a message that informs about an accident, thus, it has the SSP for it, but, cannot broadcast a message that informs about an animal on the road because it has not the suitable SSP for it. Figure 3 describes the consistency conditions to be checked by the security services before the acceptance of a packet (Secured Protocol Data Unit (SPDU)).

C. Performance requirements 1) Availability and real time Operation: The availability implies that the PKI and its services must be accessible to legitimate users on demand. Thus, a system must be resilient Fig. 3: Consistency conditions to be checked by the security services [START_REF]Service Specific Permissions and Security Guidelines for Connected Vehicle Applications[END_REF] against availability targeting attacks such as denial of service. Moreover, the operation must be in real time to insure the system's resiliency and freshness.

2) Upgradeability: It represents the capability of being improved in functionality by the addition or replacement of components. Therefore, the PKI must easily support to add or to modify one or a set of new services or components (e.g., authority) if there is a need for it.

D. Summary

The Table VII summarizes the different algorithms and mechanisms used to ensure the main communications' security requirements described above, in the C-ITS context for the different standards and deployment projects. The different cryptographic operations and algorithms descried above rely on cryptographic keys. Most of these keys are provided to the different entities as part of public key certificates. In the next section, we focus on C-ITS public key certificates.

III. PUBLIC KEY CERTIFICATES

Web PKIs manage X.509 certificates [START_REF] Cooper | RFC 5280: Internet X. 509 Public Key Infrastructure Certificate and CRL profile[END_REF]. However, C-ITS PKIs manage specific C-ITS public key certificates 4 . The latter are designed to respond to the constraints of C-ITS ecosystems. In this section we present and describe the formats and structures of ITS certificates for both IEEE and ETSI standards.

1) IEEE1609V2 certificate: IEEE 1609.2 [START_REF]IEEE Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages[END_REF] is a security standard for C-ITS PKI. The standard introduces a new certificate format. The latter supports two forms: explicit and implicit. Figure 4 depicts their formats.

Explicit certificate is the conventional certificate format. In contrary to implicit certificate, it includes a verification public key and a digital signature computed by the certificate issuer. Thus, one can authenticate the certificate owner's identity by verifying the certificate's signature.

Vanstone et al. [START_REF] Daniel | Provably secure implicit certificate schemes[END_REF]- [START_REF] Daniel Rl Brown | Security of ecqv-certified ecdsa against passive adversaries[END_REF] proposed implicit certificate use and its enhancement against attacks. It differs from explicit certificate format by not including the complete public key. Instead, it contains a partial key value called reconstruction value. The acquisition of the implicit certificate's public key value requires a computation that involves its reconstruction value and the CA's public key.

IEEE 1609.2 implicit certificate uses Standards for Efficient Cryptography (SEC 4) Elliptic Curve Qu-Vanstone (ECQV) scheme [134]. The latter suits resources' constrained environments such as C-ITS limited bandwidth, computation power or storage space [START_REF] Vaidya | Security mechanism for multi-domain vehicle-to-grid infrastructure[END_REF]. It represents an efficient alternative to traditional certificates. Indeed, the use of an implicit certificate does not require explicit CA signature verification.

A generic IEEE certificate contains the following fields: Version: specifies the certificate's version value. Currently, it is set to 3 [START_REF]IEEE Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages[END_REF]. Type: defines the certificate's format such as implicit or explicit. Issuer identifies the certificate's issuer. ToBeSigned contains the fields covered by the issuer's signature, it includes:

• Certificate ID: represents an identifier for the certificate's holder. The assurance level will serve as a reputation metric to ensure the node's trustworthiness regarding the messages and their content (data allowance).

It also can be used by misbehavior trust mechanisms in order to manage misbehaving nodes [START_REF] Whyte | A security credential management system for v2v communications[END_REF]. • App permissions: defines a sequence of PSID/SSP associations. A PSID specifies permitted application area. An SSP authorizes the sender to perform specific "application activities" within the associated PSID application area. • Cert issue permissions: are application permissions (combination of PSID-SSP) that the CA can issue to subordi- Version specifies the certificate's version value based on standard version number. Currently, this value is set to 3. Signer info: contains the certificate's issuer information which can be:

• Self: the owner self-signs its certificate.

• Certificate digest with SHA256: the issuer's identity is presented by the first 8 bytes of the issuer's certificate's SHA256 digest. • Certificate: the issuer's identity is the entire issuer's certificate value.

Subject attributes: contains multiple technical fields:

• verification key: represents the certificate public key used for signature. • encryption key: represents an optional public key used for encryption. • reconstruction value is an EC point used in ECQV scheme. Used by the implicit certificate type as for the IEEE certificate described above. • assurance level: scores both ITS platform and secret keys storage security as well as the confidence in this assessment.

• its aid list: contains the authorized applications list of the certificate's owner. It has the same role as PSID in IEEE certificate. For instance, the ITSS AID list authorizes the ITSS to send Decentralized Environmental Notification Messages (DENM). • its aid ssp list is a list of ITS AID and their Service Specific Permissions (SSP). The latter represent the authorized cases and scenarios. For instance, an ITSS having the AID DENM and the SSP On Road Accident allow an ITSS to send DENM On Road Accident message. However, it could not send a DENM construction site without the proper SSP.

Validity restrictions: specifies the restrictions regarding to the certificate's validity. A certificate includes a time validity restriction and sometimes a region validity restriction (e.g., a country). A restriction type can be:

• time end: represents the certificate's expiration date.

• time start and end: describes the certificate's beginning and expiration date. • time start and duration: represents the certificate's beginning date and the certificate's validity duration; • region: represents the certificate's geographical validity.

It includes multiple forms such as "Circular Region", "Rectangular Region", "Polygonal Region" or a "country code" as described by ISO 3166-1 [138].

Signature: represents the certificate's signature value signed by the issuer. If the Subject Attributes field contains the type reconstruction value. Then, the signature field is omitted.

3) Summary: X.509 certificate has a detailed and complete structure. However, it is not adapted to C-ITS due to numerous constraints such as the limited bandwidth and numerous different fields needed by the C-ITS environment compared to web infrastructures, which incurs the need for lighter certificates [START_REF] Bißmeyer | A generic public key infrastructure for securing car-to-x communication[END_REF]. Therefore, IEEE and ETSI standards have proposed new C-ITS certificate structures. Aforementioned certificates descriptions show numerous similarities between the standards. Moreover, current standardization efforts try to propose a common format for ITS certificates. Indeed, the last ETSI certificates are based upon IEEE ASN.1 defined structures [89].

As described above, the management of public key certificates require a Public Key Infrastructure (PKI). While web X.509 PKIs have a common hierarchical structure, C-ITS PKIs are very different. Moreover, because C-ITS standards describe only high level PKI architectures, numerous projects have designed and deployed different PKIs according to their needs. Therefore, in the next section we describe the different PKI architectures and highlight their deployment projects.

IV. COOPERATIVE ITS PKI ARCHITECTURES

In this section we describe different PKI architectures that belong to different standards and deployment projects. Each PKI is composed of a set of authorities. Some authorities are common to almost all the existing projects. However, they may have different additional functions.

A. Summary

Table VIII provides a summary of the different PKI projects discussed above. It presents the different PKI authorities for each project and their associated names. Some authorities exist in every project such as the trust anchor authority, the enrollment authority or the pseudonym authority. On the contrary, some entities can be unique or very specific to a project e.g. linkage authority for SCMS and SCME. Table VIII also allows to understand the list of all certificate types found in the different PKI architectures designed for the different projects and allows to identify the different existing certificate profiles for each PKI project and the respective names as mentioned in the specification documents. For instance, an enrollment certificate exists in all project. However, its given name can be different e.g. Long Term Certificate in SCOOP@F and Enrollment Certificate in SCMS.

It is worth noting that the majority of the projects presented are only experimental projects. Only SCMS, EU CITS and SCME will be deployed on the field involving citizens. However, because some of them were pilot projects, and because we wanted a holistic survey on the PKI standards and projects, we presented them in this work. -SDE-CA; -SDE-Enrolment : used by an entity to request new certificates; -SDE-Identified-Localized: used by the SDEE in order to secure its communications (also called communication certificate); -SDE-Anonymous: do not own any identity information about the owner. Their usage ensure anonymity and no tracking of the owner [START_REF] Petit | Pseudonym schemes in vehicular networks: A survey[END_REF]; -CRL-Signer: The CRL Signers are CRLs distribution centers, which represent entities that store and distribute certificates revocation lists (CRLs).

• WAVE Service Advertisements (WSA) CAs: WSA-CAs issue certificates to end entities that broadcast WSAs in order to advertise specific set of services e.g., log upload. 2) End Entities: All other entities that use IEEE certificates, but cannot issue certificates or CRLs, are end entities. There are defined two types of end entities: Secure Data Exchange Entity (SDEE) and Secure Provider Service Entity (SPSE). End Entities include ITSS-V, ITSS-R, application servers and software applications.

For the user's privacy protection, the IEEE 1609.2v2 standard defines anonymous certificates issued by the Root CA or SDE-CA to SDEEs. The IEEE 1609.2v2 anonymous certificates are communication certificates without identification information.

Figure 6 describes a generic IEEE PKI architecture. Multiple projects adopt this architecture as the rest of this section shows.

C. ETSI PKI architecture

The ETSI ITS Technical Committee Working Group 5 is responsible for the ITS security architecture, providing security standards as well as guidance on the use of security standards. ETSI TS 102 940 [140] and ETSI TS 102 941 [90] [141] standards specify a security architecture and the trust and privacy management for ITS communications. They identify:

(1) functional entities required to support security in an ITS environment; (2) relationships that exist between the entities themselves and the elements of the ITS reference architecture; Fig. 6: IEEE generic PKI architecture [START_REF]IEEE Standard for Wireless Access in Vehicular Environments-Security Services for Applications and Management Messages[END_REF] and (3) roles and locations of a range of security services for the protection of transmitted information and the management of essential security parameters. The latter include identifier and certificate management, PKI processes and interfaces as well as basic policies and guidelines for trust establishment.

In order to provide communications' security between ITSSs, a range of security services are available. Indeed, different categories of security services are defined such as enrollment, authorization, integrity, plausibility and validation. Security services are provided on a layer-by-layer basis, such that, each service operates within one or several ITS architectural layers, or within the security management layer of the communication stack.

Communications' security services require numerous components to ensure their functional model:

• Enrollment Authority: authenticates an ITSS and grants its access to ITS services and communications. • Authorization Authority: provides an ITSS with authoritative proof that it may use specific ITS services. The documents also presents the ITS security reference points through which information are exchanged, the types of information carried across these security reference points (CAM, DENM, authorization parameters, request for permissions and so on), and security services that each security reference point supports.

It is necessary for an ITSS to get/provide a secure access to common resources such as services, information and protocols. These security requirements can be separated into two parts: external security and internal security. External security represents the security related to the behavior of the ITSS as a communication end-point, while internal security represents the security related to the ITSS as a processing platform and application host.

ITS communication system relies on indirect trust relationships built upon certification ensured by trusted third parties such as the Enrollment Authority (EA). EA allows an ITSS to be a part of the ITS communications by providing access control and permissions. The described standards [90],

[140], [141] explain how ITS communications should support trust, privacy, access control, and confidentiality regarding ITSSs: (1) trust is supported by provisioning ITS stations with certificates allowing it to assert their permission to use the ITS system and to use specific ITS services and applications.

(2) privacy is supported by using pseudonyms that can be used to replace a more meaningful and traceable identifier. (3) access control is ensured by giving ITSSs cryptographically signed certificates from the Authorization Authority (AA), which allows it to use specific services, or send particular information. (4) confidentiality of transmitted information in a unicast communications is protected by the encryption of messages within an established security association.

Security features are ensured by a PKI composed of an Enrollment Authority, Authorization Authority and a Root CA, and used for distribution and maintenance of trust relationships between ITSSs and authorities or other ITSSs as Figure 7 describes. Root CA: issues certificates to all other Certificate Authorities. It is the root of trust for all certificates within the hierarchy. All certificates immediately below the root certificate inherit the trustworthiness of the root certificate. In order to trust an incoming message, an ITSS must have access to the root certificate at the summit of the hierarchy for the authorization certificate attached to the message.

Enrollment Authority: the EA issues a proof of identity to authenticate the canonical identifier of the ITSS by delivering an Enrollment Certificate (EC). This proof of identity allows to not revealing the canonical identifier to a third party and may be used by the ITSS to request authorization of services from an Authorization Authority.

Authorization Authority: having received the enrollment credentials, the ITSS requests its authorization certificate(s) from the AA. These certificates allow the ITSS to have specific permissions. The separation of enrollment and authorization is an essential component of privacy management.

The ITSS security lifecycle begins with the manufacture phase, and passes to the enrollment phase, authorization phase and maintenance phase as Figure 8 shows. (1) at the manufacture phase multiple information elements are established in the ITSS. The main elements are:

• canonical identifier.

• contact information for EA and AA: network addresses and public key certificates. • the set of current known trusted EA and AA that an ITSS may use/request to initiate the enrollment process and trust communications from other ITSS respectively. • a canonical public/private key pair for cryptographic operations.

(2) at the enrollment phase, the ITSS requests its enrollment certificate from the EA. (3) at the authorization phase, having received the enrollment credentials, the ITSS requests its authorization certificates from the AA. ( 4) finally, at the maintenance phase, the ITSS will be informed with any changes in EA and AA lists (adding or removing of authorities). The maintenance phase also includes the ITSS certificates renewal and update. Then, an overview of the ITS security architecture is presented. It includes sending ITSS, receiving ITSS and the ITS network. Connections, associations and interfaces between these three entities are also presented. After, the document presents the ITS authoritative hierarchy that the manufacturer, Enrollment Authority, and Authorization Authority builds. It gives also, the role of each of these entities, the different trust assumptions on which relies the security of an ITS system, and ITS security parameters' management such as identities and identifiers, and authorization and privacy with authorization tickets. The last part of the standard presents the ITS security services such as enrollment credentials, authorization tickets, security associations, single message services, integrity services, replay protection services, accountability services, plausibility validation, remote management and report misbehaving ITSS. As Figure 9 shows, the security working group of the C2C-CC defined the same PKI architecture as ETSI. However, names of ITS authorities are different. Long-Term certificate authority (LTCA): issues Long-Term certificates (LTCs) to ITSS. It provides suitable processes to associate an LTC to an ITSS, to revoke and to update it. For the provisioning of PCs, an efficient refill process is required, but it is sufficient for an ITSS to prove ownership of the private key of its LTC to acquire new pseudonyms. LTCs are valid for a longer time period and are dedicated to identify and authenticate the respective ITSS within the PKI and potentially other services, but they are never exposed to V2X communications for privacy reasons. Each ITSS has only one valid LTC at a time. Within a C2C PKI it is possible to have multiple LTCAs and because of the close relationship of LTCs to ITSS devices, C2C standard recommends that LTCAs are operated by entities that build or maintain the stations such as manufacturers or their suppliers [144].

Pseudonym certificate authority (PCA): issues Pseudonym Certificates (PCs). An ITSS have multiple valid PCs at the same time. These PCs are used for V2X communications and have to be changed frequently. A PC has a short lifetime and minimal information to preserve the privacy of the sender. Within a C2C-CC PKI it is possible to have multiple PCAs.

E. Security Credential Management System

In 2014, the National Highway Traffic Safety Administration (NHTSA) Department of Transportation (DOT) published a Request for Information (RFI) named Vehicle-to-Vehicle Security Credential Management System (V2V SCMS) [START_REF]Vehicle-to-Vehicle Security Credential Management System[END_REF]. The purpose of this RFI, is to seek responses concerning the establishment of an SCMS, security approaches for a V2V environment, and technical and organizational aspects of the SCMS. As conclusion, PKI system was selected as the security solution to adopt.

Further, in 2016, DOT and NHTSA, along with Crash Avoidance Metrics Partners (CAMP LLC) Vehicle Safety Communications 5 (VSC5) Consortium5 published parts of the SCMS Proof-of-Concept specification [START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF]. The latter extends the last RFI to V2I communications and consider RSU usage. [START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF] focus primarily on PKI description, the used certificates and their management.

SCMS PKI extends IEEE proposal and its entities are grouped into 4 classes: (1) Overall Management, (2) Registration and Enrollment, (3) Certificate Management, and (4) Misbehavior Management.

As Figure 10 describes, the SCMS PKI relies on multiple authorities called SCMS components and on ITSSs (ITSS-V and ITSS-R) called End Entities (EE). All EE own implicit type certificates in order to save storage space and over-theair bytes, while, all the SCMS component certificates are of explicit type [START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF].

Currently, there exist three Department of Transportation pilot projects that implement SCMS PKI in the U.S.: the New York City pilot 6 , the Wyoming pilot 7 and the Tampa-Hillsborough Expressway Authority pilot 8 . The aforementioned projects are part of the Connected Vehicles Pilots Deployment Program that the USDOT launched. It seeks to combine connected vehicle and mobile device technologies in innovative and cost-effective ways to improve traveler mobility and system productivity, while reducing environmental impacts and enhancing safety.

1) Certificates: According to its type, an ITSS can have multiple certificates of different types; enrollment, pseudonym, application, identification and many other.

ITSS Enrollment Certificate: it serves as the main identification document of the ITSS. It helps to identify the ITSS during the request of other certificates. Each ITSS owns only one Enrollment Certificate, provided during the initialization phase (called bootstrap process in SCMS context). It has a long validity period. Generally, equal to the operational lifetime of the ITSS-V. Nonetheless, it can be revoked by the Registration Authority through the use of its internal blacklist. It includes also an SSP list that defines the authorized application activities.

ITSS-V Pseudonym Certificate: it serves to authenticate Basic Safety Messages (BSM) and misbehavior reporting through messages signature using a butterfly key [START_REF] Badis | Using Butterfly Keys: a Performance Study of Pseudonym Certificates Requests in C-ITS[END_REF] in a way to ensure anonymity and non tracking of the user (ITSS-V). PCs do not include an encryption public key. Furthermore, in contrast with the Enrollment Certificate, an ITSS-V is given multiple simultaneously valid PCs that have a short lifetime, so that it can change them as often as necessary and possible.

Identification Certificate: Like Pseudonym Certificate, the Identification Certificate serves to authorize the use of V2I applications. The provisioning process of identification certificates is very similar to that of pseudonym certificates. However, an ITSS-V has only one identification certificate valid at a time for a given application. It includes an optional encryption public key because none of the current V2I applications require encryption. Also, like pseudonym certificates, butterfly keys are used to facilitate efficient bulk generation of identification certificates by the RA, using only a single certificate request.

Application Certificate: The Application Certificate serves for authentication and encryption features by the ITSS-R. The application certificate might contain an encryption public key. Since the ITSS-R is always motionless, there is no need to pseudonymity and non tracking features. Thus, only one valid certificate at a time is provided to the ITSS-R. Nonetheless, for continuity reasons, an ITSS-R has extra certificates that are valid for the next time periods.

2) Authorities and entities: Concerning authorities, SCMS introduces multiple new authorities such as Electors concept or 6 https://www.its.dot.gov/pilots/pilots nycdot.htm 7 https://www.its.dot.gov/pilots/pilots wydot.htm 8 https://www.its.dot.gov/pilots/pilots thea.htm Intermediate authorities. Authorities' certificates are of explicit type to support P2P certificate distribution.

Electors: the Electors are offline entities involved in the management of the Root CA. They are used primarily for the Root CA certificate management, including adding and removing a Root CA. These actions are possible through votes done by a quorum composed of more than 50% of the electors. As elector certificates are self-signed, their integrity must be ensured by other means than cryptographic signatures, e.g. tamper-proof hardware. For the same reason, provisioning and update of elector certificates are realized through out-of-band means.

Root Certificate Authority (Root CA): the Root Certificate Authority represents the center of trust of the system, and the end of trust chain. It produces a self-signed certificate verifying its own trustworthiness. Usually the Root CA certificate has a very long lifetime, as its changing is extremely difficult, time consuming, and financially expensive [START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF]. Only a quorum of Electors can issue root management messages and add them to a CRL to revoke a Root CA certificate. The main role of this authority is to issue certificates to subordinate CAs such as Misbehavior Authorities, Linkage Authorities, Registration Authorities and so on. Root CA also operates in offline environment to prevent any security threat which can have a critical impact on the security of the whole system.

Intermediate Certificate Authority (ICA): the intermediate Certificate Authority is considered as an extension of the Root CA. It is used in the sole goal of issuing certificates to other SCMS components. Thus, it provides flexibility by removing needs to connect to RCA, which is offline, each time a new SCMS entity is added to the system. However, Intermediate CA does not hold the same authority as the Root CA since it cannot self-sign a certificate.

Enrollment CA (ECA): the ECA assigns a long term certificate to EE at their first connection to the SCMS system at the bootstrap process.

Pseudonym Certificate Authority (PCA): the main roles of the PCA are: (1) to issue short term certificates to ITSSs (Pseudonym, Identification and Application certificates). And (2) to collaborates with the Misbehavior, Registration, and Linkage Authorities in order to identify linkage values to place on the CRL if a misbehaving ITSS is detected.

CRL generator: when a certificate is revoked, the CRL generator adds it to the CRL. CRL generator certificates are issued by the Root CA and can be used only to sign CRLs. The revocation of CRL generator certificates can be realized only by either Root CA or ICA.

Policy Generator: policy Generator certificates are issued by the Root CA. The Policy generator uses its private key (associated to its certificates) to sign the global policy configuration files that are distributed to SCMS components.

Linkage Authority (LA): the Linkage Authority is responsible for: (1) generating linkage values as response to RA and PCA requests. And (2) Communicate only with the RA to provide these values. The Linkage values help PCA calculating a certificate ID in a way to connect all short-term certificates from a specific device for ease of revocation if a misbehavior is detected.

Location Obscurer Proxy (LOP): the main roles of LOP are. (1) to obscure the location of the EEs seeking to communicate with the SCMS functions. (2) to shuffle misbehavior reports that the EEs send to the Misbehavior Authority. And (3) to increase the participants privacy. For privacy purposes, the LOP can mask the source IP address and route of the EE from the RA.

Registration Authority (RA): the Registration Authority (RA) is an intrinsically non-central component of the SCMS. It is possible to have multiple RAs active at the same time in the SCMS. However, an ITSS is configured to contact only one RA. The main roles of this authority are: (1) to receive and to respond to certificate requests from authorized ITSSs via LOP. (2) to initiate certificate requests to a PCA to generate certificates. (3) to initiate requests and to receive linkage values from both LAs used in ITSSs revocation. ( 4) to perform the necessary key expansions before the PCA performs the final ones. ( 5) to send certificate requests to the PCA. And (6) the RA must respond to requests from the central MA to add ITSSs to its internal blacklist and to support misbehavior investigation. The RA receives requests from different ITSSs.Therefore, in order to prevent correlating certificates IDs with users, it shuffles these requests before sending them to the PCA. Additionally, it maintains a blacklist of enrollment certificates to reject any request from a revoked ITSS.

Misbehavior Authority (MA): this entity is responsible for detecting misbehaviors by performing plausibility checks to messages, or detecting potential malfunctions or malfeasances within the system. Its main roles are: (1) to process misbehavior reports. (2) to collaborate with the CRL generator on the production of CRL. And (3) to collaborate with the PCA, the RA, and the LA to acquire necessary information about a certificate and create entries to the CRL though CRL Generator.

SCMS Manager: SCMS Manager is the primary managerial component of the SCMS. It is responsible for managing all other component entities called Certificates Management Entities (CME). It provides the policy and technical standards for the V2X system, ensures interoperability, security, privacy and auditing of the system, and manages the activities required for operation of the SCMS.

Device Configuration Manager (DCM): DCM is responsible for: (1) providing the devices access to new trust information such as updates to authorities certificates, policy decisions, and technical guidelines issued by SCMS Manager.

(2) sending software updates to devices. (3) coordinating initial trust distribution with devices by passing on credentials for other SCMS entities. (4) providing devices with information it needs, in order to request short-term certificates from the RA.

(5) providing a secure channel to the ECA to communicate Enrollment Certificates to devices. Two types of connections are used between devices and DCM, an in-band communication that passes through LOP, and an out-of-band communication that passes directly from the device to the ECA via the DCM.

F. Security Credential Management Entity (SCME)

The Chinese Ministry of Industry and Information Technology (MIIT) currently standardizes a secure V2V communications architecture and a PKI design [START_REF]of Security Certificate Management System for LTE-based Vehicular Communication[END_REF] [148] [START_REF]CCSA TC10 WG1 & IMT-2020 (5G) PG C-V2X WG[END_REF] that Figure 11 shows. The SCME design includes the following authorities:

• Root Certificate Authority (Root CA): represents the root of the trust chain and issues certificates for the lowerlevel CAs. The RCA also manages the Misbehavior Authority (MA) in order to directly revoke the misbehaving nodes. G. SCOOP@F SCOOP@F project is a french initiative launched by the ministry of sustainable development. It is divided into two parts: (1) the first part SCOOP@F Phase 1 involves several partners such as local authorities, state services in charge of national road management, automotive industries such as Renault and PSA, automotive suppliers, universities and research centers. It represents a Cooperative ITS pilot deployment project that intended to connect approximately 3000 vehicles with 2000 kilometers of roads at the national scale [START_REF] Aniss | Overview of an ITS Project: SCOOP@F[END_REF]. (2) the second part aims at the evolution of the project and the development of a common interoperable C-ITS infrastructure at the European level and involves other European countries such as Spain, Portugal, Netherlands, Austria, Belgium, the Czech Republic, Germany, Slovenia, Sweden, Denmark, Hungary, Greece, Ireland and the UK in the context of two other projects (1) C-Roads platform 9 [92] and ( 2) InterCor (Interoperable Corridors) 10 . One of the main purposes of this project is the Fig. 12: SCOOP@F PKI Architecture deployment of a dedicated ITS PKI. Figure 12 describes the architecture of SCOOP@F PKI. The PKI proposed is based on ETSI standards. However, authorities' names are different: Root Certificate Authority (RCA): within SCOOP@F only one RCA is considered. It is a CA characterized by having a self-signed certificate (issuer and signer are the same). There is no cross-certification of RCA certificate with other CAs and it can not be revoked in a normal manner i.e. being included in a Certificate Revocation List. RCA is always used offline, thus it is never connected to any network.

The RCA supports the following PKI services: (1) the generation of Root CA keypair and self-signed certificate. Distribution Center (DC): The DC is the entity that publish CRL and TSL after getting them from the RCA. The DC is also responsible for the log trail generation.

H. ISE

ITS Security (ISE) is a french project that studied security challenges related to Intelligent Transportation Systems (ITS) communication and messages authentication. The project's main objective is the design and implementation of a security management infrastructure for C-ITS [152] [153]. Figure 13 describes the PKI architecture proposed by ISE project which is based on ETSI standards. Its RCA, EA, AA and DC have the same role as in SCOOP@F. In addition, it includes two entities related to the PKI without being involved in its functioning: (1) Misbehavior Authority and (2) Privacy Authority. The Misbehavior Authority analyzes the collected ITSS' logs for misbehavior detection purposes. In the logs, the ITSSs are identified using PCs. In order to to correlate the different Pseudonyms of the same ITSS, Misbehavior Authority cooperate with the Privacy Authority.

I. Issue First Activate Later

Issue First Activate Later (IFAL) [START_REF] Verheul | Issue First Activate Later Certificates for V2X, Combining ITS efficiency with privacy[END_REF] is an ETSI based PKI, supported and developed by the Dutch ministry of the infrastructure and the environment. It relies on almost the same authorities as designed by the ETSI standards and uses the same nomenclature. Except, due to the complexity of the management and the distribution of CRLs, IFAL does not consider them in its design.

In IFAL, the AA provides the ITSS by a batch of pseudonym certificates that are valid in the far future. The set of certificates is issued in the form of an IFAL certificate file. However, the certificates can only be used when they are activated. Indeed, the ITSS receives periodically activation codes that aim at the activation of the certificates in groups corresponding with specified periods of time called epochs. To overcome the lack of CRLs, the revoked ITSSs will not be sent such codes.

J. European C-ITS platform project

European Cooperative Intelligent Transport Systems (Eu C-ITS Project) [START_REF]Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport Systems (C-ITS) DRAFT[END_REF] [156] also called C-Roads is an upper layer PKI including national or industrial PKI for C-ITS usage. Figure 14 describes its architecture.This projet is launched under the authority of the European commission and includes several members from different European countries such as academics, public entities and industrials. For now, a Certificate Policy (CP) presenting the entities and the interactions between them is under review [START_REF]2 Task Force[END_REF]. An interesting feature in this architecture is the offer of a common Eu Root CA to countries which do not want to get involved in the management of their own PKI. But at the same time, let countries or private entities which desire to be part of the Eu C-ITS trust model to plug their own PKI (RCA and sub CAs) to the Eu C-ITS PKI. Another interesting feature relies in the choice to not consider a sub PKI per European country but to let any European actor (governmental or private) to be part of this trust model. For instance, if a private company has some factories in two European countries and its IT team with its RCA in another country. If each country has a conflictual CP/CPS with another country, things can become legally complex. This is why private companies can deploy their own PKI independently of the multiple European countries where they are involved.

As described earlier, there exist different ITS communications. Among them PKI requests/responses are of a particular criticality because of the sensitive data they carry. Therefore, advanced security mechanisms are applied to secure them. In the next section we describe the different PKI requests/responses and their security mechanisms.

V. PKI REQUESTS

In this section, we describe the different PKI communications, which aim to provide ITSSs with different types of certificates (Enrollment and Pseudonym Certificates). The communication profile used to achieve a PKI communication changes from a project to another. For example, In SCOOP@F, IP over G5 communication profile is used. These communications, often called PKI requests and responses, mostly comprise critical data that must be protected and authenticated for users' privacy. However, the main standards that aim the design of PKIs suffer from the lack of a complete end-to-end process, adapted to the different types of PKI requests and responses. To the best of our knowledge, sole SCMS, SCME, SCOOP@F, IFAL, PRESERVE, and C2C-CC projects define such a protocol. In this section we describe three different approaches for PKI requests achievement: a traditional approach implemented by SCOOP@F and PRESERVE 11 projects, and two optimized approaches. The first relies on butterfly keys [START_REF] Kumar | Special Cryptographic Primitives in SCMS[END_REF], performed by SCMS and SCME and the second called Issue First Activate Later (IFAL) implemented within IFAL PKI. [START_REF] Verheul | Issue First Activate Later Certificates for V2X, Combining ITS efficiency with privacy[END_REF]. The content of the request (generated public key and the requested certificate profile 12 ) or the response (certificate and response code) are, in a first time, signed using an ECDSA private key to ensure the sender's authentication. Afterwards, the content and its associated signature are encrypted using an AES CCM key, which provides confidentiality and integrity thanks to the authentication tag produced by CCM mode. Finally, the AES CCM key is encrypted using ECIES encryption, lowering the risk of eavesdropping. The nonce used in the AES CCM encryption is sent in clear within the PKI request or response. Fig. 15: Generic request and response format [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] In order to secure PKI requests and responses, SignedData and EncryptedData structures have been defined in ASN.1 and encoded following the Distinguished Encoding Rules (DER) scheme in [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF]. SignedData: SignedData is a structure that is built to authenticate the sender using the ECDSA signature. This structure specifies the identity of the signer in order to associate the signature to an existing certificate. It consists of: (1) the content to be signed in clear, (2) the digest of the content to be signed, (3) the identity of the signer, and (4) the signature of the cited components. EncryptedData: the purpose of this structure is to encrypt a message by using AES CCM symmetric encryption. Then, ECIES algorithm encrypts the used symmetric key. Furthermore, a nonce is used for the AES CCM encryption and it is sent in clear to allow the receiver to decrypt and verify the integrity of the content encrypted.

A. SCOOP@F PKI requests mechanism

For the ECIES encryption, the sender creates an ephemeral key pair. The ephemeral private key and the receiver's certified Encryption Public Key (EPK) are used to compute the shared secret value required for ECIES encryption. For decryption, the receiver uses its certified Encryption Secret (private) Key (ESK) and the ephemeral public key generated by the sender to compute the shared secret. To allow the receiver to do ECIES decryption, the sender includes the ephemeral public key within the EncryptedData structure.

To summarize, the EncryptedData structure consists of: (1) the AES CCM encrypted content, (2) the AES CCM key encrypted using ECIES, (3) the nonce used for the AES CCM encryption, (4) the ephemeral public key used for ECIES decryption, and ( 5) the ECIES tag used to verify the integrity of the encrypted AES CCM key.

Table X, provides a list of the keys generated and used during interactions between the ITSSs and PKI entities. As explained, each ITSS uses two certificates (LTC and PC). Therefore, there are two types of certificate request communications; LTC request/response and PC request/response. The encryption secret key is used for asymmetric encryption. Its associated public key is contained in the certificate for asymmetric decryptions EPK Encryption public key

The encryption public key is, optionally, included in the certificates. This key is used for the asymmetric decryption for encryptions performed by the owner of the certificate REK Response encryption key

The response encryption key is included in the PKI requests to allow the PKI servers to asymmetrically encrypt the responses. This keys are ephemeral and just used once RDK Response decryption key

The response decryption key is used for the asymmetric decryption of the PKI responses TABLE X: List of used keys for certificates requests in SCOOP@F project [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] However, before an ITSS can execute such requests, the manufacturer provides an initialization phase for each ITSS.

1) Initialization phase: The initialization phase is performed by the manufacturer and consists in the registration of the ITSSs on the PKI. The initialization is performed as follows: (1) the manufacturer generates a technical key pair composed of Technical Public Key (TPK) and Technical Secret Key (TSK). ( 2) it selects a "Profile" and associates the technical public key to a unique canonical IDentifier (ID), which represents the permanent ID of the ITSS. (3) it specifies the associated Service Specific Permissions (SSP) related to the services supported [136]. (4) it sends a registration request. And (5) the LTCA replies by a registration response to the manufacturer. As a result, the ITSS is registered in LTCA's database and the authorities' (RCA, LTCA and PCA) certificates are stored in the ITSS.

The initialization phase have some requirements: (1) The canonical ID of the ITSS must be unique per LTCA, (2) TSK is generated in the Hardware Security Module (HSM) 13 [START_REF] Wolf | Design, implementation, and evaluation of a vehicular hardware security module[END_REF], the NIST P-256 curve is used [136]. TPK is generated outside the HSM. And (3) the certificates of Certification Authorities (CAs) and their access points are installed into the ITSS during the initialization phase as mentioned above.

The communication between the ITSS manufacturer and the LTCA for the registration of the ITSS needs to be secured. Therefore, the communications are achieved through a secured channel or a dedicated separated physical network to avoid eavesdropping.

2) LTC request and response: Figure 16 describes an ITSS-V sending an LTC request to the LTCA. Figure 17 describes the details of this request and how they are secured for the communication relying on the scheme presented in Figure 15. If the ITSS is registered in the LTCA's database, the latter replies by an LTC response that contains the LTC. Fig. 16: LTC request and response [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] For the LTC request decryption, the LTCA decrypts the EncryptedData structure using its LTCA-ESK and the ITSS's ephemeral public key, contained in the EncryptedData structure. Consequently, the LTCA, first, checks the existence of the canonical identifier and if the verification succeeds, the LTCA creates the ITSS's LTC and sends it through the LTC response. The LTC response's purpose is to provide an answer, either positive or negative, to a received LTC request. If the response is positive, it contains the requested LTC. Otherwise, if the response is negative, contains an error code.

3) PC request and response: Figure 18 describes an ITSS-V sending a PC request to the PCA. The PC request requires a verification step that the LTCA must perform. Indeed, when the ITSS sends a PC request signed with its LTC associated private key, the request is relayed to the PCA. Then, the PCA sends a validation request to the LTCA in order to verify the ITSS's LTC. The LTCA replies to the PCA by a validation response. If the LTC is valid, then the PCA creates and sends a PC to the seeker ITSS. Indeed, in order to obtain a PC, the PC request affects both the PCA and the LTCA. More precisely, the PC request includes two structures: "PCRequestContent", earmarked for the PCA and "PCRe-questSharedContent" shared between PCA and LTCA (the PCRequestSharedContent is included in PCRequestContent Fig. 17: Sequence Diagram of an LTC Request [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] structure) as Figure 19 describes and which follows the scheme that Figure 15 presents. Fig. 18: PC request and response [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] As for the LTC response, the PC response is an answer from the PCA to the ITSS. The response can be positive, containing the requested PC, or negative, specifying the error code. This structure is sent after the validation of the PC request between the PCA and the LTCA.

B. Butterfly keys mechanism

Butterfly keys rely on the principle of Elliptic Curve Discrete Logarithm Problem (ECDLP). Figure 20 describes the process of Butterfly keys generation within SCMS architecture as described in [START_REF] Kumar | Special Cryptographic Primitives in SCMS[END_REF] [150]: (1) the ITSS generates two EC Fig. 19: PC request format [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] Fig. 20: Butterfly keys scheme for providing PCs [START_REF] Badis | Using Butterfly Keys: a Performance Study of Pseudonym Certificates Requests in C-ITS[END_REF] key pairs (called Cocoon key-pairs) (a, A = aG) which is the seed for the signing keys and (p, P = pG) which represents the seed for the result's (certificates) encryption keys. Where G represents the agreed generator point of the curve E as Equation 1 describes [START_REF] Badis | Using Butterfly Keys: a Performance Study of Pseudonym Certificates Requests in C-ITS[END_REF]. (2) the ITSS generates two Advanced Encryption Standard (AES) keys ck and ek for, respectively, the expansion functions 14 of the signing keys (f 1) and the encryption keys (f 2).

               E =< G > ∀A ∈ E,
(3) the ITSS sends ck, ek, A and P to the RA. ( 5) By receiving these information, the RA is able to generate an extremely large number of derived points. Thus, for each ι15 , the RA derives signing and encryption public keys as Equation 2describes.

B ι = A + f 1(ck, ι) * G (signing keys), Q ι = P + f 2(ek, ι) * G (encryption keys) (2)
The corresponding private keys to these derived public keys are obtained as Equation 3 describes.

b ι = a + f 1(ck, ι) (signing keys) q ι = p + f 2(ek, ι) (encryption keys) (3)
(6) the RA sends each pair (B ι , Q ι ) to the PCA. The PCA does not have a knowledge about which public keys are provided by the same device thanks to the IP source obscurer (LOP). However, the RA can associate each public key to its request. Hence, the PCA must further randomize the public keys to hide them from RA. [START_REF] Whyte | A security credential management system for v2v communications[END_REF] For each request, the PCA generates a unique random integer c and sets the public key in each certificate to the "butterfly" value (B ι + cG). Then, the PCA uses Qι in order to encrypt the response towards the RA. The response contains:

• The certificate containing the public key (B ι + cG)

• The PCA's contribution to the private key c (8) the RA sends the encrypted message to the ITSS along with the corresponding ι. (9) the ITSS uses ek, p, ι to calculate q ι . It uses q ι to decipher the response and recover the certificate that contains the public key (B ι + cG) and c. It then uses ck, a, ι to calculate b ι . [START_REF] Jp Monteuuis | Securing PKI Requests for C-ITS systems[END_REF] the private key for the certificate is calculated as follows: Butterfly private key = b ι (calculated above) + c (provided by CA). Finally, [START_REF] Patil | Survey of privacy preservation in vanets[END_REF] the ITSS must verify that the private recovered key corresponds to the public key certified by the certificate.

C. Issue First Activate Later

As Section IV-I described, the AA provides the ITSS with an IFAL Certificate File (ICF) that contains a set of certificates which can be activated through the reception of activation codes. The ICF consists of: (1) an IFAL policy which defines the certificates requested parameters such as the certificate's validity time T V (in seconds), the overlap time T O between two consecutive certificates, the total number of certificates N C , and the number of epochs We describe in the following the main phases of an IFAL certificate lifecycle. 1) IFAL issuance: Figure 22 describes the certificate file request process. In the latter, the ITSS's generates two ECC keypairs. The first, generated in the HSM and called base keypair (d, dG). The public key dG is noted as P S . The second keypair (e, eG), used for EA and AA's data encryption, is generated out of the HSM. We note P E = eG. Then, the ITSS sends, to the EA, a first request for an authorization to request ICF of a IFAL policy (validity time, and so on). The EA registers the request and validates it. On success, it will provide the ITSS with an authorization credential. The latter includes the base certificate request, the public key as well as a unique identifier Id O . This identifier does not contain direct/indirect identifying information and is only shared by the EA and AA in order to later exchange activation information related to the ICF to be issued. Next, the ITSS sends the credential to the AA and requests the ICF. On reception, the AA uses the identifier Id O to register a new entry for the generation of a new ICF. Afterwards, relying on the IFAL policy requested, (1) the AA determines the number N E of epochs that the file needs to cover, (2) generates for each epoch an associated symmetric key :K 0 , K 1 , ..., K N E-1 , (3) stores that in the registry under the new entry, and finally (4) generates the ICF which contains a sequence of signed certificates as well as additional metadata such as file's encoding format and the start validity time of the first certificate. The file also contains a secret symmetric transport key K T encrypted with the public key P E that was part of the certificate request.

Each certificate in the ICF contains a public key P i . The latter is computed as Equation 4 describes:

P i = K 2 (K j , T oString(i)) * P S ( 4
)
where K 2 represents a key derivation function [START_REF] Chen | Recommendation for Key Derivation Using Pseudorandom Functions[END_REF], i is the certificate's index, K j is the epoch symmetric key, and P S represents the base public key. The private key corresponding to this public key is equal to the product of the ITSS's base private key d and the derived secret K 2 (K j , T oString(i)).

Because, only the ITSS can access and use d, it is the only entity that can use the certificate associated to this pubic key P i .

2) Activation and usage of IFAL certificates: Periodically, especially at the near end of the epochs, the AA creates a list that contains the identifiers Id O corresponding to the ITSS that are still activated. For each Id O , the AA retrieve the

Third, it computes the private key associated to the public key P i of the current certificate (C i ) . Fourth, it uses the computed private key to sign the message D. Comparison of PKI requests schemes PKI requests are vital to C-ITS functioning. Indeed, vehicles need to change frequently their certificates for privacy purposes. Therefore, most of the certificate requests relate to PC requests. Requesting a certificate represent a challenging task for vehicles because of the network's constraints like mobility and speed. Furthermore, the protocol used for the request plays a significant role in this task and have an impact on the resources allocated to it. In this context, Haidar et al. [START_REF] Haidar | C-ITS PKI protocol: Performance evaluation in a real environment[END_REF] provided an experimental study to evaluate the performance of the protocols regarding PKI requests. Their results show that the end-to-end latency between a requesting vehicle and the PKI and the vehicles' speed have an important impact on the success rate of the PKI requests. [START_REF] Badis | Using Butterfly Keys: a Performance Study of Pseudonym Certificates Requests in C-ITS[END_REF] describes a performance comparison between the scheme of PKI requests that SCOOP@F uses (described in Section V-A) and the Butterfly keys scheme that SCMS and SCME use (Section V-B). The experiments show that the Butterfly keys scheme completely overcomes SCOOP scheme, in terms of time needed to perform PKI requests and to download certificates, as well as their impact on the communication channel.

Currently, there is no implementation study, that compares IFAL scheme, with the others. However, it is clear that IFAL realizes better performances than SCOOP scheme regarding provisioning time. However, the ITSS spends a consequent time in searching the correspondent certificate and to calculate its private key for each operation, especially, knowing that in ETSI based infrastructures, the ITSS can send more than 10 messages per second.

VI. NODE REVOCATION & TRUST

Revocation of issued certificates and the trustworthiness of nodes and systems having certificates from different PKIs are among the biggest challenges to the development of C-ITS. Therefore, in this section we describe these two main concepts and how the current C-ITS systems ensure them.

A. Certificate Revocation List (CRL)

Certificates ensure the authentication of system components such as ITSS or authorities in order to operate as trusted entities for V2X communications. The ability to revoke previously-issued certificates is critical to the security of any PKI, that is, to invalidate a certificate before it expires [START_REF] Christian | A blockchain-based certificate revocation management and status verification system[END_REF] [START_REF] Liu | An end-to-end measurement of certificate revocation in the web's PKI[END_REF]. In traditional web PKIs, there exist numerous revocation methods and systems such as Certificate Revocation Lists (CRL), Online Certificate Status Protocol (OCSP), and Certificate Revocation Tree (CRT) [START_REF] Christian | A blockchain-based certificate revocation management and status verification system[END_REF]. However, in the C-ITS standards, The technique adopted is CRL. A CRL contains a list of revoked certificates. There are multiple reasons to revoke a certificate, e.g. the detection of a malicious behavior of the ITSS owner. The freshness of the CRL is very important to a C-ITS system. Indeed, having an updated CRL, allows the C-ITS system's users to be aware of current stolen, faulty, misbehaving ITSSs, or about unreliable certification authorities.

The scalability of C-ITS infrastructures are continuously increasing. Therefore, the corresponding CRL sizes are also increasing. As a consequence, it will not be always feasible to download it easily due to C-ITS communication constraints. Hence, most of the systems will implement an incremental number of updates. Nonetheless, this solution does not completely solve the problem and have shortcomings. For example, DSRC requires ITSS-R devices to send the CRL. However, in order to receive large chunks of data, the vehicle must travel past the ITSS-R devices slowly enough that they have enough time to receive the CRL. Therefore, this solution is difficult to achieve in highway scenario (except when there is a traffic jam) and is more suited for an urban scenario (because of the lower speed of vehicles).

Another possible way to distribute an updated CRL is through vehicles communicating updates to each other via the V2V interfaces. While a vehicle may not be in contact with a roadside device longtime enough to complete an update, it is sure to encounter other vehicles.

The use of public certificates in C-ITS implies the need for a revocation system. The CRL described in RFC 5280 [START_REF] Cooper | RFC 5280: Internet X. 509 Public Key Infrastructure Certificate and CRL profile[END_REF] and used for X509 certificates, is not suitable for C-ITS systems due to multiple reasons: (1) the presence of non mandatory fields which makes the X.509 CRL unnecessarily size costly for 802.11p/G5 communications. (2) the semantic used in X.509 standard is not compatible with the naming used in the C-ITS context. Therefore, new standards (IEEE and ETSI) were required to define a new CRL structure for V2X context. The CRL formats described above does not fulfill the actual needs in V2X specifications, especially due to size constraints. Indeed, the structure proposed is not size scalable, especially in the case where the number of authorities increases.

3) ISE and SCOOP@F CRL: Due to the lack of performant CRL format proposal, the team behind ISE project provided a CRL format for their own PKI project as Figure 25.a describes. SCOOP@F project also uses this CRL format. It represent a lighter structure than the CRL structures described above. It also requires lesser management by the entities involved compared to the other CRL structures due to the lesser number of its fields. In addition to the CRL, The Trust-service Status List (TSL) is a list of trusted entities among the V2X environment. This list of entities can be identified with an ID, a string Name, a certificate or a combination of the previous elements.

ISE and the SCOOP@F project define the TSL as a signed list which contains new RCA certificates, LTCA and PCA certificates and PKI service addresses (PCA and DC). It is signed by the RCA [START_REF]PKI architecture and technical specifications (v1.1[END_REF]. An example of the use of the TSL, is the case where an ITSS receives a message from an ITSS that belongs to a foreigner authority (e.g., a tourist from Germany with his car on a french road). The receiver can verify on the TSL if the sender's authority is trustworthy or not.

1) ETSI: The TSL format in ETSI is under definition (at the time of writing this paper). The lack of standardization is a problem for project deployment. This situation leads to different proposals coming from European deployment project.

2) IEEE: There is no TSL in IEEE. The standard considers that an entity can be either trusted or not trusted and therefore revoked. Thus, the existence of gray zone of trust does not exist in the standard.

3) Others: The SCOOP@F project used its own TSL structure as Figure 25.b describes. This structure is similar to the one used in ISE. However compared to ISE, the project did not implemented the use of link certificate even if the actual TSL structure allows it.

VII. THE PROPOSAL OF A GENERIC PKI ARCHITECTURE

In this section we propose a generic PKI architecture. Based on the different projects studied, the PKI proposed includes the most common authorities and ensures the security requirements needed. The authorities were chosen respecting a tradeoff between the number of authorities, modularity and infrastructure complexity. Indeed, from the one hand, if an architecture owns a high number of authorities, it leads to deployment complexity and problems. From the other hand, if the PKI contains a very limited number of authorities, the latter will be overloaded, which can cause multiple problems and slow the whole C-ITS system operation.

Figure 26 describes our proposal. In the following we describe the different authorities, and we discuss their roles and the reasons behind their architectural choice.

A. Root Certification Authority (RCA)

This Root Certification Authority is the top main trust anchor of the PKI. The deployment of multiple RCAs is advised for the following reasons: (1) for scalability and interoperability. Indeed, in order to extend the PKI coverage zone or to merge two or more interoperable PKIs e.g. multiple countries' PKIs. If the solution adopted is to rely on always one RCA, the process will be very long and costly. Indeed, because the hierarchy order of the authorities within each of the PKIs will change, the dependencies to those authorities will also change and all the certificates of these authorities will change which leads to change all the existing certificates on the C-ITS system in addition to the CRL and TSL. However, if there is an addition of the new RCA, with cross certification with the existing RCAs, the hierarchy of the new PKI remains the same, and the dependencies remain the same. Nonetheless, some certificates must change after the cross validation. (2) for resiliency purposes. If an RCA is compromised, all the underlying hierarchy is also compromised and all the certificates need to be changed. However, if the infrastructure owns multiple RCAs, only the hierarchy of the compromised RCA is compromised.

In the case of this proposal, an RCA is responsible for:

• If the PKI includes only one RCA, the latter creates its RCA key pair and its self-signed certificate

B. Enrollment Certification Authority (ECA)

Enrollment Certification Authority is a core component of the PKI infrastructure because it serves as an entrance gate to the PKI for each ITSS. Thus, it plays the role of a Registration Authority during the Initialization/Bootstrap phase. Within this solution, the implementation of multiple LTCAs is possible. We also recommend that LTCAs are operated by entities that The Enrollment Authority role is:

• the registration of the newly created ITSS Pseudonym Certification Authority represents another vital component of the PKI infrastructure because it provides the credentials (pseudonyms) to ensure V2X communications. For each RCA hierarchy, only one PCA is deployed. However, the decentralization of the PCA is highly recommended. We made the choice of implementing only one PCA in order to avoid the complexity of inter PCA collaboration and management. The PCA's role is:

• the issuance of pseudonym certificates to ITS stations which are already enrolled with the EA • the collaboration with the LTCA in order to verify the identity of the ITSSs that request new PCs • the collaboration with the ECA, Misbehavior Authority and Linkage Authority in order to identify misbehaving ITSS D. Linkage Authority (LA) Linkage Authority's main role is to collaborate with PCA and LTCA in order to connect all Pseudonym Certificates of a specific device. This identification is used by the Misbehavior Authority in its detection process. For security purposes, the LA is always offline.

E. Misbehavior Authority

This authority's role is the analysis of the system's log stream in order to perform detection of malfunction or malfeasance within the system. In addition, it collaborates with the LA that connects the different PCs of the same ITSS, in order to keep a temporary history of the ITSS' behavior. If an ITSS is detected as misbehaving, the MA creates an entry into the CRL after the collaboration with the LA to identify the ITSS. Finally, the MA sends the identity of the ITSS detected as misbehaving to the RCA in order to add them into the CRL.

F. Lists Distribution Center (LDC)

The main role of the LDC is to retrieve the CRL and TSL from the RCA and to provide them to requesting ITSSs. The reason behind having an LDC lies in keeping the RCA offline for security purposes. That way, an ITSS requests CRL and TSL from LDC and not from RCA.

VIII. OPEN CHALLENGES

Despite the important evolution of C-ITS in recent years, there are still numerous major challenges that C-ITS must face. In this section, we highlight the main open research and operational challenges.

A. Misbehavior Reporting

Misbehavior will happen and needs to be reported by vehicles to a centralized entity for investigation [START_REF] Hammi | Is it really easy to detect sybil attacks in c-its environments: A position paper[END_REF]. The SCMS has a Misbehavior Authority (MA) that allows vehicles to send misbehavior reports. However, details on how the misbehavior investigation is performed have still to be defined. Misbehavior reporting is challenging because the volume of misbehavior that can be expected on the road is unknown, and therefore, it is hard to assess the communication and computation overhead for the vehicles and the PKI (because misbehavior investigation requires collaboration between PKI components). Scalability of the Misbehavior Authority to receive and process misbehavior reports will also have to be assessed [START_REF] Cincilla | Vehicular PKI scalability-consistency trade-offs in large scale distributed scenarios[END_REF]. Indeed, to perform the misbehavior investigation the MA has to analyze the reports and identify (1) if the misbehavior is critical, (2) if the multiple pseudonym certificates are linked to the same end entity, and (3) if revocation is needed. Therefore, we identify four challenges: (1) the design of appropriate local misbehavior detection, (2) to define content of misbehavior report [START_REF] Kamel | A misbehavior authority system for sybil attack detection in c-its[END_REF], (3) to define misbehavior investigation processes, and (4) to assess communication and computation overheads.

B. Revocation

ITSS and PKI components could be compromised, and thus, would have to be revoked. The revocation would require to start a new component and providing it with the relevant credentials. It would also require every PKI component and ITSS interacting (directly or indirectly) with it to get its new certificate. In case of the Root CA being compromised, a higher authority is required. In the SCMS design, the Elector CAs are here to solve this issue. However, it is not present in the other PKI proposals, and hence, the issue of Root CA revocation must be addressed. Furthermore, the revocation of ITSS certificates still being one of the top challenges in C-ITS environments due to their scalability [START_REF] Khan | Survey on Issues and Recent Advances in Vehicular Public-key Infrastructure (VPKI)[END_REF].

C. Quantum Apocalypse

Current PKI implementations rely on non quantum-resistant cryptographic algorithms. In case of being broken by a quantum computer, all the PKI components will have to be re-enrolled with quantum-resistant credentials (and only use post-quantum cryptographic algorithms). This is why the top level CAs should use post-quantum algorithms as specified by NIST 17 .

D. New ITSS

Current Intelligent Transportation Systems research primarily consider ground vehicles (heavy-duty, light). However, it is not far-fetched to envision broadening the scope of ITS to unmanned aerial vehicles [START_REF] Sami Oubbati | UAV-assisted supporting services connectivity in urban VANETs[END_REF], [START_REF] Wang | VDNet: an infrastructure-less UAV-assisted sparse VANET system with vehicle location prediction[END_REF], maritime [START_REF] Kok-Lim | Maritime networking: Bringing internet to the sea[END_REF], rail [START_REF] Zhu | Big data analytics in intelligent transportation systems: A survey[END_REF], and so on. Indeed, it would make sense to leverage 17 The NIST PQC challenge is still open at the time of writing this paper.

the PKI deployed for ground vehicles in order to simplify key management. However, this would potentially stress further the PKI and challenges its scalability [START_REF] Cincilla | Vehicular PKI scalability-consistency trade-offs in large scale distributed scenarios[END_REF].

E. Blockchain-based management trust

The use of blockchain has been widely recommended to replace centralized trust management platforms, mainly because of their vulnerability of being a single point of failure [START_REF] Chulerttiyawong | A blockchain assisted vehicular pseudonym issuance and management system for conditional privacy enhancement[END_REF]. The use of blockchain has also been identified more specifically as a potential security and trust management solution for C-ITS [172] [173].

Chulerttiyawong et al. use the consortium blockchain technology to ensure pseudonym certificates issuance in a multijurisdictional road network. In the approach proposed smart contracts are used to issue certificates to vehicles. Therefore the decentralized blockchain replaces the centralized PKI. The blockchain and its smart contracts are also involved in the pseudonylm certificates revocation management. In [START_REF] Benarous | Blockchainbased privacy-aware pseudonym management framework for vehicular networks[END_REF] Benarous et al. propose a blockchain-based pseudonym management framework where pseudonym generation is performed purely by vehicles without interference by authorities. Mainly, two blockchains are used. The first is for the storage of the pseudonym certificates and for their state verification and the second is dedicated to revocation management. Similarly, Hui et al. [START_REF] Li | Fadb: A fine-grained access control scheme for vanet data based on blockchain[END_REF] propose a fine-grained access control scheme for VANET data based on blockchain (FADB). The approach proposed combines the ciphertext-based attribute encryption (CP-ABE), Ethereum blockchain and the Inter Planetary File System (IPFS) [START_REF] Benet | Ipfs-content addressed[END_REF] technologies to provide distributed storage and fine-grained access control. Indeed, the blockchain is used to replace the centralized PKI for user identity management as well as for data storage. Moreover, different ITS data access rights can be established according to user attribute. Besides, ITSS-V can outsource complex encryption and decryption operations to powerful ITSS-R and further improve the efficiency of data access. Zhuo et al. [START_REF] Ma | An efficient decentralized key management mechanism for vanet with blockchain[END_REF] propose a blockcain-based key management mechanism for C-ITS called DB-KMM (Decentralized Blokchain-based Key Management Mechanism) which automatically registers, updates and revokes stations public keys. The mechanism proposed relies on smart contracts and the blockchain to ensure the aforementioned tasks. Furthermore, they propose a novel mutual authentication and key agreement protocol. Finally, using smart contracts the proposed mechanism handles key update and revocation of the different users. Yang et al. [START_REF] Yang | Blockchain-based decentralized trust management in vehicular networks[END_REF] propose a decentralized blockchain-based trust management system for C-ITS environments. In the approach proposed, ITSS-Vs can validate the received messages from neighboring vehicles using Bayesian Inference Model. Based on the validation result, the ITSS-V generates a rating for each message source ITSS-V. With the ratings uploaded from ITSS-Vs, ITSS-Rs calculate the trust value offsets of involved vehicles and pack these data into a block. Then, each ITSS-R tries to add their blocks to the trust blockchain which is maintained by all the ITSS-Rs. In the same context, Lei et al.

[179] used the blockchain to manage the key transfer between the security managers in the ITS communication systems.

There exist numerous other works from the academia that aim to use blockchains for a decentralized trust management in C-ITS environments [180] [181] [182] [START_REF] Ei | Efficient certificate management in blockchain based internet of vehicles[END_REF]. However, most of the existing works suffer from different shortcomings. Mainly, they do not consider all the ITS environment standards such as the types of messages (e.g., CAM, BSM), their format or the existing standardized network functions. Which make the proposed security approaches not compatible with the existing C-ITS environments. Moreover, the proposed approaches rely a lot on the blockchain and on data storage and browsing within the blockchain. However, such tasks are very costly in time and in computation resources and cannot be considered in real time and highly scalable environments such as C-ITS. Finally, at the time of writing this paper, no standard or consortium work considered the use of blockchain technology for trust management in C-ITS.

IX. CONCLUSION

Public Key Infrastructures represent a major solution in ensuring communications' security. Because of their ability in meeting security requirements, PKIs are increasingly adopted in C-ITS environments and represent currently the first solution deployed.

Despite the huge number of works in C-ITS security area, there is no survey devoted exclusively to the topic of PKIs in C-ITS, their security functions, their architectures and how the different projects implemented them. Thus, in this work we provided an extensive survey that analyze each part and function of the set of the existing C-ITS PKIs and their related functions.

More precisely, in this survey, we studied step by step almost all PKI components and functions. We described the different certificates that exist in C-ITS environments, their standards and formats. Then, we introduced the existing C-ITS projects and standards that proposed and deployed PKI. We described the function of their authorities as well as their global architectures. Our work focuses also on the security lifecycle of the ITSS. Indeed, we surveyed the certificates' requests and responses as well as their security mechanisms. Afterwards, we discussed the different revocation and trust management standards and approaches that the different projects deployed.

Relying on all the studied aspects of PKIs, we proposed a generic model for a PKI architecture. Our model is proposed respecting a tradeoff between the number of authorities, modularity and infrastructure complexity. Finally, we highlighted the open research and operational challenges in the area of ITSS security that are related to PKIs.

Following our study and analysis, we conclude of the lack of standardization works related to numerous aspects and functions of the PKI (e.g., revocation, trust interoperability, certificates requests, and so on). We also conclude of the need of further work to overcome the different challenges (e.g., scalability, misbehavior detection, post-quantum cryptography) to ensure the functioning and service continuity of C-ITS.

Fig. 1 :

 1 Fig. 1: C-ITS scenario. V2I: Vehicle to Infrastructure, V2V: Vehicle to Vehicle, I2V: Infrastructure to Vehicle, I2I: Infrastructure to Infrastructure, D2I: Drone to Infrastructure, I2D: Infrastructure to Drone, D2V: Drone to Vehicle, V2D: Vehicle to Drone, I2P: Infrastructure to Pedestrian, P2I: Pedestrian to Infrastructure, V2P: Vehicle to Pedestrian, P2V: Pedestrian to Vehicle, D2P: Drone to Pedestrian, P2D: Pedestrian to Drone

Figure 2

 2 describes the organization of the paper. It is organized as follows: Section II describes the different security and performance requirements for the C-ITS. Then, Section III describes the different certificate standards. Section IV depicts the different standard and projects that designed and deployed PKIs in C-ITS and describes their architectures. Next, Section V details how PKI requests and responses are performed. Then, Section VI describes the different existing Certificate Revocation and Trust service Status Lists (CRLs and TSLs). Afterwards, Section VII describes our proposal of a generic PKI in C-ITS. Section VIII highlights open research and operational challenges.Finally, Section IX concludes the paper.

Fig. 2 :

 2 Fig. 2: Rodmap of the paper

Fig. 4 :

 4 Fig. 4: IEEE certificate's structure; (a) IEEE Explicit certificate; (b) IEEE Implicit certificate

Figure 5 depicts

 5 ETSI certificate fields:

Fig. 5 :

 5 Fig. 5: ETSI generic certificate

  • Sending ITSS: (1) acquires rights to access ITS communications from Enrollment Authority, (2) negotiates rights to invoke ITS services from Authorization Authority, and (3) sends single-hop and relayed broadcast messages.• Relaying ITSS: receives broadcast messages from the sending ITSS and forwards them to the receiving ITSS if required. • Receiving ITSS: receives broadcast messages from the sending or relaying ITSS.

Fig. 7 :

 7 Fig. 7: ETSI generic PKI architecture [140]

Fig. 8 :

 8 Fig. 8: The ITSS security lifecycle

D. Car- 2 -

 2 Car Communication Consortium PKI architecture The Car-2-Car Communication Consortium (C2C-CC) [143] is a non-profit organization consisting of nearly all European vehicle manufacturers, several suppliers, research organizations and other partners. The overall objective of the C2C-CC is to implement C-ITS. The technological focus is on a 5.9 GHz ad-hoc network providing low latency communication and geo-routing. It closely works together with the European standardization organizations in particular ETSI TC ITS in order to achieve commonly agreed European standards for ITS.

Fig. 9 :

 9 Fig. 9: C2C-CC PKI Architecture [144]

Fig. 10 :

 10 Fig.10: SCMS PKI Architecture[START_REF]Security Credential Management System Proof-of-Concept Implementation[END_REF]

•

  Authentication Authority System (AAS): authorizes the ITSS to request and receive an EC from the ECA eg., through the use of tokens. • Registration Authority (RA): helps in the PC requests through (1) the validation of PC requests from ITSS. (2) the performance of supporting functions e.g., the butterfly key expansion [150] [125]. (3) the forwarding of requests to the PCA. And (4) the reception of PCA's responses and the bundle of the received PCs for ITSS. The RA also provides configuration information, CRLs, and certificate chain information to ITSS. It also provides linkage values because it comprises a Linkage Authority (LA). The linkage values are used by the MA for misbehavior investigation and efficient revocation.

Fig. 11 :

 11 Fig. 11: SCME PKI Architecture

( 2 )

 2 the generation of CA certificates. (3) the signature of CRL and Trust Status List (TSL). (4) the revocation of CA certificates. (5) the update of CRL and TSL. And (6) the log trail generation. Long Term Certification Authority (LTCA): within SCOOP@F three LTCAs are implemented, two LTCAs for cars' manufacturers (Renault and PSA) and one for road operators. Each LTCA is responsible for: (1) the authentication of manufacturers to register ITSSs. (2) the authentication of ITSS deactivation requests. (3) the management of ITSS status. (4) the generation, issuance and signature of Long Term Certificates (LTCs). And (5) the management of PCA validation requests for PC requests. Pseudonym Certification Authority (PCA): SCOOP@F PKI includes one PCA which role is: (1) the management of Pseudonym Certificates (PCs) requests. (2) the generation, issuance and signature of PCs. (3) the management of communication with the LTCA and the DC in order to validate PC Request. (4) the authentication of other authorities using TSL.

Fig. 13 :

 13 Fig.13: ISE PKI Architecture[START_REF] Bakhti | PKI system requirements specifications (v1.1)[END_REF]

Fig. 14 :

 14 Fig.14: C-ITS platform project PKI architecture[START_REF]2 Task Force[END_REF]

Figure 15

 15 Figure 15 describes the generic message format used to secure and send LTC and PC requests.The content of the request (generated public key and the requested certificate profile12 ) or the response (certificate and response code) are, in a first time, signed using an ECDSA private key to ensure the sender's authentication. Afterwards, the content and its associated signature are encrypted using an AES CCM key, which provides confidentiality and integrity

  by the ITSS and saved in the HSM during the initialization phase TPK Technical Public Key Generated by the ITSS and registered in the PKI during the initialization phase VSK Verification secret key The verification secret key is the used key for the signatures. Its associated public key is contained in the certificate for the signature verification VPK Verification public key The verification public key is included in the certificates. This key is used for the verification of signatures performed by the owner of the certificate ESK Encryption secret key

  ∃ a ∈ N such as A = a.G (signing key pair), ∀P ∈ E, ∃ p ∈ N such as P = p.G (encryption key(1)

  16 N E . (2) a start time S corresponding to the start time of the first certificate in the file. And (3) a sequence of certificates C 0 , C 1 , ..., C N C . See Figure 21.

Fig. 21 :

 21 Fig.21: IFAL certificates' parameters[START_REF] Verheul | Issue First Activate Later Certificates for V2X, Combining ITS efficiency with privacy[END_REF]

Fig. 22 :

 22 Fig.22: IFAL certificates' parameters[START_REF] Verheul | Issue First Activate Later Certificates for V2X, Combining ITS efficiency with privacy[END_REF]

Fig. 23 :Fig. 24 :

 2324 Fig. 23: IEEE1609.2 CRL

Fig. 25 :

 25 Fig. 25: ISE and SCOOP@F: (a) CRL format; (b) TSL format

Fig. 26 :

 26 Fig. 26: Generic PKI architecture proposal

TABLE III :

 III Key Sizes for equivalent robustness (in bits)[START_REF] Lauter | The advantages of elliptic curve cryptography for wireless security[END_REF]

	AES counter with CBC-MAC (CCM) (Cipher Block Chaining
	Message Authentication Code) operation mode is used in
	IEEE and ETSI security standards. Symmetric-key encryption
	algorithms are very efficient and fast. However, they suffer
	from scalability issues. Indeed, in a system that includes
	multiple users, two solutions are possible; (1) all the users
	use the same key. However, if one user's key is compromised,
	all the security of the group is also compromised. (2) each
	pair of users use a different secret key. However, this solution
	induces to management problems

Table III

 III

	Function	V2X Cryptography Standards IEEE 1609.2
		[95]	ETSI 103 097 [89]
			NIST-P256, BrainpoolP256r1,
		NIST-P256,	BrainpoolP384r1,
	Curve definition	BrainpoolP	BrainpoolP512r1
	Key Agreement		ECSVDP-DHC
	Key Derivation		KDF2
	Encryption		AES-128-CCM
	MAC		MAC1
	Hash		SHA-256
			compares the key sizes
			of ECC with other algorithms.
			ECIES combines a Key Encapsulation Mechanism (KEM)
			with a Data Encapsulation Mechanism (DEM). The system
			independently derives a session encryption key and a Message
			Authentication Code (MAC) key from a common secret.
			Plaintext is first encrypted under a symmetric cipher, and then
			a MAC function is applied on the ciphertext for authentication.
			More precisely, ECIES relies on four cryptographic functions.
			For each function, multiple algorithms can be used. Table
			IV describes the possible algorithms for the different ECIES
			cryptographic functions, according to the different C-ITS stan-
			dards. The ECIES encryption algorithm needs the generation
			of sender's EC key pair and receiver's EC key pair. To achieve
			this operation, both sender and receiver must agree on the
			elliptic curve on which the key generation is based (domain
			parameters). NIST-P elliptic curves or BrainPool curves are
			required by ETSI, IEEE and ISO standards.
			2) Authentication, mutual authentication, integrity and non
			repudiation: Authentication requirement ensures that entities
			involved in a communication are correctly identified and

TABLE IV :

 IV Algorithms per ECIES Function for V2X

TABLE V

 V

	: Algorithms per ECDSA Function for V2X
	ECDSA offers multiple advantages over traditional sig-
	nature algorithms such as DSA, especially concerning key
	sizes and signature time [112] [121]. Table VI describes a
	comparison study of DSA and ECDSA key size, signature
	generation time and signature verification time for the same
	security level

TABLE VI

 VI

	: Time calculations for signing operations for RSA
	and ECDSA [122]
	by relying on a PKI, each ITSS uses simultaneously two
	certificates: (1) an Enrollment Certificate (EC) (also called
	Long Term Certificate (LTC)) and (2) a Pseudonym Certificate
	(PC) (also called Short Term Certificate (STC)). Known only
	by the EC Authority (ECA) and its owner (ITSS), the EC
	is not used in common communications, but used only to
	authenticate the ITSS to the PKI in order to request new
	PCs. However, the PC is used for the ITSS communications.
	In order to protect the privacy of the road users, a regular
	change of pseudonyms is required. The European standard
	ETSI TS 102 867 [123] recommends that pseudonyms are
	changed every five minutes, whereas the American standard
	SAE J2735

TABLE VII

 VII

	: Mechanisms and algorithms that ensure security
	requirements in C-ITS environments

  the first 8 bytes of the issuer's certificate digest realized with another algorithm than SHA256. Subject info: contains (1) a Subject name field which includes the certificate's owner name. (2) a Subject type field containing the certificate's type. The latter can be either: • enrollment credential: also known as Long Term Certificate (LTC). Enrollment Authority enrolls ITS stations in the PKI by issuing these certificates. The latter is mandatory for the Authorization Ticket request. • authorization ticket: also known as Pseudonym Certificate (PC) or short term certificate. The Authorization Authority (AA) issues these certificates to ITS stations. PC is mandatory for securing V2X communications. • root ca: is a self signed Root CA certificate. • enrollment authority: is the Enrollment Authority (EA) certificate.

• Certificate chain: contains the whole certificate chain starting from the owner's certificate up to the root certificate. • Certificate digest with other algorithm: the issuer is presented by • authorization authority: is the Authorization Authority (AA) certificate. • crl signer: represents the CRL Authority certificate.

TABLE VIII :

 VIII Root CAs are trusted by all entities and issue certificates to all other CA entities and End Entities within a defined region. The latter is specified by the region field in the Root CA's certificate and can indicate that the Root CA is worldwide. The goal behind issuing certificates to other CA entities, is to authorize them to issue certificates or CRLs to end entities.

	• Secure Data Exchange CAs: SDE-CAs issue certificates
	to end entities that use/send application secured messages.
	An SDE-CA is responsible for issuing certificates to SDE
	Entities (SDEE) and to other SDE-CAs. It is authorized
	to issue the following types of certificates:

Summary of the main PKI deployment projects messages formats and processing in Wireless Access in Vehicular Environments (WAVE) devices, including methods to secure WAVE management messages and methods to secure application messages. It also describes administrative functions necessary to support the core security functions. For PKI infrastructure, the standard classifies all the entities that provide or use IEEE 1609.2 security services into two categories; Certificate Authority entities (CA entities) and End Entities (EE):

1) Certificate Authority entities (CA entities): Issue certificates and Certificate Revocation Lists (CRLs). There are defined three types of CA entities.

• Root CAs:

  Table IX maps C2C PKI authorities into ETSI ones. Nonetheless, C2C-CC PKI does not use ETSI certificates, but, IEEE ones [144] instead.

	ETSI Certification Authorities	C2C-CC Certification Authorities
	Root Certificate Authority
	(RCA)	Root Certificate Authority (RCA)
		Long Term Certificate Authority
	Enrolment Authority (EA)	(LTCA)
		Pseudonym Certificate Authority
	Authorization Authority (AA)	(PCA)

TABLE IX :

 IX : Mapping of ETSI and C2C-CC CAs' names A C2C-CC PKI contains the following authorities: Root CA (RCA): defines common policies among all subordinate LTCAs and PCAs. The RCA only issues certificates for Long-Term CAs and Pseudonym CAs. A certification process which needs interaction with the RCA is only required once a new LTCA or PCA is created, and when the lifetime of an LTCA or PCA certificate expires. In C2C-CC proposal,

•

  Enrollment CA (ECA): issues Enrollment Certificates (EC) to V2X devices which allow them to request other certificates such as Pseudonym Certificates (PC) and Application Certificates (AC). One ITSS-V can have multiple ECs, e.g., for different geographic regions of state authorities depending from different ECAs.

• Pseudonym CA (PCA): issues Pseudonym Certificates (PC) to ITSS. The PCs are used to sign the messages sent. The number of PCs and the validity period is configurable, and the current MIIT recommendation is to use 20 PCs per week.

• Application CA (ACA): issues application authorization certificates for selected applications. This function is not fully defined yet

[START_REF] Tao | Security Certificate Management System for V2V Communication in China[END_REF]

. • Revocation CA (RCA): issues and manages the CRLs.

•

  If the PKI includes more than one RCA, each RCA cross certify other RCAs • Issue certificates for underlying authorities: LTCA, PCA, LA, MA and Lists Distribution Center (LDC) • Generate and sign the TSL and the CRL For security purposes RCA is offline and can be reachable only by other authorities.

We consider the works before 2017 as old because it represent the year where the majority of security standards and deployment projects were published or updated e.g.,[89] [90].

In the rest of the paper, we use indifferently the terms public key certificate and certificate

Members of the consortium are Ford Motor Company, General Motors LLC, Honda R&D Americas Inc, Hyundai-Kia America Technical Center Inc, Mazda, Nissan Technical Center North America Inc, and Volkswagen Group of America

https://www.c-roads.eu/platform.html

https://intercor-project.eu/

The following description concerns SCOOP project. PRESERVE implementation of the protocol is almost the same

[START_REF] Gillani | A survey on security in vehicular ad hoc networks[END_REF] The profile includes the certificate's specific related information.

HSM is a Hardware Security Module used for fast cryptographic operations. It provides security features such as a temper proofed environment to store security elements, strong authentication required and functioning without an operating system that makes it resistant to attacks over the network.It is embedded within the ITSS and provides a temper proof environment to generate cryptographic material.

An expansion function maps a variable integer ι to another integer in a range from 0 to l, the order of the elliptic curve.

ι goes from 1 to the desired number of certificates.

An epoch represents a period of time, in which a set of certificates are activated together.

ACKNOWLEDGMENTS

We thank the anonymous reviewers for their valuable comments which helped us improve the quality, content, and presentation of this paper.