IT Security Issues of Autonomous Cars

Introduction

Over the past decades’ cars have become one of the most complex IT systems. Today each new car has a large number of computer systems interconnected within the car over different bus systems. With the integration of additional assistance systems as required by semi-autonomous or fully autonomous (self driving) cars, the overall complexity of IT systems in the car will increase further as will the requirements for the ability of the car to communicate with cloud services, road-side infrastructure, and other cars.

Communication and its Security Problems

So far the computer systems within the car had only limited connection to the outside world except for their diagnosis interfaces and the interfaces they expose to user devices mainly using Bluetooth -based near field communication technology or direct connection of devices via USB. Some cars also use the cellular network for communication with the workshop or with other centralized systems used for monitoring or for emergency responses. So far cars did not provide the capability to communicate with other cars within their proximity or with the road-side infrastructure (which today usually does not have communication capabilities itself).

With the development of semi autonomous and (later) self-driving cars this will change dramatically. Today the prototypes of those cars rely mainly on the data they receive from the sensors installed within the car. While those sensor systems and the algorithms to derive a view of the car's nearby surrounding get more and more elaborate, there are still significant limitations on what the sensors can 'see' and how fast they can correlate the data to get a complete picture of the situation. What is missing today is a concept for re-using the information gathered and processed by other cars or by the road side infrastructure. Since only a few cars today are equipped with elaborated sensor systems for collecting information from the car's environment, this is not surprising.

Now let us look at a scenario in the (near) future where many (but still not all) cars are equipped with such elaborated sensor systems as well as the capability to communicate with their local environment as well as with centralized systems that can provide the car with useful information. Current developments in the mobile communication world will allow cars to download large amounts of data from cloud services and centralized systems very fast. Cloud services can provide up-to-date map information including information about the traffic situation, street conditions, free parking spots, etc. This information can be gathered from road-side units as well as other cars reporting specific conditions to the cloud services.

The communication link between the car and the centralized systems can be protected using standard protection features offered by the cellular network protocols combined with application-layer security protocols like TLS.

While the general communication security issues for this type of communication can be solved using existing protocols and technology, the situation with car-to-car communication is very different.

Car-to-car communication links are more of an adhoc type where communication partner change rapidly. With some cars, the communication links will be lasting longer (e. g. with cars driving on the same road and in the same direction) while it will be lasting only for a very short time for others (e. g. cars passing by). Especially the cars in front of you may provide very useful information about traffic situations, aspects to watch (like children playing near the road, people that want to cross, other cars trying to enter), their intention (e. g. will brake soon, will turn soon), or about road conditions (e. g. water, ice, or debris on the road) that your sensors can not (yet) 'see' and that the cloud services cannot provide. This information can supplement the data collected by the sensors and thereby enhance the picture of the local situation significantly.

Technically such an adhoc communication network can be established using upcoming technologies like IEEE 802.11p (with IEEE 1609) or LTE ProSe.  In addition, the merging 5G standards will also provide a basis for adhoc networks. Those protocols also provide general security functionality for entity authentication, encryption, and integrity protection. But this is not sufficient for car-to-car communication! You also need to know the exact location of the sender and you need to know that the data is 'fresh'. Even a delay of one or two second in receiving the data may be unacceptable since the data may not only be useless but also dangerous! Those are security issues not addressed by current protocols.

The freshness issue may be easily resolved by a time stamp, but this requires highly synchronized clocks between the sender and the receiver - not a real issue today. The exact location is slightly more complicated but using GPS in correlation with data obtained by the sensors of the car, the location can be determined very precisely and transmitted as part of the data.

While there are emerging standards for the lower protocol levels of car-to-car communication, work needs to be done on the establishment of standards at the higher protocol levels. Interoperability at all protocol levels is key for car-to-car communication at all protocol levels. This is more important than for the communication of cars to cloud services where vendor or vendor group specific solutions may be acceptable.

Security (and Safety) Aspects of IT Systems in the Car

