Download Safe and Secure Communication with Automotive Ethernet

Safe and Secure
Communication with
Automotive Ethernet
Michael Ziehensack
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015
October 27-28, 2015 – Yokohama, Japan
Safe and Secure Communication with Automotive Ethernet
Motivation
• Advanced driver assistance system are evolving towards Autonomous driving
‒ from Alert & assist, such as
Lane Departure Warning and Lane Keeping Assist
‒ to features that take more control, such as
highway chauffeur or valet parking
Photo Source: Gizmag
‒ The communication between the ECUs is critical,
e.g. invocation of the breaks with full force at the wrong time because of
• an addressing fault (message received at the wrong destination)
• a corrupted message (bit flip at the receiver)
• an attacker injecting a malicious control command …
‒ ECU communication needs to be protected  safe and secure!
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
2
Safe and Secure Communication with Automotive Ethernet
Safe vs. Secure communication
• Safe communication for sensitive data between ECUs
− Protection against effects of non-malicious faults on the communication link, such as
message corruption, resequencing, message loss, …
• Secure communication for sensitive data between ECUs
‒ Protection against effects of malicious faults on the communication link, such as
injection of malicious control commands, prevention of correct system function
(insertion, deletion, manipulation, replay and delay of messages)
‒ Assuming malicious faults are not introduced during development (such as logic
bombs or trapdoors) they are attacks on the system
Security
Safety
(protection against attacks) (prevent harm of humans)
Attack
System
Malfunction
Property
Environment
Human Life
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
3
Safe and Secure Communication with Automotive Ethernet
Threat Model – static vs. dynamic
Safety: static threat model
•
•
•
Threats are known at system design
Threats are non-malicious, humanmade or natural caused malfunctions
Goal: Prevent harm of humans
(“physical injury or damage of the
health of persons”)
Security: dynamic threat model
•
•
•
New threats can emerge during
system operation
Threats are attacks (malicious,
human made, external)
Goal: Protect assets (property,
environment and human life)
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
4
Safe and Secure Communication with Automotive Ethernet
Safe Communication
• End-to-End Protection (E2E Protection)
‒ ISO 26262-6:2011 provides a list of faults regarding the exchange of information:
Repetition, Loss, Insertion, Incorrect sequence, Corruption …
‒ E2E Protection is a collection of safety mechanism for the reliable detection of these
faults
• Basically the sender adds protection information (such as CRC, sequence counter) to the data
• The receiver evaluates the received message and indicates the result to the application
E2E Protection well established for
Sender/Receiver communication
E2E Protection need to be defined for
Client/Server communication (RPC)
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
5
Safe and Secure Communication with Automotive Ethernet
E2E for Sender/Receiver Communication
• For cyclic Sender/Receiver Communication via Ethernet up to 4kByte length,
AUTOSAR E2E Profile 4 has been introduced as part of AUTOSAR 4.2
Mechanism
Detected failure modes
Counter
Repetition, Loss, Insertion, Incorrect sequence of
information
Data ID
Insertion of information,
Masquerade or incorrect addressing
CRC
Corruption of information
Configurable Offset
User-data …
Length16
E2E Header
Counter16
DataID32 (explicit)
CRC32
… User-data (1…4083 bytes)
Data for transmission
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
6
Safe and Secure Communication with Automotive Ethernet
Proposal
E2E for Client/Server – failure mode analysis
UC1 … request action, UC2 … request data; C/S constraints defined
UC1
UC2
ISO26262 failure mode
UC1+UC2
Server Client Server Client Server Client
1
Repetition of information
X
(X)
-
(X)
X
(X)
2
Loss of information
-
X
-
X
-
X
3
Delay of information
-
X
-
X
-
X
4
Insertion of information
X
(X)
-
X
X
X
5
Masquerade or incorrect addressing
X
(X)
-
X
X
X
6
Incorrect sequence of information
-
(X)
-
(X)
-
(X)
7
Corruption of information
X
(X)
-
X
X
X
8
Asymmetric information
n/a
n/a
n/a
n/a
n/a
n/a
9
Info received by only a subset of receivers
n/a
n/a
n/a
n/a
n/a
n/a
(X)
(X)
(X)
(X)
(X)
(X)
10 Blocking access to a communication channel
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
7
Safe and Secure Communication with Automotive Ethernet
Proposal
E2E for Client/Server – Safety mechanism
• CRC32: Covering protection information and data  detects 7
• Unique Server Operation identifier (System-wide)  detects 5 (Server)
• Sequence Counter per Client and Operation  detects failure mode 1, 4, 6
‒ increased at each request, also for retries + identical value in response
• Timeout detection at Client  detects failure mode 2, 3
‒ Timeout starting at Request, deactivated at reception of Response
• RPC E2E message Header containing protection info
‒ all protection info as part of the RPC E2E Header
Length16
Server
OperationID
Client
ID
Session
ID
CRC32
… Data …
‒ or re-using existing data from Client/Server Headers (e.g. SOME/IP header)
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
8
Safe and Secure Communication with Automotive Ethernet
E2E for further communication types
• E2E Protection for global time sync messages?
‒ ASIL Assignment for Global Time Sync: QM, ASIL B? Depends on usage of global time
• E2E constraints:
correction term of Follow-Up
message is updated at each switch,
thus E2E protection information would
need to be updated at each switch
which would require an ASIL
compliant switch firmware
Slaves clock offset = t4 - (t1 + (t3 - t2))
• Possible solution:
(consideration of link_delay skipped for simplicity here)
protect OriginTimestamp (t1) by CRC
and use robust clock sync control algorithm
(i.e. perform plausibility checks of correctionField value and limit the impact of a single
(wrong) correction term to the clock sync) at the slave.
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
9
Safe and Secure Communication with Automotive Ethernet
Safe Communication with AUTOSAR
AUTOSAR E2E consisting of
• E2E Transformer E2EXf
(provides config and state)
•
E2E Library
(algorithm: protect/check,
state transition)
Tx Data path
• SWC writes data via RTE
• RTE calls Serializer
• RTE calls E2E Transformer
+ E2E Library
Rx Data path
• SWC reads data via RTE
• RTE calls E2E Transformer
+ E2E Library
• RTE calls Deserializer
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
10
Safe and Secure Communication with Automotive Ethernet
Secure Communication
• Protection against effects of malicious faults on the communication link
‒ Goal of Attack: injection of malicious control commands, prevention of correct system
function (insertion, deletion, manipulation, replay and delay of messages)
‒ Point of Attack: additional nodes (e.g. via OBD connector), corrupted and misused
existing nodes (e.g. root access to infotainment system via cellular network), nodes
replaced by manipulated ones
• Multi-Level Security Approach
‒ Several security barriers need to be established to avoid a full exposure in case a
security mechanism is bypassed.
• Level 1: restrict access to the network
• Level 2: secure onboard communication
• Level 3: apply data usage policies
• Level 4: detect anomalies at the network and defend
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
11
Safe and Secure Communication with Automotive Ethernet
Multi-Level Security Approach – Level 1
• Level 1: restrict access to the network
‒ Network design/topology:
• limit number of ECUs with off-board connections (WLAN, bluetooth, cellular, wireless key,
DAB, OBD plug, PLC …), e.g. central network access point with stateful firewall, diagonstic
communication from external tester to ECUs not directly, but via the central gateway
(communication between tester and central gateway via TLS)
• Divide network into security zones (e.g. extern, “demilitarized”, internal) and restrict traffic
between zones (physical split or separation via VLANs)
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
12
Safe and Secure Communication with Automotive Ethernet
Multi-Level Security Approach – Level 1
• Level 1: restrict access to the network (continued)
‒ static Ethernet Switch Forwarding tables
OR MAC learning only during
learning mode (e.g. end-of-line)
‒ static ARP tables at nodes OR
Address Resolution Protocol only
during learning mode
(e.g. end-of-line)
‒ device authentication/authorization,
deactivation of unused (non authorized) ports
Stream2
ECU
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
20
20
Stream1
40
‒ Enforce bandwidth limitation
at nodes and switches
(to avoid denial of service attack)
Source: AUTOSAR 4.2 EthSwt SWS
20
Switch
13
Safe and Secure Communication with Automotive Ethernet
Multi-Level Security Approach – Level 2
• Secure Communication – Level 2: secure onboard communication
‒ Data integrity, authentication
• Authentication and integrity of critical frames based on Message Authentication Code (MAC,
i.e. usage of symmetric key) and Freshness value (counter or timestamp)
• Symmetric key because of calculation effort (and required bandwidth)
• Sender generates MAC based on
DataId, data, freshness value
and secret key.
MAC and freshness value are
transmitted together with
PDU data.
DataId
DataId
• Receiver verifies MAC based on
received data and
freshness value as well as
locally stored secrete key, DataId
• CNT/MAC truncation can be used
if message length is very limited.
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
Source: AUTOSAR 4.2 SecOC SWS
14
Safe and Secure Communication with Automotive Ethernet
Multi-Level Security Approach – Level 2
• Secure Communication – Level 2: secure onboard communication (continued)
‒ Communication Groups, Session Keys, HW support
• Instead of a single and permanent secret key, critical communication is clustered into secure
communication groups, key is only valid for a certain period to limit the exposure in case of
compromise
• For efficient execution of cryptographic functions and secure key storage a
hardware security module (HSM) is used in combination with software crypto libraries.
‒ Key Distribution
SB
Internet
Asym/Sym
Off-board
ECU
KM
Sym
On-board
Based on: The EVITA Project
• Service Backend (off-board) >> KeyMaster (on-board): delivery of secrete keys for MAC
generation by using encryption (asym/sym crypto), secure storage in HSM
• KeyMaster >> ECUs: secrete keys for MAC generation assigned periodically to ECUs by using
encryption (sym crypto), secure storage in HSM
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
15
Safe and Secure Communication with Automotive Ethernet
Multi-Level Security Approach – Level 3, 4
• Secure Communication – Level 3: apply data usage policies
‒ Define policies to avoid execution of critical functions, examples:
• allow diagnostic messages only in specific vehicle state (e.g. speed < 5mph)
• accept only frames from known nodes
• Secure Communication – Level 4: detect anomalies at the network and defend
‒ Anomalies: deviations to specified communication matrices
• e.g. cyclic message is received more often than defined, very high network load, 1:n message
received with different source addresses, …
‒ Detection: via central device or at the receiver
• e.g. plausibility check based on diverse input data or data sequence, failed integrity checks
‒ Defend: report (e.g. DTC, involvement of driver, …) and start mitigation
• mask (e.g. block messages from infotainment ECU) or
• reconfigure (e.g. deactivation of critical functions, initiate hand-over in case of autonomous
driving, request change of session key …)
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
16
Safe and Secure Communication with Automotive Ethernet
Secure Communication with AUTOSAR
Csm
CryHsm
Interface layer
Csm
Implementation layer
Cry
SecMon
Hardware
Security
Module
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
17
Safe and Secure Communication with Automotive Ethernet
Summary
• Autonomous driving requires safe and secure communication
• Safe Communication:
‒ E2E for S/R extended for large messages
‒ E2E for C/S concept proposal available
‒ E2E for TimeSync solution proposal shown
• Secure Communication:
‒ Multi-Level Security Approach consisting of
4 levels implementing various protection strategies demonstrated
‒ L1: restrict access, L2: secure onboard comm., L3: policies, L4: detect and defend
• Conclusion: Solutions are available (even though not all are standardized
now) … just use them to protect your ECU communication!
IEEE-SA ETHERNET & IP @ AUTOMOTIVE TECHNOLOGY DAY 2015, Michael Ziehensack (Elektrobit)
18
Thank you!
automotive.elektrobit.com
[email protected]
We
Wetake
takeyou
youto
tothe
thefast
fastlane!
lane!