Kyusuk Han University of Michigan Contact: Kyusuk@umich · 2017. 5. 9. · • Acura: Keyless...

Challenges to make cars secure

Kyusuk Han University of Michigan

Contact: [email protected]

Day One is coming: Can cars still be safe?

With IT come cyber attacks

3

…

…

Attack routes

Cyber security threats for the vehicle?

Case Study: Attacking TPMS (1/3)

Rouf, I., Miller, R., Mustafa, H., Taylor, T., & Oh, S. (2010). Security and Privacy Vulnerabilities of In-Car Wireless Networks: A Tire Pressure Monitoring System Case Study. 19th USENIX Security Symposium, Washington, DC August 11-13, 2010


• Tire pressure monitoring system (TPMS) • While most in-vehicle sensor networks have wired connection, TPMS is

wireless • Wired connection from rotating tire to ECU is difficult

• Less Interest in deployed in-car sensor communication systems • Short communication range and metal vehicle body may render

eavesdropping and spoofing difficult • Tire pressure information appears to be relatively innocuous


• Attacked TPMS ECU • Reverse engineered TPMS Communication Protocol

• Proprietary, not open • Tested on the inter-state highway I-26 (Columbia, South Carolina) with two cars running

in parallel at 110 km/h. • Eavesdropped TPMS

• Using GNU radio together with the USRP (Universal Software Radio Peripheral) • Eavesdropping range up to 10m and 40m (with a basic low noise amplifier)

• Packet Spoofing TPMS • Could give false alarm of tire pressure

Case Study: Attacking PKES (1/5)

• Passive Keyless Entry System (with Engine Ignition) • A vehicle senses that the key (located in a pocket, purse, etc.) is approaching it • A vehicle can be unlocked without the driver needing to physically push a button on

the key fob to lock or unlock the car • Start or stop the ignition without physically inserting the key and turning the ignition

• Different vendors may use different names • Acura: Keyless Access System • Audi: Advanced Key • BMW: Comfort Access • Cadillac: Adaptive Remote Start & Keyless Access • Ford: Intelligent Access with push-button start or Ford MyKey • General Motors: Passive Entry Passive Start

Francillon, A., Danev, B., & Capkun, S. (2010). Relay attacks on passive keyless entry and start systems in modern cars. Proceedings of NDSS.


General Operation of PKES

Key position Authorization Medium used

Car -> Key Key -> Car

Normal mode: when the internal battery is present

Remote Active open/close None UHF

Outside Passive open/close LF UHF

Inside Passive start LF UHF

Backup mode: when the internal battery is exhausted

Remote Open/close Impossible

Outside Open/close With physical key

Inside Start LF LF

PKES Access Control Summary


KeeLoq: Encryption Algorithm for PKES • Non-Linear Feedback Shift Register based proprietary

block cipher • 32-bit block size and a 64-bit key

First cryptanalysis in 2007

Algorithm exposed in 2006 Side channel attack

in 2008

Relay attack in 2010


• How significant is relay attack? • If succeeds, the attacker

• Can open the door and start the engine • Does not require any information of secure data

• Based on evaluation of current cars, a certain model allowed up to 10ms of delay which, in turn, allowed relay attack within 1500km.

Attacking a car remotely still seems to be hard.. But What if….?

Reverse engineering Android APK

Pharming modified Android app

Remote controlling Android phone

Wrapping malicious code to Android app

Finding a car service subscriber’s Android phone

Who are adversaries?

Security expert Script Kiddes Thief or ..

For curiosities For bad purposes

Attackers* Target Systematic modification Theft

Attacker Individual, owner Mechanic, garage personnel

Organized crime, competitor, faker

Thief

Technical resources

Varied (Generally low)

High Very high Varied

Financial resources

Low Medium Very high Low

Physical access Full Limited

Risk Low Medium Very high Medium

*Wolf, M., Weimerskirch, A., & Wollinger, T. (2007). State of the Art: Embedding Security in Vehicles. EURASIP Journal on Embedded Systems, 2007, 1–16. doi:10.1155/2007/74706

Attacker’s capabilities (1/2) - Attack routes • With physical contact

• Attacker attaches own devices (via OBD-II, tapping to bus) • Without knowing any secrets (keys) in the existing components

• Attacker compromises existing components via physical access • physically alters any existing components, e.g., open car hood, disassemble tire,… • extracts secrets or modifies content of components

• Without physical contact • Owner updates software with compromised source

• Akin to downloads from nefarious web sites or emails • Attacker compromises components via remote/wireless access , e.g.,

Compromise Apple’s Carplay, Keyless entry system

