© 2017 Arm Limited

Andrew.Michael.Jones@arm.com

Future System Design

Architecture and Technology Group

Secure Isolation for Autonomous Vehicle Architectures

© 2017 Arm Limited 2

Engine

sensors

Engine

control

Steering

motorBraking

Vehicle

stability

Battery

manager

Wheel

sensors

Steering

wheelFuel pumpAirbags

Eco

stop/start

Gearbox

control

Tyre

sensors

Arm Processors are widely deployed in Automotive

Body electronicsSensors, actuators, commsUsually Cortex-M

ADAS, IVI, Cluster, ConnectivityCortex-A for main processorsCortex-M and R support functions

Powertrain and ChassisCortex-R, also Cortex-MSafety-related controllers

Headrest

displays

Bluetooth

MirrorLink

Navigation

eCall

Telematics

V2X

Cellular

IVI

processor

Cluster

processor

Head-up

display

Cluster

display

Front

radar

Front

camera

Side

cameras

Rear

camera

ADAS

processor

Driver

alert

Rear lightsTailgate

Beam

steering

Front

lights

Interior

lightsHVAC

LockingSide

mirrors

Seat

adjustor

Sun-roofWipers

washers

Keyless

start

Anti dazzle

rear view

© 2017 Arm Limited 3

AV Attack TaxonomyAttack on AVs

Attacker

hacktivists

thieves

Terrorists

Espionage

Attack vector

physical access

Non-invasive

side-channel

clock glitch

Power glitch

Invasive

FIB

Microstation

remote access

signal spoofing

Malware Injection

Fault Injection Query

target

ECUs

Sensors

GPS

Intra-Vehicle comms

V2V links

V2I links

motive

Financial

Challenge/ Thrill

Physical Harm

potential consequences

Information Leakage

Loss of AV control

Loss of Property

Performance Degradation

Financial Loss

Reputational Loss

© 2017 Arm Limited 4

AV Defence TaxonomyAV Defences

Preventive Defence

secure comms

In Vehicle device

Authentication

User Authentication

Firewalls

Secure Platform Architectures

Active Defence

ContinuosSecurity

Monitoring

Adaptive security

Proactive

Responsive

Passive Defence

Detection

Intrusion

Malware

Response

nullification

Quarantine

Recovery

Availability

Collaborative Defences

© 2017 Arm Limited 5

Automotive Security Standardsst

and

ard

sISO21434

SAEJ3061

ISO27001

CERT C

MISRA C

ISO12207

NIST FIPS 199

ISO 26262

Auto Alliance Consumer Privacy

Protection Principels

NIST FIPS 140-2

TVRA

STRIDE

EVITA

HEAVENS

SAE J2931

Sco

pe

System Design

Asset Protection

Threat Model

Countermeasures

Software Engineering

Security Assesments

Incident Response

© 2017 Arm Limited 6

Priority: Preventing Scalable Attacks

Central

Gateway

Instrument

Cluster

Head Unit

Comms Unit

Diagnostic I/F

Powertrain DC

Chassis DC

Body DC

ADAS DC

Laptop Tablet Smart Phone Smart Charging4G/LTE WAVE/DSRC

HSM

HSM

HSM

HSM

HSM

HSM

HSM

HSMHSM

HSM

HSM

HSM

Connectivity

Gateway

HSMFirewall HSM DC - Domain Controller

Scalable attack (noun): The ability of one malevolent actor to hack many vehicles at low cost.

• Proximity• Cost per vehicle

• The strongest attack vector is introducing malware or remotely injecting faults.

• Our biggest defence against scalable software attacks is hardware isolation mechanisms

• Domain Separation• Hardware trust anchors

including physical defences• CPU & platform have

hardware support for isolating software.

• CPU support for Virtualisation

© 2017 Arm Limited 7

Use Case: Safety Assisted Braking

V2V

V2I

• Via the Cloud, V2I and V2V• Via short range radio V2I• GPS• Air Bag deployment• Brake sensor

© 2017 Arm Limited 8

Use Case Active Brake example

Sending Vehicle

Receiving Vehicle

Brake SensorBrake ECUComms ECU

Comms ECU Brake ECU Instrument Cluster

* DENM = Decentralised Environmental Notification Message

Scenario: When emergency braking – a vehicle sends brake status info to surrounding vehicles; Receiving vehicle uses its own status to provide recommendations to driver or (even an automated brake.)

