How to Secure ITS Applications? Rim MOALLA*#, Brigitte LONC*, Houda LABIOD#, Noemie SIMONI#

# Department of Computer Science and Networks, Institut telecom; Telecom ParisTech Paris, FRANCE

labiod@telecom-paristech.fr

simoni@telecom-paristech.fr * DIESE Sce 65608, RENAULT

1 avenue du Golf,F-78288 Guyancourt, FRANCE Rim.moalla@renault.com

Brigitte.lonc@renault.com

Abstract— Intelligent Transportation Systems (ITS) based on vehicular communication enable cooperative applications to improve road safety and traffic efficiency. Security remains a major challenge because it has a great impact on implementation and deployment of ITS applications. In this paper, based on recent standardization activities, we give an overview of ITS applications and we detail a classification of road safety applications. Then, we investigate the security issues of cooperative ITS applications and we present their security profiles. Taking into account the communication architecture of an ITS Station, we advance a new application oriented security approach.

Keywords— V2X communications; ITS applications; security requirements; ITS architecture; ETSI; IEEE 1609.2

I. INTRODUCTION Intelligent transportation systems (ITS) have been recently

attracting attention from industry and research communities as they promise to be a solution for enhancing road safety. ITS, as shown in fig1, are cooperative systems involving three types of entities or stations: vehicle, Road Side Unit (RSU) and central servers. They support three types of V2X communications: vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I) wireless communications, and Infrastructure-to-Infrastructure (I2I) communications. In addition to wireless technologies already deployed like 3G, the ITS G5 (5.9 GHz frequency band) is used for Wireless Access in Vehicular Environments (WAVE).

Fig. 1 Intelligent Transportation System

ITS propose diverse applications for driver and passengers. ITS applications which are generally critical applications that may affect human life, have specific requirements and challenges such as real-time constraints, high availability of network and accuracy of information. In fact, the main purpose of ITS applications is to assist driver on the right time with right information. Moreover almost ITS applications require personal data like location data. For these reasons, ITS applications must be secured and the major question is how to secure ITS applications? Actually, securing ITS applications is a complex task because it deals with securing various elements including data, communication links, communication protocols, servers, etc.

This work aims to give an up-to-date overview of ITS applications, their characteristics and their security requirements. We focus in this paper on the most recent work and information, presented in ETSI and IEEE standards related to ITS applications domain.

We introduce, in section II, a classification and basic characteristics of ITS applications. In section III, we explain their security requirements and challenges. In section IV, we present an overview of future ITS architecture and we advance our application security approach. The final section V concludes this article and gives an outlook for future activities.

II. ITS APPLICATIONS Within the first defined classification, vehicular

applications were classified into either ITS applications or non-ITS applications [1]. ITS applications present the primary vision of vehicular applications and aim to minimize accidents and improve traffic conditions by providing drivers with useful information. Non-ITS applications are driver and passenger oriented applications, which include Internet connections and multimedia services. They also include commercial and comfort applications.

More recently, ETSI TC ITS standards [2] have classified vehicular applications, renamed ITS cooperative applications, into three classes: Road Safety, Traffic Efficiency, and other applications (eg comfort and business applications).

2012 Vehicular Communications and Applications Workshop

978-14577-0900-5/12/$26.00 ©2012 IEEE 113

Fig. 2 ITS applications classifications: (a) classic classification, (b) ETSI classification

A. Road Safety Road Safety applications presented in fig3 are primarily

defined to decrease the number of road accidents. We classify these applications, in two classes: “Driver Assistance Applications” which purpose is to inform and assist driver to avoid road dangers or accidents, and “Actions on Vehicle Applications” aiming to provide necessary information to vehicle systems to avoid or to reduce damage of accidents. In Driver Assistance Applications, the driver is continuously informed of road hazad and is the only responsible of evaluating the relevance of received data and then taking if necessary adequate actions like changing lane or braking. Generally, these applications generate a sound and light alarms/information in the range of 2 to 30 seconds before collision in order to instruct the driver to take an immediate action. Unlike “Driver Assistance Applications”, decisions and actions in “Actions on Vehicle Applications” are automatically initiated by vehicle systems a few seconds (between 1s and 3s) before a high probable event like crash. “Actions on Vehicle Applications” are the most sophisticated Road Safety applications and require a high level of security and safety of vehicle systems to be operational.

