Over-The-Air (OTA) updates for vehicles are becoming the standard in 2022. Infotainment OTA updates have been available for over a decade; but now, multiple OEMs offer OTA updates for additional ECUs in the vehicle. This change introduces challenges in the form of new attack surfaces, and opportunities for improving automotive security, such as enabling the ability to fix security issues remotely. This session briefly introduces how Automotive OTA works. We examine some aspects of the design and implementation of an end-to-end secure Automotive Software Update solution. Based off actual findings in security reviews conducted by CYMOTIVE, we describe common security misconceptions and show how they cause vulnerabilities in automotive OTA update implementations. We conclude the session by presenting some ideas for improving the OTA development process.

1. ©2022 CYMOTIVE Technologies Ltd. All Rights Reserved.
Unauthorized use, duplication, disclosure or modification of
this document is strictly prohibited. CYMOTIVE Technologies
makes no representations regarding the correctness or
completeness of the content herein.
Benny Meisels
99% Complete, Don’t Turn Off Your Car
Automotive OTA Security For The Connected Vehicle

2. About Me
• Benny Meisels
• Lead Solution Architect @ CYMOTIVE
• 9 years in IT and embedded security
research
• Enjoys working on electronic
conference badges
2

3. Motivation
• OTA adoption is on the rise
• Automotive OTA is complicated
• Complexity == Harder to secure
• We believe regulations are the
“minimum requirements”
3

4. Agenda
• Classic And OTA Updates Intro
• Design Security Considerations
• Implementation Misconceptions
• “The Server Is Always Authentic”
• “Using A Signature Is Enough”
• “Local Storage Is Secure”
• And the resulting vulnerabilities
• Suggestions For Process Improvement
4

5. Classic And OTA Updates Intro
5

6. ECU Update Objectives
• Address recall / Fix issues
• Safety
• Compatibility
• Usability
• Security
• Update function data (Maps, ...)
• Add new features
6

7. ECU Flashing – Classic Approach
• Diagnostic tester
• UDS (ISO 14229-1) over CAN
• DoIP (ISO 13400-2) over Ethernet
• USB
7

8. ECU Flashing – Diagnostic Tester
• Tester is connected to the OBD
• Flashing SW uses the tester to send UDS
messages according to the ISO 14229-1
standard
• Mostly proprietary
8

9. Over The Air Updates
• Updates are delivered from OEM cloud directly to the vehicle
• Advantages
• Remote recall
• Lower cost
• Rapid deployment
9

10. ECU Flashing – OTA Update Manager
• Fetch updates from server
• Match hardware and software
• Cache update locally
• Connectivity isn’t guaranteed
• Flash individual ECUs
• In The Correct Order
• Harness existing classic solution (UDS)
• Or develop OTA specific interface
10

11. Design Security Considerations
11

12. Design Security Considerations
12

13. Authorization
• What permission do you need to update an ECU?
• How do you verify the authorization?
13

14. Authentication
• How to authenticate the backend?
• How to authenticate the vehicle?
• How can we ensure future proofing?
14

15. Integrity
• Where should the integrity checks happen?
• How is Key Management handled?
• How can we store updates securely?
15

16. Reliability
• Guarantee deterministic update result
• Testing preconditions
• Battery
• Safety
• Availability - User consent
16

17. Regulation
• Homologation
• How does this affect security updates?
• Compliance with UN R156
• RxSWIN
• Rollback
17

18. Misconceptions In Implementation
18

19. Misconceptions In Implementation
• Let's assume you have the perfect design
• You have written specifications and requirements
• These now need to be realized in code
• What can go wrong?
19

20. Simplified OTA Example
update_path = download_to_file("https://XXX.YYY/...", SWUPDATE_PATH);
// ....
if(verify_swupdate_package(update_path)) {
flash_firmware(update_path);
} else {
// ....
}
20

21. “The Server Is Always Authentic”
21

22. Insecure Backend Communication Example
update_path = download_to_file( "https://XXX.YYY/...", SWUPDATE_PATH);
// ....
if(verify_swupdate_package(update_path)) {
flash_firmware(update_path);
} else {
// ....
}
22

23. Insecure Backend Communication Example
update_path = download_to_file( "https://XXX.YYY/...", SWUPDATE_PATH);
// ....
if(verify_swupdate_package(update_path)) {
flash_firmware(update_path);
} else {
// ....
}
23

24. Insecure Backend Communication Example
string download_to_file(string url, string path) {
// ... Create X509_STORE
X509_STORE_set_verify_cb(store, verify_callback);
// ... Add certificates to store
// ... Perform download and writing to file
}
// Called on verification failure
int verify_callback(int ok, X509_STORE_CTX *ctx) {
return 1; // Ignore Error
}
24

25. Insecure Backend Communication Example
• Turns out the certificate chain is tested using OpenSSL
• A callback registered by the code is supposed to handle all errors
• In the implementation we examined the callback returned 1 for
most errors (no error)
• An attacker can supply an invalid certificate
25

26. Additional Cases
• Updates downloaded over HTTP
• Specific updates downloaded over HTTPS without verifying the
hostname in the certificate
• Update downloaded from an FTP server
26

27. “Using A Signature Is Enough”
27

28. Broken Signature Example
update_path = download_to_file("https://XXX.YYY/...", SWUPDATE_PATH);
// ....
if(verify_swupdate_package(update_path)) {
flash_firmware(update_path);
} else {
// ....
}
28

