Home

Secure Smart Cars and Vehicular Networks

Project for Network and Computer Security

by: André Sobral, João Franco, Fábio Almeida

Problem

So far this year (Jan-Oct 2016) more than 1 million people have already been killed in traffic accidents and more than 28 million have been injured worldwide. Road crashes rank as the 9th leading cause of death in the world with more than 3000 people dying every day. This accounts for 2.2% of all deaths globally.

This statistical data shows how important it is to improve road safety. As in most systems the weakest point in security (not ciber in this case but nonetheless) are people, since even a little distraction can be enough to cause an accident. Therefore automating driving (fully or partially) looks like the most obvious and sensible solution to have safer roads. Supporting this fact are companies like Google and Tesla that are investing large amounts of resources in the development of self-driving cars and auto-pilots to assist human drivers. One major component needed to achieve this goal is a way in which vehicles and possibly other entities can reliably transfer information.

For this purpose, exist Vehicular Ad-hoc NETworks (VANETs), a technology that is based on mobile ad hoc networks (MANETs) and consists on the spontaneous creation of a wireless network (based on proximity) for data exchange from vehicle to vehicle and between vehicles and infrastructures (located alongside the road).

If VANETs were secure, and all information was truthful and accurate, we would have a nearly perfect secure road traffic system where collisions would be very rare. On the other hand, if VANETs are not secure there is a major problem, since the information communicated over this networks is vital and can be the difference between life and death. For example if an attacker can manipulate the information he can indirectly control other cars by sending messages alerting for inexistent obstacles. This would make the car brake, allowing the attacker to perform a robbery even worse.Therefore strict security requirements have to be achieved.

In this proposal we are going to define such requirements and ways in which we intend to solve the goal of achieving secure VANETs. More specifically we are going to address security in VANET beaconing messages, i.e., messages sent from a vehicle to it’s neighbours with information of location, speed, braking and other sensorial data that aid safe decision making.

Security Requirements

Requirements	Possible attacks
Vehicle and RSU identification	Different ids at the same time
Message sender authentication	Impersonation
Integrity of messages	Tampering with a message content
Non-repudiation of the sender	Attacker claims not to have sent a message which contains wrongful information that might harm other users of the system
Freshness of communication	Replaying messages
Data trust	Manipulating vehicle sensors so the car sends the wrong data even though the user is authenticated as a legitimate user
Availability	Flooding the network/vehicle with messages
Vehicle owners and drivers privacy	Identity disclosure, Location tracking

Proposed solution

Firstly we are going to address the identification requirement. To uniquely identify a vehicle we are going to use the Vehicle Identification Number(VIN) since it is emitted once the vehicle is produced, and can never be changed unlike licence plates for example. Moreover licence plates are designed so that they can be used to visually identify a vehicle making it a less appealing on the privacy standpoint.

We now need to ensure that the VIN is really coming from the vehicle it claims. For that purpose we decided to use digital signatures, which not only solves the problem of authentication but also message integrity and non-repudiation of the sender.

Furthermore we have to guarantee that messages are fresh, making it impossible for an attacker to replay them later on. To accomplish this we decided to attach a timestamp to every message, dropping messages with a timestamp above a certain threshold when compared to the current time.

Regarding data trust, more specifically, tampering with the car sensors so it sends wrongful information, we are considering using sensors in the vehicles (such as cameras) and previous information to detect this flawed data, reporting it to the RSU’s which will revoke the certificate of the problematic vehicle after a minimum threshold of reports (low but not low enough so an attacker is able to revoke a legitimate user certificate) have been received.

netwrok_scheme

Being a critical system we have also have to ensure high availability of the system. For that we intend to detect if a user is sending messages too frequently at the communication unit level, only passing them to the OBU after a minimum delta time between messages has passed. We can’t ignore all future messages because they can be critical, but we drop the excess ones that won't affect road safety. How it all works:

message_exchange

General Assumption - CA is always secure.

Stage	Assumptions	Description
Basic	Sensors can fail and can be tampered with.	In this step of the development we are going to implement the whole system, composed by: vehicles, the support infrastructure (RSU), the CA, and the vehicle to vehicle, vehicle to RSU and the CA to RSU communication. We will develop a simple protocol that sends the messages over TCP. Messages will identify the user, satisfying the Identification requirement. We will also complete the data trust requirement as specified before.
Intermediate	RSUs are physically and digitally secure and all network components are always available. Vehicle processing units have infinite resources.	At this stage we are going to implement digital signatures, implement ways to revoke and detect revoked certificates..
Advanced	RSU are only physically secure.	Availability, RSU authentication, use of RSUs as a cache for public keys, diminishing the amount of communication needed with the CA. Use Pseudonym certificates instead of VID’s. Vehicles only use a pseudonym certificate for a short sequence of messages or a period of time. This implies the use of a PP (pseudonym provider) node in the network that is trusted by all the other nodes and has the ability to issue pseudonyms. See [6].

Possible Improvements

Certificate Omission - Our proposal also lacks some possible performance improvements that could be achieved by omitting the certificate and message signature exchanged in some messages. See [7].