Connected & Driverless vehicles: the road to Safe & Secure mobility?

Connected & Driverless vehicles
The road to Safe and Secure mobility?

This presentation was given to the
British Computer Society IRMA SIG
in London on September 11th 2017
12/09/2017 CAVs: the road to Safe and Secure mobility? 2

Bill Harpley MSc
• 30+ years in technology sector
• Founder of Astius Technology
• Organiser of Brighton IoT meetup group
(700+ members)
• Initiator of Brighton node of the global
Things Network
• Organiser of the Self-driving Cars &
Autonomous Vehicles meetup group
https://uk.linkedin.com/in/billharpley
bill.harpley@astius.co.uk
www.astius.co.uk

Welcome to the world of Connected Cars
In this presentation we will talk about:
– The roadmap to a Driverless future
– The technologies and architecture
– Why automotive security is hard to achieve
– What can be done about the problem
– A glimpse into what the future may hold

The great Connected Car opportunity

Quick Audience Poll
Which of these propositions do you agree with?
A. “Driverless cars are a good idea”
B. “I can trust a driverless vehicle”
In June 2017 the Transport Research Laboratory conducted a survey 1 into public
attitudes towards driverless vehicles. Before I tell you the results, I would like to
get your opinion.
1. TRL report ‘Attitudes to Autonomous Vehicles’, https://trl.co.uk/reports/attitudes-autonomous-vehicles
Our own small audience
poll showed that:
• About 80% agreed
with proposition A
• About 70% agreed
with proposition B

TRL report summary of key findings
• 78% broadly agree
• 3% broadly disagree
• 19% undecided or slightly disagree
Source: TRL “Attitudes to Autonomous Vehicles” (p. 6)Source: TRL “Attitudes to Autonomous Vehicles” (p. 4)
B. “Driverless cars are a good idea”
• 81% broadly agree
• 1% broadly disagree
• 18% undecided or slightly disagree

Reasons to be cheerful
Cheerleaders for Connected Cars claim numerous benefits.
Here are a few of them.
ECONOMIC
BENEFITS
PWC ‘Connected
Car Report 2016’
claims that
Connected Vehicle
market set to be
worth £120bn by
2022. Would
create new jobs
and prosperity.
SAFER JOURNEYS
According to WHO,
there were 1.25
million global traffic
deaths. In 2015. The
goal of automated
driving is to reduce
this figure to zero.
Would reduce
economic cost of
accidents.
GREATER
PRODUCTIVITY
The average UK
worker spends 124
hours stuck in
traffic jams each
year. Automated
driving would
reduce stress and
enable them to be
more productive.
MOBILITY AS A
SERVICE (MaaS)
Ride-sharing and
driverless taxis
would reduce the
incentive for people
to own cars. Would
create social,
economic and
environmental
benefits.
12/09/2017 8CAVs: the road to Safe and Secure mobility?

But it’s a complex picture …
Source: https://www.vbprofiles.com/l/connectedcarstwitter
Note only
two security
apps!

The roadmap to a driverless future

The SAE J3016 classification standard
Levels 0 to 3 are commonly referred to as ADAS (Advanced Driver-Assistance System)

Quick summary of J3016 automation levels
Level Definition Summary description
0 Driver only Conventional vehicle – driver manages all
aspects of speed, direction, overtaking, etc.
1 Assisted driving Driver receives support for specialised tasks
(e.g. parking in a narrow space)
2 Partial automation Driver receives support for coping with
predefined scenarios (e.g. traffic congestion
warning and avoidance)
3 Conditional automation Driver can relinquish control of the vehicle for
specific tasks but must be ready resume control
at short notice (e.g. motorway autopilot)
4 Significant automation Majority of driving tasks may be automated but
driver must be ready to take control if needed
(e.g. urban driving in busy traffic)
5 Complete automation Complete 100% automation of the journey