• Sender’s Brake Sensor ECU updates Brake ECU via HSM-secured comms channel to Brake ECU

• BRAKE ECU algorithmically determines the active brake scenario and triggers an HSM-secure communication to the Comms ECU.

• The Comms ECU broadcasts a secure DENM*

• Receiving Comms uses HSM to verify authenticity and integrity of DENM*

• The Active Brake info is sent to Brake ECU which algorithmically determines if driver requires recommendation.

• Sends HSM-Secured message to HMI

© 2017 Arm Limited 9

Silicon Providers increasingly concerned about Side-Channel and low-cost Invasive attacks

ChipWhisperer-Lite is a complete package for exploring how side-channel power analysis and glitching attacks work against the included target device.

$250 USD

ChipWhisperer-Prointegrates a larger FPGA to provide additional features you can’t get from our ChipWhisperer-Lite., along with a robust case for use in a lab environment.

$3800 USD $Several-K USD

MCU Hacking ; Fuse reading; F/W Rev. Eng.

© 2017 Arm Limited 10

Hardware Security Modules: Physical countermeasuresHardware Security Module – Isolated – reusable security subsystem

• Crypto accelerators

• Dedicated storage and Compute resource

• Secure Key Store

Threat Class Attack Vectors Mitigation Measures at a glance

Side Channel Attacks (SCA) Power Analysis Secure power domain that protects the targets the protected logicEM Analysis

Invasive Attacks Probing Tamper resistant shield and sensing layerLayout hygieneCircuit Modification

Perturbation Attacks Optical/EMFI/BBI Energy sensing fabric – to detect malicious energy.Glitch sensors – Voltage/Clock manipulation Voltage Manipulation

Clock Manipulation

© 2017 Arm Limited 11

Software Security TechniquesProblems

▪ Modern systems are built from large, complex bodies of code

▪ Many different providers

▪ Some very old and barely understood

▪ Vast differences in quality

▪ Complex interactions between different sub-systems▪ Some code written in “safer” high level languages

▪ Java, C#, Swift▪ Much of it written in unsafe languages such as C/C++

▪ Increasing number of significant exploits

▪ New classes of attack continue to appear (ROP, JOP, LOP, COOP)

▪ ‘arms race’ of exploits and hardware/software mitigations

Fine Grain defenses

▪ Software organisation• New languages with inherent/better safety• Process based partitioning of rights

▪ Tools • Development time checks – fuzzing, static analysis, formal proofs• Runtime checks - bounds checking, stack guards, shadow stacks, CFI checks

▪ Hardware extensions• Non-execute, execute only, privilege execute never, pointer authentication

Managed Heap

Safe stacks

Managed Static/JIT code

Native C runtime

Native C libraries

Kernel

Hypervisor

Trusted Firmware

© 2017 Arm Limited 12

Coarse grained partitioning

App1 App2 App1 App2 Secure App1 Secure App2

Guest OS1 Guest OS2 Secure OS

Hypervisor

Secure Monitor

EL0

EL1

EL2

EL3

© 2017 Arm Limited 13

Threat Models and Security Analyses

Threat Models and Security Analyses

Platform Security Architecture (PSA) – Trilogy Defence

Platform SecurityArchitecture

Hardware system architecture (TBSA)

Trusted boot and firmware update

(TBFU)

Trusted device initialisation

Firmware framework (FF)

Root of Trust services

Security Model

Specify

ImplementationImplementationImplementation

Threat Models and Security Analyses (TMSAs)

Inform

Assess

HW & FW architecture specificationsOSS FW implementation

(Trusted Firmware – M)

© 2017 Arm Limited 14

Trusted Base System Architecture

TBSA comprises a set of requirements aimed at providing a secure hardware foundation for Microcontrollers.

Types of requirements :• Enforce TrustZone system principles• Supports baseline S/W secure services• Prohibitions on bad practices• Propagation of good practices

TBSA-Client (A class) TBSA-M (M-class)• Requirements • Recommendations

• Physical Isolation• Computational Isolation• Spatial Isolation• Temporal Isolation

System view

Infrastructure

Fuses

Cryptographic keys

Trusted boot

Trusted timers

Version counters

Entropy source

Cryptographic acceleration

Debug

External interface peripherals

DRAM protection

Device lifecycle

© 2017 Arm Limited 15