European and American ITS related standards and most of the projects carried out in this domain focus on “Driver Assistance Applications”, defined by OEMs as primarily Road Safety applications. These applications will be the first deployed cooperative Road Safety applications. In “Driver Assistance Applications” class, three applications are being standardized by ETSI: Cooperative Awareness Applications (CAA) [3], Longitudinal Collision Risk Warning (LCRW) [4] and Intersection Collision Risk Warning (ICRW) [5]. CAA consists on increasing the vigilance of the driver by providing relevant information when another vehicle or RSU detects and reports a road hazard. CAA is involved in the range of 5 to 30 seconds before a probable collision. However, LCRW and ICRW are activated in the range of 3 to 5 seconds before a collision and aim at avoiding collision by sending an alert to driver requiring an immediate action. “Driver Assistance Applications” use two main types of safety messages: Cooperative Awareness Message (CAM) [6] and Decentralized Environmental Notification Message (DENM) [7]. These messages are exchanged between vehicles and RSUs. CAM messages are constantly broadcasted at variable frequencies between 1Hz and 10Hz whereas DENM messages are event messages broadcasted when an event is detected.

Fig. 3 Road Safety applications

Fig. 4 CAM Message

Fig. 5 DENM Message

Multiple use cases related to Driver Assistance applications

are presented in [8], [9] such as “emergency electronic brake light”, “stationary vehicle warning”, “signal violation warning”, etc. In fact, a use case represents the utilization of an application in a particular situation with a specific purpose [8]. On the road, multiple situations and scenarios can occur. In order to cover most of scenarios of possible road collisions, different use cases related to each application class are defined. For example, wrong way driving warning is a use case of LCRW application and consists on sending a DENM message to warn vehicles when detecting a vehicle driving in a wrong way which may cause a longitudinal collision.

B. Traffic Efficiency Traffic efficiency applications aim to improve traffic flow

management, traffic assistance and cooperative navigation. Regulatory / contextual speed limits notification and Traffic information and recommended itinerary are two examples of these applications.

C. Other applications There are essentially business and mobility applications.

Typical examples of business applications are communities’ services, which include insurance and financial services. Point of interest notification is an example of mobility applications.

Traffic efficiency and others applications are based on different V2X messages like: -Service Announcement Message (SAM), which is a control message, sent by an RSU to announce provided services like internet access to vehicles, and Electric Vehicle Charging Spot Notification (EVCSN).

DENM Message ITS PDU HEADER

MANAGEMENT CONTAINER

SITUATION CONTAINER

LOCATION CONTAINER

VARIABLE CONTAINER

CAM Message ITS PDU HEADER

BASIC CONTAINER

BASIC VEHICLE

CONTAINER

BASIC VEHICLE

CONTAINER STATIC

SPECIAL VEHICLE

CONTAINER

(a) (b)

114

ITS enable diverse cooperative ITS applications with different communication characteristics and requirements. For example, some ITS applications generate periodic messages, other applications generate only event messages and others generate both types of messages. In addition, a number of ITS applications need critical time communications like road safety applications while other applications have no time constraints. Different applications and use cases give rise to different security requirements. The identification of security requirements covering various fields of applications and use cases is needed. This will allow the identification of potential optimized security solution with best technologies to integrate in future intelligent transportation systems.

III. SECURITY REQUIREMENTS AND CHALLENGES In the following, we present a number of basic ITS security

requirements. These security requirements and security challenges should be considered during the definition of security architecture and protocols.

• Availability: ITS applications, particularly safety applications, require high availability of the system.

• Authentication and Authorization: Authentication ensures that entities involved in communication are correctly identified and authentic. Entity authorization is necessary for applications that need definition of the rights that an entity (vehicle or infrastructure) has.

