Hardware Limitations to Secure C-ITS: Experimental Evaluation and Solutions

Cooperative Intelligent Transportation Systems (C-ITS) improve driving experience and safety through secure Vehicular Ad-hoc NETworks (VANETs) that satisfy strict security and performance constraints. Relevant standards, such as the IEEE 1609.2, prescribe network-efficient cryptographic protocols to reduce communication latencies through a combination of the Elliptic Curve Qu-Vanstone (ECQV) implicit certificate scheme and the Elliptic Curve Digital Signature Algorithm (ECDSA). However, literature lacks open implementations and performance evaluations for vehicular systems. This paper assesses the applicability of IEEE 1609.2 and of ECQV and ECDSA schemes to C-ITSs. We release an open implementation of the standard ECQV scheme to benchmark its execution time on automotive-grade boards. Moreover, we evaluate its performance in real road and traffic scenarios and show that compliance with strict latency requirements defined for C-ITS requires computational resources that are not met by many automotive-grade embedded hardware platforms. As a final contribution, we propose and evaluate novel heuristics to reduce the number of signatures to be verified in real C-ITS scenarios.


I. INTRODUCTION
C OOPERATIVE Intelligent Transportation Systems (C-ITS) [34] improve the driving experience by adopting communications among roadside infrastructure, road users and vehicles. Green wave systems, smart traffic lights and smart parking are just a few representative examples of the future smart city features designed to decrease traffic, energy consumption, pollution and optimize commuting, with direct consequences on both driving experience and quality of life. However, designing and implementing these complex systems is a challenging task. As an example, the novel communication networks must support a highly heterogeneous environment, that comprises many vehicles and board manufacturers, and comply with the strict C-ITS constraints in terms of low latency, security, and dynamic network configuration. In particular, the authors of [5] present an analysis of the delay introduced by an authentication protocol, and determine whether this would result in a crash. Manuscript  Standards for C-ITS communications have been developed in the United States, Europe, and Japan [4], [17], [20]. While each standard defines its own data structures and supported security mechanisms, they are all built upon the IEEE 802.11p standard, hence the management of the PHY and MAC layers is the same regardless of the regional standard. In this paper, we investigate security solutions for Vehicular Ad-hoc NETworks (VANETs) and focus on the integrity and authenticity guarantees of vehicle communications. To this aim, we consider the security protocols described in the IEEE 1609.2standard defining the secure message formats for WAVE, policies for the management of the security certificates, and the supported digital signature and encryption algorithms. This paper proposes four main contributions to the state of the art. First, we present an implementation of the Elliptic Curve Qu-Vanstone (ECQV) implicit certificate scheme and the Elliptic Curve Digital Signature Algorithm (ECDSA) that is compliant with the IEEE 1609.2standard and evaluate its deployment on automotive-grade boards. To the best of our knowledge, this is the first open implementation of implicit certificates for resource-constrained devices in terms of computational power and memory. Second, we investigate the feasibility of the implicit certificate scheme in multiple C-ITS scenarios characterized by different latency constraints identified by the National Highway Traffic Safety Administration (NHTSA) for safety-critical communications between vehicles [30]. Third, we analyze the applicability of the automotive boards against realistic scenarios. The realistic scenarios are built on different areas of the city of Modena (Italy) and simulated using real traffic data provided by the municipality. These experiments highlight the limitations imposed by the constraints of several automotive-grade embedded platforms. The last contribution of this paper is the proposal of a prioritization strategy to improve the applicability of automotive-grade boards to real traffic scenarios. The proposed strategy adopts position-based heuristics based on information included in V2V messages. We assess the effectiveness of the proposal by using the simulations based on the considered traffic scenarios.
The rest of the paper is organized as follows. Related work is presented in Section II, while the base knowledge required for the understanding of this paper is presented in Section III. Section IV presents our prototype implementation of the ECQV and ECDSA schemes for low-power devices, as well as its applicability to representative automotive-grade boards. The description of the realistic traffic scenarios and the results of our simulations are presented in Section V. Section VI proposes the 0018-9545 © 2021 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission.
novel heuristics for the prioritization strategy. Finally, conclusions and future research directions are outlined in Section VII.