Points to note
Twin strategies
The automotive industry is
divided into two camps
A. Take an evolutionary path to full
automation (requires driver
handover up to L4 capability) –
e.g. Volvo, Tesla
B. Safe and reliable handover is
difficult to achieve, so focus on
developing L5 capability – e.g.
Google Car (Waymo)
A period of transition
There is no roadmap for smooth
transition from ‘manual’ to
‘driverless’ motoring
• Expect vehicles with varying
levels of SAE J3016 capabilities
to share the road space for
many years to come
• Possible recipe for chaos,
crime, accidents and novel
security exploits?

It’s not just about cars
For convenience, we will only talk about cars today. But everything in
this slide deck applies equally well to driverless Taxis, Trucks and Buses.
Trials of Taxis, Trucks and Buses – with various levels of automation – are
being conducted in many countries around the world.

Building blocks of Connected & Driverless cars

Car hacking has been in the news
Let’s take a look at what makes them so vulnerable …

Brief overview of Smart Car components
Sensors monitor the
internal and external
environment.
Actuators apply force
or switch ON/OFF
Data is transferred
along Communication
Buses
Key subsystems which
need to be monitored
and controlled
Specialised
control units
Electronic
Control Unit
(100+ ECUs in
modern cars)
Telematics Control Unit
( TCU ) connects vehicle
to the outside world
Diagnostics
interface
( OBD-II )
Onboard Diagnostics Port gives vehicle
technician access to status of
subsystems via CAN protocol. Also used
by 3rd party aftermarket devices.
LIDARRADAR
ULTRASOUNDTEMPERATURE
CAMERAS
ACCELERATION
PRESSURE ELECTRICAL
HYDRAULIC
CAN LIN FlexRay MOST Ethernet
POWERTRAIN CHASSIS BODY INFOTAINMENT

High level architecture of a Smart Car
Source: ENISA, ‘Good practices on the Security and Resilience of smart cars’, Fig. 3 (p. 15)

ECUs (Electronic Control Units)
ECU is a generic term for an
embedded system which controls
one or more electrical subsystems
within a vehicle
• A modern vehicle may have
100 or more of these units
• Examples of functions which
an ECU may provide:
– Parking Assist
– Brake-by-wire collision
avoidance
– Automatic windscreen wipers
– Cruise control
– Airbag activation
Example: Siemens keyless-entry ECU

Controller Area Network (CAN) layout
Example of CAN bus layout
CAN bus
Dashboard
Engine
control
Transmission
control
Power
Door
ABS Brake
control
Airbag
control
Occupant
Detection
Electric Park
Brakes
Lane
Assist
If the CAN bus is
compromised then the
safety of the vehicle
and its occupants may
be at risk.

TCU (Telematics Control Unit)
Source: http://ficosamwc.com/telematics-control-unit/
TCU provides vehicle with a gateway to the outside
world. It’s designed to enable security, safety and
infotainment applications within the vehicle.
Example shown is the Ficosa TCU product:
• Linux OS based
• 3G and 4G connectivity enabled
• WiFi hotspot connection
• eCall enabled
• GNSS onboard (GPS, GLONASS, Galileo)
• Able to detect crashes and trigger airbag
deployment by CAN bus
• Support for up to 6 CANbus connections and
Ethernet

OBD-II standard
Onboard diagnostics is a service which allows
a technician to gain access to various vehicle
subsystems.
ECU A ECU B ECU C
OBD-II Port
Aftermarket OBD-II device
• Huge security concerns around ‘misuse’ of
ODB-II interface due to fact that it provides
access to the CAN bus
• Potential for safety-critical issues to arise (e.g.
driver distractions, steering malfunctions)

From ‘smart cars’ to ‘smart traffic’

Vehicle-to-Vehicle (V2V)
Radar for hazard detection
Status message
V2V messages must be securely
transmitted and processed.
 Reliable
 Encrypted
 Authenticated
 Ensure privacy (no tracking)
Vehicles transmit status messages
to each other to improve traffic
flows and increase safety.
 “Traffic jam ahead”
 “I have just put the brakes on”
 “Ice on the road ahead”
Secure these
wireless links Communication links
use the IEEE 802.11p
standard

