Automotive Intrusion Detection · 2019-04-12 · Automotive Intrusion Detection/Prevention Attack 2. Report Consolidation of security events, event storage and reporting (e.g. hardware

V1.0 | 2019-04-03

In Cooperation with the Institute for Information Processing Technologies (ITIV) – Karlsruhe Institute of Technology (KIT)Vector Cybersecurity Symposium 2019

Automotive Intrusion DetectionBenefits of a Static E/E Architecture combined with Machine Learning

© 2019. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V1.0 | 2019-04-03

~100M lines of code in one vehicle [2]

Boeing 787 Dreamliner: ~14M lines of code [2]

Increased potential for safety-relevant attacks

History with summary of exploited interfaces

Automotive Megatrends

Attack Surface and Attack History

Motivation

Connectivity

~470M connected vehicles by 2025(E.U., U.S. and China) [1]

Autonomous Driving

~80M vehicles with high or full automation by 2030(E.U., U.S. and China) [1]

2010-

2014

2015

2016-

2018

Physical access to in-vehicle network, diagnostic port, multimedia interfaces, cellular network

„Jeep Hack“ via cellular network: Recall of 1.4M vehicles

Diagnostic port, multimedia interfaces, cellular network

[1] pwc, and strategy&. 2017. “The 2017 Strategy& Digital Auto Report: Fast and furious: Why making money in the "roboconomy" is getting harder.” https://www.strategyand.pwc.com/media/file/2017-Strategyand-Digital-Auto-Report.pdf.”

[2] “McCandless, David, Pearl Doughty-White, and Miriam Quick. 2015. “Codebases: Millions of lines of code.” https://informationisbeautiful.net/visualizations/million-lines-of-code/.”

2/12


Five Steps to Compromise an ECU

Attack Example

ADASDomain Controller

InfotainmentDomain Controller

Telematic Control UnitPowertrain

Domain Cont.

ChassisDomain Controller Body

DomainController

Intrusion Detection/Prevention System (IDPS)

Diagnostic port

1.Remote access

2.Access to

in-vehicle network

3.Bridge domain

boundaries

4.Access to

target ECU

5.Manipulate ECU orvehicle behavior

Defense barriers

3/12


The Big Picture

Automotive Intrusion Detection/Prevention

Attack

2. Report

Consolidation of security events, event storage and reporting

(e.g. hardware security module, secure communication, signed uploads)

3. Analyze

Threat monitoring and threat triage for single vehicles and the whole fleet

(e.g. impact analysis, root cause analysis)

4. Develop

Threat response (e.g. identification, implementation

and test of countermeasures)

5. Deploy

Secure download of software updates(e.g. secure communication, signed updates)

Security Operations Center (SOC)

1. Prevent and Detect

Intrusion prevention and detection sensors(e.g. firewalls, gateway, diagnostics,

watchdog, operating system)

4/12


Static electric/electronic (E/E) architecture

Definition of in-vehicle communication and to some extend also ECU internals in a semi-formalized way

[DBC, FIBEX, LDF]

AUTOSAR XML (ARXML)

Host-based (ECU internals)

Control flow

CPU runtime

Memory consumption

ECU-internal communication

Network-based (in-vehicle communication)

Ethernet

Controller Area Network (CAN)/CAN FD

[Local Interconnect Network (LIN)]

Automotive Intrusion Detection Principles


Detection principles

Signature-based (detection of known attacks)

Anomaly-based (detection of deviations from normal behavior)

5/12


How to implement sensors without standardized information source?

Option 1: Extension of the ARXML format

ARXML format is already complex and difficult to maintain

Some properties cannot be specified in advance at all

Option 2: Usage of machine learning

Avoid additional specification and standardization efforts

Efficient combination of static checks and machine learning necessary> Machine learning not used as a replacement for

static checks but as a complement

➔ Deep dive: Plausibility sensor

Intrusion detection sensors (Müter et al. [3])

Intrusion Detection for Communication


Nr. SensorStandardized

Information Source

S-1 Formality

S-2 Location

S-3 Range

S-4 Frequency

S-5 Correlation

S-6 Protocol

S-7 Plausibility

S-8 Consistency

✓

✓

✓

✓

✓

✓

[3] M. Müter, A. Groll, and F. C. Freiling, “A structured approach to anomaly detection for in-vehicle networks,” in Sixth International Conference on Information Assurance and Security (IAS), 2010. Piscataway, NJ: IEEE, 2010, pp. 92–98.

6/12


Input vector Ԧ𝑥 contains the last samples of a single communication signal (sliding window)

OCSVM: No online learning

LODA: False alarm rate in first tests >= 0,3% (~ one false alarm every 5-6 minutes in the test setup)

Machine Learning Mechanisms to Check Signal Plausibility

Deep Dive: Plausibility Sensor

Autoencoder a.k.a. Replicator Neural Network [6]

𝑝2(𝑥)

𝑝1(𝑥)

𝑝3(𝑥)

One Class Support Vector Machine (OCSVM) [4]

Lightweight On-line Detector of Anomalies (LODA) [5]

Autoencoder a.k.a.Replicator Neural Network [6]

Topology: 4-2-4

[4] B. Schölkopf, R. Williamson, A. Smola, J. Shawe-Taylor, and J. Platt, “Support vector method for novelty detection,” in Advances in Neural Information Processing Systems 12. Cambridge, MA, USA: MIT Press, 2000, pp. 582–588.

[5] T. Pevný, “Loda: Lightweight on-line detector of anomalies,” Machine Learning, vol. 102, no. 2, pp. 275–304, 2016.

[6] S. Hawkins, H. He, G. Williams, and R. Baxter, “Outlier detection using replicator neural networks,” in Data Warehousing and Knowledge Discovery, ser. Lecture Notes in Computer Science, Y. Kambayashi,M. Arikawa, and W. Winiwarter, Eds. Berlin, Heidelberg: Springer-Verlag Berlin Heidelberg, 2002.

7/12


Workflow (example)Working Principle

Training

TensorFlowTM used as framework for training and evaluation

Inference

Autoencoder


Initial training and evaluation

Data pre-processing and split into different data sets(Training: ~76%, Validation: ~12%, Test ~12%)

[Results not promising]

Definition of empirical study(Variation of autoencoder topology)

Training

[Results promising]

Diagnostic data (~68h)

Synthesis of anomalies in signal curves and definition of evaluation metrics

Evaluation according to defined metrics

𝑂𝐹: Outlier Factor; 𝑂𝐹𝑆: Threshold

8/12


Synthesis of anomalies for evaluation

Definition of 13 anomaly types based on potential hardware failures (ISO 26262-5:2011 [7])

Random anomaly instances

Evaluation results

6-18-54-18-6 autoencoder

True positive rate: 85,8%

False positive rate: 00,0%

4-3-4 autoencoder

True positive rate: 78,5%

False positive rate: 00,0%

Anomalies and Evaluation Results


[7]: International Organization for Standardization, Hrsg. Road vehicles – Functional safety – Part 5: Product development at the hardware level. 15. Nov. 2011.

All Anomaly TypesOriginal Signal

Signal with Anomalies

Time [s]

Norm

. vehic

le s

peed

Norm

. vehic

le s

peed

9/12


Generation of automotive C code

No dynamic memory management, fixed point and floating point arithmetic, MISRA compliance

Optimized for execution time

Evaluation on a prototypical ECU (VC121)

Boundary conditions

120MHz, PowerPC, 32 Bit

4-3-4 autoencoder

32 Bit fixed point arithmetic

Plausibility check for one signal

~4 µs for one inference

20 Byte RAM

1112 Byte ROM

Prototypical Implementation


Check plausibility of ~250 signals (10 ms cycle) with 10% additional CPU load

10/12


Summary and Outlook

Automotive Intrusion Detection

2. Report

Consolidation of security events, event storage and reporting → need for standardization

3. Analyze

4. Develop

5. Deploy

Security Operations Center (SOC)


Quick wins with static analysis

Advanced analysis by machine learning within ECUs

First step: Inference only (no online learning)

Collaboration model to be clarified> Who provides the necessary training data?

> Who trains the algorithm?

11/12


Author:Weber, MarcVector Germany

Your questions are welcome!

http://www.vector.com/

Documents

Automotive Intrusion Detection · 2019-04-12 · Automotive Intrusion Detection/Prevention Attack 2. Report Consolidation of security events, event storage and reporting (e.g. hardware