Example of security integration with E/E architecture

Example of security integration with E/E architecture

Yasuaki MORITAToyota Motor Europe NV/SA

12/Oct/2017

Overview

Background

Toyota E/E Architecture

Approaches

Summary

- Defcon 21 (Aug, 2013)

‘08 Prius was hacked by injection on board communication

- Defcon 22 (Aug, 2014)

Several OEMs architecture was analyzed and assessed

- Blackhat/Defcon 23 (Aug, 2015)

Other OEMs telematics systems was hacked

- Defcon 24 (Aug, 2014)

No specific car hacking

- Defcon 25 (Aug, 2017)

…

Reference Youtube

Background : Security threat increasing against vehicleBlackhat / Defcon:

famous hacker event for cyber securityVehicle is trying to be hacked on famous hacker event

Vehicle becomes a target to be hackedThis threat will increase when autonomous driving deployed widely

Vehicle becomes a target to be hackedThis threat will increase when autonomous driving deployed widely

1. Isolation between Vehicle and IVI

There is dedicated API to control vehicle behavior from NW I/F

in Gateway (i.e. function which could be control from NW I/F was limited)

2. OTA

Framework to update security against vulnerability is prepared

3. Individuality between each component in a system

If one component is hacked,

it will not have high impact on the other component

Background

Ethernet switch

CAN bus

USB

Ethernet

USB

Ethernet

Service

Port

SoC SoC

Gateway

Free RTOS

Vehicle

Control

WIFI/Bluetooth GSM

Networkinterface

Network

System

SoC: System on ChipRTOS: Realtime OSOTA: Over the air update

Best practice in industry : assessment was highly secured because it has the following factor

To improve security of vehicleadequate EE architecture is needed

To improve security of vehicleadequate EE architecture is needed

Isolated

Legend

NextPast Now‘05 ‘08 ‘10 ‘12 ‘15

Main Driver

/ Goal

Security

Software

oriented

Toyota EE architecture history

Safety & More security

ECU assignment

policy to main BUS

Option rate of ECU

(e.g. Mandatory attached

or Optional)

Domain (e.g. Powertrain, Chassis)

& Security (e.g. Exposed & Internal)

Bus A

Physical

Architecture

layer stack central gateway

pro

tect

ed

new generation ECU add on

Bus Protocol

(global bus)

Bandwidth

demandsIncreased as usual

Autonomous

& connected driving

Big bang

Secure EE architecture shall be consideredSecure EE architecture shall be considered

Cen

tral

Gat

eway

DLC

Near range(ex. DSRC)

DOS attack

ITS

DCMFar range

(ex. 3G/4G)backend FirewallFirewall

FirewallFirewall

Head Unit

FirewallFirewall

Near range(ex. BT)

V2X

Connected

IVI

Fire

wal

l/DM

Z/F

ilter

ed ro

utin

gK

ey m

anag

emen

t

DC

DC

CoreVehicleFunctionalityD

C

AccessPointAccessPoint

In vehiclenetworkIn vehiclenetwork

ECUECU

SoftwareUpdate(OTA)

Data MAC

DCM: Data connection moduleIVI: in vehicle infotainment

V2X: Vehicle to XOTA: Over the air update

DOS: Denial of service

EE architectural goal in security aspect (example)

To mitigate risk, multiple layer security is neededTo mitigate risk, multiple layer security is needed

2nd layer (GW) :

- Firewall

- Demilitarized Zone

4th layer (Private IVN) :

- Message Authentication

3rd layer (Public IVN) :

- Message Authentication

1st layer (Access point) :

- Firewall

- Intrusion detection

5th layer (ECU) :

- Anti-tampering

1st layer 2nd layer

3rd layer

4th layer

5th layer

Layer and functionality

1) Architectural change due to domain isolation from exposed

communication

2) Consensus making with silicon vendor on required peripheral

3) Secure global time mechanism

4) Payload for MAC (message authentication code) requires high

bandwidth

…

Help me!

Major blocking points

1) Private communication decoupling (e.g. CAN-FD for private bus)

2) Counter based freshness (compressed) representation as shorter

payload and interpreted freshness master

3) Standardization (JasPar / Autosar)

4) CAN-FD as longer payload (e.g. 64 byte)

5) Negotiation and training…

…

Only continuous small steps enable innovation

愚直

Approaches

Problem : Legacy bus payload (e.g. CAN only has 8 bytes)

Solution : introduce more high bandwidth network (e.g. CAN-FD which has 64 bytes) but …

New NW introduce and Public / Private decoupling

Another problem : Legacy bus cannot be changed to new NW at once

Additional Solution : Introduce dedicated bus for it

New network introduction solve payload problemHighly secured message will be exchanged in private bus

Normal secured message will be on public bus

New network introduction solve payload problemHighly secured message will be exchanged in private bus

Normal secured message will be on public bus

Public

Private

Message to be protectedw/ high protectionIsolate from public busese.g. CAN-FD

e.g. CAN

DC

DC

Cen

tral

G

atew

ay

This also solve the following fact

- Isolation : New NW is hidden from public bus

- MAC message sending do not affect the other legacy bus load

Fresh value ID TripCounter

ResetCounter

MessageCounter

ResetFlag

e.g. message format

JasPar specification (message authentication) Autosar Secure on board communication

Problem : Secured global time is mandatory to establish secure environment but bandwidth is not enough

Solution : introduce compressed FV (Normal time notation consumes unnecessary bandwidth) but …

Compressed secure global time and standardization

OEM A

solution

OEM B

solution

OEM C

solution

OEM D

solution

Another problem : OEM propriety solution

Additional Solution : Standardize this solution

Compressed FV solution is standardized in JasPar & AUTOSARCompressed FV solution is standardized in JasPar & AUTOSAR

ECU AECU B

MCU plant ECU plant OEM plant

Cen

tral

C

entr

al

Gat

eway

Data Center

Dealer / Garage

ECU A

ECU B

Xupdate

Toyota installs key into vehicle from data centerTier-1 support is essential to establish this framework

Toyota installs key into vehicle from data centerTier-1 support is essential to establish this framework

Additional aspect : Key management system

install

Cen

tral

C

entr

al

Gat

eway

ECU A

ECU B

activate activate

Over view of Toyota key management system

Key

Generator

Key

Generator

Legend

Encryption software key

Key action Place / way

Key generation Data center

Key distribution way By connecting data center

Key installation place ECU plant

Key activation place OEM plant (initial) / Dealer (after market)

Future architecture / Software aspect

Further security improvement is needed for futureFurther security improvement is needed for future

Software

oriented

More security

Autonomous

& connected driving

Near future

- New generation ECU (SoC silicon) enable us to

deal with autonomous driving system

- Communication between these ECU will be

more high bandwidth

- This communication shall be protected by

using matured technologies (e.g. TLS)(e.g. One of this ECU shall behave as one of key

important role in the vehicle as “offline cloud” )

Future

- Centralized architecture is expected

- Integration of ADAS & IVI require more and

more security / isolation (e.g. protected

runtime environment)

• To make our car secure, 1. Isolation, 2. OTA, 3. Individuality is needed• Current Toyota EE architecture consider about security but more

secured architecture is needed to realize the above 3 key factors• There are blocking point to introduce secured EE architecture but we

are solving it by 1. introducing new network, 2. Implementing compressed FV, 3. Standardizing this solution

• Protected communication (e.g. TLS), more strong isolation (e.g. protected runtime environment) is also considered for future EE architecture

Summary