Vehicle-to-Infrastructure (V2I)
“Spaces available in
Broad Street car
park”
“Road works ahead”
“Traffic lights not
working at junction
ahead”
ROADSIDE UNITS
Status messages can be
transmitted from kerbside
infrastructure to warn of
delays, hazards or provide
useful advice to travellers.
“Road ahead closed.
Turn left at junction”
Secure these
wireless links
IEEE 802.11p
wireless links

Vehicle-to-Person (V2P)
Pedestrians
and joggers
Horses (and
other animals)
Cyclists, scooter
riders and other
2-wheeled transport
Non-vehicular road
users can indicate their
presence by sending
status messages to
oncoming vehicles
Secure these
wireless links
IEEE 802.11p
wireless links

Vehicle-to-Everything (V2X | LTE-V)
Cellular
Operator
• LTE-V was developed by 3GPP
(organisation which develops
Cellular technology standards)
• Not likely to be available until
2018 at the earliest
• Aims to provide all the functions
of V2V, V2P and V2I
• UK has relatively poor 4G coverage!
• Would vehicle owners be able to
choose which MNO to subscribe to?
• Would government license
infrastructure as a concession?
• Would key roads be privatised to
facilitate use of V2X?
Leverages security of Cellular network

Some applications of V2X
Urban traffic
management
Improved traffic flows
at junctions and
collision avoidance
Vehicle platooning
Vehicles can be closely
packed into convoys to
improve road space
efficiency
Hazard detection and
warning
A vehicle which encounters
dangerous road surface
conditions can warn other
traffic in the area
All of these applications depend on the security of wireless links
and the integrity of onboard systems.

Key challenges for automotive security

Challenge No. 1: the supply chain
3rd Party value-added productsPRIME
MANUFACTURER
Tier 1 suppliersTier 2 suppliers Aftermarket
OBD-II
Diagnostics
Vehicle manufacturer
Huge challenge
to secure all
components in a
global supply
chain

Challenge No. 2: the huge attack surface
EXTERNAL INTERFACES
Wi-Fi, 3G, 4G,
802.11p (V2X)
Cloud data storage
and services
• Data theft
• Identity theft
• Insecure APIs
• Denial of Service
SMARTPHONE
Bluetooth, USB,
Wi-Fi, 3G, 4G, NFC
OBD-II PORT
Garage diagnostics,
Aftermarket dongles
Body Control
(ECUs, Sensors,
Actuators)
Door Lock,
Warning Lights,
Windows, Seat
Belts …
Powertrain Control
(ECUs,Sensors,Actuators)
Engine, Gearbox,
Transmission …
Chassis Control
(ECUs, Sensors, Actuators)
Steering, Braking, Airbag,
ADAS systems, Wipers …
INFOTAINMENT
(ECUs, Sensors)
Multimedia, Satnav,
Phone, Internal
networks (Bluetooth,
NFC, WiFi), USB
Communications
Control (TPU)
Telematics gateway
connectivity and
services (e.g. V2X,
eCall, GNSS)

Challenge No. 3: the complexity of code
Example: Ford F150
‘smart’ pickup truck
150 million
lines of
software code
Multiple
‘Electronic
Control Units
(ECUs)’
Numerous potential
points of attack
Complexity is the
enemy of security!

Challenge No. 4: a tale of two cultures
‘INFOMOTIVE’
INDUSTRY
INFORMATION
INDUSTRY
AUTOMOTIVE
INDUSTRY
AUTOMOTIVE CULTURE
• Key values of Safety and
Reliability
• Long product development
cycles
• Long product lifetimes
• Strong focus on ‘hardware’
INFORMATION CULTURE
• Values of UX and Security
• Rapid product
development cycles
• Short product lifetimes
• Strong focus on ‘Software’It will take many
years to create a
unified culture, with
Security at its heart

