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

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.

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 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

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

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 and connected cars

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.

Security and connected cars

• 

Security threats

•  vulnerability of the CAN bus

•  Denial of Service attack on CAN bus possible?

•  A few examples:

http://www.forbes.com/sites/andygreenberg/2013/07/24/hackers-reveal-nasty-new-car-attacks-with-me-behind-the-wheel-video/ and

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

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

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

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

Safety Assurance in Connected Vehicles

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 An Example--a partial preliminary safety case for a braking system.

ITS applications such as Collaborative Cruise Control require controlling the braking system.

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.

Safety Assurance in Connected Vehicles

DoS chassis safety controller

Disable in-car sensors Jamming in-car

communication A partial attack tree for automatic brake function

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

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.

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

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

/ Faculteit Wiskunde en Informatica