How does Uptane work?
Uptane, an open standard/specification for automotive software update security, provides a high degree of safety against the entire spectrum of potential attacks. It expands upon The Update Framework (TUF), providing the extra features and security that are needed for over-the-air updates in the automotive industry. ATS is now integrating one of the first commercially-available Uptane implementations, including making it available in our SaaS OTA updating platform, ATS Garage.
Server side security
Every update package, whether it's updating firmware, software, or data like maps packages, must have a metadata file describing its contents that is cryptographically signed and which allows the package contents to be verified. The metadata file gets signed by an authorized authority—for example, the Tier 1 supplier developing the firmware, or the QA department, or others. This signing authority can be delegated on multiple levels, and the requirements for different sign-offs can be set by the auto manufacturer, providing both flexibility and security. Once a package has been signed by the authorized provider (and/or anyone else required by business logic), it's a valid target for installation. In a TUF setting, this would be the final authority on installation; once a package is signed by the right keys, it is possible to install.
This isn't ideal for the automotive world, however. An automaker likely wouldn't want their suppliers to have absolute authority over the installation of new software on vehicles, for example. It would be possible to set up the signing authority so that the final signature needs to come from the automaker, but that has its own drawbacks. Uptane adds a new role, to address this problem. There is now a new repository called the director, which has the authority to decide which combinations of targets (called a *bundle*) can be installed on vehicles. This is managed with online keys, letting the director flexibly permit software updates to be installed while maintaining the security of having the supplied software (the targets) signed with offline keys. It is only when the director and the targets both agree that update bundles are permitted to be installed.
Client side security
On the client side, the vehicle communicates with the director repository to get its instructions about what software/firmware/data packages it should have installed. When it receives its instructions from the director, it downloads the packages in the bundle, each containing their own metadata. But before any update can be installed, several verification steps have to happen. First, the primary ECU in the vehicle (the one that downloads the updates initially) verifies the entire package, making sure that all of the signatures are valid. This includes checking that the metadata it received from the director matches the metadata it got in the packages, and checking to make sure that the signatures from the suppliers are valid.
If (and only if) everything passes muster, updates get sent from the primary ECU on to their final destinations, the secondary ECUs. Secondary ECUs are any ECUs that don't have a direct internet connection themselves. Under Uptane, however, secondary ECUs aren't allowed to trust that the updates they receive are safe; this is because of the possibility that an attacker might have compromised an internal communication bus in the vehicle, letting it impersonate the primary ECU. Secondary ECUs that are safety critical perform the same exhaustive verification steps that the primary ECU does before they install anything. For resource-limited ECUs that aren't safety critical, there is also the option of performing only a partial verification; in this case, the ECU checks only the signatures from the director. (This process is much faster, since the full verification requires checking the validity of the entire update bundle, each piece of which might have a long chain of delegated keys.)
In this way, in-car electronic systems can be updated over the air with confidence. Any attack on the system requires an attacker to have man-in-the-middle capabilities alongside compromised keys. Attacks on safety-critical systems aren't possible unless the attacker has somehow compromised multiple offline and online keys and has the capability to execute a man-in-the-middle attack.