market trends and challenges in vehicle...
TRANSCRIPT
External Use
TM
Market Trends and Challenges in
Vehicle Security
FTF-AUT-F0080
A P R . 2 0 1 4
Richard Soja | Automotive MCU Systems Engineer
TM
External Use 1
Microcontrollers and Digital Networking Processors
A Global Leader
>50 Year Legacy
>5,500 Engineers
>6,000 Patent Families
> 24 Security Certifications
Microcontrollers
Digital Networking
Automotive MCU
Analog & Sensors
RF
Five Core Product Groups
TM
External Use 2
The Connected Vehicle
Infotainment + Communication + Security
• Consumer electronics trends are dictating
features in the car
• Always connected, applications driven,
advanced graphics
• Infotainment systems becoming battleground
for Auto differentiation
• As more connected systems get introduced into
the vehicle, the need for security is critical
− Increasing external communication features
(Bluetooth, TPMS, Ethernet, Wi-Fi, etc).
− Future interface for vehicle-to-vehicle and
vehicle-to-infrastructure.
TM
External Use 3
Automotive Security Attack Surface
Base Station/
Infrastructure/
Other cars
Modem
Gateway
Diagnostics
Immobilizer
Powertrain/Body/
Chassis ECU
External
Sensors
TPMS
Dash Board/
DIS
TM
External Use 4
A Proven History in Driving Automotive Security
Mid 1990s
Censorship
Infrastructure
2010s +
Hardware
Security Module
Early 2000s
Enhanced
Censorship
Infrastructure
Late 2000s
Crypto
Security
Engine
32-bit Qorivva MCUs built on Power Architecture® technology
32-bit i.MX
Mid 2000s
High
Assurance
Boot
TM
External Use 5
Security Standards
TM
External Use 6
Freescale Participation in Standards/Consortium
• HIS – SHE specification
− SHE module (CSE) implementation in 2011
• EVITA Specification
− 3 levels of definition: Light, Medium and Full
− HSM module (Evita medium) implementation in 2012
• Preserve
− Project duration 2011-2014
− V2X Security Subsystem
− Based on EVITA Full
TM
External Use 7
Cryptographic Strengths of different Algorithms
• NIST recommendations, 2012
• The Date is the time frame during which the algorithms could be expected to provide adequate security
• The Strength is a measure of the difficulty of discovering the key
TM
External Use 8
Cryptographic Strengths of current Freescale Products
• NIST recommendations, 2012
• The Date is a projection of the time frames during which the algorithms
could be expected to provide adequate security
• The security Strength is a measure of the difficulty of discovering the key
• The Hash types are the minimum required to provide the desired security
strength
Devices Date Strength Symmetric
Algorithms
Hash
Signature
Hash
HMAC,KDF, RNG
Qorriva (AES-128 only) >2030 128 AES-128 SHA-256 SHA-1
i.MX6 (no SHA-512) >>>2030 256 AES-256 SHA-512 SHA-256
§ SHA-1 is not recommended for signatures in new systems
TM
External Use 9
Freescale Security Architectures
TM
External Use 10
Freescale Security Architecture
Multi-layered approach strengthens overall vehicle security Protects against HW and SW theft, tuning, parts cloning, mileage manipulation and personal data theft
Communications
Applications
HSM/CSE/Trust Zone
Tamper detection module
Encryption
Authentication
Firewall
Audit Trail
Flash
TM
External Use 11
Freescale Hardware-Enabled Security Options
CSE HSM TDM
Cryptographic
Security
Engine
• MPC564xB/C
• MPC5777C
• Turn-key solution
• SHE Compliant
• AES-128
• Secure Key Storage
Hardware
Security
Module
• MPC5746M
• MPC5777M
• User programmable
• Secure debug
• Supports CSE functional requirements
• Secure sensor interface
− Voltage, temperature and clock monitoring
Tamper
Detection
Module
• MPC5777M/C
• Records all
attempts to
modify flash
memory
• Detects
unauthorized re-
programming of
application code
• Protects
manufacturers’
investment
HAB
High
Assurance
Boot
• i.MX Processors
• Supports ARM
TrustZone
• Physical tamper
detection
• AES-128, AES-
256, 3DES,
ARC4
• SHA-1, SHA-
256, MD-5
TM
External Use 12
Security for the Development Lifecycle
• Increased security level required at each stage of the development lifecycle – non-reversible, non-revocable
• Ensures application can be safely developed, debugged and validated without compromising security in the production vehicle
• Protects customer software IP in field returns
Security
Level
Out of
Fab
Application
Development
In
Field
Vehicle
Production
Field
Return
Development Lifecycle Over Time
TM
External Use 13
Security Lifecycle State - Example of Impact on MCU
Resources
Customer
delivery
OEM production Failure analysis
Device test interface Closed Closed Open
BAF block Programmed
and set as OTP
Programmed
and set as OTP
Programmed
and set as OTP
UTest OTP protected OTP protected OTP protected
Passwords to unlock
the Flash protections
and the debug port
Accessible /
Programmed
SSCM access only SSCM access only
PASS LOCK register
update Can be updated
independently from the
password
Upon password matching Upon password
matching
Main core debug
interface Open Based on Censorship Based on Censorship
Boot From internal Flash if a valid
header is found, otherwise
from Serial Boot
From internal Flash if a
valid header is found,
otherwise from Serial Boot
From internal Flash
Apps Development
(Customer delivery)
Vehicle production
(OEM production)
Field Return
(Failure analysis)
Device & Flash test
interface Closed Closed Open
BAF block Programmed
and set as OTP
Programmed
and set as OTP
Programmed
and set as OTP
UTest Block OTP OTP OTP
Passwords Programmed /Readable SSCM Access only SSCM Access only
PASS LOCK register
update Without password Upon password matching Upon password
matching
Cores Debug Interface Open
Boot From internal Flash if a valid
header is found, otherwise
from Serial Boot
From internal Flash if a
valid header is found,
otherwise from Serial Boot
From internal Flash
Customer
delivery
Closed
Programmed
and set as OTP
OTP protected
Accessible /
Programmed
Can be updated
independently from the
password
Open
From internal Flash if a valid
header is found, otherwise
from Serial Boot
Out of fab §
(Pre-Delivery)
Open
Not Programmed
Programmed during test
Not Programmed
Open
From internal Flash if a valid
header is found, otherwise
from Serial Boot
n/a
§ Actually 2 states. Only
UTest Block is changed in
“Out of Fab” states
UTest OTP protected OTP protected OTP protected Flash Blocks Access Based on PASS LOCK bits Based on Censorship,
PASS LOCK bits
OTP protected Erase/Program/Read Based on Censorship,
PASS LOCK bits
In field
Closed
Programmed
and set as OTP
OTP protected
SSCM access only
Upon password matching
Based on Censorship
From internal Flash
In field
Closed
Programmed
and set as OTP
OTP
SSCM Access only
Upon password matching
From internal Flash
OTP protected Based on Censorship,
PASS LOCK bits
Based on Censorship,
PASS LOCK bits
Based on Censorship,
PASS LOCK bits
Based on Censorship,
PASS LOCK bits
Lifecycle →
TM
External Use 14
SNVS – Physical Tamper Detection
14
47 bit counter
Power Supply
Glitch
Detectors
32 bit GP Register
32.768kHz
Syn
c
OCOTP
LP
HP
i.MX6x
48 bit Monotonic Counter 47 bit counter Zeroizable Master
Key
SNVS System
Security Monitor
Master Key
Control
OTP Master
Key
CA
AM
Maste
r K
ey
External
Tamper Inputs
Tamper
Detectors
Security Violation
CAAM
Monotonic Counter
Rollover
Protection Mechanism
Security Violations
SJC WDOG
Security State
TM
External Use 15
MPC5777M - The Flagship Automotive
MCU Device
TM
External Use 16
MPC5777M – High Performance Automotive MCU
TM
External Use 17
Security Application Examples
TM
External Use 18
Chain of Trust (Secure Boot) Example
• Security code provides root of trust
• Root of trust may progressively
authenticate the application code and
enable execution to reduce startup time
• Hardware acceleration may allow faster,
one step authentication
• Real time authentication may provide
added security
− Run as background task
Application Code Security Code
Sys
Boot ROM
Check
App Boot
App Boot Check App
Step 1
App Step 1 Check App
Step 2
Enable
Reset Check Sys
Boot ROM
Enable
Enable
TM
External Use 19
Sensor Authentication Example
• Trusted application sends random code to sensor (the challenge)
− Random number used to prevent replay attacks
• Sensor generates hash for code using its key, and returns result (the
response)
− Key may be secret (symmetric) or public (asymmetric)
• Trusted application uses its key to authenticate the sensor result
Trusted
Application
Code
Secure
Sensor
Serial
Interface
1. Application
sends
challenge
2. Sensor
sends
response 3. Application
authenticates
response
KeyA
RNG
KeyB
TM
External Use 20
Trust Architecture – The Problem, part I
• Potentially many independent software providers
• Potentially many different “sensitive” resources
Code Segments
Tier 1 code
OEM code
MCAL
OS
AutoSAR
Other 3rd parties
Security Code
Access Regions
FlexCAN
SRAM0
Secure SRAM
SRAM2
Secure Flash
GTM
eTPU
AES-128 Engine
TM
External Use 21
Trust Architecture – The Problem, part II
• Without a trust architecture, all code can access all memory regions
− This might not be a good thing
Code Segments
Tier 1 code
OEM code
MCAL
OS
AutoSAR
Other 3rd parties
Security Code
Access Regions
FlexCAN
SRAM0
Secure SRAM
SRAM2
Secure Flash
GTM
eTPU
AES-128 Engine
TM
External Use 22
Trust Architecture - Enablers
• A Hardware Firewall
• Authenticated method of installing object code
• Hardware Map between Code and Access Regions
Code Segments
Tier 1 code
OEM code
MCAL
OS
AutoSAR
Other 3rd parties
Security Code
Firewall
Access Regions
FlexCAN
SRAM0
Secure SRAM
SRAM2
Secure Flash
GTM
eTPU
AES-128 Engine
Authenticated
software
installation
TM
External Use 23
Trust Architecture - Features
• Provides program isolation
• Provides peripheral modules isolation
• Allows security code to have exclusive access to secured resources
• Also supports non-core masters (e.g. DMA, Ethernet, FlexRay)
Code Segments
Tier 1 code
OEM code
MCAL
OS
AutoSAR
Other 3rd parties
Security Code
Firewall
Access Regions
FlexCAN
SRAM0
Secure SRAM
SRAM2
Secure Flash
GTM
eTPU
AES-128 Engine
Authenticated
software
installation
TM
External Use 24
Security Enhancements
TM
External Use 25
Security Enhancements
• Attacks on vehicle systems will becoming more pervasive as the
vehicle becomes more connected to the Intelligent Transportation
System of the future
• More advanced crypto algorithms must be implemented, such as
SHA-512, ECC256/384 to protect OEM and customer assets
• Enhanced security measures must be enabled to counter side
channel attacks such as SPA and DPA
• Of course the cost of an attack must be weighed against the cost of
prevention
TM
External Use 26
A Proven Leader in Automotive Security
• Growth will come from new applications
− Advanced Driver Assistance Systems
− Hybrid/Electric Vehicles
− Connectivity and Entertainment
• Affordable solutions for emerging markets
• We will continue to deliver
− Advanced robust process technologies
− Consistent optimized architectures that are safe and secure
− Software, tools and reference designs
− Zero defect quality
Market
Expertise
and
Consistency
TM
External Use 27
For Further Information
• Freescale link
− http://www.freescale.com/security
• SME Contact information
− Richard Soja, System Engineer
• Additional Information
− http://portal.automotive-
his.de/index.php?option=com_content
&task=view&id=31&Itemid=41
− http://www.evita-project.org/
− http://www.preserve-project.eu/
TM
External Use 28
TM
© 2014 Freescale Semiconductor, Inc. | External Use
www.Freescale.com