Will future vehicles be secure?

Will future vehicles be secure
Alan Tatourian (Intel)

Agenda
• What is a connected vehicle, and why is it hard to
secure?
• What is Functional Safety?
• Can we secure vehicles?
• Summary
2

The Interconnected Car
Components associated with physical
control of the vehicle
Components associated with safety
Components associated with
entertainment and convenience
Image credit: Mercedes-Benz
Museum (as cited in Computer History
Museum, 2011)
3
Huge Complexity
• Up to 100 million lines of code and going
to 300, of it 30 million for the
multimedia system (Android OS has about 15
million lines of code, Modern Fighter Jet has about 25,
Windows has close to 40, LHC has 50)
• Up to 100 ECUs, 25 - 200
microprocessors
Recent high-end luxury car
• ECU connections: 10 for FlexRay, 73 for
CAN and 61 for LIN
• Base vehicles employ 1,376 wires with a
total length of 2,474 meters. A fully
optioned vehicle requires 2,385 wires,
with a total length of 4,293 meters (2.66
miles).
• 100 motors in the interior

Evolution of In-Vehicle Networks
4
Image credit: Renesas

Connected Infrastructure
5
V2V
Ad-Hock Network
Radio Data System (RDS)
GPS
Uni-directional Communication
Bi-directional Communication
Trusted Network (e.g. Repair Shop)
Internet Backbone
Automotive Company
Application Center
Access Point (AP)
Local ServiceAP
Mobile Devices
Untrusted Network
Local Service
Open AP
Road Side Unit (RSU)
ISP
BS
BS
ISP
ISP
3rd Party
Application Center
Electric Chargers

Software Defined Cockpit (SDC)
6 Image credit: Mentor Graphics

Advanced Driver Assistance System (ADAS)
7

Connected and Autonomous Car
8
Automotive Bus
Distributed Services
Source: RTI
Cloud
Services
Traffic Maps
Situation
Awareness Planning
Vehicle
Control
Logging
Cameras, LIDAR,
Radar … Data Fusion Localization Vehicle Platform Visualization Navigation
Sensing
Error
Management

Five Levels of Automation
(SAE J3016)
9

Autonomous Vehicle Technology Roadmap
10
Autonomy
Level
Safety
Connectivity
Autonomy

Agenda
secure?
• Summary
11

Toyota Unintended Acceleration
12
• Toyota Lexus ES 350 sedan Reached 100
mph+
• 911 Emergency Phone Call from passenger
during event.
• All 4 occupants killed in crash.
• Toyota data on infotainment software
shows an expected one “major bug” for
every 30 coding rule violations. [Kawana
2004]
Source: Prof. Phil Koopman. A Case Study of Toyota Unintended
Acceleration and Software Safety

What is Functional Safety?
13
• IEC 61508: The part of the overall safety related to the equipment under
control (EUC) that depends on the correct functioning of the safety-related
system in response to its inputs
• ISO 26262: Absence of unreasonable risk due to hazards caused by
malfunctioning behavior of E/E systems
• ISO 25119: A system ta performs in a way that does nto present an
unreasonable risk or injury to operators and bystanders
Are you Able to Provide the
EVIDENCE
that Risks have been Minimized?

ISO 26262 Adaptation of IEC 61508
14
IEC 61508
Functional Safety for E/E/PES Safety Related Systems
IEC 61513
Nuclear
IEC 61511
Process Industry
ISO 26262
Road Vehicles
IEC 62061
Machinery
ISO 13849-1
Machine Safety
ISO 25119
Tractors…
ISO 26262 is “State of the Art” For Automotive

How E/E Systems Fail?
15
Random Failures: “Usually a permanent or transient failure due to a system component loss of functionality –
hardware related
Systematic Failures: “Usually due to a design fault, wrong specification, not fit for purpose , error in software
program, ...
Technical Safety MeasuresProcess – Methods – Organization
ISO 26262 Functional Safety Principles
Avoidance of Faults Control of Failures
Avoid Systematic Faults Control of
Systematic Failures
Control of
Random Failures
In OperationBefore Delivery
Implement Correctly Detect and React

Agenda
secure?
• Summary
18

What is Security?
19
Security covers all the processes and mechanisms by which digital equipment, information and
services are protected from unintended or unauthorized access, change or destruction.
 Wikipedia