Layered architecture of ECU ECU: Electronic Control Unit

Types of Attackers - Physical Access, compromised/attached device

17

Examples Mechanic replaces ECU. Chip tuning, OBD-II

Attack possibility

Low (NOT negligible), in practical environment

SW

HW

Types of Attackers - Remote Access, Compromised device

18

Examples Hack car infotainment system remotely

Attack possibility

High

SW

HW

Attacker’s capabilities (2/2) - Attacker’s knowledge

• With in-vehicle information • Proprietary and confidential CAN design including CAN ID, data length, etc.,

e.g., attacker knows and attacks CAN design of 2013 Ford Focus

• Without in-vehicle information • E.g., attacker picks a target randomly and attacks it

What can cyber attackers do? - Attack Abstraction

20

Read

Write

Interception

Injection/ Fabrication

Modification

Interruption

Attacker reads frames on the bus Replay attack available with interception

Attacker transmits unauthorized frame

Attacker modifies transmitting frames

Attacker disturbs frame transmission

Injection/Fabrication

1. With in-vehicle information • ex) OEM’s CAN ID and data format • Attacker injects frames to a specific target

2. W/o in-vehicle information • Attacker injects frames to a random target

• Weaker • In conjunction with interception, attacker can partly guess a specific target

Modification

• With in-vehicle information • Attacker intercepts a frame, then modifies it to compromise a specific target

• W/o in-vehicle information • Attacker override data on in-vehicle communication to random target

Interception

• Attacker reads in-vehicle communication • Reading only in the car is not harmful. • Collecting large intercepted data may cause privacy problem

• Modification to specific target: read ID and override fraudulent (target accepts) data

• Replay attack • Injection with intercepted data • Modification with intercepted data

• Interruption to specific target • Repeatedly read ID and override invalid (target may or may not discard) data

Interruption

• Attacker weakens/disables normal in-vehicle communications • DoS attack on target ECU

• Disable ECU by flooding (data overflow) • Disable ECU by starvation (data drop)

• Can design fail-safe mode (if data is not received…)

• DoS attack on CAN • Physically damage bus (Cut the wire) • frequently inject frames consuming more bandwidth • frequently override frames to make nobody receive

Countermeasures against attacks

• Intrusion detection and prevention • Detection

• monitors network or system activities for malicious activities or policy violations and produces reports to a management station

• Misuse detection (Signature-based) • Anomaly detection – learning • Specification-based

• Prevention • Firewall • Authentication, Authorization

In-vehicle communications

• Vehicle bus standard designed to allow microcontrollers and devices to communicate with each other within a vehicle without a host computer.

• CAN (Controller Area Network) is de facto standard for in-vehicle communication

Communication over CAN Multi-master model - CAN has no host computer managing communications - Arbitration

CAN format for DATA frames

Arbitration

Message filtering in CAN

Security support in CAN

Access control

Authentication

Non-repudiation

Data confidentiality

Communication security

Data integrity

Availability

Privacy

Only authorized personnel or devices are allowed access

Ensures the validity of the claimed identities of the entities

Preventing an individual or entity from denying performed action

Ensures the data content cannot be understood by unauthorized entities

Ensures information flows only between the authorized end points

Keeps the correctness or accuracy of data.

There is no denial of authorized access due to events impacting the network.

The protection of information that might be derived from the observation of network activities.

Security Dimension Description

- Security Dimensions - Security architecture for systems providing end-to-end communications, ITU-T Recommendation. X.805 (10/2003)

Data integrity Frame format of Controller Area Network

What do we need? – Secure CAN

32

CAN Bus

Data Security Function

Application

“Is the data authentic?”

Proof

CAN: Controller Area Network

Problem 2: How to fit ‘proof’ and ‘data’ in small data field (64 bit for CAN)

Problem 1: How to deploy security function in ECU?

No authenticator field

Too small payload Full SHA-1 output: 160 bits (20 bytes) AES block size: 128 bits (16 bytes)

Limited capability of ECUs: 8 ~ 32 bits processors

Problem 1 & 2

Example solution for Problem 1

• Secure Hardware Extension (SHE) • Specification by Hersteller Initiative

Software (HIS) • Audi, BMW, DAIMLER, PORSCHE, VW • meets ‘Light EVITA HSM’ of EVITA

• Concept: • Add a Secure Zone • Prevent user access to security

functions other than those given by logic

EVITA

• European research project during June 2008 –Dec 2011 • E-safety vehicle intrusion protected applications

• Objective: • Design, verify, and prototype an architecture for automotive on-board

