Security and Privacy challenges in Automobile Systems

Transcription

1 Security and Privacy challenges in Automobile Systems Sandip Kundu National Science Foundation on leave from University of Massachusetts, Amherst

2 Automotive Security Breaches Present: Multiple breaches in automotive security reported Future: Problems will get worse as we move towards driverless cars Sources: Second International Workshop on Vehicular Security

3 S&P Landscape Security Challenges: access control, intrusion, malware, Trojans, data contamination, packet forging/injection, data synchronization, side-channels, system failures, black-swan events, privacy leakage, Security Solutions: controlled access, isolation, encryption, trusted code base, intrusion detection, contingency management, anonymization, Technical Solutions are not adequate: perimeter security, usability, responsiveness, maintainability Threats Security Compromises vehicle/passenger safety Privacy Surveilled without explicit consent Second International Workshop on Vehicular Security

4 Security Threats Second International Workshop on Vehicular Security

5 Security Threats Rapid integration of technology, larger attack surface Ever increasing number of sensors, communication technologies Rapid innovation, lack of standardization Car software proprietary to manufacturer Security patch deployment can be uneven similar to cellphone landscape Wireless access No need for physical connection to perform attack Multiple vehicles can be affected simultaneously Hardware/software attacks can affect both safety and privacy Automotive networks 3rd party devices Vehicular software control or infotainment systems Sensors Second International Workshop on Vehicular Security

6 Automotive Network issues

7 Automotive Networks Modern cars offer increasing number of functionalities > 70 Electronic Control Units (ECUs) in current cars Multiple protocols employed for communication varied data rates Courtesy of: L. D Orazio, F. Visintainer, and M. Darin, Sensor networks on the car: State of the art and future challenges, DATE, 2011 Modes of access and Bandwidth requirements will only increase in future Eg. USB, 4G LTE, Vehicle to Vehicle (V2V), Vehicle to Infrastructure (V2I) Second International Workshop on Vehicular Security

8 Car networks are vulnerable Multiple Networks such as Controller Area Network (CAN), Media Oriented Systems Transport (MOST) offer large attack surface 1 eg. Every message sent on CAN is visible to all nodes, not designed for security Attackers can use message spoofing, denial of service, non-repudiation Multiple access points to interface with the networks On-board diagnostics (OBD)-II readily accessible and mandatory in vehicles Vehicular viruses can gain control of various ECUs 2 Greater wireless access in future remote attacks Balancing security of various vehicular access points, protocols and functionalities is a difficult problem More complex with driverless vehicles, Vehicle to Vehicle (V2V) and Vehicle to Infrastructure (V2I) systems 1 I. Studnia, V. Nicomette, et al., "Survey on security threats and protection mechanisms in embedded automotive networks, DSN-W, Budapest, Hungary, Nilsson, Dennis K., and Ulf E. Larson. "Simulated attacks Second can International buses: vehicle Workshop virus." IASTED on Vehicular International Security conference 2017 on communication systems and networks (AsiaCSN)

9 Attack Surfaces and capabilities - Examples Courtesy of: Checkoway, Stephen, et al. "Comprehensive Experimental Analyses of Automotive Attack Surfaces." USENIX Security Symposium Second International Workshop on Vehicular Security

10 Potential Solutions Cryptography enabled CAN Eg. Canauth 1, LiBrA-CAN 2 Need dedicated modules like Hardware Security Modules (HSMs) prevent computational loading of existing ECUs Anomaly/Intrusion Detection (IDS) and Prevention (IPS) systems Signature-based: Use pre-characterized anomaly signatures. Need constant updates Anomaly-based: Characterize normal behavior model, raise alerts upon deviation. System complexity prevents accurate modeling Proper handling of False positives and false negatives crucial Miller/Valasek 3 said any CAN anomaly detection would prevent their attacks 1 A. Van Herrewege et al., Canauth-a simple, backward compatible broadcast authentication protocol for can bus, in 9th Embedded Security in Cars Conf., Dresden, Germany, B. Groza, et al., Libra-can: a lightweight broadcast authentication Second International protocol for Workshop controller on area Vehicular networks, Security CANS, 2017 Darmstadt, Germany, Chris Valasek and Charlie Miller, Adventures in Automotive Networks and Control Units, Technical Whitepaper, IOActive, 2014