Existing Definition, also used by NIST
1999 National Academies study “Trust in Cyberspace”
Security research during the past few decades has been based on formal policy models that focus on
protecting information from unauthorized access by specifying which users should have access to data
or other system objects. It is time to challenge this paradigm of “absolute security” and move toward a
model built on three axioms of insecurity:
1. insecurity exists;
2. insecurity cannot be destroyed; and
3. insecurity can be moved around’.

Automotive Security Standards
22
2. SAE J3061—Cybersecurity Guidebook for Cyber-Physical Vehicle
Systems
a) Enumerate all attack surfaces and conduct threat analysis
b) Reduce attack surface
c) Harden hardware and software
d) Security testing (penetration, fuzzing, and more)
1. SAE J3101—Hardware-Protected Security for Ground Vehicle
Applications
a) Secure boot
b) Secure storage
c) Secure execution environment
d) Other hardware capabilities…
e) OTA, authentication, detection, recovery mechanisms …

Example: Security analysis
23
Threat
Security Goal
Asset
Owner Attacker Malicious Action
Attack Potential
Point of Attack
Potential for attack on
Potential with risk of
Has a value for Has
Potential for
execution
Risk is reduced
by
Is performed at
Credit: Vector

Example: Incoming Message Integrity
24
Message Received
Integrity Check
Sender
Authentication
Authorization
Message Consumed by an App
CRC MAC/Signature
Source Address
Plausibility Checks
Source Access
ACL
Safety Security

Example: Lane Departure Analysis
25
Function: Corrective steering
intervention
Asset: Protect assistance
function from manipulation
Hazard analysis Threat analysis
Requirements for safety Requirements for security
New functions with added value and with manageable risk
System:
Lane departure warning
assistant

Common Security Requirements
26
1. Auditing and logging
2. Authentication and authorization
3. Session management
4. Input validation and output encoding
5. Exception management
6. Cryptography and integrity
7. Data at rest
8. Data in motion
9. Configuration management
10. Incidence response and patching
Together, these formulate the end-to-end security architecture for the product and thus should be considered alongside
one another—not in isolation. Also, each of the categories has many sub-topics within it. For example, under authentication
and authorization there are aspects of discretionary access controls and mandatory access controls to consider. Security
policies for the product are an outcome of the implementation decisions made during development across these nine
categories.

Defense in Depth
Fast cryptographic performance
Device identification
Isolated execution
(Message) Authentication
Virtualization
Hardware security services that can be used by applications
Platform boot integrity and Chain of Trust
Secure Storage (keys and data)
Secure Communication
Secure Debug
Tamper detection and protection from side channel attacks
Hardware security building blocks
Over-the Air Updates
IDPS / Anomaly Detection
Network enforcement
Certificate Management Services
Antimalware and remote monitoring
Biometrics
Software and Services
Security features in the silicon, for example Memory Scrambling,
Execution Prevention, etc.
Defense in Depth
HardwareRootofTrust
Analog security monitoring under the CPU
27
V2X antenna
Mobile Devices
ISP
BS
BS
Occupant safety
Surround sensors
Brake control system
Electric power steering
CAN bus
GPS

Hardware Security Building Blocks
28
1. Secure boot
2. Secure Storage
3. Trusted Execution Environment (HSM)
4. Cryptographic Acceleration
5. Key Generation
6. Secure Clock
7. Monotonic Counters
8. True RNG
9. Unique Device ID
10.Secure Debug
11.Physical Tamper Detection and Protection
Against Side-Channel Attacks
Defense in Depth
• Platform boot integrity and chain of trust
• Secure storage (keys and data)
• Secure communication
• Secure debug
• Tamper detection and protection from side
channel attacks
Hardware security building blocks

Why do you need HW Security?
29
Basic Cryptography Key Management Miscellaneous
Secure Hash (SHA2, SHA3) Key Derivation Function (KDF) Compression/Decompression
Message Authentication Code (CMAC,
HMAC, GMAC)
 Generation
 Verification
Secure Key and Certificate Storage
 Access Management
 Import/Export Services
 Generation
 Update
Checksum
Signatures
 Generation
 Verification
Key exchange protocols
Random Number Generation
Encryption/Decryption
 Symmetric (CBC, CTR)
 Asymmetric
 ECC (P-256, NIST, SEC2, Brainpool)
Secure Clock
 Time stamping
 Validity check for key data

Agenda
secure?
• Summary
30

