Automated driving: When safety meets security

The technology behind the dream of autonomous driving is within reach, with conditionally automated driving at SAE Level 3 becoming a feature of premium cars. The leap to full automation at levels 4 to 5 – at which the car mostly drives itself – seems possible once the necessary legal framework is in place.

Without functional safety, automated vehicles are going nowhere: acceptance of fully automated and autonomous driving hinges on equipping vehicles with software and digital technology that work reliably and flawlessly, while making better decisions than a human. Once again, the principle is “no safety without security.” Ultimately, a vehicle’s functional safety, and with it the safety of road users, is only as effective as the extent to which its cybersecurity protects the vehicle – and in particular its safety-relevant systems – against unauthorized access and manipulation. In this way, automated driving requires a comprehensive automotive security approach designed according to vehicles’ functional safety.

Linking safe state and secure state

Figure 1: In the future, a defined secure state for a vehicle’s internal network and systems will become a potential trigger of a safe state for automated vehicles in the event of a cyberattack.

As a rule, vehicles are designed so that in the event of a serious malfunction in safety-relevant components, they can be put into a safe state to protect the occupants and other road users. In other words, the vehicle is brought to a standstill: either the driver takes control, or the fully automated or autonomous vehicle (level 4 and 5) controls and stops itself in response to the traffic situation.

With vehicles becoming increasingly connected and automated, cybersecurity is also critical to functional safety. Similar to how a vehicle enters a safe state in the scenario described above, its systems must switch to a secure state in the event of a potential or recognized cyberattack. They do this either by performing only those basic functions that do not threaten safety or by securely shutting down. This raises an important question concerning the future: When and in what way does a recognized case of unauthorized access to relevant systems trigger a secure state, and how does this in turn initiate a safe state to stop the vehicle safely in the given driving situation? Increasing automation will mean that security and safety, and with that the secure state and the safe state, will have to become equally weighted instances in a shared decision-making system.

Defense in depth

Figure 2: “Defense in depth” comprises security measures on all levels of vehicle architecture and communication – from microcontroller to infrastructure.

Providing the automated vehicle with effective protection against manipulation of safety-relevant functions (steering, braking, engine control, etc.) involves implementing security measures on various levels in the vehicle as part of the defense-in-depth approach. Special attention must be given to external attacks: despite increased connectivity, the number of external communication interfaces must be kept to a minimum – for instance, by using a dedicated component to connect to external systems. The remaining interfaces can be secured via communication protocols and access protection mechanisms based on standardized cryptographic algorithms as well as by way of an automotive firewall that blocks unauthorized requests. It is also imperative that safety functions for automated vehicles be entirely cut off from external interfaces. Various systems within a given vehicle component can be neatly partitioned with the help of, say, different hardware components or a hypervisor. Additional security measures, such as regular verification when starting (secure boot) or secure updates, ensure the system’s authenticity and enhance attack protection. Moreover, hardware security modules (HSMs) create the trustworthy environment required to carry out secure cryptographic operations.

Secure onboard communication that is protected against manipulation through breached systems relies on specific cryptographic protocols tailored to each bus system. From level 3 upward, the increased amount of data means that the E/E architectures of more and more automated vehicles will feature Automotive Ethernet. Automotive Ethernet can make use of proven protocols, like Transport Layer Security (TLS) or IPsec, while taking into account the real-time requirements – for instance, through pre-shared keys that speed up the time-consuming process of exchanging keys. In addition, the automotive firewall and access protection mechanisms monitor access to safety-relevant functions even within the electrical system by applying defined rules for individual subnetworks or virtual local area networks (VLANs).

Securing vehicles in the field

Despite multilayered security measures, it is not possible to completely rule out unauthorized access to a vehicle (e.g. through what are known as “zero-day vulnerabilities”). This makes it all the more important to recognize such an attack in time and take steps to mitigate its effects. The method of choice is a distributed system for attack detection in the vehicle, or intrusion detection system (IDS). Automotive IDSs have now attained market readiness and meet some AUTOSAR specifications. They identify anomalies and typical attack signatures (e.g. in cyclical messages or abusive diagnostic requests) in the vehicle’s internal network and report them to a vehicle security operations center (VSOC) tied into the backend.

At the VSOC, the security events collected from the entire connected fleet are continuously evaluated, validated, and analyzed in terms of their threat potential with a view to deriving suitable countermeasures. This process dovetails two instances: security incident and event management (SIEM), which automatically examines incoming IT security events in real time, and specialized automotive security analysts, which analyze attack paths and expand the threat detection methodology so that SIEM and the IDS in the vehicle will automatically register new threat scenarios in the future. As a result, an over-the-air (OTA) update can be used to close the exploited attack vector and potentially update the regulations for IDS, firewalls, and other security access mechanisms – across the entire fleet. For fully automated or even autonomous vehicles in connected fleets, this kind of continuous security risk management with short response times will go a long way towards ensuring a vehicle’s functional safety and the safety of its occupants.

Security as enabler for automated driving

Mobility is at a turning point. Increasingly, we will see highly connected, automated vehicles take the steering wheel from the driver’s hand. The functional safety of automated driving systems is paramount – and this basic condition cannot be met without the security that comes from protecting against unauthorized access to, and manipulation of, precisely these systems. Coherent strategies to prevent potential cyberattacks are thus an indispensable part of the further development of automated driving.

Also available in our Newsroom