• Integrity: Integrity is a key security requirement for ITS applications especially Road Safety applications and it is ensuring that exchanged information are not altered between sender and receiver.

• Confidentiality: Some ITS applications require that the content of a message is accessible only by the sender and the receiver.

• Non-repudiation: it may be crucial in some cases (eg wrong information that causes accident) not only to identify a sender but also to get the proof of the originator of the message (for accountability).

• Privacy: privacy is a major security requirement as ITS applications exchange personal data in particular location data over wireless communications. The design of ITS security solution must take into consideration measures to ensure protection of personal data and privacy. ITS applications must comply with European Directives relevant to the protection of privacy and data protection: the Directive 95/46/EC on data protection.

• Plausibility: plausibility checks are used to validate the correctness of the data and can be performed on the received message information. For example, the claimed information state sent from vehicles must reflect their actual physical state.

In addition to security requirements, ITS have specific security challenges, presented below and related to the vehicular environment.

• Large scale and heterogeneous system: a large number of vehicles and road infrastructures will be communicating. Different manufacturers and carmakers will use different implementations.

• High mobility: vehicles move at a fast velocity changing the reception area of vehicles (topology of system). ITS are highly dynamic environments.

• Critical time constraints: A critical feature in ITS is their time sensitiveness. It is a very challenging task for application to send, process and receive messages on time. Security mechanisms should be optimized to meet critical time constraints.

• Very low tolerance for errors: as decision in ITS, based on received information, may affect human life, ITS need right and correct information. Therefore, ITS applications have a very low tolerance for errors.

• A huge number of ITS applications: ITS applications have different characteristics and may have different security requirements. The challenge is to define security requirement to each application and not applying the same security services to all ITS applications.

• Trade-off authentication versus privacy: privacy of drivers is a basic right that must be protected. So, identity and personal data must not be disclosed. On the other hand, systems entities should be authenticated and authorized to access services/data.

We draw up a table I in which we list for different classes of ITS applications the needed security requirements.

IV. SECURITY ON FUTURE ITS ARCHITECTURES The design of an efficient communication architecture in an

ITS station is very critical in order to be able to propose a powerful and complete security solution adapted not only to ITS applications but also to ITS communication architecture.

Many organizations such as C2C-CC, projects like COMeSafety and standardization institutions like ISO-CALM, IEEE and ETSI have defined several ITS communication architectures. Focusing on ETSI architecture, we give in the following section an overview of the defined architecture.

A. ETSI based ITS communication architecture European ITS communication architecture is described in

ETSI standard EN 302 665 [2]. The communication architecture, shown in fig 6, consists of four layers: access, networking/transport, facilities and applications. This architecture contains also two cross layers one for security and the other for management, which is the specificity of this architecture compared to the traditional OSI layered model. We present briefly the different layers of this communication architecture.

• Access layer: aims to interface with both wired and wireless communication technologies that are available in an ITS station. ETSI ITS G5 is an access technology used for Safety applications and represents the European profile of IEEE 802.11p.

• Networking & transport layer: provides data transport between source and destination ITS stations. It is composed of two parts: ITS specific network and transport protocols and IP-based network and transport protocols.

115

Fig. 6 Communication architecture of an ETSI ITS station [2]

• Facilities layer: acts as a middleware and is composed of three function blocks: application support, information support, and communication functions support. These blocks contain support like messages generation and environment information to all ITS applications.

• Application layer: implements and executes one or more ITS applications presented in section II.

• Management cross layer: concerns transversal management of horizontal layers defined above. It includes management of communications depending on requirements of ITS applications.

• Security cross layer: provides security services and management of these services to all layers in the communication stack.

B. Analysis of security standardization activities In this section, we present ETSI standardization activities

dealing with security in ITS communication architecture and compare it with IEEE similar activities.