11 Centralized Gateways Authentication Every valid bus controller needs a certificate Gateway Functions Protected memory area to store secret keys securely Holds list of valid bus controllers and authorizations Certificates of valid controllers Bus group keys additional protection Inter-bus communication done exclusively over the gateway Firewalls: Implement strong firewalls for complete vehicular bus communication security Vehicular controllers with digital signatures Firewall rules based on authorizations given in the certificates Only authorized controllers broadcast valid messages Vehicular controllers without digital signatures Firewall rules established only on authorization of each subnet Second International Workshop on Vehicular Security

12 3 rd Party Device Security Issues

13 3 rd Party Devices Multiple 3 rd party products access OBD-II port Eg. Progressive Snapshot Driving behavior tracking OBD-II port allows comprehensive access to car systems Devices (like Zubie) can also access cloud servers via GPRS or WiFi Send real-time data like driving behavior, vehicle location, fuel level Download updates from remote server Access data analytics from server in real-time (Eg. traffic management) Second International Workshop on Vehicular Security

14 3 rd Party Device Security Issues Insecure connection or erroneous software is security hazard * Unsecured Firmware code can be reverse-engineered to find exploits Unsigned updates attacker can push malicious updates Lax authentication hackers can spoof server Attackers can siphon user data breach of privacy Compromised devices allow access to other systems via OBD-II port and CAN bus Any number of cars with connected insecure devices can be attacked * Second International Workshop on Vehicular Security

15 Potential Solutions Encourage open platforms Higher scrutiny = better vulnerability detection Patches deployed immediately Robust encryption standards must be enforced User data privacy cannot be compromised Secure Firmware updating is a must Signed software Devices still able to access all CAN bus data Restrict device access Second International Workshop on Vehicular Security

16 Software Code Integrity Second International Workshop on Vehicular Security

17 Software Code Vulnerability Telematics, Fleet management, Infotainment system Logs, Forensics Attack on untrusted software can be critical to vehicle/passenger safety Hard to verify software security multiple vendors, firmware updates Poor firewalls between critical components = full access to vehicle Best coding practices need to be enforced Hardware-software co-design Cryptography and secure root of trust Virtualization Second International Workshop on Vehicular Security

18 Engineering Solutions: Trusted Computing Base (TCB) TCB smallest amount of code (or hardware, firmware) that must be trusted in order to meet security requirements TCB modules enforce principle of least privilege TCB software ensures self-protection TCB design complicated by many factors Multiple ECU and related software vendors Automotive system complexity is increasing TCB confidence increased via code inspection, formal verification, testing Reducing TCB complexity/ size = reduced overhead Robust Hardware Security Module (HSM) can facilitate trusted computing Second International Workshop on Vehicular Security

19 Hardware security modules Hardware security modules (HSMs) are primarily used as root of trust * Integrity measurement Cryptography applications like encryption/decryption, digital signature handling, integrity checking Secure key Management Facilitate secure firmware updates For vehicular on board network : scalable and flexible HSMs required Centralized root of trust Integration additional components based on manufacturer requirements Adaptability towards different sensors, ECUs, bus systems Courtesy of: * Idrees M.S., et al., Secure Automotive On-Board Protocols: A Case of Over-the-Air Firmware Updates, Nets4Cars/Nets4Trains'11, 2011 Second International Workshop on Vehicular Security

20 Secure Booting When the device is first powered up, the authenticity and integrity of its software needs to be verified Secure bootloader checks digital signatures before passing control to rest of the software Bootloader is part of HSM Secure booting critical as most vehicle electronics are powered down when user turns off the engine and exits vehicle Always-ON components may not be feasible wasteful power consumption Crucial for secure firmware updates Due to automotive complexity, multiple boot-up stages and bootloaders may be necessary ECUs and Infotainment systems may be separated Second International Workshop on Vehicular Security

