The research area of SET group is software engineering, and model-based software engineering in particular:

Transcription

1 Introduction The research area of SET group is software engineering, and model-based software engineering in particular: Given the high-tech software-intensive industry in the Eindhoven region, we consider time- and cost-efficient development of high-quality software as crucial.

2 Introduction SET focuses research-wise on two topic: 1. domain specific languages including semantics of domain specific languages, language workbenches, and verification of model transformations; 2. software evolution of multi-lingual systems, including advanced metrics and repository mining. Application areas: High-tech systems Automotive

3 Automotive Software Engineering Some figures on automotive software: Today premium cars feature not less than 70 Electronic Control Units (ECU) connected by more than 5 different bus systems Within 30 years the amount of software in cars went from 0 lines of code to more than 10,000,000 lines of code More than 2000 functions are controlled by software in highend cars

4 Automotive Software Engineering By more software we realize innovative functions, we find new ways of implementing known functions with reduced costs, less weight, less emission, or higher quality, we save energy and, what is, in particular, important, we combine functions and correlate them into multifunctional systems.

5 Automotive Software Engineering Examples: adaptive cruise control online information of road information systems connected cars autonomous driving etc. Consequences cars are no longer closed systems communication with environment and other cars own IP address security threats

6 Security and connected cars In-vehicle network The network of sensors and Electronic Control Units (ECUs) that compose each (motor) vehicle. Connected vehicle Enables communicating the in-vehicle network with other entities, such as other vehicles, back offices or mobile devices.

7 Security and connected cars Security threats vulnerability of the CAN bus Denial of Service attack on CAN bus possible? A few examples: and

8 Security and connected cars Access to CAN bus is needed a car could be used in order to know the specific components used and reverse engineer the messages sent over the bus: to get insight in existing messages and exchanged data Via this approach one can reverse engineer the message sent when braking

9 Security and connected cars Hacking the CAN bus: Firmware of special hardware (CAN controller) adapted to construct fake messages. By putting these fake messages on the CAN bus leads to inference and influences the behavior of the car. In some cases checks are performed by ECU, for instance by checking against inverted data Some ECUs can be reprogrammed via CAN bus

10 Security and connected cars

11 Security and connected cars

12 Safety Assurance in Connected Vehicles Lessons learnt: If CAN message ID is known, malware can be written, However, direct connection with CAN bus is still needed. More general purpose ECU increases the risks of attacks certainly in combination with communication infrastructure

13 Security and connected cars Research questions What kind of McAfee software is needed to detect this malware? Should security threats be integrated with safety assurance for connected vehicles? What are the challenges for extending safety assurance for connected vehicles to include security threats?

14 Safety Assurance in Connected Vehicles An Example--a partial preliminary safety case for a braking system. Braking system is acceptably safe in normal operations All related hazards are sufficiently addressed System offers enhanced safety over existing systems System complies with safety standards Existing related hazards are sufficiently addressed New related hazards are sufficiently addressed System complies with legal requirements System complies with safety standards ITS applications such as Collaborative Cruise Control require controlling the braking system.

15 Safety Assurance in Connected Vehicles Impact of threats Attackers can remotely attack connected vehicles and change their behaviors. Attacking a connected vehicle does not require physical access to the vehicles as in unconnected vehicle. An attacker can remotely change the behavior of the components and features of a connected vehicle and compromise the safety mechanisms. Example of attack on e-call system: Exploit an error in the authentication program of aqlink protocol implementation to inject malicious code to the connected vehicle. => The use of the e-call system, a safety feature, is not safe.

16 Safety Assurance in Connected Vehicles A partial attack tree for automatic brake function Attack automatic brake function Delay automatic brake function Prevent automatic brake function Jamming DSRC communication DoS chassis safety controller Jamming in-car communication Disable in-car sensors DSRS is acronym for Dedicated Short Range Communications.

17 Safety Assurance in Connected Vehicles Threats to connected vehicles that affect ITS systems include: disseminate bogus data to nearby vehicles cheat in aggregating data tamper the device hardware tamper the device software Denial of Service (DoS) attack unauthorized over the air update of devices masquerade attack

18 Safety Assurance in Connected Vehicles Proposed extension to safety assurance We need to extend the notion of safety to consider harms caused by unintended and intended behavior of system components. Extended safety is: absence of potential for harm caused by unintended and intended behavior of systems judged to be unacceptable according to valid societal moral concepts.

19 Safety Assurance in Connected Vehicles Challenges How to model the interactions between safety and security aspects in extended safety assurance for connected vehicles? The model must include e.g., conflicts between security and safety mechanisms. How to manage extended safety assurance case evolution considering to changes to the connected vehicle? The evolution of extended safety cases could affect the relationships between the safety and security implemented mechanisms. How to develop ITS applications for connected vehicles assured for extended safety?

20 Safety Assurance in Connected Vehicles Conclusions Safety hazards and security threats are not independent in connected vehicles. Connecting the in-vehicle network to external entities requires extending safety assurance cases to consider security threats. Integrating safety and security aspects into extended safety assurance cases induces a set of challenges. Safety standards (ISO 26262) have to be reconsidered in order to ensure security.

21 Discussion/Questions / Faculteit Wiskunde en Informatica