II. RELATED WORK
Securing C-ITS implies protecting connected vehicles from cyber-attacks. These attacks are aimed to disrupt both communications between the microcontrollers composing the internal vehicular network (intra-vehicular communications) and communications between the vehicles and other external devices (inter-vehicular communications). Research efforts on intravehicular communications propose different prevention [41], [53], detection [14], [32], [54] and reaction [28], [57] approaches against a variety of cyber-attacks to the main communication buses supporting intra-vehicular communications [27], [35]. However, the focus of this paper is on security approaches for inter-vehicular communications that enable C-ITS.
Several security schemes applied to inter-vehicular communications have already been proposed to guarantee the integrity and authenticity of V2V communications [22], [33], [40]. These solutions are the adaptation of secure standard protocols designed for the IT domain and fail to consider the requirements of the automotive environment.
Other works considering the peculiarities of V2V communications focus on privacy [25], [44] and safety requirements [59]. However, these works are only based on theoretical analyses, whereas this paper also leverages experimental evaluations based on realistic simulations that demonstrate the limitations of general purpose automotive-grade boards in supporting V2V communications in a real city and for real traffic scenarios. Many papers already published in the literature that leverage simulations are based on the LuST scenario [13], developed with the mobility data and road structure of the city of Luxembourg. However, the traffic in LuST is extremely sparse and spans a wide area, while our goal is to analyze the applicability of security solutions for V2V communications in dense scenarios including rush hours in which many vehicles are concentrated in a small area. For these reasons, the traffic scenarios analyzed in this paper comprise four different representative areas of the city of Modena (Italy) and different traffic conditions. Analyses in the context of realistic traffic scenarios have been proposed to compare the effects of obstacle shadowing during transmission of messages using both IEEE 802.11p and ARIB STD-T109 PHY layers [18], but it did not consider the full protocol stack nor the timings required to process received messages and to verify digital signatures. In this paper, we consider the full IEEE 1609 protocol stack and we focus on the computational requirements of the boards to process received messages and verify their authenticity.
Although the authors of [10] analyzed the energy consumption required for ECDSA signature verification in inter-vehicular communications, they did not consider the specifications of the IEEE 1609 standard including implicit certificates. On the other hand, this paper focuses on the timings of the cryptographic operations of both ECQV and ECDSA when deployed on automotive-grade embedded systems, and evaluates their applicability in real traffic scenarios.
The authors of [6] analyze if VANET communications security based on ECQV certificates can satisfy latency constraints that are needed to guarantee safety in case of a car crash. Although the proposed objectives and results are interesting, the proposed testbed is based on a laptop computer and does not evaluate timings by using a proper implementation on hardware that typically characterizes automotive boards. Moreover, the evaluation is based on a simplified scenario based on synthetic traffic conditions composed of a fixed number of vehicles on a straight road traveling at constant speeds. On the other hand, the evaluation presented in this paper is based on multiple and different traffic conditions characterizing various city zones, with no fixed number of vehicles and variable travel speeds, hence better representing realistic communications between connected vehicles. The evaluation proposed in this paper focuses on real automotive-grade boards and is based on the first open prototype implementation for ECQV and ECDSA. The prototype implementation is optimized for low-power devices and allows to better analyze the performance of the implemented protocols in real-world scenarios.
One of the challenges of implementing cryptographic protocols on embedded hardware is to guarantee adequate performance to verify digital signatures. A possible solution is to use specialized hardware implementations. As an example, the authors of [29] adopted a FPGA that allows to verify up to 250 ECDSA signatures every 100 ms. Further improvements have been proposed in [49] to reduce the power consumption. However, both implementations use elliptic curves at a 81-bit security level (the size of the cryptographic prime groups is about 163-bits), while in this paper we focus on a 128-bit security level (we use the secp256r1 curve as required by the standards). Another approach is the one proposed in [23], where the authors designed an application-specified integrated circuit implementation for ECDSA verification that can achieve a verification throughput of up to 2700 signatures every 100 ms. Other commercial solutions based on dedicated hardware exist, such as RoadLINK SAF5400 by the NXP Semiconductors [48] that claim a throughput of up to 200 signatures every 100 ms. However, implementations of commercial boards are typically closed source and cannot be easily audited by researchers or updated in case of security vulnerabilities [45]. In this paper we propose an open source implementation of the ECQV/ECDSA stack for general purpose microcontrollers that is accessible and auditable.
This work is also motivated by the lack of shared and established workloads to assess the computational requirements of microcontrollers responsible for V2V communications. As an example, IEEE 1609.2prescribes that V2V messages are sent every 100 ms. However, the standard does not provide any minimum requirement in terms of the number of messages that a recipient should be able to manage in a given time frame. The time required to handle a single message is dominated by the verification of its attached digital signature, hence constraints related to the number of messages that can be received in a fixed time frame directly translate to limitations to the number of the surrounding vehicles or the hardware requirement of microcontrollers. We argue that the number of the surrounding vehicles is an independent variable and that urban environments lead to a concentration of vehicles (and hence to a number of received messages) far higher than the scenarios already considered in previous studies [6], [13]. We improve related works by proposing analyses based on a wide range of requirements in terms of allowed latency and throughput, that are compliant with standards for safety-critical communications. Moreover, we propose novel heuristics for prioritizing signature validations that allow constrained automotive-grade boards to selectively verify the authenticity of a subset of more relevant V2V messages. We observe that despite the proposed analyses are based on the established Dedicated Short Range Communication (DSRC) protocol stack (see Section III-A), they are also applicable to emerging Cellular-V2X (C-V2X) due to the similarities of the security services. C-V2X is a promising alternative or complementary vehicular communication technology that is being developed as part of the overall Third Generation Partnership Project (3GPP) process to advance cellular systems from 4 G to 5 G technologies. It has been introduced in Release 14 of 3GPP [46], [47]. The primary goal of C-V2X technologies is to supersede the IEEE 802.11p/DSRC stack. We observe that C-V2X adopts communication channels with higher bandwidth with regard to DSRC in the context of V2I communications. However, the bandwidth of C-V2X in the context of V2V communications is only slightly better or comparable [7], [55]. Finally, we highlight that C-V2X replaces the PHY and the MAC layers, and leverages all the existing standards in the applications, message/facilities, security services, and the Transport/Networking layers defined by SAE International, ETSI, and IEEE [39]. Since this paper focuses only on the characteristics of these higher layers, the proposed methodologies are also applicable to C-V2X. Due to the comparable performance in V2V communications, quantitative results based on simulations should also apply to C-V2X.