ETSI TC ITS is interested into ITS system and is organized in five working groups: The working group ETSI TC ITS WG5 addresses security in ITS. A major achievement of ETSI’s work in this area has been the publication of the technical report Threat, Vulnerability and Risk Analysis (TVRA) in ITS: ETSI TR 102 893[10], then, the publication of ETSI TS 102 731 [11] describing security services for ITS. A third document ETSI TS 102 867 which aims to define a security architecture for ITS is approved but not published. The ETSI approach intends to define security modules and mechanisms to be used by all communication layers.

In US, IEEE develops WAVE (Wireless Access in Vehicular Environment) standards which include IEEE 1609 protocols and IEEE 802.11p [12]. IEEE 1609 defines standards for upper layers based on IEEE 802.11p. We point out that IEEE standardization activities related to security in ITS is more advanced than ETSI activities. In fact, IEEE

TABLE I : ITS APPLICATIONS AND SECURITY REQUIREMENTS

Communication types

Exchanged messages

Mode of transmission

Examples of use cases Security requirements

Road Safety V2V

CAM Broadcast -Emergency vehicle approaching indication -Stationary vehicle indication -Emergency electronic brake lights warning

Authentication Integrity Privacy Plausibility Availability DENM GeoBroadcast

I2V CAM Broadcast -Traffic condition

indication -Roadwork warning

Authentication Integrity Plausibility Availability

DENM GeoBroadcastSPAT Broadcast

Traffic Efficiency I2V

SAM+ othermessages

Broadcast -Traffic information and recommended itinerary -Regulatory / contextual speed limits notification

Authentication Authorization Integrity Availability

Others Applications

I2V SAM+EVCSN Broadcast -Point of Interest notification: charging point of electric vehicles

Authentication Authorization Integrity Availability

V2I&I2V

-Insurance and financial services

Authentication Authorization Integrity Privacy Confidentiality Non repudiation

116

1609.2 standard [13] defines security system architecture, secure message formats, and the processing of those secure messages within the WAVE system. The security position processing in IEEE standard is not clear; some researchers interpret security mechanisms defined in IEEE 1609.2 as a security process in application layer, others interpret it as a security mechanisms to be applied in all layers over physical and IEEE 802.11p MAC layer.

Several European projects deal with communications security like recently SeVeCom [14] and PRE-DRIVE C2X [15]. SeVeCom has not selected communication protocols to secure but has defined communications patterns. Recently and based on ETSI communication architecture, communication protocols can be IP based or ITS specific protocols which are GeoNetworking protocol [16] and BTP protocol [17]. In PRE-DRIVE C2X, security mechanisms and data are integrated in each layer of the communication architecture which is the ETSI communication architecture. [18] discusses security position processing question and concludes that security implementation will be appropriate on networking and transport layer and can be done in application or access layers but not on Facilities layer.

C. Security processing analysis The general approach defined to secure communications

within the ETSI communication architecture is that security services and mechanisms should be included in each layer. This approach can result on a redundant security functions and a high security overhead. For these reasons and regarding ITS applications requirements such as real time constraints and very low latency time, we have to reduce security overhead and choose where to include security processing and what is the appropriate layer for security services integration. Where security should be applied: in Facilities layer or in Networking & Transport layer? In the following, we analyse advantages and inconvenients of each approach.

1) Networking & Transport Layer Security Processing security on Networking&Transport layer is

based on generic approach as it deals network header as well as applicative data (message). There is no need for re-defining the security data payload for each message type. Furthermore, this processing mode allows having secure routing protocols. Especially in case of message forwarding, it is important to have end-to-end security securing both the source and forwarders of the messages. Moreover, common security functions such as integrity can be executed on Networking&Transport layer as it is a common layer for all ITS applications.

But different network and transport protocols can be implemented on the Networking&Transport layer (eg Geonetworking Stack and IP stack) and each protocol has its own specific requirements and packets’ formats. Having a generic security processing on Networking&Transport layer can be not efficient and complex regarding implementation. On the other hand, some security services as confidentiality, privacy are specific requirements of an application. Therefore, if such function is realized on Networking&Transport layer,

the data messages shall contain more information (flag, algorithm identification, key identification etc.). More data streams should be then exchanged between Network and Facilities layers in both directions. During transmission, the Facilities layer communicates its security needs and / or the type of messages to the Network layer. Upon their reception, the Network layer informs the Facilities layer of the security level of the data messages.