31
1. Interactive computing.
2. Time sharing.
3. User authentication.
4. File sharing via
hierarchical file systems.
5. Prototypes of ‘computer
utilities’.
Emerging
concerns
1. Access controls
2. Passwords
3. Supervisor state
Security
Technologies
1960s
1. Packet networks
(ARPANET)
2. Local networks (LANs)
3. Communication secrecy
and authentication
4. Object-oriented design
5. Multilevel security
6. Mathematical models of
security
7. Provably secure systems
1. Public key cryptography
2. Cryptographic protocols
3. Cryptographic hashes
4. Security verification
1. Adoption of TCP/IP
protocols for the
Internet
2. Exponential growth of
Internet
3. Proliferation of PCs and
workstations
4. Client-server model for
network services
5. Viruses, worms, Trojans,
and other forms of
malware
6. Buffer overflow attacks
1. Malware detection
(antivirus)
2. Intrusion detection
3. Firewalls
1. World Wide Web
2. Browsers
3. Commercial
transactions
4. Data repositories and
breaches
5. Portable apps and
scripts
6. Internet fraud
7. Web-based attacks
8. Social engineering and
phishing attacks
9. Peer-to-peer (P2P)
Networks
1. Virtual private networks
(VPNs)
2. Public-key
infrastructure (PKI)
3. Secure web connections
(SSL/TLS)
4. Biometrics
5. 2-factor authentication
6. Confinement (virtual
machines, sandboxes)
1. Botnets
2. Denial-of-service attacks
3. Wireless networks
4. Cloud platforms
5. Massive data breaches
6. Ransomware
7. Malicious adware
8. Internet of things
9. Surveillance
10. Cyber warfare
1. Secure coding and
development processes
2. Threat intelligence and
sharing
3. Adware blocking
4. Denial-of-service
mitigation
5. WiFi security
1970s 1980s 1990s 2000s

32
1980 1985 1990 1995 2000 2005
Source: escrypt
Increasing digitalization and
digital integration
Security
Escalation:
Hypothetical vulnerabilities
identified
Security threats become
relevant in practice
Regular security breaches
with severe damages
ICS-CERT
(2008)
20152010 2020
???
CAESS
(2010)
GSM Interface
Exploit (2015)
Stuxnet and Duqu
(2010/11)
German Steel
Plant (2014)
AS/1 Card
Cracking (2009)
IMSI Catcher,
NSA iBanking
(2014)
Cabir, Premium
SMS Fraud (2008)
DOS via SMS
DoCaMo (2008)
I Love You
(2010)
Heart Bleed
(2014)
Sasser
(2004)
Melissa
(1999)
Michelangelo
(1992)
Leandro
(1993)
Brain
(1986)
F. Cohen
(1981)
Confliker
(2008)
NSA, PRISM
Reign
(2014)
SQL Slammer
(2003)
Code Red
(2001)
Morris Worm
(1988)
Tribe Flood DDOS
(1998)
CCC BTX Hack
(1984)
Creeper
(1971)

33
Emerging
concerns
Security
Technologies
Attacks against Cyber-Physical Systems (CPS):
1. Autonomous vehicles
2. Smart communities
3. Aviation and transportation
4. Robots
5. Drones
6. Infrastructure
1. Self-adaptive Systems which can evaluate and modify their own
behavior to improve efficiency, and which can self-heal.
2. Multi-agent Systems, a loosely coupled network of software
agents that interact to solve problems, are resilient and
partition tolerant.
3. Artificial Intelligence (Genetic Algorithms)
2010/2020s
In information technology, self-healing describes any device or system that has the ability to perceive that it is not operating correctly and,
without human intervention, make the necessary adjustments to restore itself to normal operation. IBM, for example, is working on an autonomic
computing initiative that the company defines as providing products that are self-configuring, self-optimizing, and self-protecting - as well as self-
healing. For all of these characteristics together, IBM uses the term "self-managing."

When safety and security are interlinked
34
The fundamental meaning of quality in relation to a system is that
the system provides the functions expected of it.
reliability
resilience
survivability
performance
safety
security
privacy
dependability
When safety and security are interlinked, this classic definition is extended to include the meaning that
the system does not provide any other functions that are not expected of it
– because of failure, human error, equipment malfunction or malicious attack.

Will future vehicles be secure?

Related slideshows

More Related Content

Will future vehicles be secure?

Editor's Notes