Challenge No. 5: Inadequate practices
Lack of
‘Security by
Design’ and
‘Privacy by
Design’
Weak or non-
existent
authentication
and authorisation
between
components
Weak password
policies and use
of defaults (e.g.
passwords,open
ports, telnet)
Lack of shared
technical
standards leads
some suppliers
to use “glue
code”
No clear standard
for product
liability makes
resolution of
security problems
difficult
Automotive
vendors are
slow to release
security patches
Actors within
the smart car
ecosystem have
different
approaches to
security
Design and
development
processes fail
to integrate
safety and
security
Here’s a sample of the poor practices which security researchers have
discovered within the automotive industry and its suppliers *
* To be fair, the industry is trying to fix these problems. See for example, Auto-ISAC ‘Cybersecurity Best Practices FAQ’

Challenge No. 6: Safety v. Security
Adding more security features sounds like a good idea. But it does present some
technical challenges to designers. Here are two examples.
EXAMPLE 1
• A safety engineer
wishes to set a
microcontroller to
debug mode in order
to examine the
contents of RAM
• The security engineer
wishes to disable
debug mode in order
to prevent the
contents of RAM being
discovered
EXAMPLE 2
• A security engineer
wishes to add firewalls
and authentication to
a safety-critical
component in order to
improve security
• The safety engineer
objects that this may
add unwanted latency
to response times and
jeopardise functional
safety
Functional
Safety Security &
Privacy
Conflicts of this type can
only be resolved through
dialogue and designing
better processes.

The current ‘state of the art’

Functional safety: ISO-26262
The automotive industry has very mature standards for ensuring the
functional safety of products. In the next few slides we will examine the
principal ones which you need to be aware of.
• ISO 26262 “Road vehicles – Functional safety” is an
international standard for functional safety of electronic
systems in vehicles.
• Describes a complex process by which a product can
be judge to be in compliance with this standard
• It aims to address possible hazards caused by the
malfunctioning behaviour of electronic and electrical
systems. However, it is not directly concerned with
matters of security.

MISRA-C
MISRA-C is a set of software development guidelines for the C/C++
programming language
• First released in 1998, it is developed and maintained by MISRA (Motor
Industry Software Reliability Association)
• It aims are to facilitate code safety, security, portability and reliability in
the context of embedded systems
• C/C++ widely used for developing embedded applications but known to
have potential deficiencies (e.g. buffer overflows) which can cause
security problems

AutoSAR: a common software platform
AUTOSAR (AUTomotive Open System ARchitecture)
• Defines a methodology and a software architecture for
automotive ECUs (Electronic Control Units)
• In Version 4.2 the specifications have been expanded to
consider evolving security landscape for connected vehicles
– Memory protection
– Cryptographic services
– End-to-End message protection
• Use of a common software platform may help to
improve security in the long run

Euro-NCAP
The European New Car Assessment Programme (NCAP) provides consumers with
Safety information about new vehicles. Published ratings do not yet include
cybersecurity as part of the criteria!

ISO 15408 : Common Criteria for security
ISO 15408 Common Criteria is an internationally
accepted standard for computer security certification
• It permits a product to be certified to a specific
Evaluation Assurance Level
• Levels are defined 0 to 7 , each with increasingly stringent
security requirements
• Evaluations are conducted by accredited laboratories
• Examples: many common operating systems have been
certified to EAL4 (e.g. RedHat 5 Server)

SAE J3061
J3016 “Cybersecurity Guidebook for Cyber-Physical
Vehicle Systems” - published June 2016
• Defines a complete lifecycle process framework from concept
phase through production, operation, service, and
decommissioning.
• Provides information on some common existing tools and
methods used when designing, verifying and validating cyber-
physical vehicle systems.
• Documents basic guiding principles on Cybersecurity for
vehicle systems.
• Enables the foundation for further standards development
activities in vehicle cybersecurity

IEEE 1609 Connected Vehicle Security
• IEEE 1609 Defines a set of
standards for Wireless
Vehicular Access (WAVE)
– Employs IEEE 802.11p ( an
amendment to the common
802.11 “Wi-Fi” standards)
– Supports V2X data
exchange between high-
speed vehicles and between
the vehicles and the
roadside infrastructure

