Florian Stosse security engineer

Automotive manufacturers are initiating a major breakthrough in the development of their cars. As they are increasingly connected, these cars should quickly become autonomous. How is this change affecting our societies and also the security of data and passengers ? Florian Josse, from the operational security department at Bureau Veritas, answered our questions on that matter.

Autonomous cars are about to be revolutionary in our societies. What are the benefits of such cars?

There are many benefits to connected cars (and to autonomous ones in the future):

  • There will be less accidents thanks to the inter-vehicle communication skills (V2V) and to the infrastructure (V2X). Autonomous vehicles will also offer a 360-degree view, thus reducing accidents caused by blind spots.
  • The congestion on the road network will be reduced thanks to a more accurate prediction of traffic jams upstream (alternative routes). Autonomous vehicles will also bring about other improvements in this respect such as the ability to drive a convoy and to synchronize with each other (while braking – once an incident is detected – but also while starting at a traffic light or at a crossroads). This will reduce ‘accordion effects’ and thus traffic jams.
  • As far as autonomous vehicles are concerned, using a car will be different for drivers: they will be able to read, to watch videos and to rest. The driving experience will change completely.
  • We should expect in the long run a fundamental change in the urban-planning of large cities – such as the end of red lights and crossroads – thanks to the synchronicity of vehicles.
  • Finally, the very notion of owning a vehicle could change for consumers, particularly with the rise of concepts such as Uber which will offer renting or membership services. The automotive industry could even look like today’s aircraft industry: manufacturers such as Renault could stop selling vehicles directly to private individuals and sell them to these service suppliers instead who will be in charge of the maintenance and upgradability of their vehicles.

What are possible risks of hacking of a connected vehicle?

As with any other current connected system, connected vehicles are facing many risks in terms of security. These risks can be divided into several categories:

  • Integrity: in the event of a compromise of the critical UCE, drivers’ physical safety can be jeopardized (unintended deactivation or activation of the brakes, steering lock and so on). We should also take the vehicle’s integrity into account in cases where the legitimate user tries to change its behaviour (such as increasing the engine’s capacity by modifying the parameters of the car’s electronic box).
  • Confidentiality and privacy: the theft of personal data such as a contact list  is also a possibility. Using the vehicle’s hands-free kit to exfiltrate conversations for espionage purposes is another possible risk.
  • Availability: the immobilisation of the vehicle is also likely to happen when the rolling code is modified on certain UCEs which will lead to a garage return. There is no small risk that ransomwares dedicated to certain vehicles will appear (especially since the advent of systems such as Android Auto or Apple CarPlay) and they would have consequences for the manufacturer’s brand image too.
  • Theft: the compromise of key systems (and of keyless systems) can also lead to greater risk of theft (like the SUV thefts that happened in Houston).

What data can hackers collect from a connected vehicle?

Currently, with physical access to the vehicle it is possible to collect a lot of data through the diagnostic socket or simply through the multimedia system. For example, this system stores your routes (through the GPS) but also a list of contacts if you have paired the system with a telephone.

With more sophisticated methods, hackers could collect telephone conversations that take place within the car (if a hands-free kit is being used).

How do hackers get into the system of a connected vehicle?

First of all, we must remind you that this is not necessarily a trivial thing to do. Chris Valasek and Charlie Miller, the two safety researchers who are responsible for the distance compromise of a Jeep (and who now work at Uber’s research centre), worked for more than a year before reaching this result and they have a lot of experience in terms of car safety and technology.

Standoff attacks are still uncommon today (at least publicly) and require a certain expertise, a certain amount of time, and especially physical access to the vehicle so that hackers can work on it and its components – while bearing in mind that the risk of damaging one of these components is rather high when one is looking to modify related software.

However, we can divide these attacks on connected vehicles into three steps: the compromise of equipment allowing communication through the vehicle’s internal network, the identification of messages allowing the control of the electronic control units (ECU) and the injection of messages into that network.

Although that might sound simple, in reality it is not. Quite often, the compromised equipment does not allow for communication directly with the ‘critical’ ECUs during the first step (brakes or steering control), especially because of the bridges filtering the messages that are authorized to pass from one network to another. We must then either compromise this bridge or directly compromise an ECU located on the subnet where the targeted component is located.

Injecting messages is not an easy thing to do either. Even if all vehicles use a CAN bus for ECU interconnection, the format of issued frames on that bus often are proprietaries and specific to a manufacturer. Therefore, there needs to be reverse-engineering efforts so as to identify frames that can be used during the attack.

Cars are not the only connected means of transport. Buses are becoming connected to: what typology of cyber risks would you make for these vehicles?

Risks are basically the same as for cars but the consequences of taking advantage of these risks are completely different. Immobilizing a fleet of buses or autonomous shuttles does not have the same impact as immobilizing private cars. The ransomware attack on San Francisco’s transit system which occurred in November gives us a good overview, even if the author didn’t directly target vehicles.

In contrast, autonomous buses and shuttles are more difficult to access for ill-intentioned people. If anyone can buy an On-Board Diagnosis (OBD) to connect to the diagnosis plug of his or her vehicle, this isn’t the case when it comes to buses and shuttles for which the different ports of access are less easier to reach.

What do you think of the world’s being more and more connected today (Internet of Things)? Are we dealing with threats or opportunities according to you (personal data, possible hacks)?

As pointed out by the recent denial of service attack on Dyn, which happened because connected security cameras weren’t secured, risks posed by IoT are very real and even partly completed.

Although we may wonder about the relevance of connecting toothbrushes, the IoT has many opportunities for local authorities and companies (inventory management, preventive maintenance, decision aid tool and so on) and it is unlikely that we will see a step back happening towards an ‘unconnected world’. Thus, we are going to have to do a lot of work to standardize the security of future objects – many work groups are already working on it – and to confine objects that are currently vulnerable because they were put on the market too early and with no update possibility.

What would you consider to be good practices in terms of vehicle cybersecurity?

Vehicle security will be built on several pillars:

  • Security management for manufacturers, suppliers and companies providing services to vehicles;
  • Software security: at present, a car contains about 100 millions of lines of code divided into the different ECUs, the multimedia system and so on. Manufacturers and suppliers are going to have to take the issue of code security into account as the aerospace and spatial industry have done before them. This will happen through the setup of development cycles incorporating security from the very start (‘security by design’), just like operating safety is currently taken into account in determining design.
  • Material security: UCEs and embedded processors will have to be solidified and authenticated;
  • The use of emerging standards or guides such as BV’s.