## 5 Securing ITS Applications: A Practical Case Study
### The Collision Risk Warning Application Case Study  
As shown in Figure 11, the case study consists of the collision risk warning (CRW) road safety application, in which a vehicle (or roadside unit) detects the risk of collision between two or more vehicles and broadcasts a DENM message to all of its neighboring vehicles. The overall detection and notification process undergoes fourteen main steps, as described below:  
Figure 10: GeoNetworking packet structure as defined in ETSI TC ITS.  
* At time T0, a vehicle (on the left side) performs a sudden and harsh braking due to a detected hazard;
* At time T1, the information related to this harsh braking event is available at the in-vehicle's ECUs;
* At time T2, this information is received by the vehicle's OBU by the corresponding ITS application;
* At time T3, a DENM message is built at the facilities layer, including all of the required information (e.g., timestamp, location, speed, event-type, _etc._);
* At time T4, the DENM message is received and processed by the networking and transport layer;
* At time T5, the DENM message is signed by the security layer using an elliptic curve digital signature algorithm (ECDSA) [12] and is encapsulated (Encap) into a secured message, which includes the certificate of the ITS station;
* At time T6, the signed DENM message is received again by the networking layer and is queued;
* At time T7, the packet is transmitted over the air by the IEEE 802.11p MAC and PHY layers. Eventually, the packet might be re-transmitted multiple times due to collisions and/or harsh propagation conditions at the PHY layer;
* At time T8, the packet is finally received by a neighbor vehicle's OBU (vehicle on the right side of Figure 2);
* From time T9 to T13, the message undergoes the reverse flow, _i.e._, the message is decapsulated (Decap) and verified (using ECDSA) by the security layer and is made available to the ITS application layer at time T13;
* At time T14, a warning message is displayed to the vehicle's driver for taking immediate action or an automatic action is triggered by the vehicle's ECUs (e.g., emergency brake, speed reduction, _etc._).  
As shown in the above communication flow, the real-time availability and processing of the information is a key requirement, especially in life-threatening scenarios, such as road safety applications. If we assume that the second vehicle (on the right) is driving at 120 km/h (around 33 m/s), while keeping a minimal safe distance of 66 meters with the first vehicle (on the left), the  
Figure 11: The collision risk warning road safety ITS application case study.  
time-to-collision (TTC) will be around 2 s. This time period corresponds to the minimal time required to perceive a given hazard (_i.e._, either by humans or machine/ITS-based systems) and to react accordingly in order to avoid the collision. The end-to-end system critical-latency (_i.e._, \(T14-T0\) in Figure 11) is thus one of the most critical requirements for ITS safety applications.  
The typical values of such critical-latencies depend mainly on the target ITS use cases, as listed in Table 1, and are mostly impacted by three main factors: (i) the message queuing and QoS management strategy; (ii) the performance limitations of the underlying wireless channel; and (iii) the overhead of the cryptographic operations. For instance, the ETSI standard recommends the usage of the ecdsa_nistp256_with_sha256 digital signature schema for signing and verifying safety messages [24] (_i.e._, DENM and CAM); whereas the IEEE 1609 standard supports the ecdsa_nistp224_with_sha224 schema [92] in addition to the previous one.