21 Secure Firmware Updates Firmware Over-the-air (FOTA) updates are crucial Recalls are a very costly activity and should be avoided where possible Driverless cars in future will need more frequent updates Firmware upgrade issues * Safety Transmission errors (corrupted firmware), Transmission failures (truncated firmware), Information loss (incomplete firmware) Security Firmware modification, Unauthorized firmware transmission, Unauthorized device updated, Code reverse engineering Firmware security needs HSM Secure Booting Digital Signatures, Device Authentication, Encryption * Atmel, Atmel AT02333: Safe and Secure Bootloader Implementation for SAM3/4. sam-at02333-safe-and-securebootloaderimplementationfor-sam3-4 application-note:pdf. Second International Workshop on Vehicular Security

22 Virtualization Automobile electronics are evolving towards hierarchical approach * Functionalities from several ECUs are consolidated into few domain computers Using virtualization allows segregation in time and space of shared resources Objectives: performance and low latency Virtualization reduces attack surfaces and facilitates reuse of legacy applications Offers flexibility across various automotive systems from same manufacturer Virtualization by itself does not guarantee security Needs hardware support (IOMMU, Secure Boot) Specific software solutions (Inter-partition communication protection, secure system update) Virtualization increases complexity conflicts with TCB requirements * O. Sander et al., "Hardware virtualization support for shared resources in mixed-criticality multicore systems," 2014 Design, Automation & Test in Europe Conference & Exhibition (DATE), Dresden, 2014 Second International Workshop on Vehicular Security

23 Execution Isolation Software execution isolation is an attractive security solution Reduce attack surface via isolation More fine-grained and versatile than Virtualization Require hardware support Ex. memory enclaves One-way isolation protects sensitive data Intel offered Software Guard Extensions (SGX) for computers Offers array of defenses against a variety of software and physical attacks Many vulnerabilities have been exposed 1 not secure against sidechannel attacks Need hardware-software co-design solutions for automotive systems Can prove crucial for V2V and V2I environments 1 Costan, Victor, and Srinivas Devadas. "Intel SGX Explained." IACR Cryptology eprint Archive 2016 (2016): Costan, Victor, Ilia Lebedev, and Srinivas Devadas. "Sanctum: Minimal hardware extensions for strong software isolation." USENIX Security. Vol Second International Workshop on Vehicular Security

24 Automotive Sensor Data Second International Workshop on Vehicular Security

25 Automotive Sensors Modern cars have hundreds of sensors Mandatory sensors pollution, tire pressure Optional sensors rear-view camera Large number of sensors Sensors may need replacing over vehicle lifetime Compromised sensor used to replace legitimate part Third-party sensors used due to cost Insecure devices Sensor data can be corrupted or sensor used as gateway for attack on other systems * Ex. Wireless tire sensors mandatory in USA since Feed data to Tire Pressure Monitoring System (TPMS) Attacks on sensors allowed raising false alarms and remote access to various ECUs * Second International Workshop on Vehicular Security

26 Sensor Data Corruption Sensor data may be bad due to Faulty sensor aging, unauthorized sensor, bad calibration Attacks on sensor Can be difficult to tell the difference Sensor can be hacked * False data generate erroneous data to misinform other modules Ex. Tire sensor indicates flat tire Timing attacks change data frequency by delaying, grouping = erroneous responses from downstream modules Ex. Parking sensor delay causes crash Replay attacks use old data to inform current behavior Ex. Self-driving car LIDAR data replayed at later time = wrong response from control systems * Second International Workshop on Vehicular Security

27 Protecting sensors and data Authentication capabilities built into critical sensors Mutual authentication adds extra security Non-repudiation of sensor generated data is vital Strong Validation procedures Help secure vehicle upon sensor replacement during maintenance Sensors Redundancy Multiple sensors feed data more accuracy, greater data reliability Sensor data Feedback facilitates data integrity checking Control unit can test if sensor is working/calibrated correctly Sensor ad hoc networks dynamic, no single point of failure Can be better than CAN Second International Workshop on Vehicular Security

28 Privacy Threats Second International Workshop on Vehicular Security

29 Privacy threats Attackers may be more interested in compromising privacy than harming passenger safety Financial and identity theft more lucrative Location data is highly valuable Reveals behavioral information of vehicle users Legitimate companies also interested in data Sell targeted advertisements Hard to advocate not collecting the data Passenger privacy is not the only thing at risk External sensors (ex. camera) can record people outside the vehicle Second International Workshop on Vehicular Security