networks where security-relevant components are protected against tampering and sensitive data are protected against compromise when transferred inside a vehicle.

• More found at http://evita-project.org/index.html

http://evita-project.org/index.html

EVITA Security Models – Categorization

Full EVITA HSM Medium EVITA HSM Light EVITA HSM

V2X communication On-board communication

Maximum level of functionality, security and performance

Maximum level of functionality and security

Optimized for low cost HW-solution

Asymmetric cryptographic engine & Hash engine

Symmetric cryptographic engine Symmetric cryptographic engine e.g., AES-128

User-programmable functionality Pre-defined functionality

Secure CPU @ 100 MHz Secure CPU @ 25 MHz Secure Zone no CPU needed

64k Optional NV Memory

512k Optional NV RAM

PRNG with TRNG seed Optional T/PRNG

Security LT > 20 years

Solution for Problem 2

• Borrow WSN solutions [Groza 2011]

• Reduce MAC size • Truncated MAC [Schweppe 2011, Szilagyi 2009] • Replace 16 bits CRC field [Nilsson 2008]

• Improve CAN [Herrewege 2011] • CAN+: higher performance with backward compatibility

Full size SHA-1

Payload

Truncated MAC

Questions:

• Q) How many bits should be assigned for Message Authentication Code?

• Will 8 bits be enough? Or 16, 32 bits?

• Q) Will sending multiple frames solve the limitation? • Four 16 bits MAC = 64 bits MAC ?

Required number of trials to break MAC

•8 bits – 2^8 | 256 possibilities • approximately 16 times trials needed to attack

success (50%) •16 bits – 2^16 |65,536 possibilities

• 2^8 times to attack success •32 bits – 2^32 | 4,294,967,296 possibilities

• practically secure. 65536 times.

Let’s think of worst scenarios

Band -width (kbps)

Frame Interval

(ms)

Max # trials Interval Max #

trials Interval Max # trials Interval Max #

trials

1000

1000

25,000

500

12,500

100

2,500

5

125

500 12,500 6,250 1,250 62

125 3,125 1,562 312 15

100 % utilized bus, 100 % attacker occupied, transmitting a 40-bit frame.

CAN Bus

What is still the problem?

42

Receive Data

Execute Data Verify it

Time is increased

Delay under 1 Millisecond (Class C Application Requirement Considerations, SAE J2056/1)

Overhead in Message Authentication

• General idea of MAC

43

MAC Output

MAC Output

“Data is valid!”

“Data is invalid!” One-way function

Data MAC

Message Authentication Code

Output

Key

Latency is negligible

Latency matters

Why can system fail?

44

2260 Hayward St. Ann Arbor, MI 48109

Properly addressed message will arrive What happens if thousands of messages are sent?

Receiver is swamped and

unable to react in real-time

How long does it take?: We tested! Verify 1 sec interval frame!

Cases 8bit, 16Mhz

Arduino UNO R3 32bit, 40MHz

Chipkit 32MAX

Trials 1 (ms)

25,000 (ms)

1 (ms)

25,000 (ms)

SHA-1 with 64-byte key 12.152 287506.8 0.23 5717.186

SHA-1 with 20-byte key 12.156 287506.772 0.228 5717.187

SHA-1 with 100-byte key 12.160 287506.768 0.228 5718.086

SHA-1 with 49- byte key,

truncated to 12-byte HMAC

12.156 287506.792 0.228 5717.370

• Test of the example cases of Keyed-Hash Message Authentication Code, FIPS PUB 198, Appendix A • SHA-1 code from http://code.google.com/p/cryptosuite/

Under attack?

Under attack?

How we can solve this problem?

46

2260 Hayward St. Ann Arbor, MI 48109

2901 Baxter Rd, Ann Arbor, MI 48109

Oops, not this address! Sorry!

Our idea: anonymize the receivers’ ID

Attacker cannot find the target to attack, therefore no impact

Sender side: AID & MAC generation

Message 2 MAC 2 AID 2

Message 1 MAC 1 AID 1 Un-transmitted secret chunk

MAC algorithm

Output Un-transmitted secret chunk

MAC algorithm

Nonce shared before the session

Transmitted!

Receiver side: AID & MAC verification

AID 2

Message 1 MAC 1 AID 1 Un-transmitted secret chunk

MAC algorithm

Output Un-transmitted secret chunk

Received Message Received MAC

Received AID

Identical? Identical?

Output

MAC algorithm

Nonce shared before the session

Finished!

Computation sequences in Sender/Receiver ECUs

Frame 1 transmitted

Frame 2 transmitted

Frame Interval

