Extending Software Architectures fromSafetytoSecurity（功能安全到信息安全）

| 文章摘录自elektrobit，完整资料学习可联系小编，本文仅供学习参考!

In this paper we summarize approaches for software architectures used in the automotive domain for safety-critical or mixed safety-critical systems and extend the approach to security-critical systems. Safety and security aspects of systems in- fluence each other and we show solutions which combine both worlds in a common architectural and development process approach.

1. Motivation and Background

In recent years several studies (e.g. [KCR + 10], [MV13], [Dan10]) revealed a growing security threat potential for cars from all kinds of aspects, e.g.

• System and software complexity: e.g. functionality per ECU, lines of code

• Connectivity: e.g. WiFi, Bluetooth, Ethernet and Internet, Car2Car, Car2X

• Interoperability: e.g. WiFi, Bluetooth, Internet, mobile phone integration

• Sped up time-to-market due to the necessity to adapt quickly: e.g. Apps, 3 rd party SW

For future applications in the automotive domain the topics connectivity and collaboration with various outside sources are essential features. On the one hand this includes commu- nication with various sensors and applications in the car itself. On the other hand, however, this will also comprise external sources such as mobile devices, roadside infrastructure or backend IT systems that provide cloud computing capacities.

The signals exchanged here will be utilized in safety and security critical use cases like assisted and autonomous driving, or in the exchange of traffic and hazard information between cars and roadside infrastructure. As shown by different independent studies the mutual influence between safety and se- curity aspects is very strong. Safety software engineering and the resulting applicationshave a direct impact on security and vice versa.

This has been recognized by established software safety standards like IEC 61508 [IEC10] or ISO 26262 [ISO11b]. And it has also been addressed by regulators of other domains, e.g. by the FDA jointly with the ICS-CERT in 2013: “Manufacturers are responsible for remaining vigilant about identi- fying risks and hazards associated with their medical devices, including risks related to cybersecurity, and are responsible for putting appropriate mitigations in place to address patient safety and assure proper device performance” [FDA13], [IC13]. Even regulatory bodies or political institutions like the European Commission correlate both topics, e.g. José Manuel Dur˜ ao Barroso in a speech about nuclear safety in 2012: “[. . . ] there is no safety without security and vice-versa”, see [Jos12].

There are already initiatives by standardization bodies to identify synergies in creating the assurance cases that combine approaches like safety cases, security assurance and system integrity levels, e.g. ISO 15026 [ISO11a].

A practical consequence for today’s systems is that most safety critical use cases will have to consider intentional manipulation of messages and data as well as direct attacks on software and hardware level. Such systems need to be accompanied with a state of the art argumentation for safety and security, see e.g. the BGH airbag case [Bun09]. However, the practical interpretation of “state of the art” is changing quickly and system development needs to take this background into account.

This article presents practical approaches for software architectures addressing the in- tegrity ofautomotive ECUs using establishedenvironments like AUTOSAR (see [AUT14a]). Such software architectures provide methods to address safety, security and availability as- pects of today’s state of the art ECUs.

2 Integrity and Safety Mechanisms

The basic software architecture of a safety-critical system is responsible for providing mechanisms to establish the integrity of the system from a software point of view. Such mechanisms also include the critical interfaces between hardware and software, including detection mechanisms of hardware faults. AUTOSAR provides a framework that allows Software Components (SW-Cs), as the building blocks of a full AUTOSAR application are called, to concentrate on safety-critical functions independent of the practical imple- mentation of the basic software layers.

The provision of such basic mechanisms is well established, e.g. in the definitions of “independence” in IEC 61508 [IEC10] or freedom from interference or criteria for coexis- tence ofelements in ISO 26262 [ISO11b]. Technically the “best” definition can be found in DO-178C (see [RTC11], 2.4). It defines three classical architectural considerations: partitioning, multi-version dissimilar software and safety monitoring. This chapter mentions these methods briefly as reference. The focus of this paper is on the extension of these safety mechanisms to security mechanisms. Further details can be found in [MA09], [HJMA14], [GM18].

Security-critical systems have different needs than safety-critical systems as the “oppo- nent” changes. The intention ofa safety-critical system is to prevent harm emanating from the system itself whereas a security-critical systems intent to prevent harm to the system from outside, e.g. from a malicious human attacker.

In ideal world the “threat model” of a safety-critical system can be determined up-front during system design, analysis and implementation. The risk emanating from a safety- critical system is usually based on systematic or random hardware faults or systematic faults in software. Such a threat model is iteratively enhanced to include previously un- known faults, but basically one could call it “static”.

Security-critical systems however need to deal with “dynamic” threat models as the meth- ods used by an attacker are not known during system creation and can significantly im- prove during system operation. The major factors are long-term use of automotive sys- tems, evolution in computing power, but most importantly the ingenuity of the attackers. Usually this makes security-critical systems more complicated to build and analyze than safety-critical systems.

4 Extended Safety and Security Architecture

As seen in chapters 2 and 3 message protection plays an essential role in safety as well as security related applications. For both aspects protection against corruption, repetition, loss and delay of information must be ensured.

However the goals of both protection methods differ. For safety aspects the path from the originating to the receiving software application shall be protected against transmission and processing errors both on bus level as well and particularly as throughout the basic software stack on sender and receiver side. Message protection mechanisms with regard to security aim to protect messages on the bus against manipulation attacks. Protection within the software stack itself is not a goal of currently proposed security mechanisms (see [AUT14b]).

Therefore different methods are used to address safety and security aspects independently from each other. For protection against safety issues a checksum based end-to-end (E2E) protection mechanism specified by AUTOSAR (see [AUT13]) is most commonly used. Protection against malicious attacks is done as specified in [AUT14b] and explained in sections 3.2.2 and 3.2.1 by appending and transmitting (parts of) a MAC value to the actual message data.

Ifa message is both safety and security relevant at the same time, currently two individual and independent attributes of significant length have to be added to the actual message data.

5 Systems and Software Engineering

For safety-critical systems techniques for performing safety analyses are well-established and these are based on approaches known from risk management combined with specific analysis techniques, e.g. for software architectures or the implementation itself. Risk analyses ofthe system and the implementation are the most important “add-on” in the de- velopment process ofsafety-critical systems compared to standard development processes.

Security analysis of systems is already established in other domains, e.g. in the IT sector. For many automotive ECUs a dedicated security analysis is often not part of the standard development processes yet. However both analysis types are similar in the sense that they are risk-based. These analyses become more alike the closer they are performed to the actual implementation: starting with the software design the formal inspections are nearly identical.

6 Conclusion

In this paper we presented a practical approach to extend a software architecture designed for safety critical systems based on AUTOSAR to be used in security critical systems.

We have pointed out the mutual influence between safety and security aspects which are recognized already in different standardization groups as well as by regulatory bodies and political institutions. José Manuel Dur˜ ao Barroso summarized them spot on by pointing out “[. . . ] there is no safety without security and vice-versa”, see [Jos12].

Already well-established mechanisms in safety development, e.g. in the definitions of “independence” in IEC 61508 [IEC10] or “freedom from interference” and “criteria for coexistence of elements” according to ISO 26262 can be reused. For applications in com- mon security use cases they are extended by cryptographic methods to ensure e.g. entity and message authentication as well as advanced integrity checks.

We have shown, that one can achieve a significantly increased level of safety as well as security by combining already available solutions from both worlds and consequently ap- plying rigid software engineering processes and methods derived from functional safety development and extending them to security use cases.

关键词： 信息安全