The “car of the future” is poised to deliver increased comfort, convenience and safety but with these benefits comes an increased potential for damage. In the past, damage could only be inflicted upon a vehicle through direct physical access. Today, however, a car can be compromised without physical intervention via the wireless networking associated with con-nected vehicles.
As the industry moves toward a truly autonomous driving experience, managing rising in-vehicle system complexity and related security vulnerabilities will demand greater focus from automakers and suppliers. The longterm goal is to develop a self-protective system, designed to respond to changing threats. To be successful, this requires a holistic approach to safety, security and availability.
Automotive software and vehicle networks are becom-ing increasingly complex due to consumer demand for technologies that enable both on-board and external connectivity. Customers want vehicle integration with mobile devices, internet services and apps, which can be quickly updated and deployed. It ́s short lifecycles put pressure on automotive software providers and automakers to achieve similar rapid innovation cycles. In turn, an ever-growing number of on-board systems and sensors must communicate with each other, as well as with external sites (Fig. 1).
The exchanged signals are used in functional safety applications as well as in those potentially subject to IT security issues. Typical applications include solutions for driver assistance systems and autonomous driving, which e.g. support the exchange of traffic and danger messages between vehicles and road infrastructure.
Safety and security aspects exert a strong mutual influ-ence. This fact is now reflected in the use of common standards for Functional Safety, e.g., IEC 61508 and ISO 26262. In addition, even government organizations such as the European Commission have recognized a direct relationship between both Functional Safety and security. In 2012, José Manuel Durão Barroso aptly highlighted this point in a speech on the safety of nuclear energy: “… There is no safety without security and vice-versa.” Therefore, in-car systems must offer a conclusive rationale concerning the management of safety and security areas according to the latest technology developments.
Integrity and safety mechanisms
The basic software of a system subject to Functional Safety requirements must provide mechanisms to ensure the integrity of a software system. At present, these fundamental mechanisms are well established by the AUTOSAR framework and described, for example, in ISO 26262. In this respect, we distinguish three different freedom of interference types representing the aim of Functional Safety:
“Spatial freedom from Interference” means that data related to safety-critical components must be protected from access by other components. In most software architectures, the operating system provides mechanisms for memory partitioning. Fig. 2 shows a sample architecture with protection mechanisms for Functional Safety based on AUTOSAR. Memory protection is provided by the “Safety OS”.
“Temporal Freedom from Interference” deals with the temporal component: It must be ensured that safety-critical software is allocated required computation time and that it executes in its expected sequence. In Fig.2, this is represented by the module “Safety TimE Protection”.
ISO 26262 defines the so-called “Exchange of Information” as the third freedom from interference pillar. Safety-critical data and signals must be protected so that corrupted or missing data are detected. Within an electronic control unit (ECU), protection can be achieved directly via the “Runtime Environment” (Safety RTE in Fig. 2).
Security mechanisms
While safety-critical systems minimize errors arising from the system itself, security mechanisms must protect the system from potential damage arising from unauthorized external access. The threat model of a security-related system is therefore highly dynamic, as threats change dramatically during the service life of a system, and methods of attacks are largely unknown during system design. Key factors in this respect are primarily the availability of ever-increasing computing power and the creativity of attackers.
The bottom line is that, basic software must still provide mechanisms to ensure system integrity. This can be achieved both by expanding system safety mechanisms and by adding security-related measures. Given that the analysis of both aspects relies on risk models, it is crucial to recognize and use synergies. Thus, the search for security vulnerabilities can bring new safety exposures to light and vice versa.
Stack overflows constitute a good example of vulnerabilities with safety and security impacts. They arise either from software defects – a safety problem – or are triggered by targeted attacks – a security vulnerability. In both cases, such scenarios must be identified during the corresponding analysis and prevented via suitable software design or, if nothing else, detected at runtime.
In particular, such errors and attacks can be prevented by the above-described memory protection mechanism “Spatial Freedom from Interference.” Although this measure by itself provides no protection against denial-of-service attacks, it will ensure that the system does not end in an undefined state but in a previously defined error condition. Furthermore, the use of the “Freedom from Interference” reasoning allows the reliable separation of safety-relevant software parts from any parts deemed vulnerable to external attacks. On the one hand, modern CPUs allow assigning read rights – in addition to pure write-protection via MPU. This is used to make security-relevant data -e.g., cryptographic keys – readable only by modules with the right privileges. On the other hand, execution rights can be specifically set or revoked.
That way, code, which has been written to access sensitive security data, can be marked as non-executable and not allowed to access sensitive data until its planned execution time. Moreover, the assignment of appropriately restricted execution rights on the stack prevents unwanted code execution from a false context. Accordingly, the com-bination of both mechanisms protects from two typical attack vectors.
Message protection by security measures
In the context of safety, safety-critical applications must be able to rely on received messages. Responsi-bility for message protection is the task of security: The authenticity of communication partners and exchanged messages, data integrity, as well as the freshness and confidentiality of message content must be ensured.
Ensuring the correct message source and content authenticity entails verifying the received data integrity – to exclude any message manipulation. The most common way to do this is to use a Message Authentication Code (MAC). A good example of this is the Cipher-based Message Authentication Code (CMAC), which is proposed with the release of the AUTOSAR 4.2.1 specification. The base of CMAC is the symmetric Advanced Encryption Standard (AES) algorithm with a corresponding underlying cryptographic key. The calculated MAC is wholly or partially attached to the original message before delivery. On the recipient side, message integrity can be checked by using the same calculations performed on the transmitter side. Both results are then compared with each other (Fig. 3).
However, MACs alone will not protect against valid messages being recorded at any time and (re-)sent af-terward. Protecting the system from such an intrusion calls for the individualization of any proof of authentic-ity, which must be verifiable by the recipient. This can be accomplished by using values subject to frequent changes for MAC generation, e.g., simple monotonic counters or a reliable and tamper-proof time stamp.
Message confidentiality, i.e. the protection of the mes-sage content from third party reading, can be ensured by encryption. The most common method to that end is the symmetric method AES.
Systems and software development
There are a number of established and proven procedures to analyse functional safety aspects. They are usually based on classical risk analysis and extended with special techniques, e.g., for the analysis of software architecture and actual implementation. Consequently, system risk and implementation analysis represent the most important extensions for safety application development. To date, however, security analyses are seldom applied in the standard develop-ment process for ECUs.
Safety and security analyses have nonetheless much in common, as both are risk-based. The closer the analy-sis gets to actual implementation, the more similar they appear. Formal inspections, starting with software design, are almost identical. Ultimately, both areas require conscientious software development. Thus, many threats in the safety and security areas can be prevented or minimized with today’s common methods and processes.
Safety and security in AUTOSAR ECUs
Existing AUTOSAR architectures featuring proven safety mechanisms can be used consistently to design ECUs under Functional Safety and IT security requirements. To address common security requirements, appropriate use cases can be extended with modules such as EB tresos SecOC, which consists of protection components for bus communication. In addition, individual meas-ures can be extended, e.g. broader integrity protection mechanisms or confidentiality protection methods.
Concerning the mutual interaction of safety and secu-rity, it is important to consider both disciplines together and identify process and methodological synergies. Several security aspects enhance safety engineering with additional protection features. Conversely, it must be examined whether specific security measures include those features already considered for safety purposes.
Moreover, ensuring the permanent availability of critical system functions will be key to the emergence of autonomous-driving vehicles. The safe state – to which a system often passes upon detection of a safety and security risk – is simply ”off.” This situation is however unacceptable for self-driving cars, as basic functionality must be ensured without exception under all circumstances. This complete availability critically relies on various software mechanisms but also on appropriate hardware support. Therefore, the medium-term objective leading to fully autonomous driving requires a comprehensive view of in-vehicle system components in order to develop systems which combine the necessary safety, security and availability aspects, to form a standalone protection system.
Further reading: Practical experience with safety analyses at the software architectural level
For an overview of possible safety analyses, refer, for example, to ISO/IEC 31010 ‘Risk management – Risk assessment techniques’. Among other things, this standard describes the bottom-up (inductive) HAZOP method and the top-down (deductive) fault tree analysis (FTA) method.
Authors
Martin Böhner
Former Head of Product Management for OTA and Security
Dr. Alexander Mattausch
Lead Project Manager HPC Architecture
Alexander Much
Head of System Architecture
