Daniel Kent 1 May 2019

1. Assuring Vehicle ECU Update Integrity using Public Key Infrastructure (PKI) and Public Key Cryptography (PKC) Daniel Kent 1 May 2019

2. Outline • Problem Statement • Existing PKC/PKI-based Systems • Proposed ECU Update Assurance Scheme • Security Analysis of Proposed Scheme • Impact of Proposed Scheme • Demonstration • Questions

3. Problem Statement • Currently, ECU firmware is barely protected, if at all • Miller et al. demonstrated capability to reprogram ECUs even with manufacturer obfuscation[1] • Tools to reprogram cost thousands of dollars, but can be obtained/cloned by unauthorized third parties • Update mechanisms were obfuscated, not secured/encrypted • ECU tuning is commonly performed by enthusiasts looking to improve performance • May result in increased emissions (sometimes deliberately) • How trustworthy is third-party modified/developed/hosted firmware? • ECUs must be able to assure that a given firmware image/update is valid and has not been altered, corrupted, or tampered with • By assuring ECU firmware update integrity, the security of the transmission channel becomes much less important

4. A Brief Overview of Encryption Essentials[2] • A symmetric key is a file that can be used to scramble (encrypt) a file, which itself can be used to reverse the scrambling operation. • An asymmetric key pair are a pair of files that allow for encryption using one key and decryption using the other and vice versa, but does not allow (mathematically) the decryption of the file using only one half of the key pair. • A checksum is a mathematical operation that produces a small datum from a larger set of data that can be used to validate message integrity (Ex: last 4 digits on a credit card; CRC in many protocols including CAN) • A cryptographic checksum is a checksum operation that is very difficult to reverse (except for brute-force attacks) (Ex: SHA256)

5. A Brief Overview of Public-Key Cryptography and Public-Key Infrastructure[2] • A signature is the cryptographic checksum of a file, encrypted with a private key. Signatures can be verified by decrypting the checksum with the public key, and then independently computing the checksum. • Public-Key Infrastructures are built by taking a public key and using it to sign other public keys that also contain identity metadata, which is used to designate identity and/or scope (example: server keys that are only valid for certain domains, and can identify ownership for a domain). Can be repeated to form a larger chain. • X.509 standardizes the format for the combined key and metadata information (called a certificate)

6. Prior Art – SSL/TLS[2] • When connecting to a secure website, the server can provide a certificate that allows the user and the server to securely exchange a symmetric session key (and optionally provide identity information) • This security was originally used for commerce and banking, but has expanded to more websites as privacy becomes more valued • With so many websites, it is impossible for users to store all certificates, so instead users typically keep a smaller number of root certificates that can be used to validate individual website certificates • Due to decentralized nature of root certificate authorities, bad-acting issuers can weaken the security of TLS [3]

7. Prior Art – DoD Common Access Card (CAC) • US Department of Defense created a PKI-based identification system in the early 2000s to supplant passwords that is still used today[4] • Based on physical tokens (smartcards) – private keys are generated on and cannot be easily extracted from tokens • Not impossible, but very difficult and time consuming, and may result in the destruction of the token.[5] • If a token is stolen, there is a window of time that allows previous certificate to be revoked and replaced • Some security weaknesses have been identified, but typically involve the CAC being used on Internet-connected computers • Due to scope of system, CAC infrastructure is very costly to maintain An example of a CAC (courtesy cac.mil)

8. Prior Art: Hyundai Patent Application[6] • Hyundai applied for a patent for a method to secure ECU updates in 2013 • Follows procedure similar to session-key exchange used in SSL/TLS • Only secures transmission of firmware from manufacturer to “diagnostic apparatus” • What about apparatus to ECU itself? • Shows interest within automotive sector for adopting PKC/PKI for securing ECU updates Encryption and Transmission Scheme for Hyundai Patent [6]

9. Prior Art: Intel Patent Application[7] • Intel applied for a patent covering the use of cryptographic coprocessors to validate firmware. • Specifically mentions automotive applications in patent, but is generic enough to cover other fields • Does not cover updates specifically, but could be easily extended to do so • Shows interest within automotive sector for using additional cryptographic hardware if necessary