2) Facilities layer security As shown in table I, security requirements depend not only

on applications use cases but also on type of carried messages. Then, we believe that the proposal of a generic solution manipulating all applications messages and consequently all network packets could have many drawbacks. Actually, for each type of message, we have to redefine the security functions necessary to apply. The appropriate solution consist in applying security as near as possible to applications context messages which correspond rather to Facilities layer. Moreover, as Facilities layer is like a middleware used by all applications, security services applied on Facilities layer can be re-used by all applications. Indeed, it will be not necessary to re-define the security mechanisms for each application and re-generate the same secure message used by different applications.

In addition, some ITS applications as safety applications require the assurance provided by the signature and certificate verification. That means applications must have the proof and the validation of security services applied to data. If security is not processed in higher layer, Networking&Transport layer must be able to pass security related information of packet from the Network layer to higher layers in the stack. It leads to more data streams exchanged between layers and more time processing that may affect system performances. If security is processed in Facilities layer then lower layer components may be changed or updated without affecting the delivery of applications. For example, an ITS application may change the used communication technologies (change ITS G5 communication to G3 communication) or just integrate a new communication protocol without affecting the security level of applicative data.

Moreover, in some use cases, we need to authenticate the sending application of the message and to verify if user (vehicle or RSU) is authorized to execute it. So, applying a network-layer authentication is irrelevant.

The emerging standards namely IEEE 1609.2 and ETSI TS 102 867 describe security services for applications messages. To ensure interoperability, it is better to follow these descriptions and apply security in higher layers (Facilities and applications layers). Since on current implementations and specifications, the generation of messages is done in the Facilities layer, it will be interesting that security services will be also supported in this layer.

3) Discussion and our application security approach The main advantage of applying security in

Networking&Transport layer is securing all data packets: applicative data and routing information. This provides a

117

generic security solution. But assuming the same security mechanisms for all ITS applications is not optimal. In fact, within ITS system, different categories of ITS applications are defined and each applications type or its associated messages’ types may have specific security requirements. For example some uses cases require privacy like Stationary Vehicle Warning or confidentiality like Parking Reservation other not. In these cases, applying security in higher layer will be better. For privacy requirement which is mandatory in some use cases, pseudonym certificates (authorization tickets) and data minimization are proposed to ensure privacy of users. These mechanisms can be used as well as on network layer or Facilities layer. If this solution is applied on Facilities layer, specific service (application) permissions of an ITS Station can be included in these certificates.

In order to have an optimal security solution, we propose to have specific security solution to each application (message) type/classes depending on security requirements. So we propose to use security within higher layers in order to respect specificity and security requirements of each ITS application. Like this, we define a security service oriented approach in which security depends on the nature of an ITS service (application) and not on the communication type. The advantage of this approach is to have an extensible and flexible ITS system that can be easily updated with new ITS applications; we have not to redefine security mechanisms for the whole system but only the security blocks associated to the new application. Security processing will be an integrated part of applications operation. We are convinced that applying security in Facilities layer will bring efficiency and good performance when deploying future ITS. In this paper, we give arguments to select this direction. Indeed, we propose to adopt generic security modules with specific security mechanisms processed on Facilities layer for first ITS applications defined by Car2Car. Our solution will be able to be upgrade with adapted security mechanisms to newly applications that will be deployed progressively.

It’s obvious that security of ITS applications is necessary but in some cases we need security mechanisms implemented on network level. Multi-hop and unicast communications are concerned with this issue. For the initial deployment of ITS applications, only DENM messages are forwarded on multi-hop using Geobroadcast over GeoNetworking. In this case, the security of the path and the trust of vehicles that participate on packet routing should be proved. We will take into consideration this aspect and define appropriate mechanisms.

We conclude that applying security in only one layer remains not efficient. Following an application security approach is promising but in some use cases still not sufficient. When needed, we extend the application security approach with network security mechanisms. Like this, we define an adaptive and efficient security solution.