Current regulations
Regulation will play an important role in the evolution of the ‘Infomotive’ sector
• Strengthens individual
privacy rights.
• Adopted in UK from May
2018
• Privacy issues are a hot
topic for Connected Cars!
Network and Information
Security directive
• Set of EU-wide rules and
regulations regarding
cybersecurity
• Puts special responsibilities
on owners and operators of
“critical infrastructure”

UK Government guidance
In August 2017 the UK Government issued ‘Principles of cyber security
for connected and automated vehicles’
1. Organisational security is owned, governed and promoted at board
level
2. Security risks are assessed and managed appropriately and
proportionately, including those specific to the supply chain
3. Organisations need product aftercare and incident response to
ensure systems are secure over their lifetime
4. All organisations, including sub-contractors, suppliers and potential
3rd parties, work together to enhance the security of the system
5. Systems are designed using a defence-in-depth approach
6. The security of all software is managed throughout its lifetime
7. The storage and transmission of data is secure and can be controlled
8. The system is designed to be resilient to attacks and respond
appropriately when its defences or sensors fail
There is nothing new in any of these principles!

The highway to the future

ISO 21434 : Road vehicles cybersecurity
• ISO/SAE 21434 Road Vehicles --
Cybersecurity engineering
• Eagerly awaited standard which is
currently in development ( ~ 2018 )

A unified development process
A crucial milestone will be the development and adoption of a standard industry
process which integrates each stage of Functional Safety and Security design.
It might well look something like this …
Hazard Analysis
& Risk
Assessment
Definition of
Safety
Requirements
System Design
System
Verification and
Validation
Threat Analysis
& Risk
Assessment
Definition of
Security Model
&
Requirements
Defence-in-
depth System
Design
Security
Verification and
Validation
SYNCHRONISATION SYNCHRONISATION SYNCHRONISATION SYNCHRONISATION
FUNCTIONAL
SAFETY
SECURITY
DESIGN

Collaborate and share
There is a growing spirit of
openness and collaboration
between automotive and non-
automotive actors
• Regular conferences
• Industry consortia
• Sharing of expertise
• ‘Bug bounty’ programmes
• ‘White Hat’ hackathons
CaRSEC Expert Group

A role for blockchain
Many organisations are currently exploring how
blockchain can be used to improve security within
the automotive sector. Examples:
• Track and verify automotive parts across the supply
chain (including spare parts and warranty repairs)
• Log vehicle performance data on a blockchain to
prevent fraud
• Enable pooling data from vehicle owners, fleet
managers, and manufacturers to shorten the time
achieving safety and security of autonomous

Conclusions

What have we learned today?
1. We are heading for a driverless future but public acceptance is key
2. There are a myriad of ways cars can be compromised due to their large attack surface
3. The automotive sector has developed an exemplary Safety culture
4. New actors in the automotive space demand creation of Security culture
5. Existing processes and technical standards are inadequate but many new initiatives
6. We are witnessing the birth of the ‘Infomotive’ industry but cybersecurity lags behind

Audience poll (revisited)
Which of these propositions do you agree with?
A. “Driverless cars are a good idea”
Our audience at this
meeting broadly
stuck to the views
which they expressed
in Slide 6. However,
there was a lively
debate afterwards!

Automotive cybersecurity meetup
Fancy starting an Automotive Cybersecurity
meetup group? London or Thames Valley.
Come and see me during the break
or ping me a mail at bill.harpley@astius.co.uk

Questions and Answers?
Hack me if
you can!

Advanced System Technologies
in Urban Spaces™

Connected & Driverless vehicles: the road to Safe & Secure mobility?

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Connected & Driverless vehicles: the road to Safe & Secure mobility?

Similar to Connected & Driverless vehicles: the road to Safe & Secure mobility? (20)

More from Bill Harpley

More from Bill Harpley (10)

Recently uploaded

Recently uploaded (20)

Connected & Driverless vehicles: the road to Safe & Secure mobility?