10. Prior Art: Desktop/Mobile OS Updates • Most major Linux distributions use a package manager to resolve dependencies and provide updates to users • Advanced Package Tool (APT) and Red Hat Package Manager (RPM) are two commonly used package managers • Both APT and RPM repositories provide a signed list of package checksums to validate that an attacker cannot tamper with packages, and individual packages themselves can be signed • Debian hosts APT servers over HTTP; Debian maintainers believe that security of package signatures overrides concerns of HTTP security, and that overhead of HTTPS is not worthwhile in this case • Google’s Android mobile operating system uses PKC to secure updates • Keys are controlled by manufacturer, not Google

11. Desired Update Scheme Attributes • Use PKI/PKC similar to existing consumer OS/firmware updates to assure update integrity (OS/PKC) • Allows for use of alternate keys if the original keys are lost or stolen (PKI), but does not allow untrusted third parties to possibly make valid keys (SSL/TLS) • Secure private signing keys of the update mechanism from theft (DOD CAC) • Relatively inexpensive, even for lower-powered ECUs (additional hardware may be acceptable per recent patent activity, e.g. Intel patent) • Provides appropriate control over contents for both Tier 1 and Automotive Manufacturers

12. Proposed Split-Key Signing Scheme • Split firmware into two segments: the firmware code itself, and the configuration • Reflects reality of automotive ECUs: single ECU can be used by multiple manufacturers, but may need different configurations (even within a single manufacturer) • Hybrid-signature approach • Tier 1 signs firmware code; auto manufacturer signs code, T1 signature, and configuration • Auto Manufacturer gets to ultimately approve firmware updates, but cannot tamper with Tier 1 produced code • Tier 1 cannot release updates that can be installed on vehicles without Auto Manufacturer approval • Firmware files are NOT encrypted, only signed • Lower overhead for ECUs – no need to store session key, only public keys for Manufacturer/Tier 1 • 3-segment PKI Chain – Root, Year, Model • Reduces cost, lowers chain surface area • Private Keys are kept on physical tokens (smart cards) protected by PIN or passphrase • All signing activities performed on non-Internet connected computers

13. Proposed Split-Key Signing Scheme: PKI Tier 1 Key Structure Auto Manufacturer Key Structure

14. Proposed Split-Key Signing Scheme – Producing a Firmware Update • Tier 1 supplier develops and approves a firmware update • Tier 1 supplier uses their product model signing key to produce a firmware update signature • Tier 1 supplier sends the firmware to the automotive manufacturer • Automotive manufacturer validates firmware signature, and performs acceptance testing • Automotive manufacturer produces configuration for new firmware • Automotive manufacturer signs the combined firmware, firmware signature, and configuration • Automotive manufacturer releases the 4-part update image for installation on target vehicles (OTA, dealerships, etc.)

15. Proposed Split-Key Signing Scheme – ECU Update Process • ECU receives an update blob, and optionally updated model or yearly keys • ECU checks the signature against all stored keys to validate whether its stored model key was used to sign the 3-part update • If not, verify that the update keys were signed by the master key. If so, continue using these keys. Otherwise, halt update • Independently compute the checksum of the firmware update file to validate the integrity of the 3-part update. If this fails, halt update • Separate the configuration, firmware, and firmware signature components • Repeat steps 2-3 for the firmware and firmware signature, using the Tier 1 keys instead. • If all signatures are validated, initiate firmware update process

16. Proposed Split-Key Signing Scheme – ECU Update Process

17. Live Demonstration

18. Security Vulnerability Analysis • Key duplication / theft • Use of smartcard tokens does not guarantee security in case of theft, but should increase time it takes for an attacker to successfully extract card contents • Physical security of cards themselves (i.e., locked in safe) should also help reduce likelihood of theft • Use of non-Internet connected computer to sign reduces possible firmware load substitution, makes it harder to exfiltrate substituted firmware from non-Internet connected computer • PIN protection would reduce number of insiders that could use the key maliciously