III. BASE KNOWLEDGE
This section presents the base knowledge required for understanding of this paper. An introduction on the Dedicated Short Range Communication (DSRC) stack is presented in Section III-A, while the IEEE 1609.2 standard is described in Section III-B.

A. Dedicated Short Range Communication
The Dedicated Short Range Communication (DSRC) stack is the current standard for V2V and V2I wireless communications. The PHY and MAC layers of DSRC are based on IEEE 802.11p [21], the network layer adopts the IEEE 1609 Wireless Access in Vehicular Environments (WAVE) protocol [20], and the transport layer uses the well-known Internet protocols (UDP and TCP). At the application layer, the DSRC stack includes 15 different types of messages [42]. As an example, the Map message provides intersection and roadway lane geometry data for one or more locations, and the TravelerInformationMessage contains a variety of traffic conditions such as weather, local or regional emergencies and speed warnings. The most used schema is the Basic Safety Message (BSM), which is designed for low latency and safety-relevant applications. The default size of each safety message is 254-byte and includes two types of data. The first part of a BSM message is mandatory and contains the core information about the vehicle (i.e. its size) and its status (i.e. speed, position, and accelerations). The second part is optional and adds a variable number of event-related data, such as notification about the activation of safety-related subsystems within the vehicle (e.g., the activation of the ABS).

B. IEEE 1609.2
The IEEE 1609.2 [19] standard includes (I) the security services that must be supported by all the devices, (II) the schema of the messages, and (III) the adopted cryptographic schemes and protocols.
1) Security Services: IEEE 1609.2defines two types of security services: the WAVE Internal Security Services and the WAVE Higher Layer Security Services. The services composing the WAVE Internal Security Services are the Secure Data Service (SDS) and the security management. These two services are used to convert Protocol Data Units (PDUs, unsecured by definition) into Secured Protocol Data Units (SPDUs) and vice-versa. The security services defined in the WAVE Higher Layer Security Services are the Certificate Revocation List Verification Entity (CRLVE) and the Peer-to-Peer Certificate Distribution Entity (P2PCDE). The former service is used to validate incoming Certificate Revocation List (CRL), forwarding the revocation lists to the Security Services Management Entity (SSME); while the latter service is used to enable Peer-to-Peer certificate distribution.
2) Message Schemas: The IEEE 1609.2standard supports three types of SPDUs: unsecured, signed, and encrypted. Unsecured SPDUs do not provide any security guarantees. Signed SPDUs guarantee authenticity and non-repudiation and can be used for authorization mechanisms and Basic Safety Messages (which are not encrypted). Encrypted SPDUs guarantee confidentiality. It is possible to combine Signed and Encrypted SPDUs into a single SPDU through encapsulation to guarantee authenticity, non-repudiation and confidentiality. We remark that signature verification is performed for each received message, and in a V2V communication protocol the number of messages received by any given vehicle is greatly larger than the number of messages sent within the network. Due to these characteristics, one of the most computationally expensive operations operated by vehicles is the verification of the digital signatures attached to Signed SPDUs.
3) Cryptographic Schemes: The IEEE 1609.2standard requires adopting the Elliptic Curve Digital Signature Algorithm (ECDSA) instantiated with one out of three elliptic curves identified as NIST-P256, BrainpoolP256r1 and BrainpoolP384r1. Moreover, IEEE 1609.2requires a Public Key Infrastructure (PKI) to distribute public keys, where trusted Certification Authorities (CA) bind the identity information of communicating parties to their public keys within certificates. Two types of certificates are supported: traditional certificate chains and implicit certificates [12]. For implicit certificates, the IEEE 1609.2standard specifies usage of the Elliptic Curve Qu-Vanstone (ECQV) scheme. Intuitively, an ECQV certificate does not include the public key of the sender but allows a recipient to re-compute it by using the certificate of the sender and the public key of the CA, thus saving network usage. Network savings of implicit certificates can be considered negligible in most Web scenarios because communications are mostly high-bandwidth and can tolerate latency. Moreover, certificates are only used once during the secure channels handshakes. However, vehicular networks are characterized by datagram-oriented communications that include small data packets, each including a digital signature and a certificate (especially safety-critical packets, see Section IV). Moreover, vehicular networks, especially vehicle-to-vehicle communications, are deployed on low-rate wireless networks and have tighter latency requirements. Hence, ECQV is the best fit for this scenario.
The ECQV operations framework includes four routines: certificate sign request, certificate generation, certificate reception and public key extraction. These operations, combined with the signature and verification procedures of ECDSA, allow guaranteeing message integrity and authenticity by using trusted CAs as trusted anchors. In the following, we describe the flow of the operations from the generation of an ECQV certificate to the signature verification by referring to Fig. 1.
The actors are the requester client, the certification authority (CA) and the receiver client. The requester client generates a Certificate Sign Request (CSR) via the CSR generation function (CSRGen). The CSRGen function requires the ID of the entity requesting the certificate and produces an output composed by the CSR (that includes ID and PK, which is the intermediate public key of the requester) and the intermediate private key sk (Algorithm 1).
The CSR is sent to the CA that produces the corresponding certificate CRT and the private key contribution r by using the CRT generation function (CRTGen, Algorithm 2). sk , PK = KeyGen 5: P = PK + PK 6: CRT := (P, ID) 7: x = H (P ID) 8: while (x · P + PK CA ) = O 9: r = (x · sk + sk CA )mod 10: return(CRT , r) if PK U = PK U then 7: return InvalidCertificate 8: After having received the CRT from the CA, the requester validates it with the CRT reception function (CRTReception). Upon verification, the requester generates the final key pair (sk U , PK U ) by using CRT and r (Algorithm 3).
The private key sk U is used to generate the signature σ of the messages m with the ECDSA signing function (Sign). The client then broadcasts the message m, the signature σ and its own certificate CRT (Algorithm 4).
Each receiver client uses the public key extraction function (Extract) to extract the public key of the sender client from the CRT (Algorithm 5), which is later used for the verification of k{0, 1} n−1 7: while r = 0 10: while s = 0 12: return σ = (r, s) if r ≡ x 1 mod n then 10: return ValidSignature 11: else 12: return InvalidSignature the signature of the message with the verify function (Verify, Algorithm 6).

