kyusuk han university of michigan contact: kyusuk@umich · 2017. 5. 9. · • acura: keyless...
TRANSCRIPT
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
Case Study: Attacking TPMS (2/3)
• 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
Case Study: Attacking TPMS (3/3)
• 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.
Case Study: Attacking PKES (2/5)
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
Case Study: Attacking PKES (3/5)
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
Case Study: Attacking PKES (4/5)
Case Study: Attacking PKES (5/5)
• 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
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.
Transmitting over multiple frames?
Data 1
Data 2
Data 3
Data 4
MAC 1/4
MAC 2/4
MAC 3/4
MAC 4/4
MAC = F(K|Data 1|Data 2|Data 3|Data 4) MAC -> MAC 1|MAC 2| MAC 3| MAC4
Attacker’s data Bogus
Data
64-bit MAC
Attacker’s data
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!