The Connected Car
Introduction
The “Internet of Things” promises a
future fuelled by the art of the possible.
Connected Cars which can talk to each
other and access the Internet will provide
on-board features that we can’t imagine
yet. Predictive systems which bypass
traffic jams, reduce carbon emissions and
improve safety could become the norm.
BT Whitepaper: The Connected Car
However, there is an alternate version of
reality. A version of reality that threatens
the privacy, security and safety of
everyone who shares the road with this
“Smart Car”. In this reality, remotely
connected vehicles are compromised with
malware, subject to hijacking, untrusted
and unsafe. Therefore, it is vital that the
automotive industry, the regulators and
thought leaders not only consider the
potential of the Connected Car, but also
recognise the vulnerabilities and the
potential for abuse.
2
Attack Surface and
Threat Landscape
While the attack vectors of the Connected Car can
mirror those of other networked computer systems,
there are some unique challenges.
Here are a few of the key differences:
Connected Cars
Typical Networked Computer
Computing resources are fixed
for lifetime of vehicles – can’t
rely on car to protect itself
PCs and servers are replaced
every 3 years or less, and can
easily be upgraded
Updating vehicles software,
can’t rely on persistent
connectivity, some files 1.3Gb
can’t chop them up
Virus guard updates run in
background daily, with no
disruption to end users
Vehicle data could be
compromised and provide
untrustworthy information
Computers are easier to
physically secure
Multiple CPUs all accessible via
OBD2 port, CPUs can share
same keys, some don’t even
support PKI
Single CPU, with no physical
external access
VPNs are not designed to
protect millions of entities
outside a firewall
VPN protects small numbers of
employees accessing systems
outside normal firewall
Sub-systems in cars need to
be able to freely talk to each
other, even for Infotainment
Provide physical network
separation
High overheads to keep onboard signature database up
to date, not all malware relevant
Existing tools mature, and
have little impact on computer
processing
In fact, the Connected Car threat landscape closely
resembles the profile of critical infrastructure systems
like SCADA (Supervisory Control and Data Acquisition)
networks or those used in manufacturing, the smart
grid and energy production & distribution. These all
have the following in common: embedded systems
from multiple vendors developed in isolation, are
assumed to be deployed in “non-hostile” (secure)
environments; can’t be patched.
Whenever mechanical and digital systems are
integrated or automated, new and novel threats must
be considered, especially when human life is at stake.
BT Whitepaper: The Connected Car
Fact or Fantasy
As defenders build their threat catalogues, they need
to consider three things; the asset being protected,
the known attack surface and adversary’s capabilities.
Rarely can all of these be known to any degree of
certainty at any given time. This forces defenders to
be pragmatic in their operations but forward thinking
in their architectural approach.
The defender is well advised to consider theoretical
vulnerabilities as part of its risk management practice,
as a properly motivated and resourced adversary will
develop a capability to exploit vulnerabilities. This
allows for a more effective application of the
predicative threat assessment methodology expressed
in the diagram below.
Defenders must temper the hype associated with
theoretical attack scenarios with the more likely general
system failure risks associated with infected software.
How can defenders determine the right mix given the
unique challenges facing the connected car without
creating vehicles nobody wants to buy or trust? One
approach would be to consider the most relevant
theoretical vulnerabilities and current published
research available to create a list of attack types.
These can provided the necessary context for the
various stakeholders to have an intelligent
conversation about the specific threat agent. What
follows is not an exhaustive list but can provide a
starting point for such conversations.
3
TPMS Attacks:
Navigation & Infotainment systems
TPMS stands for Tyre Pressure Monitoring Sensor.
They are plugs that are installed inside of tyres. They
communicate on a simple wireless communication
protocol that sends a unique ID along with the tyre
pressure, rotation and temperature. It is possible to
cause unwarranted errors and send signals about the
tyre pressure being low (or not being low) regardless
of the tyre's actual state. Not only can the unique ID
be used to monitor the location of the vehicle it could
be used to trigger targeted kinetic attacks such as
improvised explosive devices that only detonate when
the targeted vehicle is within the kill zone.
The motivation for much of the early research into
modifying navigation systems was to repurpose the
navigation screen to play movies and video games.
One proof of concept changed the splash screen, the
DVD warning message and modified the binaries to
allow for "backup" copies of the mapping software.
Navigation systems are the same as any desktop
system except they are often directly connected to the
CAN bus network. This makes them especially
susceptible to attacks. Security of such systems is
rarely kept up to date.
Car-Jacking
It is possible to hijack vehicles over the CAN Bus
system. The CAN (Controller Area Network) bus is a
vehicle bus standard that uses a simple protocol
allowing devices to communicate with each other
without a host computer. CAN lines run throughout
the entire vehicle and typically connect to around 150
sensors per vehicle. If an attacker can tap into any of
these lines they can communicate directly with the
car's other connected systems. In its crudest form,
simply popping out a tail light to get to a CAN line,
unlocking the door then running the signals to start a
car, completely bypasses the immobiliser system. It’s
not a stretch to believe that an adversary would desire
the ability to launch this type of attack remotely.
Many vendors provide such capabilities as premium
services, which make their management systems a
very attractive target. Why take over a single vehicle
when you can commandeer all of them?
ICSim
The Instrument Cluster Simulator was written as a
teaching mechanism to understand and reverse
engineer CAN bus packets. On the CAN Bus every
sensor can see every packet with no indication of the
source. This tool teaches students how to RE CAN
packets by giving them random Arbitration IDs and
bytes for which the CAN bus system operates as well
as a game controller interface to control the car. The
student can then use the controller to operate the
simulated vehicle while sniffing the CAN bus packets
to practice finding and sniffing packets.
https://github.com/zombieCraig/ICSim
BT Whitepaper: The Connected Car
4
“
Related Research
Reasonable Response
While not exclusively the domain of the Connected
Car, smart phone hacking has implications for the
security and safety of smart cars. A compromised
phone connecting via Bluetooth, USB, Wi-Fi or some
other method can become the delivery vehicle for
common or custom malware. This can provide the
attacker remote access to sensitive systems without
the risk of physically attacking the car. By using a
compromised phone audio, video and location
surveillance can also be affected. GPS spoofing is
another area of research to consider. By sending
specially crafted GPS signals an attacker could reroute
drivers via the “trusted” navigation systems.
Adversary’s Asymmetric Advantage
Modern automobiles are
pervasively computerized, and
hence potentially vulnerable to
attack…remote exploitation is
feasible via a broad range of attack
vectors (including mechanics tools,
CD players, Bluetooth and cellular
radio), and further, that wireless
communications channels allow
long distance vehicle control,
location tracking, in-cabin audio
exfiltration and theft....”
http://www.autosec.org/pubs/cars-usenixsec2011.pdf
BT Whitepaper: The Connected Car
The asymmetric nature of the current attack & defend
paradigm only adds to the defenders burden. They
must be successful all of the time, while attackers only
need to succeed once to gain a beachhead or pivot
point. By monitoring the current state of public
research one can track the shrinking gap between
theoretical vulnerabilitties and a practical prototype.
In many cases the hacking and open garage
community is outpacing (arms race) the multi-billion
dollar automotive industry.
Since there is no such thing as 100% security, risk
reward optimisation should be sought. This must
considered as part of the total cost of production and
is closely related to safety and quality control through
the vehicle life-cycle.
In parallel, a flexible capability to quickly detect [mean
time to detection] and remediate [mean time to
containment] from the inevitable exploitation of the
Connected Car must be developed.
Safety & Security by Design
We know that bad things can and will happen. We
need to ensure that we prepare for the most impactful
“bad things” and continually improve our capabilities
to properly respond to the evolving threat posed by
motivated adversaries.
Merging the discipline of car safety and cyber security
is not a trivial exercise. Its complexity represents a
significant threat in its own right. However, it is
needed as they are no longer mutually exclusive
domains! The engineering department needs to be
directly connected to the security department. In
many automotive firms engineering and electronics
have their own people who look at "security" but the
definitions tend to vary and lean more towards
physical safety than cyber security. The internal IT
department needs to ramp up its hardware
capabilities and provide guidance to the engineers
designing the components.
5
CAN Bus
The CAN (Controller Area Network) bus protocol uses
arbitration ID’s. An arbitration ID is a number that
more or less represent a category. Each packet has up
to 8 bytes. The goal of a CAN packet is to quickly send
information to or from the appropriate sensor. The
safety of CAN is focused on differential signalling, the
idea of having a high and low signal to help eliminate
noise on the line. When these protocols were
developed the network was assumed to be closed and
trusted, outside attacks were not considered a realistic
threat to the protocol. Today there are many attack
vectors: CAN bus, Navigations systems have wi-fi, XM,
GPS, Bluetooth as well as other methods of wireless
communications, all attached to the CAN bus.
There are some fundamental architectural tenants and
engineering practices we can adopt which can be very
successful against the most significant class of attacks
(control affinity). These simple approaches and
practices can save lives in the connected car world and
should be carefully considered:
The Automobile “Blackbox”
This is a read-only logging mechanism that is
physically secure, resilient and tamper proof. Ideally
the secure data would also be easily accessible by
authorised parties, including the owner of the vehicle.
This mechanism is great for forensics but vehicle
owners need to know what is being recorded because
of the potential for privacy abuse. The data collected
would also be useful for the community. New tools
and capabilities could be developed by the
community further extending the value of the data
beyond basic vehicle forensics.
A standardised logging format should be developed
(see standards). Using the OBD (On-board
Diagnostics) is not recommended for Blackbox
functionality, because of its exposure to abuse by
various actors, including law enforcement. There is a
high risk of having this system of recording
inaccessible to the owners of the vehicle and only
accessible to the car manufactures and/or law
enforcement. This is not the ideal situation. It is
BT Whitepaper: The Connected Car
important to start treating vehicles the same way we
treat other computing devices. The evidence needs to
be recorded so that an attack can be verified however
the owner of the vehicle needs a physical method to
control how this information is used if we expect the
public to trust these systems. If the owner wishes to
share this information they can however in the end as
it is *their* vehicle. If law enforcement requires access
to the data they can go through the appropriate legal
channels. This balances the needs of society and
protects the privacy of the owner.
Layer 1
We have to acknowledge that physical security (layer
1) is now and will always represent a primary attack
vector which will be exploitable. This should not come
as a surprise to the reader as car theft is an everyday
occurrence. Therefore tactics and controls that have a
high degree of affinity and effectiveness when
executed properly should be considered in any
Connected Car play book. From a cyber-standpoint,
physically protecting the CAN lines from easy outside
exposure should be a priority. We must make it
difficult to simply pop out a tail light to splice into the
CAN bus to achieve an easy hack. Keep CAN lines away
from easy access from outside the vehicle. Full stop!
Standards
The industry should consider opening up vehicle specific
protocol information for owners and researchers. This
will crowd source findings and provide new solutions.
Immobiliser systems need to be open and auditable.
They should use the same standards developed for web
based authentication mechanisms. Proprietary
encryption did not work for network authentication and
it will not work for automotive industry. Longer term,
CAN needs to be updated to support a more standard
secure protocol. This protocol should have sender info,
support encryption and have separate lines to use for
larger packets. Small quick packets will always be
necessary but a new CAN bus protocol and/or additional
CAN buses could provide physical and virtual
segregation of data.
6
M2M
Secure Machine to Machine (M2M) communications
present some unique challenges. In most sensor
networks, speed of communications and limited
processing power require very efficient communications
protocols. Security is often an afterthought. Machines
can’t enter passwords but they can use signed
certificates. The proper implementation of certificates
requires Public Key Infrastructure (PKI) for the life-cycle
management of certificates. On the web we have
learned that using standards in encryption and
authentication methods is ultimately more secure than
the outdated notion of security through obscurity.
Besides authentication, certificates can also be used to
support encrypted communications between devices.
Another technique known as “white listing”, can be
used to limit which devices are authorised to
communicate with each other. This technique doesn’t
work well in Internet security applications but can be
very effective in closed systems like the Connected Car.
Embrace the Community
Often new tools can be written by the community
faster and with an “outside of the box” perspective.
One only needs to look at the success and impact of
the Open Source software movement to understand
the potential. The simple act of maintaining a
Responsible Disclosure web page for security
researchers to submit findings creates value. It shows
a forward thinking attitude to modern security
research and provides a communication path to the
community. Public researchers should be considered
an asset to be cultivated and embraced. They are not
the enemy. The enemy wouldn't tell you about your
issues but instead would use them against you.
Comprehensive Correlation Engine
The Connected Car sensors provide limited security
relevance by themselves, as CAN packets do not have
state. However, when combined with other contextual
data, correlation techniques and modelling predicative
capabilities can be developed. Therefore, some form of
automated threat modelling should be developed. By
modelling complex interactions in ways we haven’t
previously can identify conditions that would cause
systematic failure affecting security and safety.
BT Whitepaper: The Connected Car
Open Garages Movement
As the community of researchers, small independent
garages and general public interest in Connected Cars
grows so does the art of the possible. The following
community contributions warrant further study to
better understand their impact on safer connected cars;
• SocketCAN - Linux based CAN drivers/sniffers
• CAN in the Middle - HW CAN injection tool
• CANiBUS - Multiuser web based CAN monitoring tools
• rusEFI - Open source ECU system/replacement
• CHT - CAN Hacking Tool
• GoodThopter - CAN Bus Sniffing HW
• Arduiono CAN Shields - CAN Bus sniffing HW
• Kayak – CAN Bus diagnosis and monitoring
Call to Action
The automotive industry must understand the
evolving threat landscape. Bringing new features,
services and amenities to market also introduces new
risks to security, privacy and safety. This is the nature
of progress and intra-domain convergence.
The automotive industry should embrace the
community and even the odds of the adversary’s unfair
advantage. They must understand that cyber security
has a direct impact on vehicle safety. Software and
embedded security systems need to be tested the same
way we test other safety standards. On top of normal
crash tests we need to see if a malicious adversary can
also intentionally cause a remote crash.
The automotive industry needs to share the details of
the CAN packets as well as the wiring diagrams.
Embracing the maker movement will not only increase
sales but also increase safety.
7
About the Authors
Craig Smith
Craig Smith is the CEO of Theia Labs, core founder of
Hive13 Hackerspace and founder of OpenGarages. He
has specialised in security and reverse engineering for
over 20 years. He has spent the last 4 years working
with the automotive manufacturers and research
companies on security vehicle infrastructure. He has
taught car hacking classes at the US Cyber Camps and
is the author of the 2014 Car Hacker's Manual.
Bryan K. Fite
A committed security practitioner and entrepreneur,
Bryan is currently the Global Innovations Product
Manager for Assure Intelligence at British Telecom
(BT). Having spent over 25 years in mission-critical
environments, Bryan is uniquely qualified to advise
organisations on what works and what doesn’t.
Bryan has worked with organisations in every major
vertical throughout the world and has established
himself as a trusted advisor. “The challenges facing
organisations today require a business reasonable
approach to managing risk, trust and limited resources
while protecting what matters.”
Offices worldwide
The services described in this publication are subject to availability
and may be modified from time to time. Services and equipment
are provided subject to British Telecommunications plc’s
respective standard conditions of contract. Nothing in this
publication forms any part of any contract.
British Telecommunications plc 2014.
Registered office: 81 Newgate Street, London EC1A 7AJ
Registered in England No: 1800000
27 June 2014