IV. PROTOTYPE IMPLEMENTATION AND MICROBENCHMARKS
This section describes the microbenchmarks of ECDSA and ECQV on representative automotive-grade boards. Results have been obtained by using our prototype implementation that supports the NIST P256 curve (secp256r1) as required by the IEEE 1609.2standard. The implementation depends on the microECC [26] library, that provides efficient elliptic curve operations on constrained devices thanks to optimized ASM code for ARM platforms.
The implementation complies with the following best practices: r cryptographic operations comprising secret information adopt time-constant code to avoid timing side-channels (e.g., no conditional branches, time-constant scalar point multiplication [8]); r no variables are allocated by using dynamic memory allocation; r random numbers are generated with a hardware TRNG when available, otherwise we use the software pseudorandom number generator provided by the board library; r although the implementation supports multiple elliptic curves, the code selects only the required curve at compile time to avoid wasting storage by including useless code; r elliptic curve points are always transferred by using the compressed format defined in the standard SEC 1 [11] to reduce the network overhead, while cryptographic operations are computed by using the uncompressed representation (x, y). The source code of the prototype implementation is open for reuse and inspection by researchers and industry practitioners. 1 The testbed of the evaluation included the following automotive-grade boards: These boards are similar to automotive microcontrollers produced by STMicroelectronis [1]. For completeness, we also include results of an x86_64 architecture: a modern laptop with an Intel Core i7-9750H.
We observe that the implementation is single-threaded. This is a typical design choice for most cryptographic algorithms that cannot be easily parallelized without the risk to introduce security vulnerabilities. This is not a limitation since low-power embedded devices are based on single-core architectures, and more powerful architectures can verify concurrently multiple signatures on different cores.
The columns of Table I represent the platforms used for the evaluation, while the rows represent the cryptographic operations of ECDSA and ECQV: key generation (KeyGen), certificate request generation (CsrGen), certificate generation (CrtGen), certificate reception (CRTReception), extraction (Extract), signature (Sign) and verification (Verify). All results are expressed in milliseconds. We observe that the most powerful ARM architectures (A72 and A53) can execute all operations in a few milliseconds, while cheaper ARM architectures (ARM11) are an order of magnitude slower. Moreover, ultra-low power architectures (M4 and M3) are two orders of magnitude slower, thus requiring a few hundred milliseconds to execute each operation. We observe that although the certificate generation operation (CrtGen) can usually be deployed on a dedicated server machine, the implemented library would also be able to generate novel certificates with low-power devices.
We now analyze the applicability of our implementation deployed on automotive-grade boards for securing V2V communications. To this aim, we consider communication requirements defined by the National Highway Traffic Safety Administration (NHTSA) [31], which considers multiple vehicle communication scenarios and defines the constraints that must be satisfied to guarantee safety. Among these constraints, we are interested in the allowable latency, which is the maximum latency allowed for end-to-end communication and processing of data, and the communication range, which is the maximum distance for which the communication is of interest for the receiver. The report identifies 8 high-priority and safety-critical scenarios, and for each of them defines the associated allowable latency and communication range: We evaluate the timings required to compute all the due cryptographic operations for sending and receiving an authenticated message on the automotive-grade boards. We define three device roles: full sender (FS), direct sender (DS), and receiver (R). The device operating as FS generates a novel certificate for each communication, as used in the Butterfly protocol [50], while a DS device requests a valid certificate offline and uses the same certificate for multiple communications. The operations required by a FS are CsrGen, CRTReception, and Sign, while the only required operation for a DS is Sign. The R devices must extract the public key from the certificate and verify the validity of the signature, thus requiring the execution of Extract and Verify. Table II shows the timings required for the cryptographic operations executed by each role. Table III summarizes the applicability of the considered automotive-grade boards for secure V2V communications in the scenarios outlined by the NHTSA. The rows of Tables III represent the three most strict allowable latencies (20 ms, 100 ms, and 1000 ms), while the columns represent the different platforms and roles. The FS and DS sub-columns are used to present the applicability of each board as a sender device with regard to send rates, and the R sub-column shows the maximum number of messages that the platform can validate as a receiver within the allowed latency. We remark that the actual number of received messages depends on the number of vehicles within the communication range, hence it might exceed the validation capability of a board. We investigate the capabilities of the boards in real traffic scenarios in Section V. In the following we summarize the main results. With an allowable latency of 20 ms, it is possible to deploy the x86_64, the A72 and the A53 boards in the FS role, while in the DS role it is possible to also deploy the ARM 11 board. When using the boards as R role, only the x86_64, A72 and A53 systems are able to verify the signatures of 29, 6 and 3 incoming messages within the allowable latency. In safety-critical applications with allowable latency of 100 ms, it is possible to use the x86_64, A72, A53, and ARM 11 boards in all roles, while the M 4 nor M 3 boards cannot be deployed for any role. The maximum number of messages that the boards are able to verify within the 100 ms allowable latency in the R role are 144, 33, 15, and 3 for the x86_64, A72, A53, and ARM 11 boards, respectively. Moreover, we highlight that both the M 4 and M 3 boards are not able to send any message nor to verify any signature within allowable latencies of 20 and 100 ms due to their limited computational power. Finally, with an allowable latency of 1000 ms, it is possible to deploy all the boards for all the roles, but the M 4 and M 3 board can only verify 3 and 2 signatures respectively. Finally, the M 4 and M 3 boards can still be deployed for non-safety-critical scenarios with higher allowable latencies, as demonstrated in [37].