Generate AID 2

Frame 1 received

Frame 2 received

Generate Data 2

Generate MAC 2

Verify MAC 1

Run Data 1

Check AID 1

Generate AID 2

Sender side Receiver side

50

Kang G. Shin, Professor, globally renowned researcher

Kyusuk Han, Postdoc, experienced researcher, experienced developer

Andre Weimerskirch, Research faculty, entrepreneur (co-founder and former CEO of ESCRYPT), well connected to automotive industry

S2Car (Secure and Safe Car) Team - IA-CAN: Identifier Anonymization for secure in-vehicle communication

Demo!

51

Sender ECU

Receiver ECU Attacker!

“Red”, “Blue”, “Green”, “Yellow” ..

Attacker’s message

NXP LPC1768 MCU • High performance ARM® Cortex™-M3

Core • 96MHz, 32KB RAM, 512KB FLASH • Ethernet, USB Host/Device, 2xSPI, 2xI2C,

3xUART, CAN, 6xPWM, 6xADC, GPIO

We compared three scenarios!

Unsecured communication

Secured with MAC (Previous methods)

IA-CAN

Normal case

44-45 us

70-72 us

44-46 us

70-73 us (With MAC)

Under attack (Inject 20-40 frames @115kbps)

N / A

1100 us

44-46 us

70-73 us

System is ALWAYS compromised

Unreliable under flooding

If we only consider remote attack

Consider physical attack

Result: Unsecured ECU

53

...

gre #13:Time: 45 us

blu #14:Time: 44 us blu #15:Time: 44 us blu #16:Time: 44 us gre #17:Time: 44 us red #18:Time: 43 us blu #19:Time: 44 us blu #20:Time: 45 us gre #21:Time: 44 us gre #22:Time: 44 us .....

.... blu #46:Time: 44 us blu #47:Time: 44 us

gre #48:Time: 44 us

gre #49:Time: 44 us yel #50:Time: 44 us yel #51:Time: 44 us gre #52:Time: 44 us yel #53:Time: 45 us blu #54:Time: 44 us red #55:Time: 44 us red #56:Time: 44 us .....

Normal Under attack

Compromised !

Result: Secured with MAC

54

... yel #12: Time: 71 us, MAC 24 us gre #13: Time: 70 us, MAC 24 us blu #14: Time: 70 us, MAC 24 us blu #15: Time: 70 us, MAC 25 us

blu #16: Time: 72 us, MAC 24 us

gre #17: Time: 72 us, MAC 24 us red #18: Time: 71 us, MAC 24 us blu #19: Time: 72 us, MAC 24 us blu #20: Time: 71 us, MAC 24 us gre #21: Time: 72 us, MAC 24 us ...

Normal Under attack

… red #87: Invalid!: TOT 516 us MAC 173 us red #88: Invalid!: TOT 588 us MAC 196 us red #89: Invalid!: TOT 664 us MAC 223 us red #90: Invalid!: TOT 736 us MAC 247 us red #91: Invalid!: TOT 808 us MAC 271 us red #92: Invalid!: TOT 884 us MAC 298 us red #93: Invalid!: TOT 957 us MAC 322 us red #94: Invalid!: TOT 1029 us MAC 346 us

red #95: Time: 1100 us, MAC 370 us

Delay fails the system!

Result: Secured with IA-CAN

55

yel #8: Time: AID 1 us, MAC 25 us, TOT

73 us

yel #9: Time: AID 1 us, MAC 24 us, TOT 72 us red #10: Time: AID 1 us, MAC 24 us, TOT 72 us red #11: Time: AID 1 us, MAC 24 us, TOT 73 us yel #12: Time: AID 1 us, MAC 24 us, TOT 73 us ...

Normal Under attack

*** #116: Time: AID 1 us, Not match! TOT 2 us *** #116: Time: AID 0 us, Not match! TOT 2 us *** #116: Time: AID 1 us, Not match! TOT 3 us *** #116: Time: AID 1 us, Not match! TOT

3 us

yel #117: Time: AID 1 us, MAC 25 us, TOT 73 us

Questions

• Q) Physical access? – How realistic?

• Q) How to distribute keys to in-vehicle components? • When to share? Manufacturing stage or after market? • Who is key holder? ECU or CAN-ID?

Types of Attackers SW HW

SW

HW

External I/O Physical Access

ECU ECU

Remote Access

Closed in-vehicle network

Physical Attacker Remote Attacker

Target SW and HW SW only

Possible Attacks

Injection, Modification Interruption, Replay attack

Injection, Interruption(limited) Replay attack