V. CONCLUSION In this paper, we have presented an overview of recent

standardization works on ITS applications Domain. First, we have classified ITS applications and specified their security

requirements. Secondly, we presented the European communication architecture of an ITS station in order to outline possibilities of integration of security functions in this architecture. We have then analysed standardization activities of IEEE and ETSI dealing with security in ITS.

Finally, we propose a new approach of integration of security functions at higher layer based on ITS applications constraints and their security requirements taking into account communication architecture of ITS station. In our future work, we will define a complete security solution for V2X messages with security modules, architecture and security policies.

REFERENCES [1] H. Moustafa, G. Bourdon, “Vehicular Networks Deployment View:

Applications, Deployment Architectures and Security Means,” Ubiquitous Computing and Communication Journal, special issue on Ubiquitous Roads, March 2008.

[2] ETSI EN 302 665: “Intelligent Transport Systems (ITS); Communications Architecture”.

[3] ETSI TS 101 539-1 “Intelligent Transport System (ITS); V2V application; Part 1: Cooperative Awareness Application (CAA) specification..

[4] ETSI TS 101 539-3 “Intelligent Transport System (ITS); V2V application; Part 3: Longitudinal Collision Risk Warning (LCRW) application specification

[5] ETSI TS 101 539-2 “Intelligent Transport System (ITS); V2V application; Part 2: Intersection Collision Risk Warning (ICRW) application specification.

[6] ETSI TS 102 637-2 V1.1.1 “Intelligent Transport System (ITS); Vehicular communication; Basic Set of Application; Part 2: Co-operative Awareness Message (CAM) basic service specification”.

[7] ETSI TS 102 637-3 V.1.1.1 “Intelligent Transport System (ITS); Vehicular communication; Basic Set of Applications; Part 3: Decentralized Environmental Notification Message (DENM) basic service specification”.

[8] Georgios Karagiannis, Onur Altintas, Eylem Ekici, Geert Heijenk, Boangoat Jarupan, Kenneth Lin, and Timothy Weil, “Vehicular Networking: A Survey and Tutorial on Requirements, Architectures, Challenges, Standards and Solutions,” IEEE communications surveys & tutorials. vol. 13 issue 4, pp. 584–616, novembre 2011.

[9] M. L. Sichitiu and M. Kihl, “Inter-Vehicle Communication Systems: A Survey,” IEEE Commun. Surveys Tutorials, vol. 10, no. 2, pp. 88–105, 2nd Quarter 2008.

[10] ETSI TR 102 893: “Intelligent Transport Systems (ITS); Security; Threat, Vulnerability and Risk Analysis (TVRA)”.

[11] ETSI TS 102 731: “Intelligent Transportation Systems (ITS); Security; Security Services and Architecture”.

[12] Yangqing Hu, Wei Zhang;,Yang Li;, and Peng Xiong; “The research of WAVE Architecture Based vehicles to vehicles communication technology of Intelligent Transport System”, Power Electronics and Intelligent Transportation System (PEITS), 2009 2nd International Conference on, février 2010.

[13] IEEE 1609.2, Trial-Use Standard for Wireless Access in Vehicular Environments (WAVE) Security Services for Applications and Management Messages, IEEE Std. IEEE 1609.2, version 2006, 2006.

[14] “SeVeCom Project – Secure Vehicle Communications.” [Online]. Available: www.sevecom.org.

[15] “PRE-DRIVE C2X Project - Preparation for Driving implementation and Evaluation of Car-2-X communication technology.” [Online].Available: www.pre-drive-c2x.eu.

[16] ETSI TS 102 636 – 3 v1.1.1 Intelligent Transport System (ITS); Vehicular Communications; GeoNetworking; Part 3: Network architecture.

[17] ETSI TS 102 636 – 5-1 Intelligent Transport Systems (ITS); Vehicular Communication; GeoNetworking; Part 5: Transport Protocols; Basic Transport Protocol.

[18] PRE-DRIVE C2X Deliverable D3.1, “Security Architecture” , 2009

118