29. Broken Signature Example
bool verify_swupdate_package(string path) {
unsigned char received_hash[SHA256_DIGEST_LENGTH];
unsigned char calculated_hash[SHA256_DIGEST_LENGTH];
// ... Read file contents into data and verify file length
memcpy(calculated_hash, data.data(), SHA256_DIGEST_LENGTH);
calculate_sha256(
calculated_hash,
data.data() + SHA256_DIGEST_LENGTH,
data.length() - SHA256_DIGEST_LENGTH);
return 0 == memcmp(calculated_hash, received_hash, SHA256_DIGEST_LENGTH);
}
29

30. Broken Signature Example
bool verify_swupdate_package(string path) {
unsigned char received_hash[SHA256_DIGEST_LENGTH];
unsigned char calculated_hash[SHA256_DIGEST_LENGTH];
// ... Read file contents into data and verify file length
memcpy(calculated_hash, data.data(), SHA256_DIGEST_LENGTH);
calculate_sha256(
calculated_hash,
data.data() + SHA256_DIGEST_LENGTH,
data.length() - SHA256_DIGEST_LENGTH);
return 0 == memcmp(calculated_hash, received_hash, SHA256_DIGEST_LENGTH);
}
30

31. Broken Signature Example
bool verify_swupdate_package(string path) {
unsigned char received_hash[SHA256_DIGEST_LENGTH];
unsigned char calculated_hash[SHA256_DIGEST_LENGTH];
// ... Read file contents into data and verify file length
memcpy(calculated_hash, data.data(), SHA256_DIGEST_LENGTH);
calculate_sha256(
calculated_hash,
data.data() + SHA256_DIGEST_LENGTH,
data.length() - SHA256_DIGEST_LENGTH);
return 0 == memcmp(calculated_hash, received_hash, SHA256_DIGEST_LENGTH);
}
31

32. Broken Signature Example
bool verify_swupdate_package(string path) {
unsigned char received_hash[SHA256_DIGEST_LENGTH];
unsigned char calculated_hash[SHA256_DIGEST_LENGTH];
// ... Read file contents into data and verify file length
memcpy(calculated_hash, data.data(), SHA256_DIGEST_LENGTH);
calculate_sha256(
calculated_hash,
data.data() + SHA256_DIGEST_LENGTH,
data.length() - SHA256_DIGEST_LENGTH);
return 0 == memcmp(calculated_hash, received_hash, SHA256_DIGEST_LENGTH);
}
32

33. Broken Signature Example
bool verify_swupdate_package(string path) {
unsigned char received_hash[SHA256_DIGEST_LENGTH];
unsigned char calculated_hash[SHA256_DIGEST_LENGTH];
// ... Read file contents into data and verify file length
memcpy(calculated_hash, data.data(), SHA256_DIGEST_LENGTH);
calculate_sha256(
calculated_hash,
data.data() + SHA256_DIGEST_LENGTH,
data.length() - SHA256_DIGEST_LENGTH);
return 0 == memcmp(calculated_hash, received_hash, SHA256_DIGEST_LENGTH);
}
33

34. Broken Signature Example
• Hash is extracted from the file
• Hash is also calculated on file contents
• Hashes are compared
• No actual signature is checked
• Attacker can create a file which will pass this check
34

35. Additional Cases
• Skip signature check if no signature is present
• CRC32 checksum as signature alternative
• Hyundai default keys (Non-OTA) – by greenluigi1
35

36. “Local Storage Is Secure”
36

37. Insecure Storage Example
update_path = download_to_file("https://XXX.YYY/...", SWUPDATE_PATH);
// ....
if(verify_swupdate_package(update_path)) {
flash_firmware(update_path);
} else {
// ....
}
37

38. Insecure Storage Example
update_path = download_to_file("https://XXX.YYY/...", SWUPDATE_PATH);
// ....
if(verify_swupdate_package(update_path)) { // First Read, Time-Of-Check
flash_firmware(update_path); // Second Read, Time-Of-Use
} else {
// ....
}
38

39. Insecure Storage Example
• File is read twice
• First for verification
• Then for flashing
• File can be changed in between being read
• Requires some way to manipulate the file
• Assume pre-existing limited code execution
39

40. Additional Cases
• OTA files stored in unencrypted storage
• OTA files accessible by other processes
• Tesla GTW storage on SD Card – Blackhat USA 2017 – Tencent
KeenLab
40

41. Suggestions For Process Improvement​
41

42. Suggestions For Process Improvement​
42

43. Design
• Don’t reinvent the wheel
• Learn from OTA in other industries
• Write detailed requirements
• Avoid mechanism duplication
• Share design across ECUs
43

44. Implementation
• Make no assumptions
• Follow best practices
• Defensive programming and multi-layered security
• Use comprehensive testing suites, static analysis, and fuzzing
• Share implementations across generations and variants
• Perform code reviews and penetration tests
44

45. General
• Standardization of software updates (AUTOSAR?)
• Open-Source reference designs and implementations
• Share your experience with the community
45

46. Special Thanks
• CYMOTIVE
• Ilay Levi (Security Researcher)
• Ruben Bokobza (Vehicle Security Team Lead)
• Dan Givon (HW Specialist Team Lead)
• Gal Zaban (Security Researcher @ Armis)
46

47. Questions?
47

48. cymotive.com

49. References And Further Reading
• Hyundai default keys (Non-OTA) – by greenluigi1
• Tesla GTW storage on SD Card – Blackhat USA 2017 – Tencent
KeenLab
• Cybersecurity of Firmware Updates - 2020 - NHTSA
• Secure OTA Software Updates in Connected - 2019 - (Halder,
Ghosal, Conti)
• Introduction to UN Regulation No 156 and the Software Update
Management System - Tobias Pilz
• Uptane project - Linux Foundation
49