Connected Car OTA Updating – Another Security Need
We’ve been profiling automobile evolutions that will require the security in connected cars to improve and be well architected from the start. In our last post we discussed the move to Automotive Ethernet and its implications.
In this post we discuss another growing trend, Connected Car OTA updating.
Why is Software or Firmware Updating Necessary?
Commercial computer software, applications and operating systems require updating to add new features and capabilities, resolve bugs and fix security vulnerabilities. Updates are offered by software vendors to owners of these systems on a regular basis and can either be automatically downloaded and installed, downloaded and manually installed or ignored.
In the case of a car, updating software (in actuality firmware) running on automotive engine control units or ECUs is a different story. There are a number of logistical and physical barriers that have to be overcome including:
- Amount and type of memory
- ECU type
- Vehicle availability
- Dealer installation only
- Criticality of the update
Vehicle Software Updates are Handled by Dealers Today
When a car owner brings a vehicle to a dealer for a routine service at a predetermined interval, usually every 10K miles, there are regular windows available to update ECU firmware. However with right to repair laws, car owners are not obligated to bring their vehicle to a dealer for service or repair. However, auto manufacturers do not and will not provide repair shops outside of their dealer networks with the firmware code or systems necessary to update an ECU with the latest version. ECU firmware that resides outside of manufacturer or dealer control could be compromised and make the car it is installed on unsafe or inoperable, while the liability of any problem or accident still resides with the OEM.
In the end this means that 1,000s, 10,000s or 100,000s of cars could all be running different versions of firmware for the various ECUs in the vehicle or not have been updated at all. If an update is safety related, then the only way to ensure that the entire production run has the update installed is to issue a recall. Which, by the way, automotive manufacturers want to avoid at all costs due to the negative publicity and revenue implications.
The Promise of OTA
One new automotive company that has avoided the difficulties of ECU firmware updates is Tesla. Tesla has taken its cues from and implemented a similar model to the commercial software industry, pushing ECU firmware and other software updates over the air (OTA) via AT&T mobile network.
This approach has opened the eyes of other OEMs and with the push to implement Automotive Ethernet as the in-car networking technology, the ability to implement OTA by all manufacturers is on the horizon.
While the upside potential is very high to ensure that the most up-to-date firmware is running on the greatest possible number of their cars, the path to getting the updates to cars is full of potholes. The architecture of an OEM to vehicle OTA software update solution could be represented by the following diagram.
Generic OTA Architecture
OTA Attack Surfaces
Today car dealers are the only source for the installation of updates to ECU firmware, so the integrity of the code can be assured, as the update loop is closed. That is to say there is little to no outside attack vector via a dealer that could be used to exploit any vulnerabilities within in-car systems, unless an internal dealer employee choose to do so. Knowing my car dealer’s maintenance people, that would be some employee. That said we always advocate that engineers take the pessimistic view of system breaches.
The most probable mechanism that manufacturers will use for updates via OTA is via WiFi through the Telematics system or TCU. Depending on the availability of a WiFi connection, as an alternative, WiMax or cellular connectivity could also be used.
Cellular connectivity, with its direct bus connection is already a proven attack vector that was successfully exploited in a white hat attack which resulted in a recall of Jeeps by Fiat Chrysler Group in 2016 to fix the vulnerability. As we discussed in our post on security negatives to Automotive Ethernet, the use of WiFi or WiMax for OTA updates would open additional attack surfaces which offer additional paths to malicious activities.
Attack modes could include a WiFi/WiMax man-in-the-middle based attack or compromise of a WiFi home network that is using inadequate or no security at all. There are also a number of known WiFi attack methodologies that could be used to access in-car systems.
7 Design Considerations for Ensuring Strong OTA Update Security
Automotive engineers should try and design in a multi-layered approach to OTA security. Pushing a new version of ECU code to a vehicle over a wireless Cloud connection requires that the transaction be secure from end-to-end.
Based on my years of experience in security, here are 7 design tips and best practices automotive engineers should keep in mind when designing and building OTA software update mechanisms. If you are interested in our complete view on the topic, download our Essential Guide to Automotive Cybersecurity.
- Strong foundation
For devices and services for mission critical systems, we should select hardware that includes support for a secure boot mechanism, hardware-based strong random number generator, and a strong cryptographic identity (i.e. private key). A strong random number generator will make future certifications much more painless – generating entropy is questionable and time consuming. A strong random number generator enables secure end-to-end trustworthy communication, which can be used communicate diagnostics, and perform future financial transactions. The device maker must take adequate steps to protect the private key – securing in hardware removes great deal of burden; and there should be a backup plan in place in the low probability event that a private key is lost or stolen.
- Keeping device trustworthy
The OTA objective is very basic — to provide high assurance the ECU is running safe, trusted code. We can use digital signatures or code-signing to assure the code came from the device maker, using strong cryptography. We can’t anticipate all avenues or vulnerabilities, but we can through the secure boot mechanism assure only trusted code is allowed to execute at power on. The secure boot mechanism should work with the OTA update to prevent a “firmware downgrade attack” or what is sometimes known as a “replay attack.” This will eliminate many attack vectors, even when the attacker has physical access (“the angry valet” scenario).
- Protect twice
The US Department of Defense (DoD) requires for Secret and above communications to use two layers of encryption for data in transit protection; e.g. TLS layer over VPN layer. The rationale for this design is that it is difficult to find two vulnerabilities, which lineup between two independent layers to allow breaking a secure communication link. This same principle should be applied to code signing. While secure boot ensures the firmware is safe at time of startup, a second layer of defense that checks that each individual executable or library when loaded has not been tainted will prevent dropper attacks; for example while a device is running an attacker loads a malicious application onto the main flash or possibly a RAM disk space and that goes undetected. Dellfer ZeroDayGuard implements this type of second layer of protection using more than one hash algorithm for added strength.
- End-to-end secure communications
A secure boot verifying that code is properly signed eliminates many attack vectors, but for there to be safety and awareness in assuring the two parties in the OTA transaction, the car and the authorized cloud service, there should be an end-to-end secure communication link using mutual cryptographic authentication. It’s important for the car to connect to an OEM’s trusted server for updates, but also important for the OEM to know which car is connecting to their server as well. To ensure all cars are being updated, for spotting issues with update failing to properly install quickly, potentially to offer different updates for different devices, spot unusual configurations as well or to just have the ability to audit the field of devices for compliance and safety.
- Dependencies – plan for “MD5, SSHv1, SSLv2, HTTP 1.0, etc, etc moment”
At some point for some OEM there will likely be situations where two or more ECUs will require a patch to be applied at same time for secure communications inoperability. The ability to recognize and respond to those rare event situations will require some upfront preplanning to avoid expensive recalls.
- Take a pessimistic approach to cyber defense in design
In general, security design should be approached from the standpoint of worst-case modeling and thinking. If the communications integrity were compromised, how could code integrity continue to be maintained? If a trusted source were compromised and impersonated, what safe guards could be added to limit damage and exposure?
- It is always best to keep things simple
Code signing could be accomplished using certificates, which has the ability for supplier and OEM to potentially issue firmware updates, but there would need to be some inner firmware image that would be need to be signed –sharing private keys opens significant risk that the key is stolen. It is very easy to have a bug in ASN.1 BER/DER parser – this code is too complex for secure boot; e.g. many ASN.1 parsers use recursion. Certificates have a nice proven revocation mechanism, however If there is firmware downgrade protection in place, revocation is not necessary, simply push out a new secure version which invalidates the revoked firmware image. Recently, there has been some talk of using Blockchain for attesting to the provenance of a firmware image – but there will always need to be some immutable data anchor. Complexity is the enemy of safety and security.
Conclusion
OTA updates of ECU firmware and software will make connected cars more security than the current dealer closed network that exist today. Security will become more real-time, which is a huge positive.
But it’s clear that automotive engineers that design these systems must consider a security architecture from the start, and one that will work over the lifecycle of the car. OTA designs need to guard against the probability that attempts will be made to exploit this new attack surface and the above scenarios provide some insight into approaches that could offer a level of confidence that ECU software integrity can be maintained using an OTA software update methodology.
