Updating software and firmware using Over-the-Air (OTA) has increased in the handheld devices, industrial, and automotive sectors for the embedded platform with time. Once the product is in the real world, firmware or the software update related to bug fixes, security fixes, or the feature update is required for the betterment of the device and keeping it updated with latest software.
OTA is a technology to update the software or the firmware remotely.
In case of a vehicle, the firmware or software is updated wirelessly using a telecommunication device, through a gateway inside the car to the ECU whose presence is increasing in modern vehicle.
What is the Need of OTA (Over-the-Air Update) for the Vehicle?
In Automotive industry, the vehicle has become more and more intelligent and smart. Currently, the vehicles are majorly controlled by a software rather than traditional mechanical components.
A decade ago, if there was a need to update the software the vehicle was towed to the service station and the vehicles were connected to the system/computer for an update. OTA solves the problem of reliability of each updated that used to be present earlier, secondly dependency of the service station, carrying the vehicle to the station, the cost of update the software becomes very low, and no much hassle to the customer and well as the service station. Last but not least, the security update on time for every vehicle is important and is done at easeThe approach of the OTA update for the mobile phones and the vehicles are different, the vehicle OTA update is more complex and stringent as compared to the handheld device, improper software update may cause harm to user life too.
Electronic Control Units (ECUs) has become the major component in the vehicle today, ECU has replaced all mechanical steering components. In general, ECUs are interconnected by one or more networks and share information that enables complex interactions and regulations. For example, In Advanced Driver Assistance Systems (ADAS), the increasing functional capabilities comes with a higher system complexity, which makes software bugs more likely to occur that might have implications for the safety and security of the whole vehicle. With regular software updates and enhancements, one can ensure the systems’ correctness, efficiency, and reliability over the complete lifetime of the vehicle.
This blogs mainly describe the end-to-end solution that can be deployed to support OTA software updates in the automotive sector.
In the previous section, we talked about the OTA and understand that OTA update in the automotive sector has major challenges in terms of security while updating the software over the air.
If the attackers get control of the vehicle, one might end up in a hazard situation.
- Engine transmission can be turned on/off
- Passengers or the drivers can be locked inside the car
- Blowing the horn continuously
- Controlling the steering system
- Car braking system
- Speeding the car beyond road regulation.
- Controlling the navigation, audio or infotainment system
- False alarm in the cockpit
Let’s see how the OTA update happens in the vehicle.
Overview: The OTA remote update method of the vehicles is fast, cost-effective, and allows updating of the software running on their ECUs over-the-air, and the car users can update the software anywhere without having to go to the service centre or repair shop. Further, OEM can diagnose the car based on the data received through over-the-air from the car
Figure 1: General overview of the OTA update
Secure OTA in the automotive system: The secure OTA update is the most important factor while updating the firmware or software for the ECU. There are a lot of challenges to achieve secure OTA update. There are many techniques proposed and implemented across the industry to achieve the secure OTA updates. We will be discussing some of them and explain the most common technique used in the automotive industry.
Let’s divide the whole end-to-end architecture into three components and what is the purpose of it.
Backend Server: The backend server is mainly responsible for creating the firmware and software images that need to be deployed in-vehicle units. The backend server tries to collect the images that need to be deployed from the different Tier-1 suppliers and packed it in one single image for all the ECU.
This backed server can be based on the Yocto based system (open source) or third-party support architecture.
Communication Channel: The most challenging part of the component is when the data/Images are exposed to the n/w and they are easy for the attackers to manipulate. There are many techniques, open-source and third-party solution for secure update to the head unit
Most commonly used is Uptane. Uptane is the first comprehensive security framework guiding the implementation of OTA update systems on a design level.
Head Unit (Vehicles itself): Head units comprise of many ECU’s, maybe some are high speed, or some less speed, and also different type of ECU, TCU (telematics control unit), gateways, every component as a role to play in the OTA update.
The head unit also needs to make sure that it is ready to connect to the backend to get updated firmware and software. Or itself has the capability to trigger to request update.
OTA update using Uptane
The Update Framework (TUF) is designed to create a security system to protect users of software repositories from the security attacks. It has been designed, keeping in mind that the backend server may not be secure, or the key used for the cryptography can be stolen.
So, what it does is it creates a distributed system, where the dependency on a particular system is not there, and in case of the attacker’s thread, all the systems cannot be hacked so easily at the same time.
The Update Framework (TUF) has divided the roles into four parts (Root of trust, Timestamps, Snapshot, Targets)
Uptane builds on The Update Framework (TUF), which is distributed (Timeserver, directory and image repository, manifests, Primary/secondary ECU’s, full and partial verification.
Figure 2: Overview of the Uptane
It will contain the images (the data that need to be updated to the ECU) with metadata (cryptographic hashes, file size)
Image Repository: Image repository uses an offline key to sign the metadata for all available updates for the ECU.
Periodically (e.g., weekly, monthly) update metadata about available images
Use Uptane command-line tools to generate the metadata
Use threshold of offline keys (e.g., Yubikey, HSM, etc. often used) to sign metadata
Figure 3: Image repository
Directory Repository: Directory repository used the online key to sign metadata to be used to install in ECU on the vehicle. It determines which images need to be installed in which ECU’s, create different metadata for the different vehicle, and access the inventory data to get details about the vehicle.
Typically used to instruct a vehicle which updates to install, depending on what it has
- Can be used to instantly blacklist updates
- Use Uptane API to generate signed metadata
- Uses an inventory database to read and write information about ECUs (e.g., public keys, what was previously installed, etc.)
Figure 4: Directory repository
So, the key here is that’s, before installation, it needs to confirm that the instruction from directory and image repository matches.
Figure 5: Vehicle and OEM end information sharing
Time server: When the primary ECU sends the list of tokens for every ECUS, to the time server, time server returns a signed message containing the list of tokens and the current time
Head unit (Vehicle Itself):
In the head unit of the vehicle, we have a different type of ECU based on how they connected internally or the external world, how powerful in terms of speed, storage, etc.
- The primary ECU (TCU) download the images, verifies it and then distribute the metadata to the other secondary ECU’s
- The secondary ECU’s also verify the image before updating the images.
- It does the full and partial verification
Figure 6: Communication between ECUs
Complete flow of communication from the head unit to the Backend server.
Figure 7: Communication channel
What does it take to deploy the Uptane?
- The OEM sets up and maintains
- Director repository
- Image repository
- Time server (optional)
- Images are signed by
- Supplier, or OEM, or Both!
- ECUs shall do either
- Full verification, or
- Partial verification
- May keep using your existing TLS, etc. transport
- If transport / caching compromised, little security risk
Challenges on OTA update
- Automotive is more complex architecture with an increasing number of ECU, updating the different type of ECU itself become challenging
- The security of the data over the air is at high risk.
- How to update firmware and software is done using minimal resources like network bandwidth, storage, and compute.
- Is it Possible to update not only the application/ but the core driver /software of the device?
- The rollback mechanism of the software update
- Higher downtime is not accepted while updating the software or firmware.
- The size of the software blocks
- How seamlessly OTA happens with impacting the current system.
In the automotive world with time the software update will increase to make sure the it is up to date with time. Vehicles needs to updated securely. Uptane can be one of promising solutions to update the software over the air.
- Enabling SAE L3-L5 Autonomy with Sensor Fusion: Approaches and Challenges
- Safety Concept for Automated Driving
- Guide to Porting Real-time Traffic Sign Recognition Algorithm on Texas Instruments TDA2x SoC