V. SIMULATION IN REALISTIC TRAFFIC SCENARIOS
We assess the applicability of the automotive-grade boards to realistic traffic scenarios in simulated environments. We describe the characteristics of the traffic scenarios in Section V-A and the results of the simulations in Section V-B, and we analyze the applicability of the boards in Section V-C. In Section V-D we adopt the results of the simulations to assess the advantages of implicit certificates over certificate chains in V2V networks.

A. Realistic Traffic Scenarios
To recreate realistic simulations, we use data regarding the city of Modena for multiple road and traffic scenarios. We characterize each scenario by using multiple parameters, including the average number of vehicles per hour, the distribution of

B. Simulations Results
We simulated the considered scenarios by using VEINS [52], that is an open source framework for vehicular network simulations based on OMNeT++ [58] for the simulation of networks, and on SUMO [24] (Simulation of Urban MObility) for the simulation of the road traffic. In our simulation, we adopted the IEEE 802.11p, IEEE 1609.4 DSRC/WAVE [16], Physical Layer [9], Obstacle Shadowing [51] and Antenna Patterns [15] modules. The first two modules (IEEE 802.11p and IEEE 1609.4 DSRC) extend the VEINS capabilities by enabling the DSRC/WAVE stack, including Quality-of-Service channel access, the Wave Short Message (WSM) management and periodic beaconing of BSMs. For details on the protocols please refer to Section III. The other modules simulate the propagation and attenuation of the wireless signals to recreate proper signal coverage of messages in urban environments.
The simulations aim to provide meaningful insights about the actual number of messages received by all the vehicles in a particular road scenario, hence we recreated the four scenarios based on the city of Modena. Each scenario is used twice in our simulations, once to simulate the communication between vehicles during the rush hour as a high traffic condition (Rush), and once to simulate the communications during normal traffic conditions (Normal).
We recreated the scenarios within the simulated environment by using the road and polygonal maps of the buildings available at Open Street Map [56]. The vehicles simulated in our scenarios are programmed to send beacon messages with a frequency of 10 Hz (i.e. one message each 100 milliseconds), as recommended by the SAE J2945-201712 [43] standard. The four scenarios were simulated for five minutes for both Rush and Normal traffic conditions. Results are summarized in Table IV, including the total number of vehicles and the total number of messages exchanged in the simulated VANETs.
In the following, we analyze the results of the simulations that are of interest with regard to the specifications included in the NHTSA report for 20 ms and 100 ms safety-critical messages respectively (see Section IV).