19. Security Vulnerability Analysis • Replay Attacks • Lack of real-time clock on many ECUs precludes ability to verify updates via timestamp (i.e., old valid firmware cannot easily not be discerned from new valid firmware) • If attackers also control manufacturer keys, they could potentially keep replacing updated firmware with out-of-date firmware • If manufacturer can control firmware version blacklist, attackers with manufacturer key could blacklist all future versions as well

20. Security Vulnerability Analysis • Development Process Code Insertion • If attackers insert malicious code into firmware update repository (i.e., Git/Subversion repository), and malicious code is not detected, vulnerability will be introduced in signed code • If code can tamper with on-ECU keys or update process, consequences could be catastrophic – could lock manufacturers/Tier 1 out of ECU updates entirely • However, if code cannot tamper with on-ECU keys, manufacturers could replace malicious firmware, and with addition of blacklist could prevent rollback to vulnerable version. • While this is a problem, non-existence of security now is a much more pertinent problem.

21. Other Effects – ECU Tuning / Repair • Currently, most non-manufacturer ECU flashing is performed by enthusiasts seeking to change their vehicle’s performance • ECU tuning can increase performance at the cost of emissions (if done correctly) • Securing ECU updates and configuration would lock out tuning community • Would not intrinsically lock out mechanics updating ECUs with valid firmware images (regardless of source) • Should jailbreaking ECUs be allowed?

22. Other Effects – Cross-ECU Validation • Proposed scheme does not address cross-ECU validation, which is arguably as important as validating individual ECU firmware integrity • Some proposals have been put forth for cross-ECU validation, but a standard would be helpful

23. Other Effects –ECU Update Timing • Proposed scheme does not address timing of ECU updates • Updating ECUs at the wrong time could make vehicles undrivable, or could be used as a Denial of Service attack (even with legitimate updates) • Some proposals have been put forth for choosing appropriate time for ECU updates[8].

24. Summary • Created a scheme for ECU updates that can be used to assure update integrity • Draws on existing PKC/PKI Prior Art • Scheme has a clear roadmap that can be easily duplicated by automotive manufacturers and Tier 1 suppliers • Respects split authority of Automotive Manufacturers and Tier 1 Suppliers • Cost is a concern, but could be reasonable • Analyzed and addressed possible security vulnerabilities in proposed scheme • Overall, much better security than current status quo • Analyzed other effects of proposed scheme

25. References [1] Miller, C., & Valasek, C. (2015). Remote exploitation of an unaltered passenger vehicle. Black Hat USA, 2015, 91. [2] Davies, J. (2011). Implementing SSL/TLS using cryptography and PKI. John Wiley and Sons. [3] A. Ayer, “Misissued/suspicious Symantec certificates,” mozilla.dev.security.policy, Jan 2017. [Online]. Available: https://groups.google.com/forum/#!msg/ mozilla.dev.security.policy/fyJ3EK2YOP8/yvjS5leYCAAJ [4] Dasgupta, P., Chatha, K., & Gupta, S. K. (2009). Viral attacks on the DoD common access card (CAC). Tempe, AZ: Department of Computer Science and Engineering, Arizona State University, ND http://cactus. eas. asu. edu/partha/Papers-PDF/2007/milcom. pdf. [5] Markantonakis, K., Tunstall, M., Hancke, G., Askoxylakis, I., & Mayes, K. (2009). Attacking smart card systems: Theory and practice. information security technical report, 14(2), 46-56. [6] H. J. Jung, H. S. Ahn, and C. H. Lee, “Firmware upgrade method and system thereof,” South Korea Discontinue Patent Application 20 150 074 414A, December 24, 2013. [7] J. Zander, M. Zmuda, I. A. Tatourian, and P. Szymanski, “Methods and apparatus to use a security coprocessor for firmware protection,” US Patent App. 15/273,997, March 7, 2018 [8] J. Siegel, “System and method for providing predictive software upgrades,” U.S. Patent 9,086,941 B1, 2015.

26. Questions