Attack possibility

Low (NOT negligible), in practical environment

High

Examples Mechanic replaces ECU. Chip tuning, Attaching device to OBD-II

Hack car infotainment system through Bluetooth, Cell-network.

Problem 1 for secure interaction between car and external entity

Problem 2 for secure interaction between car and external entity

ECUs

Vehicle Side User Side

010101101011011…

CAN frames

{"name": "steering_wheel_angle", "value": 45}

JSON, XML

GW

Connect: Car <-> Smartphone Approx.$110

System model to setup secure channel*

External User Device

(UD) ECUs GW

Wired (CAN) Wired/Wireless (USB, Bluetooth, …)

Short term (Months ~ 2 year)

Mid term (Years)

Long term (As same as a car’s lifetime)

On registration On purchase Built-in

Lifetime

Obtaining Key

*Kyusuk Han, Swapna Divya Potluri, Kang G. Shin, On Authentication in a Connected Vehicle: Secure Integration of Mobile Devices with Vehicular Networks, ICCPS 2013, April, 2013

Assumptions

UD ECU Attacker UD

Physically Restricted

GW

Once GW is attached and remains attached to the vehicle, we consider it secure.

UD does not directly connect to ECU

Each ECU has its own unique seed key provided by an external trusted party

ECU ECU

ECU ECU

Attack Scenarios - Exposing keys using a compromised device

ECU GW UD

Compromised

GW

Physically Restricted

Attack Scenarios - Fake key generation

UD ECU GW Attacker GW

Fake certificate to derive secret key

Considered as valid certificate

Attack Scenarios - Impersonation of UD/GW to ECU

UD ECU GW Attacker Adv- GW

Fake authentication code to impersonate a genuine UD

Considered as valid Authentication Code

Considered as valid UD

UD

CAN

BUS

GW

What we proposed: Three-step verification

P1: Authentication process between Gateway and ECUs

P2: Mutual Authentication process between Device and Gateway

P3: Authentication process for the device request

ECU

Protocol Description

Vehicle Manufacturers, Certificate Authorities P1: Gateway Authentication

Verifies Computes

P2: Secure Channel Setup

Verifies

Computes

P3: Device Authentication

Selects

Verifies

Verifies

Initial setup

Evaluation - Security

• Key exposure from compromised entities

• Fake key usage

• Impersonation of a user device

• Impersonation of GW

1 1 1[ ( ) ] [ ( ) ] [ ( ( )) ]Pr SK MK Pr SK LK Pr h m m≡ ∪ ≡ ≡ ≡F F F

Finding Pre-image

Finding Collision

Evaluation - Performance

Total load for P1 = 9 frames/ECU Total load for P3 = 5 frames/ECU (11 frame/ECU for initial time)

128 bits ID 34/64 bits: Timestamp 160 bits: Certificate of ID and timestamp 160 bits: Authentication Code

Step 1

160 bits: Certificate of ID and timestamp 64 bits: Random Nonces 160 bits: Authentication Code

Step 3

Is he really interpreting?

How to know fake interpreter? Nicole Du Toit, an official sign language interpreter, understanding both

“I sincerely mourn Nelson Mandela”

“I am hungry”

Wilma Newhoudt-Druchen, the first deaf woman to be elected to the South African parliament, said “rubbish. He cannot sign. Please get him off”

Interpreter problem

Alice (External device)

George, the interpreter

Bob (ECU)

Bob does not want reveal the raw data, but wants Alice know it

Alice understands data from George, but does not sure the data is really what Bob sent

Alice wants to send commands to Bob, and wants to be sure if George correctly translate it

Raw Data

Commands

Bob wants to know if the command is really from Alice and not modified

Attack scenarios

• Compromised gateway, • Drops or modifies commands/data to/from ECUs • injects fake commands/data

• Assumption • Internal ECUs are trustful • Exposing proprietary CAN data is not considered

Summary and concluding remarks

• Problem of vehicle • Weak security of in-vehicle network • Different nature integrating in-vehicle network and external network • Vendor’s requirements – Cost-’sensitive’ and ‘under the hood’

• Our challenges • Real-time authentication in-vehicle network • Secure interaction between in-vehicle network and external networks

• On-going work • Security against compromising ‘once authenticated’ gateway • Various applications including intrusion detection and prevention

Thank you!

Kyusuk Han University of Michigan Contact: Kyusuk@umich · 2017. 5. 9. · • Acura: Keyless...

Documents

Transcript of Kyusuk Han University of Michigan Contact: Kyusuk@umich · 2017. 5. 9. · • Acura: Keyless...