1) 20 Ms Allowable Latency:
The results of the analysis on the number of messages received by the vehicles in the realistic scenarios with allowable latency of 20 ms and a distance of 50 m are presented in Table V. The columns represent the simulated areas with different traffic conditions and the rows represent the maximum, minimum and average (rounded to the lowest integer) number of messages received by a single vehicle within the allowable latency. The table shows that the maximum number of messages received by the vehicles ranges from 2 to 5 and 5 to 12 in Normal and Rush traffic conditions. In all scenarios and conditions the minimum number of messages is equal to 1.
2) 100 Ms Allowable Latency: The results of the analysis on the number of messages received by the vehicles in the

C. Applicability of the Automotive-Grade Boards
To determine the applicability of the automotive-grade boards we analytically evaluate the time required by each board to verify the authenticity of the messages received by a vehicle in each traffic scenario. To this aim, we multiply the maximum number of messages received by a vehicle for the time required by the boards to extract the implicit certificate and verify the digital signature (see the Receiver timings in Table II of Section IV). Table VII shows the results for 20 ms allowable latency. The rows include the boards and the columns include the traffic scenarios. We highlight in gray the cells of the table that refer to the boards that do not satisfy the latency requirement. The results show that no automotive-grade board can verify all the received messages within 20 ms in the worst case traffic scenario (Rush) by using a single core. Only the A72 board is able to satisfy all Normal traffic scenarios. Moreover, the reference x86_64 architecture can verify the signatures of all the received messages in all scenarios. Table VIII shows the results for 100 ms allowable latency. We omit the boards with timings greater than 4000 ms. The results show that no automotive-grade board can verify all the received messages within 20 ms in the worst case traffic scenario (Rush) by using a single core. Only the A72 board is able to satisfy all Normal traffic scenarios. Moreover, the x86_64 reference architecture can verify the signatures of all the received messages in all scenarios. The results show that no automotive-grade board can verify all the received messages in both traffic scenarios. Only the x86_64 reference architecture is able to verify all the signatures in all scenarios, except for the Grapes scenario in the Rush traffic condition.
The results highlight that even modern vehicles will fail in verifying all safety-related messages in real urban scenarios. As a result, a few safety messages will either be completely ignored, or accepted without verification. Both solutions are unacceptable since they expose drivers and road users to safety risks and cyberattacks. However, we also remark that improved results could be achieved if we consider the concurrent verification of digital signatures by multiple cores of a single board. To

D. Comparison With Certificate Chains
We compare the effectiveness of implicit certificates and explicit certificate chains.
We analyze the sizes of implicit and explicit certificates for ECDSA instantiated over a 256 b curve (secp256r1), that is the recommendation of IEEE 1609.2standards for vehicular communications. Each BSM message transmitted by using the DSRC stack over V2V networks is authenticated with implicit certificates and includes 64 bytes for the ECDSA digital signature, 93 − 180 bytes for the implicit certificate (the size depends on the attached metadata and on padding), and a minimum of 254 bytes for the payload (see Section III-A). Hence, the average size of a full message ranges from 410 to 500 bytes.
Since the size of an ECDSA digital signature is 64 bytes, a message authenticated with explicit certificates (with a certificate chain with no intermediate CAs) is about 64 bytes longer (the actual size may vary depending on padding). The average size of a full message ranges from 474 to 565 bytes. By considering these estimations, using ECQV implicit certificates reduces network usage ranging from 10% to 15%.
The NHTSA report [30] defines variable data rates and distance ranges for V2V communications, which nominally range from 3 Mb/s to 27 Mb/s and from 300 m to 1000 m. The maximum data rate suggested by the NHTSA report for the control channel related to safety applications is 6 Mb/s, while the 27 Mb/s data rate should only be used for bursts. Increasing the data rate from 6 Mb/s to 27 Mb/s can cause higher packet losses and reduced communication ranges. By considering a bandwidth of 6 Mb/s, a latency of 100 ms, an average packet size of 460 bytes for ECQV implicit certificates and of 520 bytes for explicit certificates, the maximum number of messages supported by the network is 163 and 144 messages respectively.
The validation of an explicit certificate requires two digital signature verification operations: the first to validate the signature of the explicit certificate, and the second to validate the signature of the BSM. On the other hand, the ECQV implicit certificate scheme requires only one signature verification, that is, to validate the signature of the received BSM. However, the receiver must first extract the sender's public key by using the ECQV public key extraction operation. An analytic estimation based on the timings of the operations obtained by using the proposed implementation on the automotive-grade boards (see Table I) let us conclude that implicit certificates are comparable to explicit certificates in terms of computational costs.
Our analysis confirms that the use of implicit certificates as indicated by the IEEE 1609.2standard is advantageous to reduce network overhead (and to increase the throughput of wireless vehicular networks).