Application RoT Services

Platform Security Architecture Firmware FrameworkPartition

• The unit of execution

Secure Partition Manager (SPM)• Provides the boot, isolation and IPC services

to the SPE

Secure Service• A set of related APIs invoked through secure

IPC

Application Root of Trust (RoT) Services• App-specific security services

PSA Root of Trust Services• Secure services provided by generic trusted

firmware specified by PSA

Non-secure partition

Application firmware

OS libraries

OS kernel

Application RoT Service

Updateable RoTService

Secure Partition ManagerSecure IPC Secure isolation Secure debug

Isolation boundary

Secure Processing EnvironmentNon-secure

Processing Environment

ApplicationRoT Service

ApplicationRoT Service

Immutable Root of Trust

HWUK Boot Validation Key TRNG

H/w Acceleration Attestation Key Boot Decryption Key

Attestation

Device Binding

FW Validation

RNG

Nonce Counter

Crypto Ops

Boot ROM

Key Storage

Attestation Endpoint

Secure Storage

Device Management

Crypto Services

…

© 2017 Arm Limited 16

Managing the Security Ecosystem

• The SoC Trusted OS (ToS) is typically chosen by the Si Vendor

• Some OEMs rely on features which are not present in all TOSs

• OEMs may want to ship ECUs with different Si Vendors with common s/w.

=> Porting costs, timescale

generic vendor specific

SoC TOS

ARM TF

Rich OS

Non-secure Secure

EL0

EL1

EL2

EL3

NS Apps

Trusted Apps

TCB

Open Applications

Applications

Requiring

TOS support

TrustZone API

TOS Driver

© 2017 Arm Limited 17

Ecosystem Security - Problem

Challenges arising from increasing secure world complexity

Significant software footprint in one address space

• Requires trust in several providers software

Cannot:

• Limit Secure-EL1 address map visibility

• Protect non-secure world from secure world accesses

Hosting multiple Trusted OS requires modification

Breaks principle of least privilege

Complicates Certificationgeneric vendor specific

SoC TOS

ARM TF

Rich OS

Non-secure Secure

EL0

EL1

EL2

EL3

NS Apps Trusted Apps

TOS

co-existent

TCB

© 2017 Arm Limited 18

Architectural Solution with Secure EL2

S-EL2 provides improved isolation

Each Trusted OS runs in a secure partition

Separates platform firmware from Trusted OS and applications

Arm providing Secure Partitions standardization and Trusted Firmware support for interfaces and runtimes

Hardware support for virtualizing the secure world

White Paper : https://community.arm.com/processors/b/blog/posts/architecting-more-secure-world-with-isolation-and-virtualization

generic vendor specific

SoC TEE

ARM TF

Rich OS

Non-secure Secure

EL0

EL1

EL2

EL3

Trusted Apps

TOS

SP runtimeSP interface

Arm v8.4-ANS Apps

© 2017 Arm Limited 19

Virtualized applications Security and Hardware security

EL0

EL1

EL2

EL3

Application trusted OS specific

Application provider specific

Generic Software

Silicon vendor specific software

Isolation boundary

VW Trusted App

Trusted Application

VW Client

APP

Client Application

TA LibraryTA LibraryClient Library

VKMS Adaptor

Trusted OS KernelAUTOSAR-CSM

Trusted OS Driver

Platform Firmware

Secure Partition Manager

SEL2 Firmware

EL3 Firmware

SPCI

SPCI

SPRT SPRT

Hypervisor

Secure Partition with trusted OS

Secure Partition Silicon vendor drivers

Resource Description

Normal World Common firmware

Normal World Secure World

Physical HSM

Firmware

VKMS

CC

RTOS

Crypto Library

SHE+ emul

Key Store

HSM I/F

Security AppsSecurity Apps

Security Apps

AUTOSAR-CSM

Trusted OS Driver

SPCI

VM-1 VM-2

© 2017 Arm Limited 20

Summary

• Prevention of scalable attacks – highest priority

• Requires physical and architectural defences

• Ramping up Architectural defences – both fine grain and coarse grain Isolation

• Addressing ecosystem diversity with Virtualisation of Trusted and Non-Trusted worlds.

2121

Thank You!Danke!Merci!谢谢!ありがとう!Gracias!Kiitos!

© 2017 Arm Limited

© 2017 Arm Limited

Backup