30 Vehicular data privacy and security Second International Workshop on Vehicular Security

31 Sensitive Vehicular Data Personally sensitive data contain either (Sensitive) Personally Identifiable Information ((S)PII) or data that could lead to the discovery of (S)PII. Ex. License plates, addresses on in-car GPS etc. Commercially sensitive data include data elements that may compromise the competitive advantage of a business if the data were to be shared publicly. Ex. Commercial trucking origins and destinations Research sensitive data, these data include any data that may compromise the goals and objectives of a research endeavor Ex. Proprietary driverless car test data All such data valuable to many parties Insurance companies, dealerships driving behavior, maintenance Marketing companies sell personalized advertisements Governments track persons of interest, spying Malicious entities identity or financial data theft Second International Workshop on Vehicular Security

32 Vehicular Data Privacy and Security Telematic Systems like OnStar (GM), Car-Net (VW) access large amounts of telemetry data Systems can also remotely control cars, may collect and transmit any kind of data CAN bus gives full access Even more sensors and complex systems in future, especially self-driving vehicles Telematic systems present opportunities to attackers Steal data stored in vehicle Use access to control vehicle remote arrest of vehicle Second International Workshop on Vehicular Security

33 Securing Vehicular Data Secure data storage policies are critical Sensitive data should be encrypted Physical storage medium should be protected, tamper-proofed Identity management Robust access control and data privilege policies Encrypted logs store information on who requested for data, useful for security audits Secure Authentication Data transfer to only authorized parties Second International Workshop on Vehicular Security

34 Location data Second International Workshop on Vehicular Security

35 Location Data Location based services (LBS) have gained prominence Modern vehicles come with in-built GPS modules Location data valuable to 3 rd parties Data can reveal behavioral information like spending habits Malicious entities detect movement patterns, plan burglaries Data anonymization may not be enough Analysis of data can still reveal personally identifiable information. Ex. Driver goes to same address in evening home address Location information must be manipulated so as to protect the enduser Only authorized parties may retrieve relevant data Second International Workshop on Vehicular Security

36 Intelligent Transportation Systems (ITS) Intelligent systems are being widely deployed Enable traffic management Support for future driverless vehicles Vast array of tracking technologies = More security and privacy concerns Malicious nodes may be introduced to obtain vehicular tracking information Robust policies needed Authenticated tracking queries attackers cannot impersonate legitimate parties Minimize tracking time reduce risk of correlating location data with specific identity Second International Workshop on Vehicular Security

37 Pattern Recognition (Driverless Autos) Second International Workshop on Vehicular Security

38 Pattern Recognition systems Cars incorporating systems to assist or replace drivers Ex. automatic parking Self-driving cars with NN infrastructure will become commonplace Ex. NVIDIA DRIVE TM PX 2 open AI car computing system Courtesy of: /drive-px.html Second International Workshop on Vehicular Security

39 Privacy Vulnerabilities External entities PII can be compromised if no privacy policy present Ex. Google StreetView blurs certain objects Greater deployment of V2I attractive to offload certain computation Data sanitization necessary remove fine-grained information Details about people Other car license plates Keeping pattern recognition data local also prevents man-in-themiddle attacks False data injection may alter vehicle behavior Second International Workshop on Vehicular Security

40 Usability Second International Workshop on Vehicular Security

41 Usable security Operation Transition Revision Satisfaction Correctness Usability Maintainability User-fulfilment Integrity Portability Modularity Mission-fulfilment Efficiency Transferability Testability Usability Reliability Flexibility Responsiveness Contingency management Safety Extensibility Lifetime Compatibility Functionality Second International Workshop on Vehicular Security

42 Summary Security and Privacy solutions involve technology, engineering execution, policy, usability Technology: Many of the technology elements are in place Engineering execution: proactive threat analysis, security and cost proportional solutions Policy: via law or via standardization Usability: Pressing problem Second International Workshop on Vehicular Security

43 Thank You Second International Workshop on Vehicular Security