VI. PRIORITIZATION STRATEGY BASED ON SENDERS POSITION
The results of the evaluation of the applicability in realistic scenarios (Section V) show that the computational constraints of the boards may prevent verification of some messages within safety-critical timings. In this section, we propose a scheduling strategy to identify a subset of messages that should be verified with a higher priority. The strategy adopts heuristics based on the relative positions of the vehicles. Upon reception of a message, the receiving vehicle extracts the geographical coordinates of the sender. If the coordinates are within a certain area surrounding the receiver, they are verified and analyzed before the other messages. Two rationales guide this approach. First, messages sent by vehicles that are relatively far from the receiver do not convey meaningful information for immediate reaction, hence it is safe to ignore their content, thus decreasing the number of signature validations. Second, messages sent by vehicles that are equally distanced from the receiver may have different importance depending on their relative positions. In the following, we analyze the impact of the proposed strategy in the scenarios considered in Section V by considering three different areas: circular, elliptical, and forward-facing. We consider the same scenarios of the simulation presented in Section V-A and analyze the number of messages sent within the areas. For each area and for each scenario, we evaluate the average time required by the boards to analyze all the prioritized messages.

A. Circular Area Heuristic
We consider a distance-only approach where the receiving vehicle controls whether the sender vehicles are within a circle with radius r. The values of the radius r in our analysis are 150, 250 and 300 meters, that are the distance requirements proposed by the NHTSA report for the 100 ms latency. As a comparison, we also report results for a radius of 1000 meters, that is the typical maximum communication range of DSRC. Table IX shows the average number of messages sent within the circle of radius r. The columns represent the scenarios used in our evaluation and the rows represent the values of the radius r. The table shows that on average the 26%, 59% and 66% of the messages are sent by vehicles within a maximum distance of 150, 250 and 300 meters. All messages are within the maximum distance of 1000 meters. Table X shows the timings required for each board to verify messages authenticity within the circular area within 100 ms. Cells of the table with a gray background identify the scenarios that cannot be deployed due to high timings. We observe that it is possible to deploy the A72 board to satisfy almost all scenarios with a radius of 150 meters (the only exception is Grapes with heavy traffic conditions). We observe that the A53 platform is only able to satisfy an extremely limited number of scenarios, and the ARM 11 is not able to satisfy any scenario. For this reason, we omit the m4 and m3 boards that have even worse performance.

B. Elliptical Area Heuristic
The elliptical area considers the surroundings of the vehicle by building an ellipse centered on the vehicle. This type of area gives more priority to vehicles that are behind or in front of the receiver, and reduces the priority of side vehicles. This heuristic is useful in particular in all those scenarios that do not require information from the side vehicles, as the Pre-Crash Sensing in one-way road (e.g. Highway), Lane Change Warning that provides a warning to the driver if an intended lane change may cause a crash with nearby vehicles, Cooperative forward collision warning that is designed to aid the driver in avoiding or mitigating collisions with the rear-end of vehicles, Emergency Electronic Brake light application that sends a message to other vehicles following behind, and Left Turn Assistant with regard to vehicles coming from the opposite direction.
We model the elliptical area by using the equation x 2 a 2 + y 2 b 2 = 1, where a denotes the side distance and b denotes the distance from the front and rear vehicles. We consider a single value for the parameter a of 25 meters. Instead, we consider multiple values for the parameter b of 150, 250, 300 and 1000 meters in case of 100 ms allowed latency, and a single value of b of 50 meters for the 20 ms allowed latency. As a result, we consider a total of five different ellipses. Table XI shows the average number of messages sent within the different ellipses. The columns represent the different scenarios and the rows represent the values of the two parameters a and b. The table shows that the number of messages received within 20 ms allowed latency ranges from 6% to 10% for the different scenarios, and on average the 17%, 18% and 20% of messages are received within 100 ms for values of b equal to 150 m, 250 m and 300 m, respectively. Table XII shows the timings required for each board to verify messages authenticity within 20 ms and 100 ms allowed latencies. We observe that it is possible to deploy the A72 and A53 boards to satisfy almost all scenarios within 20 ms allowed latency (the only exception is Grapes with heavy traffic conditions). Instead, ARM 11 and less powerful boards are not able to satisfy any scenario within 20 ms allowed latency. For 100 ms allowed latency, the Grapes scenario with heavy traffic conditions still cannot be satisfied by any board (with the exception of the reference x86_64 architecture) and the Grapes

