4 LAYERS OF SECURITY
FOR CONNECTED CARS
DANNY MCKENNA
AUTOMOTIVE MICROCONTROLLERS & PROCESSORS
PUBLIC USE
The Connected Car…
A Cloud-connected Computer Network on Wheels
802.11p
•
A networked computer
•
•
•
•
•
up to 100 ECUs per car
and many sensors
inter-connected by wires
more and more software
Increasingly connected
to its environment
• to vehicles & infrastructure
• to user devices
• to cloud services
1
802.11p
PUBLIC USE
#NXPFTF
Radar
NFC
LF, UHF
Portable Device
Connectivity
NFC
NFC
… is an Attractive Target for Hackers!
Valuable Data
High Vulnerability
Easy (Remote) Access
• Collection of data/info
• Storage of data
• Diagnostic functions
• Increasing number of nodes
• More advanced features
• X-by-Wire
• Fully Connected Car
• External & internal interfaces
• Wired & wireless interfaces
Protect Privacy
Increase Safety
Prevent
Unauthorized Access
Cloud Connection
Consumer Device Integration
In-Vehicle Network
2
PUBLIC USE
#NXPFTF
Car2X
What is Security?
•
Security is a quality aspect…
− Attackers
•
should not be able to subvert the proper operation of a system
…in an uncontrolled and evolving environment
− Attackers
do not obey to “the rules”
− Attack(er)s only get better over time
•
Security must be an integral part of the system design
is as strong as the weakest link  point solutions usually don’t work
− Secure by design vs. security as an afterthought
− Security
•
100% secure does not exist in the real world
− It’s
3
about finding the right balance between costs (protection level) and benefits (risk reduction)
PUBLIC USE
#NXPFTF
Security requires a Different Mindset
Hacker:
Engineer:
Let’smake
makeititwork
fail
Let’s
Security engineer:
Think about how things can be made to fail...
…and prevent such failures!
4
PUBLIC USE
#NXPFTF
From Physical to Remote (Logical) Attack
•
Anatomy of a typical, successful attack:
•
1. Find a vulnerability in one ECU
•
− Automated
hacking scripts/tools are
published on the internet
− The complete attack can be mounted
remotely
Ideally an ECU that is remotely accessible
2. Exploit the vulnerability
•
E.g. gain more / full access over that ECU
3. Attack other ECUs
•
•
5
It gets really “scary” if the attack can
be scaled, e.g. because:
From the now compromised ECU
Ultimately, a hacker might achieve full
control over the vehicle
•
Worst case scenario: script kiddies can
remotely control fleets / series of cars
Physical Attacks
Remote Attacks
Typically difficult, requires:
• deep knowledge
• physical access
• reverse engineering
May be relatively easy,
if e.g. automated tools
are published
PUBLIC USE
#NXPFTF
Defense in Depth
Securing the Vehicle’s Electronics Architecture
•
•
Multiple security techniques, at different levels in the architecture
To mitigate the risk of one component of the defense being compromised or circumvented
Prevent
access
Detect
attacks
Reduce
impact
SECURE
CAR ACCESS
Fix
vulnerabilities
+1
SECURE
PROCESSING
Authenticate code
(secure boot)
Authenticate
code
Run-Time
(secure
boot)Protection
Integrity
Run-Time
Resource control
Integrity Protection
(virtualization)
Resource control
(virtualization)
4
SECURE
NETWORK
Secure messaging
Secure messaging
Firewalls (context-aware
Firewalls (context-aware
Intrusion detection
message
filtering)(IDS)
message filtering)
systems
M2M authentication
Firewalls (isolate
access points)
6
PUBLIC USE
M2M authentication
Firewalls (isolate
access points)
#NXPFTF
3
Secure OTA updates Secure OTA updates
…)
(firmware,
policies, …) (firmware, policies,SECURE
Separate
functional
GATEWAY
domains
Separate functional
Intrusion detection
domains
systems (IDS)
Isolated TCU & OBD-II Isolated TCU & OBD-II
2
SECURE
INTERFACES
1
NFC
4 Layers to Securing a Car
Defense in Depth
Layer 1: Secure Interface
Layer 2: Secure Gateway
Secure M2M authentication, secure key storage
Domain isolation, firewall/filter, centralized intrusion detection (IDS)
ADAS
SE
Braking
ADAS
SE
Powertrain
TCU
TCU
IVI
Braking
Powertrain
Safety domain
Gateway Comfort domain
OBD
OBD
IVI
Cluster
Cluster
Body
Layer 3: Secure Network
Layer 4: Secure Processing
Message authentication, CAN ID killer, distributed intrusion detection (IDS)
Secure boot, run time integrity, OTA updates
ADAS
SE
TCU
Braking
Powertrain
IVI
TCU
Safety domain
Gateway
#NXPFTF
Powertrain
Safety domain
Gateway Comfort domain
Cluster
PUBLIC USE
Braking
IVI
Comfort domain
OBD
7
ADAS
SE
Body
Body
OBD
Cluster
Body
Layer 1 – Secure Interface
•
Secure authentication of users, devices and messages
•
•
•
•
Automotive (M2M): V2X communication, Telematics (online services), …
Traditionally (user): banking cards, electronic passports, …
Implemented on a tamper-resistant platform…
•
•
•
Securely hosts security applications and their confidential data
Protected against physical attacks (SCA, reverse engineering, …)
Proven security, via 3rd party evaluation and certification
(Common Criteria, EMVCo, FIPS 140, …)
…that provides:
•
•
•
8
Form factors:
smart card
embedded Secure
Element (eSE)
Example applications:
mobile payment
2nd factor user auth.
V2X communication
electronic passport
secure crypto processing (AES, RSA, ECC, TRNG, …)
secure (crypto) key generation & storage
secure certificate handling (validate & store)
PUBLIC USE
#NXPFTF
Layer 2 – Secure Gateway
•
Vehicle Architecture (Simplified)
Gateway is THE central node in the
vehicle architecture
•
Connects all the vehicle domains across all
the interfaces (Ethernet, CAN FD, LIN)
•
Provides network isolation and security
between functional domains and networks
•
Includes hardware accelerated crypto
capability (HSM/CSE)
•
Transmits message to ECU on destination
domain (adding secure signature to message)
Gateway
ECU
ECU
Infotainment
domain
(CAN1)
ECU
ECU
Safety
domain
(FlexRay)
Body
domain
(CAN0)
Other
Domains
(Ethernet,
CAN, LIN)
Gateway Function
•
~20% adoption in vehicle architecture
today, moving to ~50% by 2020
•
NXP will be #1 in this market by 2018
CAN,
LIN,
FlexRay,
Ethernet
R
X
Filter /
Firewall
What
Action?
SOC Resources
HSM
PUBLIC USE
#NXPFTF
Outgoing
Frame
T
X
CPU
Comms
9
Sign
Auth
HSM
Comms
CAN,
LIN,
FlexRay,
Ethernet
Layer 3 – Secure Network
Starting from an ultra-low Emission, 5Mbps-fast CAN transceiver
Advanced technology enables intelligence being added
•
Adding security at network (link)
level:
•
rate limiting
•
context-aware message filtering
(incl. deep packet inspection)
•
•
10
message protection
(message encryption, authentication)
•
device (ECU) authentication
•
…
CAN Transceiver
CAN
decoder
CAN FD
controller
Set of policies
stored in
memory
Reacts to
Wake up Frame
CAN bus monitor  Partial Networking
Stops all FD frames
Sends error frames
CAN FD bus monitor  FD Shield
Detect / block
malicious
frames
ID/Frame/Rate inspection  IDS / IPS
Message
authentication
(+encryption)
Crypto engine  CAN message protection
Hybrid
Networks
CAN, CAN FD
Network
Security
Option: small
programmable core
AES
accelerator,
Key storage
CAN FD
Network
Security
Example: extending a CAN FD PHY with message filtering and message protection features
For example, integrated into:
•
CAN transceivers
(retrofit security to legacy networks)
•
Ethernet transceivers and switches
(MACsec / 802.1AE)
PUBLIC USE
Energy saving,
ECU flashing
#NXPFTF
Future IVN: Automotive Ethernet
Layer 4 – Secure Processing
•
Defined by hardware
accelerated Crypto
capability
•
IP can be applied to any
MCU/Processor
•
Use cases:
•
•
•
•
•
11
CAN Message authentication
Secure boot – FW auth.
Key storage
Encryption
OTA software updates
PUBLIC USE
#NXPFTF
ADAS
GPIS
C&S
VDS
Advanced Driver
Assistance Systems
General Purpose &
Integrated
Connectivity & Security
Vehicle Dynamics &
Safety
Radar
8 Bit
Vison
16/32 Bit
Fusion
Integrated
Gateway
Chassis
& Safety
Powertrain
Custom
Securing Firmware Over-the-Air (FOTA) Update Flow
Security Needs:
• Protect the authenticity and
integrity of firmware to prevent a
hacker from running modified code
• Encrypt the firmware to prevent a
hacker from stealing IP
• Establish secure end-to-end
connection to prevent man-in-themiddle attacks.
• Ensure firmware cannot be rolled
back
• Ensure a secure, trusted location
for the OTA Manager application
12
PUBLIC USE
#NXPFTF
User Demands:
• Minimal affect on drivers (e.g.
no vehicle down time during
update)
• no risk of failed update leaving
car unusable.
Hardware Security is a Must
•
Crypto accelerators,
to guarantee strict performance requirements
− E.g.
•
SECURE
CAR ACCESS
message authentication (V2X, CAN), secure boot
Hardware-enforced isolation,
to protect against software attacks
− E.g.
•
+1
SECURE
PROCESSING
system vs. user mode, TrustZone, SHE/HSM
4
Tamper-resistant hardware,
to protect against advanced, physical attacks
− E.g.
•
SECURE
NETWORK
3
Secure Elements
SECURE
GATEWAY
Lifecycle management
to gradually close device access through manufacturing cycle
− E.g.
13
test & debug access
PUBLIC USE
#NXPFTF
2
SECURE
INTERFACES
1
NFC
Security Throughout the Entire Lifecycle
Increased security level at each
stage of the development lifecycle
•
Non-reversible, non-revocable
•
Enable application development,
debugging and failure analysis
•
Without compromising security in
In
Field
Security Level
•
Vehicle
Production
Application
Development
Out of
Fab
the production vehicle
Vehicle Lifecycle
14
PUBLIC USE
#NXPFTF
Field
Return
NXP Automotive Security
SECURE
CAR ACCESS
●
NXP #1 in Auto HW Security
●
4-Layer Cyber Security Solution
●
Secure on-board
communication
Secure Transceivers
Plus ‘Best In Class’
Car Access Systems
●
Recognized Thought &
Innovation Leader
Central Gateway
Secure Routing, Firewall
●
> 900 security patent families,
~ 200 specific to Automotive
●
Partner of Choice for OEMS, T1s
& Industry Alliances
+1
NFC
Secure Car Access
Immobilizer, RKE/PKE & Smart Car Access
SECURE
PROCESSING
Secure “Brains”
Secure MCU/MPU
4
SECURE
NETWORK
3
SECURE
GATEWAY
2
SECURE
INTERFACES
1
15
Secure Cloud Connections (V2X, Telematics, cGW)
Secure Element
PUBLIC USE
#NXPFTF