Drew Moseley
Solutions Architect
Mender.io
Securing the Connected Car
Session overview
â—Ź Opportunities and challenges with the software
defined car
â—Ź Anatomy of an attack: security risks of the
connected car
â—Ź The patching problem & solution designs
About me
â—Ź Drew Moseley
â—‹ 10 years in Embedded Linux/Yocto
development.
â—‹ More than that in general Embedded
Software.
â—‹ Project Lead and Solutions Architect.
â—‹ drew.moseley@mender.io
â—‹ https://twitter.com/drewmoseley
â—‹ https://www.linkedin.com/in/drewmoseley/
â—‹ https://twitter.com/mender_io
â—Ź Mender.io
â—‹ Over-the-air updater for Embedded Linux
â—‹ Open source (Apache License, v2)
â—‹ Dual A/B rootfs layout (client)
â—‹ Remote deployment management (server)
â—‹ Under active development
The software defined car
1990 2000 2010 2020
Hardware enabled Software enabled Software defined
Telematics Infotainment Connected
Assisted
driving
AutonomousElectronics
Opportunity: New Revenue Streams
New revenue streams:
● “Automakers could add up to $27.1B annually from services such as car
sharing and more” - Navigant Research
â—Ź Tesla
â—‹ OTA update system for easy upgrades after purchase.
â—‹ Autopilot (semi-autonomous) feature: $2,500 USD at order; $3,000
USD upgrade.
Free features:
â—Ź Increased automobile range during Hurricane Irma1
1
http://www.businessinsider.com/hurricane-irma-tesla-increased-range-florida-2017-9
Opportunity: Cost Savings
IVI stack
Hardware
Board support pkg.
Operating system
Middleware
Apps
HMI
Cost
10%
30%
60%
Differentiation
Focus on
commodity
code here.
â—Ź Lower layers are expensive and
provides no differentiation
â—Ź Use commodity software here
to:
â—‹ Shorten time-to-market
â—‹ Lower cost
â—‹ Reallocate development
to differentiating features
OTA updater
Challenge: More complexity/larger attack surface
â—Ź 1-25 bugs per 1000 lines of code*
â—‹ Assume that all software components have vulnerabilities
â—Ź Rely on well-maintained software and keep it updated
â—‹ Open source vs. proprietary is a red herring
â—‹ Do not build all the software in-house
â—Ź Principle of least privilege
â—Ź Separation of privilege
● Kerckhoff’s principle
*Source: Steve McConnell, Code Complete
Challenge: OTA updates are must-have
â—Ź Increased software complexity requires more frequent
improvements
● “33% of current recalls are for problems that could be fixed OTA” -
ABI Research
● “OTA updates will save carmakers $35B in 2022” - IHS Automotive
â—Ź Fiat Chrysler hack (next up) required a recall of 1.4 million vehicles
that could have been avoided with an OTA update
Jeep Cherokee hacked in July 2015
â—Ź Presented at Black Hat USA 2015
â—‹ Charlie Miller and Chris Valasek
â—Ź Remote exploit giving full control
of the car
â—Ź Clearly demonstrates physical
safety risk
â—Ź No way to fix remotely
â—Ź 1.4 million cars recalled
â—Ź August 2016: Extended to
unauthorized ECU update via CAN
Jeep Cherokee Head Unit with Wifi
Wifi hotspot offered
as a service
â—Ź Cherokee customers can buy wifi
subscription as an add-on (~$40/month)
● Connect devices in the car to the car’s
wifi to get online (phones, tablets, …)
â—Ź Wifi is password protected
“Head unit”, “IVI”
Wifi-based breach: Short-range
â—Ź Wifi password based on system time after
provisioning
â—Ź January 01 2013 00:00 GMT +- 1 minute
â—Ź Multimedia system breached due to
software vulnerability
â—Ź Scope: Control music player/radio/volume
and track GPS coordinates when within
wifi range
Guessable
password
Software
vulnerability
Cellular-based breach: Country-wide
â—Ź Scope: Control music player/radio/volume
and track GPS coordinates countrywide
â—Ź Can also select a specific Jeep based on its
GPS-coordinates
Breach Sprint
Cellular network
Software
vulnerability
The Controller Area Network (CAN) bus
â—Ź The CAN bus connects ~70 electronic
control units (ECUs), including engine
control, transmission, airbags, braking
â—Ź V850 chip is designed to only read from the
CAN bus, to isolate components
V850 chip
Read-only
Diagnostics
CAN bus
â—Ź The head unit can update the firmware
of the V850
â—Ź Firmware update authenticity not
checked properly
V850 chip
Full control
Malicious firmware
update
Putting it together
Lessons
â—Ź Wifi hotspot password was predictable
â—Ź Remotely accessible service (in head unit)
was vulnerable (and not updated)
â—Ź Firmware update (for V850) did not have
proper authenticity checks
â—Ź The only way to fix the vulnerabilities is
through a manual update (by customer or
dealership)
FW update
Cellular breach
Vulnerability
Security patching is done too late
60 days: >90% probability it is exploited
110 days: remediation time avg.
5-10 days: <10% probability it is exploited
Source: How the Rise in Non-Targeted Attacks Has Widened the Remediation Gap, Kenna Security
Why security patching happens too late
â—Ź The value is invisible until too late
â—Ź Too costly or risky
â—‹ Manual? Too expensive to integrate updater?
â—‹ Requires downtime of production? Risk of breaking production?
â—Ź Interdepartmental politics (ie fingerpointing)
â—Ź How often do you patch?
â—‹ Do you have a way to do it? A process?
â—‹ Often not a core competence and not a priority to develop updater
Patching connected devices is harder
â—Ź No/expensive physical access
â—‹ Need failure management
â—Ź Unreliable power
â—‹ What if power disappears in the middle of patching?
â—Ź Unreliable (wireless) network connectivity
â—‹ Handle partial downloads
â—‹ Ideally resume downloads in expensive networks like 3G
â—Ź Public and insecure (wireless) networks
â—‹ Can someone inject arbitrary code during the update process?
â—‹ Verify authenticity of update
Generic embedded updater workflow
Detect update
(secure channel)
Download
(secure channel)
Integrity
(e.g. checksum)
Authenticate
(e.g. signature)
DecryptExtract
Install
Failure recovery
(e.g. roll back)
Compatibility
check
Sanity checks
Post-install
actions
Pre-install
actions
Must-have
Environment-specific
Choose a
strategy
Choice of update type has tradeoffs
Full image Package (opkg, …) tar.gz Docker/Containers
Download size Large* Small Small Medium
Installation time Long* Short Short Short
Rollback Yes (dual partition) Hard Hard Yes
Consistency Yes Medium Hard Yes
Design impact Bootloader,
Partition layout
Package manager tar, ... Kernel, docker
* Can mitigate with compression or binary diffs
â—Ź Integrity checking
â—‹ This must be done
â—‹ Easy to implement
â—Ź Rollback support
â—‹ This should be a requirement: power loss, installation error, etc.
â—‹ Could be hard depending on update type (tarball, package)
â—Ź Phased rollout
○ I.e. don’t deploy update to all devices in one go
â—‹ Most do this to some extent: test & production environments
○ Can be more granular on device population (1%, 10%, 25%, 50%, …)
What can
go wrong?
Strategies to reduce the risk of bricking
Prepare for securing the software defined car
â—Ź Commodity software where no differentiation
â—Ź Well-maintained software
â—Ź Over-the-air updates
â—Ź Apply well-known security design principles
The best way to respond to hacking?
Fiat Chrysler said exploiting the flaw "required
unique and extensive technical knowledge,
prolonged physical access to a subject vehicle and
extended periods of time to write code" and added
manipulating its software "constitutes criminal
action".
Sources: BBC News, Wired
Straubel [Tesla CTO] credits KeenLabs’
researchers [...] says Tesla will pay
KeenLabs’ team a monetary reward for its
work [...] “They did good work,” Straubel says.
“They helped us find something that’s a
problem we needed to fix. And that’s what we
did.”
Thank You!
Q&A
@drewmoseley
drew.moseley@mender.io