C. Forward-Facing Area Heuristic
The forward-facing area considers a circular arc in front of the vehicle. This type of area helps to further improve all the scenarios in which priority should be given to front vehicles like the Pre-Crash Sensing, Left Turn Assistant, and Stop Sign Movement.
We denote the angular aperture of the circular arc as α, for which we consider values of 90, 135, and 180 degrees. Moreover, we consider values for the radius of the arc equal to 50 and 300 meters for the 20ms and 100ms allowed latencies, respectively. These values are compliant with recommendations by the NHTSA for the considered scenarios. Table XIII shows the average number of messages sent within the different forward-facing areas. The columns represent the different scenarios and the rows represent the values of parameter α. The table shows that the average number of received messages are 3%, 4% and 6% for 20ms allowed latency, and 6%, 8% and 36% for 100ms allowed latency, for 90, 135 and 180 degrees, respectively. Table XIV shows the timings required for each board to verify messages authenticity within 20 ms and 100 ms allowed latencies. We observe that it is possible to deploy the A72 and A53 boards to satisfy almost all scenarios within 20 ms allowed latency. Instead, ARM 11 and less powerful boards are not able to satisfy any scenario within 20 ms allowed latency. For 100 ms allowed latency, the A72 board satisfies almost all scenarios. The A53 board satisfies all scenarios for α equal to 90 and 135 degrees, but it can only satisfy a few scenarios for α equal to 180 degrees. The ARM 11 board can satisfy only very low traffic scenarios.

D. Evaluation of the Prioritization Strategy
Our results demonstrate that prioritizing messages based on the position of the sender is a viable solution to validate all relevant safety messages in real traffic conditions by adopting general purpose automotive-grade boards. By using the circular area heuristic described in Section VI-A we confirmed that the distance-prioritization scheme implicitly specified in the NHTSA requirements help to reduce the number of signatures by up to 75% with a distance of 150m, but this heuristic is not sufficient with greater distances (e.g. 300m) and heavy traffic scenarios as shown in Table X. By introducing more complex heuristics like the elliptical area described in Section VI-B we can improve the applicability of the boards enabling low power boards like the A53 to be suitable in most scenarios as shown in Table XII. Finally, with the Forward-facing area heuristic VI-C, we can further improve the applicability of the boards by reducing by up to 90% the number of the messages in some specific scenarios (see Table XIV).
A question that is worth analyzing is whether the proposed prioritization strategy affects the security guarantees of the protocol. In particular, we show that the strategy does not improve nor decreases security guarantees. We analyze the security guarantees with regard to the IEEE 1609.2 standard and the NHTSA specifications. The proposed strategy does not conflict with safety requirements specified by the NHTSA (Section IV) and can be potentially integrated with other prioritization strategies based on the classes of messages. Moreover, the proposed strategy requires that the authenticity of all the messages must be verified by using the ECQV scheme as specified by the IEEE 1609.2 standard.
We observe that the proposed strategy is not meant to defend receiving vehicles against Denial of Service (DoS) attacks by adversaries that are within the communication range of the receiver. First, attackers could transmit any number of messages to saturate the wireless communication channel and thus completely jam the wireless network [3]. This type of attack is outside the scope of the paper because it regards the physical layer of the communication protocols stack. Second, attackers could send messages with fake sender position either with legitimate or illegitimate digital signatures. The first case is outside the scope of the paper because we consider legitimate senders to only send legitimate information. The effects of false information sent by legitimate vehicles are further analyzed in [36]. In the second case, messages with illegitimate digital signatures are discarded by receivers. However, the proposed prioritization strategy is based on senders positions before verifying message authenticity. A potential attack could envision sending a high number of messages with fake sender positions that satisfy the heuristic that could saturate the verification throughput of the receiver, thus possibly causing a Denial of Service. Despite this type of attack, the proposed strategy does not introduce security issues. First, since the prioritization heuristics are modeled after the NHTSA heuristics, the messages that are discarded due to the attacks are those that have also a lower priority for safety recommendations. Second, an adversary with the same capabilities (e.g., sending a message within the communication range of a certain vehicle) can operate an even more powerful DoS attack by simply jamming the physical layer of the wireless network, as mentioned above.

VII. CONCLUSION
This paper presents an experimental evaluation of ECQV performance on automotive-grade boards for their application in VANETs communications. As a first contribution, we propose an open implementation of ECQV and ECDSA cryptographic operations, available at [38]. This implementation is used to test the performance of four different automotive-grade boards with different roles, in terms of maximum number of messages that these platforms can verify in a given time window. This second contribution allows to estimate the highest possible workload that each board can sustain, and demonstrates their applicability in both normal and safety-critical scenarios identified by the NHTSA in V2V communications. As a third contribution, we performed an experimental evaluation of the applicability of the boards in realistic scenarios, representing different portions of a real city (Modena, Italy) characterized by different traffic conditions. These experiments allow us to define several reference workloads that are representative of the number of messages that a single car has to receive and validate in an urban scenario. These workloads demonstrate that even powerful boards are not able to verify the signatures of all the incoming messages within the maximum allowed time. To mitigate this issue and improve the applicability of constrained hardware platforms to the V2V context, we propose and evaluate different heuristics to prioritize signature validation as our final contribution.