Security and Safety Challenge

Interaction between Safety and Security

Functional safety and vehicle security are both "first-class" issues, meaning they consider each other to be of paramount importance. Functional safety aims to protect against threats to life and limb, while vehicle security ensures the protection of the vehicle and its safety-critical systems from attackers. When conflicting requirements arise, it is impossible to prioritize either security or safety unilaterally. For example, cryptography for safety-relevant systems with stringent real-time requirements remains a challenge, as the known strong cryptographic algorithms require a considerable increase in storage space, bandwidth, and computing power. Even though research in this area is ongoing (see, for example, [6]), a balance between safety, security, and, not least, cost is still necessary. Furthermore, experience with the internet shows that the demands on cryptography are increasing—and with them, the need for computing power in electronic control units (ECUs). For a car that is in use for ten to fifteen years, this may mean that after a few years the hardware is no longer able to ensure the required security while maintaining the necessary real-time requirements.

The following presents three different ways in which safety and security can interact.

Impact of Safety on Security

First, a fault can compromise security. For example, in an electronic steering column lock (ESCL), a fault can cause the lock to unlock. While the ESCL itself is a safety-relevant system, as a faulty locking while driving is dangerous, the event of a faulty unlocking that compromises security would not be identified as a hazard by a Hazard Analysis and Risk Assessment (HARA) according to ISO 26262, since the vehicle is not moving in this scenario and therefore no damage can occur. Other consequences of random or systematic hardware or software failures can include security vulnerabilities in the software or the circumvention of cryptography. An example of such a scenario could be a random number generator returning constant values due to a stuck-at error. Another possibility would be the failure of a firewall on the car's system bus. This could result in security mechanisms having safety requirements, e.g., they would have to be designed in a diverse manner, which in turn opens up two potential attack paths for an attacker.

Impact of security on safety

On the other hand, an attack can compromise safety. In the obvious case of a direct attack on, for example, driver assistance systems, an attacker can gain control over safety-relevant systems. In this case, the ASIL can at least provide a starting point for assessing criticality.

A special case arises when the safety-critical systems are not the target of the attack, but the safeguards of a safety-critical system fail (e.g., as a side effect of an attack). In such cases, security and safety measures do not work together properly, and may even work against each other.

A common misconception is the assumption that safety mechanisms can adequately detect and handle attacks by bringing the system into a safe state. If the attack's objective is not, in any case, to achieve a safe state (i.e., shutdown), then it must be assumed that the safety mechanisms are also affected by the attack. In safety engineering, various simplifying assumptions are made when designing safety measures. Random hardware failures are generally assumed to be statistically detectable. Overall, the safety architecture in ISO 26262 is based on the assumption of a single failure and a latent failure. However, such fundamental assumptions are no longer tenable in security. A sophisticated attacker may therefore be able to attack a system in such a way that the safety mechanisms fail to detect the attack.

ISO 26262 and Security

Although there is a need to consider safety and security equally, and the two disciplines interact, security is not addressed in ISO 26262. As a standard from the field of functional safety, it deals exclusively with safety requirements. Additional requirements from external sources are typically considered during software development, starting with the software architecture design. This is usually too late if conflicting requirements lead to additional system-level requirements or necessitate a complete design overhaul. Therefore, safety and security requirements must be developed together from the design phase onward. For the development of COTS (commercial-of-the-shelf) components, this also means that assumptions and guidelines regarding security must be documented in the safety manual.

HARA's expanded focus

To support the development of security requirements from a safety perspective from the outset, HARA (Hazardous Vehicle Alert System) can be implemented. When analyzing hazardous situations, the category of "manipulation" can be introduced as a general umbrella term to consider additional dangerous scenarios. This would allow for the inclusion of scenarios such as "loss of driving function under unusual circumstances," multiple-fault scenarios, and driver deception, for example, through deliberately false instrument panel displays. The results of a threat analysis should also be considered at this stage.

Summary

Besides safety, security has also arrived in the automotive industry as a second "first-class" concern. Although there is still no universally accepted standard for car security, it is already necessary to consider security during development. Since safety and security are interdependent, safety and security requirements must be developed together from the outset. Security must also be incorporated into the safety manuals. A good starting point is to consider threat analyses, beginning with HARA (Hazard Analysis and Restriction of Action). The case of manipulation can be helpful in considering additional scenarios. However, it is also true that security and safety methods cannot simply be mixed. Safety and security requirements must be given equal consideration.

literature

[1] ISO 26262 – Road Vehicles – Functional Safety, Part 1-10, International Standard, 2011

[2] Spara, Dieter: Open up, car! – Security gaps in BMW's ConnectedDrive (accessed on 16.10.2015)

[3] Timberg, Craig: Hacks on the Highway (accessed on 16.10.2015)

[4] ISO/IEC 27001 – Information technology – Security techniques – Information security management systems – Requirements, International Standard, 2013

[5] Common Criteria for Information Technology Security Evaluation, Version 3.1 Rev. 4, International Standard, 2012

[6] Philipp Mundhenk, Sebastian Steinhorst, Martin Lukasiewycz, Suhaib A. Fahmy, and Samarjit Chakraborty. 2015. Lightweight authentication for secure automotive networks. In Proceedings of the 2015 Design, Automation & Test in Europe Conference & Exhibition (DATE '15). EDA Consortium, San Jose, CA, USA, 285-288.

Download the article as a PDF