As stated in the introduction, the IT systems in the car have been developed for a closed operational environment. Security was therefore often not a top priority. Those systems also have been quite static with software updates being performed in the workshop only. Adding new applications like it is common in mobile devices was not foreseen and not necessary.

The isolation of the IT systems in the car was broken up with the ability to connect smart phones to the car. Seeing the possibilities Apple (with Apple CarPlay) and Google (with Android Auto) then developed integrated solutions that allow to use the smart phone as an intelligent bridge into the car's navigation and entertainment systems. It is just a matter of time until they also serve as bridges into the more critical IT systems of the car, especially those that collect and correlate the data required for semi-autonomous or autonomous driving.

With the smart phone technology comes greater flexibility, including the ability to install new applications or to update the software over the air.  

Supporting this type of flexibility while also satisfying the strict safety requirements will be the main challenge for the future. The smart phones export quite a number of communication interfaces and their operating systems have reached a level of complexity that allow for the same type of attacks we have seen in standard client and server operating systems over a long period of time. Although iOS and Android allow only for the download of applications that have been signed by Apple or Google, both companies are not able to verify that applications they have signed are free of (intentional or unintentional) security critical flaws. What needs to be prohibited is that those applications can be used as a trojan horse to attack the more critical systems of the car.

To do this the IT systems within the car need to be structured into several criticality levels where levels of higher criticality are separated from the next lower criticality level by some kind of guard system that controls the data transferred between the levels. For example, a guard system protecting a critical system could pass data from the 'low assurance' Android or iOS system to the critical system only if the data as a whole is digitally signed by an entity allowed to communicate with the critical system. The guard system would only verify that the data has a well defined format and is digitally signed. If confidentiality is required the guard system could also be used to decrypt the data. The correctness of such a system can be verified at a high level of assurance and with such a technique the 'low assurance' system can be used just as a 'pass through' system to allow for controlled communication between the critical system and well-defined entities. This is a way that can be used to transport software updates, specific data, and even new applications to the critical system without the ability of other entities within the communication path to interfere with the integrity and - if required - the confidentiality of the data transmitted.

This opens up the possibility to use the smart phones and their technology as a gateway that can easily adapt to new communication protocols e. g. when 5G becomes mainstream. With this concept, the gap between the (relatively short) life time of communication protocols in the mobile world and the (compared to this: relatively long) life time of a car can be bridged.

We have talked about different levels of criticality before. In our model, we see at least three of those levels:

• low criticality: infotainment, navigation data (for use by human drivers) etc.
• medium criticality: connection to roadside assistance services, monitoring performance of car systems and communication with vendor/workshop
• high criticality: sensor systems and the data they collect, navigation data (when used automated navigation in semi-autonomous or fully autonomous cars), critical information received from other cars, any data received from other systems used for automated driving.

As stated before each level should be separated from the others by using a gateway but also by cryptographic means. Cryptography will play an important role for secure car systems. There should be a separate 'master key' for each level (usually the private key of a private/public key pair) as the top of a key hierarchy used for the different application areas within each level. Software updates as well as the installation of new applications would require a digital signature as is already the case in the mobile systems we use. But unlike those systems within the car updates or new applications for the medium and high criticality levels within the car will need a significantly more careful analysis - preferable by an independent third party - to ensure that the software update or the new application adhere to well defined safety and security standards, work as specified and do not misuse the privileges assigned to them. This could be achieved by multiple signatures applied to a software update or a new application where each independent third party applies a signature with the specification of what it has analyzed e. g. the standard used within the analysis, the level of scrutiny (if the standard defines such levels), specific properties looked at during the analysis. Based on those signatures and its attributes the software management within each criticality level can then decide if the update or new application is accepted and what privileges or access to critical functions is allowed.

This could be the basis for a secure IT architecture within a car. To get there, it requires a lot of work to develop the standards not only for communication but also for data structures at the application level and for the general policies of software management within the car. 

By Helmut Kurth