Securing the Connected Car - SCaLE 2018

  • 1.
  • 2.
    Session overview â—Ź Opportunitiesand challenges with the software defined car â—Ź Anatomy of an attack: security risks of the connected car â—Ź The patching problem & solution designs
  • 3.
    About me â—Ź DrewMoseley â—‹ 10 years in Embedded Linux/Yocto development. â—‹ More than that in general Embedded Software. â—‹ Project Lead and Solutions Architect. â—‹ drew.moseley@mender.io â—‹ https://twitter.com/drewmoseley â—‹ https://www.linkedin.com/in/drewmoseley/ â—‹ https://twitter.com/mender_io â—Ź Mender.io â—‹ Over-the-air updater for Embedded Linux â—‹ Open source (Apache License, v2) â—‹ Dual A/B rootfs layout (client) â—‹ Remote deployment management (server) â—‹ Under active development
  • 4.
    The software definedcar 1990 2000 2010 2020 Hardware enabled Software enabled Software defined Telematics Infotainment Connected Assisted driving AutonomousElectronics
  • 5.
    Opportunity: New RevenueStreams New revenue streams: ● “Automakers could add up to $27.1B annually from services such as car sharing and more” - Navigant Research ● Tesla ○ OTA update system for easy upgrades after purchase. ○ Autopilot (semi-autonomous) feature: $2,500 USD at order; $3,000 USD upgrade. Free features: ● Increased automobile range during Hurricane Irma1 1 http://www.businessinsider.com/hurricane-irma-tesla-increased-range-florida-2017-9
  • 6.
    Opportunity: Cost Savings IVIstack Hardware Board support pkg. Operating system Middleware Apps HMI Cost 10% 30% 60% Differentiation Focus on commodity code here. â—Ź Lower layers are expensive and provides no differentiation â—Ź Use commodity software here to: â—‹ Shorten time-to-market â—‹ Lower cost â—‹ Reallocate development to differentiating features OTA updater
  • 7.
    Challenge: More complexity/largerattack surface ● 1-25 bugs per 1000 lines of code* ○ Assume that all software components have vulnerabilities ● Rely on well-maintained software and keep it updated ○ Open source vs. proprietary is a red herring ○ Do not build all the software in-house ● Principle of least privilege ● Separation of privilege ● Kerckhoff’s principle *Source: Steve McConnell, Code Complete
  • 8.
    Challenge: OTA updatesare must-have ● Increased software complexity requires more frequent improvements ● “33% of current recalls are for problems that could be fixed OTA” - ABI Research ● “OTA updates will save carmakers $35B in 2022” - IHS Automotive ● Fiat Chrysler hack (next up) required a recall of 1.4 million vehicles that could have been avoided with an OTA update
  • 9.
    Jeep Cherokee hackedin July 2015 â—Ź Presented at Black Hat USA 2015 â—‹ Charlie Miller and Chris Valasek â—Ź Remote exploit giving full control of the car â—Ź Clearly demonstrates physical safety risk â—Ź No way to fix remotely â—Ź 1.4 million cars recalled â—Ź August 2016: Extended to unauthorized ECU update via CAN
  • 10.
    Jeep Cherokee HeadUnit with Wifi Wifi hotspot offered as a service ● Cherokee customers can buy wifi subscription as an add-on (~$40/month) ● Connect devices in the car to the car’s wifi to get online (phones, tablets, …) ● Wifi is password protected “Head unit”, “IVI”
  • 11.
    Wifi-based breach: Short-range â—ŹWifi password based on system time after provisioning â—Ź January 01 2013 00:00 GMT +- 1 minute â—Ź Multimedia system breached due to software vulnerability â—Ź Scope: Control music player/radio/volume and track GPS coordinates when within wifi range Guessable password Software vulnerability
  • 12.
    Cellular-based breach: Country-wide â—ŹScope: Control music player/radio/volume and track GPS coordinates countrywide â—Ź Can also select a specific Jeep based on its GPS-coordinates Breach Sprint Cellular network Software vulnerability
  • 13.
    The Controller AreaNetwork (CAN) bus â—Ź The CAN bus connects ~70 electronic control units (ECUs), including engine control, transmission, airbags, braking â—Ź V850 chip is designed to only read from the CAN bus, to isolate components V850 chip Read-only Diagnostics
  • 14.
    CAN bus â—Ź Thehead unit can update the firmware of the V850 â—Ź Firmware update authenticity not checked properly V850 chip Full control Malicious firmware update
  • 15.
    Putting it together Lessons â—ŹWifi hotspot password was predictable â—Ź Remotely accessible service (in head unit) was vulnerable (and not updated) â—Ź Firmware update (for V850) did not have proper authenticity checks â—Ź The only way to fix the vulnerabilities is through a manual update (by customer or dealership) FW update Cellular breach Vulnerability
  • 16.
    Security patching isdone too late 60 days: >90% probability it is exploited 110 days: remediation time avg. 5-10 days: <10% probability it is exploited Source: How the Rise in Non-Targeted Attacks Has Widened the Remediation Gap, Kenna Security
  • 17.
    Why security patchinghappens too late â—Ź The value is invisible until too late â—Ź Too costly or risky â—‹ Manual? Too expensive to integrate updater? â—‹ Requires downtime of production? Risk of breaking production? â—Ź Interdepartmental politics (ie fingerpointing) â—Ź How often do you patch? â—‹ Do you have a way to do it? A process? â—‹ Often not a core competence and not a priority to develop updater
  • 18.
    Patching connected devicesis harder â—Ź No/expensive physical access â—‹ Need failure management â—Ź Unreliable power â—‹ What if power disappears in the middle of patching? â—Ź Unreliable (wireless) network connectivity â—‹ Handle partial downloads â—‹ Ideally resume downloads in expensive networks like 3G â—Ź Public and insecure (wireless) networks â—‹ Can someone inject arbitrary code during the update process? â—‹ Verify authenticity of update
  • 19.
    Generic embedded updaterworkflow Detect update (secure channel) Download (secure channel) Integrity (e.g. checksum) Authenticate (e.g. signature) DecryptExtract Install Failure recovery (e.g. roll back) Compatibility check Sanity checks Post-install actions Pre-install actions Must-have Environment-specific Choose a strategy
  • 20.
    Choice of updatetype has tradeoffs Full image Package (opkg, …) tar.gz Docker/Containers Download size Large* Small Small Medium Installation time Long* Short Short Short Rollback Yes (dual partition) Hard Hard Yes Consistency Yes Medium Hard Yes Design impact Bootloader, Partition layout Package manager tar, ... Kernel, docker * Can mitigate with compression or binary diffs
  • 21.
    ● Integrity checking ○This must be done ○ Easy to implement ● Rollback support ○ This should be a requirement: power loss, installation error, etc. ○ Could be hard depending on update type (tarball, package) ● Phased rollout ○ I.e. don’t deploy update to all devices in one go ○ Most do this to some extent: test & production environments ○ Can be more granular on device population (1%, 10%, 25%, 50%, …) What can go wrong? Strategies to reduce the risk of bricking
  • 22.
    Prepare for securingthe software defined car â—Ź Commodity software where no differentiation â—Ź Well-maintained software â—Ź Over-the-air updates â—Ź Apply well-known security design principles
  • 23.
    The best wayto respond to hacking? Fiat Chrysler said exploiting the flaw "required unique and extensive technical knowledge, prolonged physical access to a subject vehicle and extended periods of time to write code" and added manipulating its software "constitutes criminal action". Sources: BBC News, Wired Straubel [Tesla CTO] credits KeenLabs’ researchers [...] says Tesla will pay KeenLabs’ team a monetary reward for its work [...] “They did good work,” Straubel says. “They helped us find something that’s a problem we needed to fix. And that’s what we did.”
  • 24.