Uptane Standard for Design and Implementation v.1.1.0
This document describes a framework for securing ground vehicle software update systems.
Uptane is a secure software update framework for ground vehicles. This document describes procedures to enable programmers for OEMs and suppliers to securely design and implement this framework in a manner that better protects connected units on ground vehicles. Integrating Uptane as outlined in the sections that follow can reduce the ability of attackers to compromise critical systems. It also assures a faster and easier recovery process should a compromise occur.
These instructions specify the components necessary for a compliant implementation. Individual implementers can make their own technological choices within those requirements. This flexibility makes Uptane adaptable to the many customized update solutions used by manufacturers. If implementers wish to have compatible formats, they may use POUFs. POUFs contain a description of implementation choices as well as data binding formats. An implementer who adopts a POUF, as well as the Uptane Standard, will be able to interoperate with other implementations using that POUF.
2.1. Conformance terminology
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in [RFC2119].
In order to be considered Uptane-compliant, an implementation MUST follow all of these rules as specified in the document.
Bundle: A set of images released by the repository that is meant to be installed by one or more ECUs on a vehicle during the same update cycle.
Bus: An internal communications network that interconnects components within a vehicle. A vehicle can have a number of buses that will vary in terms of power, speed, and resources.
ECU Identifier: An attribute used to identify a specific ECU (e.g., a unique serial number).
ECU Version Manifest: Metadata which details the software version currently installed on the ECU.
Hardware Identifier: An attribute used to identify a model of an ECU.
Image: File containing software for an ECU to install. May contain a binary image to flash, installation instructions, and other necessary information for the ECU to properly apply the update. Each ECU typically holds only one image, although this may vary in some cases.
Metadata: Information describing the characteristics of data including, for example, structural metadata describing data structures (e.g., data format, syntax, and semantics) and descriptive metadata describing data contents (e.g., information security labels). As used in Uptane, metadata can be described as information associated with a role or an image that contains the characteristics or parameters thereof (e.g., cryptographic material parameters, filenames, and versions.)
Primary/Secondary ECUs: Terms used to describe the control units within a ground vehicle. A Primary ECU downloads and verifies update images and metadata for itself and for Secondary ECUs, and distributes images and metadata to Secondaries. Thus, it requires extra storage space and a means to download images and metadata. Secondary ECUs receive their update images and metadata from the Primary, and only need to verify and install their own metadata and images.
POUF: A document that contains the protocol, operations, usage, and formats (POUF) of a specific Uptane implementation. The POUF contains decisions about SHOULDs and MAYs in an implementation, as well as descriptions of data binding formats. POUFs MAY be used to create compatible Uptane implementations.
Repository: A server containing metadata about images. May also contain the images themselves. Other data may be stored on the repository to be accessed by ECUs during the update process.
Suppliers: Independent companies to which vehicle manufacturers may outsource the production of ECUs. Tier-1 suppliers directly serve the manufacturers. Tier-2 suppliers are those that perform outsourced work for Tier-1 suppliers.
Vehicle Version Manifest: A compilation of all ECU version reports on a vehicle. It serves as a master list of all images currently running on all ECUs in the vehicle.
2.3. Uptane role terminology
These terms are defined in greater detail in Section 5.1.
Delegation: A process by which the responsibility of signing metadata about images is assigned to another party. Role: A party (human or machine) responsible for signing a certain type of metadata. The role controls keys and is responsible for signing metadata entrusted to it with these keys. The roles mechanism of Uptane allows the system to distribute signing responsibilities so that the compromise of one key does not necessarily impact the security of the entire system.
- Root role: Signs metadata that distributes and revokes public keys used to verify the Root, Timestamp, Snapshot, and Targets role metadata.
- Snapshot role: Signs metadata that indicates which images the repository has released at the same time.
- Targets role: Signs metadata used to verify the image, such as cryptographic hashes and file size.
- Timestamp role: Signs metadata that indicates if there are any new metadata or images on the repository.
2.4. Acronyms and abbreviations
CDN: Content Delivery Network
ECUs: Electronic Control Units, the computing units on a vehicle
LIN Bus: Local Interconnect Bus
OBD: On-board diagnostics
SOTA: Software Updates Over-the-Air
UDS: Unified Diagnostic Services
VIN: Vehicle Identification Number
3. Rationale for and scope of the Uptane Standard
This Standard document provides the essential components for the secure design, implementation, and deployment of Uptane by OEMs and suppliers. These guidelines contribute to compromise resilience, or the ability to minimize the extent of the threat posed by any given attack.
However, this specification is intended as an implementation guide, and not as a detailed technical argument about the security properties that Uptane provides. Readers interested in such documentation should refer to published papers that cover this topic. [UPTANEESCAR]
3.1. Why Uptane requires a standards document
A standards document that can guide the safe design, integration, and deployment of Uptane in vehicles is needed at this time because:
- The number of connected units on the average vehicle continues to grow, with mainstream cars now containing up to 100 million lines of code. [USATODAY]
- The expanded use of software over-the-air strategies creates new attack surfaces for malicious parties. [CR-OTA]
- Legacy update strategies, such as SSL/TLS or GPG/RSA, are not feasible for use on vehicle ECUs because they force manufacturers to chose between enhanced security and customizability.
- Conventional strategies are also complicated by the differing resources of the ECUs, which can vary greatly in memory, storage space, and Internet connectivity.
- The design of Uptane makes it possible to offer improved design flexibility without sacrificing security.
- This added design flexibility, however, could be a liability if the framework is implemented incorrectly.
- Standardization of crucial steps in the design, implementation, and use of Uptane can assure that customizability does not impact security or functionality.
3.2. Scope of Standard coverage
This document sets guidelines for implementing Uptane in most systems capable of updating software on connected units in ground vehicles, including passenger vehicles, light-duty trucks, heavy-duty trucks, and motorcycles. Uptane could potentially also be applied to other ground vehicles, such as automated shuttles, recreational vehicles, and military ground vehicles. Uptane could even be applied to domains such as IoT devices, medical devices, and autonomous aerial vehicles. In this section, we define the scope of that applicability by providing sample use cases and possible exceptions, aspects of software update security that are not applicable to Uptane, and the design requirements governing the preparation of these standards.
We assume the following system preconditions for Uptane:
- Vehicles have the ability to establish connectivity to required backend services. For example, this could be done through cellular, Wi-Fi, or hard-wired mechanisms.
- ECUs are either directly connected to the communication channel, or are indirectly connected via some sort of network gateway.
- ECUs are programmable and provide sufficient performance to be updated.
- ECUs must be able to perform public key cryptography operations and calculate hashes of images and metadata files.
- There are state-of-the-art secure servers in place, such as the Director and Image repository servers.
It is important that any bugs detected in Uptane implementations be patched promptly. Failure to do so could interfere with the effectiveness of Uptane’s operations.
3.2.2. Use cases
The following use cases provide a number of scenarios illustrating the manner in which software updates could be accomplished using Uptane.
184.108.40.206. OEMs initializing Uptane at the factory using SOTA
An OEM plans to install Uptane on new vehicles. This entails the following components: code to perform full and partial verification, the latest copy of the relevant metadata, the public keys, and an accurate attestation of the latest time. The OEM then either requires its tier-1 suppliers to provide these materials to the suppliers’ assembly lines or can choose to add the materials later at the OEM’s assembly lines. The OEM’s in-vehicle implementation is Uptane-compliant if:
- all Primaries perform full verification;
- all Secondaries that are updated via OTA at least perform partial verification; and
- all other ECUs that do not perform any type of verification cannot be updated via OTA.
220.127.116.11. Updating one ECU with a complete image
A tier-1 supplier completes work on a revised image for an electronic brake control module. This module will control the brakes on all models of an SUV produced by the OEM mentioned above. Assuming supplier delegation is supported by the OEM for this ECU, each tier-1 supplier digitally signs the image, then delivers the signature, all of its metadata, including delegations, and associated images to the OEM. The OEM adds these metadata and images to its Image repository, along with information about any dependencies and conflicts between this image and those for other ECUs used in the OEM’s vehicles. The OEM also updates the inventory database, so that the Director repository can instruct the ECU on how to install these updated images.
18.104.22.168. Updating individual ECUs on demand
An OEM has issued a recall to address a problem with a keyless entry device that has been locking people out of their cars. The OEM prepares an updated flash image in the manner described above. The OEM then ships USB flash drives to vehicle owners and dealerships that allow those parties to update the firmware of their vehicles.
22.214.171.124. Update one ECU with multiple deltas
The OEM wants to use delta updates to save over-the-air bytes. The delta images contain only the code and/or data that has changed from the previous image version. To do so, the OEM must first modify the Director repository, using the vehicle version manifest and dependency resolution to determine the differences between the previous and latest images. The OEM then adds the following to the custom Targets metadata used by the Director repository: (1) the algorithm used to apply a delta image, and (2) the Targets metadata about the delta image. The OEM will also check whether the delta images match the Targets metadata from the Director repository.
There are a number of factors that could impede the completion of the above scenarios:
- ECUs may be lacking the necessary resources to function as designated. These insufficient resources could include limited CPU or RAM inadequate for performance of public key cryptography; a lack of sufficient storage to undo installation of bad software; or a location on a low-speed network (e.g., LIN).
- ECUs may reside on different network segments, and may not be able to directly reach each other, requiring a gateway to facilitate communication.
- A user may replace OEM-installed ECUs with aftermarket ECUs.
- A vehicle may be able to download only a limited amount of data via a cellular channel due to limits on a data plan.
- A system may lack sufficient power to download or install software updates.
- Vehicles may be offline for extended periods of time, thus missing required updates (e.g., key rotations).
- OEMs may be unwilling to implement costly security or hardware requirements.
3.4. Out of scope
The following topics will not be addressed in this document, as they represent threats outside the scope of Uptane:
- Physical attacks, such as manual tampering with ECUs outside the vehicle.
- Compromise of the packaged software, such as malware embedded in a trusted package.
- Compromise of the supply chain (e.g., build system, version control system, packaging process). A number of strategies (e.g., git signing, TPMs, in-toto [IN-TOTO]) already exist to address this problem. Therefore, there is no need to duplicate those techniques here.
- Problems associated with OBD or UDS programming of ECUs, such as authentication of communications between ECUs.
- Malicious mirrors of package repositories, which may substitute original packages with malicious packages with matching version numbers [MERCURY].
3.5. Design requirements
The design requirements for this document are governed by the following principal parameters:
- to clearly mandate the design and implementation steps that are security critical and must be followed as is, while offering flexibility in the implementation of non-critical steps. In this manner, users can adapt to support different use models and deployment scenarios.
- to ensure that, if Uptane is implemented, the security practices mandated or suggested in this document do not interfere with the functionality of ECUs, vehicles, or the systems that maintain them.
- to delineate guidelines to ensure that, should any part of the SOTA mechanism of a vehicle be attacked, an attacker must compromise two or more modules to breach the SOTA mechanism.
4. Threat model and attack strategies
The overarching goal of Uptane is to provide a system that is resilient in the face of various types of compromise. In this section, we describe the goals an attacker may have (Section 4.1) and the capabilities they may have or could develop (Section 4.2). We then describe and classify types of attacks on the system according to the attacker’s goals (Section 4.3).
4.1. Attacker goals
We assume that attackers may want to achieve one or more of the following goals, in increasing order of severity:
- Read the contents of updates to discover confidential information, reverse-engineer firmware, or compare two firmware images to identify security fixes and hence determine the fixed security vulnerability.
- Deny installation of updates to prevent vehicles from fixing software problems.
- Cause one or more ECUs in the vehicle to fail, denying use of the vehicle or of certain functions.
- Control ECUs within the vehicle, and possibly the vehicle itself.
4.2. Attacker capabilities
Uptane is designed with resilience to compromise in mind. We assume that attackers may develop one or more of the following capabilities:
- Intercept and modify network traffic (i.e., perform man-in-the-middle attacks). This capability may be developed in two domains:
- Outside the vehicle, intercepting and modifying traffic between the vehicle and software repositories.
- Inside the vehicle, intercepting and modifying traffic on one or more vehicle buses (e.g., via an OBD port or using a compromised ECU as a vector).
- Compromise and control either a Director repository or Image repository server, and any keys stored on that repository, but not both the Director and Image repositories.
- Compromise either a Primary ECU or a Secondary ECU, but not both in the same vehicle.
4.3. Description of threats
Uptane’s threat model includes the following types of attacks, organized according to the attacker goals listed in Section 4.1.
4.3.1. Read updates
- Eavesdrop attack: Read sensitive or confidential information from an update intended to be encrypted for a specific ECU. (Note: Not all implementations will have a need for protecting information in this way.)
4.3.2. Deny installation of updates
An attacker seeking to deny the installation of updates may attempt one or more of the following strategies:
- Drop-request attack: Block network traffic outside or inside the vehicle.
- Slow retrieval attack: Slow down network traffic, in the extreme case sending barely enough packets to avoid a timeout. Similar to a drop-request attack, except that both the sender and receiver of the traffic still think network traffic is unimpeded.
- Freeze attack: Continue to send a properly signed, but old, update bundle to the ECUs, even if newer updates exist.
- Partial bundle installation attack: Install a valid (signed) update bundle, and then block selected updates within the bundle.
- Conduct a denial of service attack against the Uptane repositories or infrastructure.
4.3.3. Interfere with ECU functionality
Attackers seeking to interfere with the functionality of vehicle ECUs in order to cause an operational failure or unexpected behavior may do so in one of the following ways:
- Rollback attack: Cause an ECU to install a previously valid software revision that is older than the currently installed version.
- Endless data attack: Send a large amount of data to an ECU until it runs out of storage, possibly causing the ECU to fail to operate.
- Mix-and-match attack: Install a malicious software bundle in which some of the updates do not interoperate properly. This may be accomplished even if all of the individual images being installed are valid, as long as valid versions exist that are mutually incompatible.
4.3.4. Control an ECU or vehicle
Full control of a vehicle, or one or more ECUs within a vehicle, is the most severe threat.
- Arbitrary software attack: Cause an ECU to install and run arbitrary code of the attacker’s choice.
5. Detailed design of Uptane
Uptane does not specify implementation details. Instead, this Standard describes the components necessary for a compliant implementation and leaves it up to individual implementers to make their own technological choices within those requirements.
At a high level, Uptane requires:
- Two software repositories:
- An Image repository containing binary images to install and signed metadata about those images.
- A Director repository connected to an inventory database that can sign metadata on demand for images in the Image repository.
- Repository tools for generating Uptane-specific metadata about images.
- A public key infrastructure supporting the required metadata production and signing roles on each repository:
- Root - The certificate authority for the Uptane ecosystem. Distributes public keys for verifying all the other roles’ metadata.
- Timestamp - Indicates whether there are new metadata or images.
- Snapshot - Indicates images released by the repository at a point in time via signing metadata about Targets metadata.
- Targets - Indicates metadata about images, such as hashes and file sizes.
- A secure way for ECUs to know the time.
- An ECU capable of downloading images and associated metadata from the Uptane servers.
- An in-vehicle client on a Primary ECU capable of verifying the signatures on all update metadata and downloading updates on behalf of its associated Secondary ECUs. The Primary ECU MAY be the same ECU that communicates with the server.
- A client or library on each Secondary ECU capable of performing either full or partial verification of metadata.
5.1. Roles on repositories
A repository contains images and metadata. Each role has a particular type of metadata associated with it, as described in Section 5.2.
5.1.1. The Root role
A repository’s Root role SHALL be responsible for a Certificate Authority as defined in [RFC3647]. A repository’s Root role SHALL produce and sign Root metadata as described in Section 5.2.2. A repository’s Root role SHALL sign the public keys used to verify the metadata produced by the Timestamp, Snapshot, and Targets roles. A repository’s Root role SHALL revoke keys for the other roles if they are compromised.
5.1.2. The Targets role
A repository’s Targets role SHALL produce and sign metadata about images and delegations as described in Section 5.2.3.
The Targets role on the Image repository MAY delegate the responsibility of signing metadata to other, custom-defined roles referred to as delegated targets. If it does, it MUST do so as specified in Section 126.96.36.199.
Responsibility for signing images or a subset of images MAY be delegated to more than one role and therefore it is possible for two different roles to be trusted for signing a particular image. For this reason, delegations MUST be prioritized.
A particular delegation for a subset of images MAY be designated as terminating. For terminating delegations, the client SHALL NOT search any further if it does not find validly signed metadata about those images. Delegations SHOULD NOT be terminating by default; terminating delegations SHOULD only be used when there is a compelling technical reason to do so.
A delegation for a subset of images MAY be a multi-role delegation [TAP-3]. A multi-role delegation indicates that multiple roles are needed to sign a particular image and each of the delegatee roles MUST sign the same metadata.
Delegations only apply to the Image repository. The Targets role on the Director repository MUST NOT delegate metadata signing responsibility.
5.1.3. The Snapshot role
A repository’s Snapshot role SHALL produce and sign metadata about all Targets metadata the repository releases, including the current version number of the top-level Targets metadata, and the version numbers of all delegated Targets metadata, as described in Section 5.2.4.
5.1.4. The Timestamp role
A repository’s Timestamp role SHALL produce and sign metadata indicating whether there are new metadata or images on the repository. It MUST do so by signing the metadata about the Snapshot metadata file.
5.2. Metadata structures
Uptane’s security guarantees all rely on properly created metadata that follows a designated structure. The Uptane Standard does not mandate any particular format or encoding for the metadata as a whole. ASN.1 (with any encoding scheme like BER, DER, XER, etc.), JSON, XML, or any other encoding format that is capable of providing the required structure MAY be used.
However, string comparison is required as part of metadata verification. To ensure an accurate basis for comparing strings, all strings MUST be encoded in the Unicode Format for Network Interchange as defined in [RFC5198], including normalization into Unicode Normalization Form C ([NFC]).
In the Deployment Best Practices ([DEPLOY]), Joint Development Foundation Projects, LLC, Uptane Series provides some examples of compliant metadata structures in ASN.1 and JSON.
5.2.1. Common metadata structures
Every public key MUST be represented using a public key identifier. A public key identifier is EITHER all of the following:
- The value of the public key itself (which MAY be, for example, formatted as a PEM string)
- The public key cryptographic algorithm used by the key (such as RSA or ECDSA)
- The particular scheme used to verify the signature (such as rsassa-pss-sha256 or ecdsa-sha2-nistp256)
OR a secure hash over at least the above components (such as the keyid mechanism in TUF).
All four Uptane roles (Root, Targets, Snapshot, and Timestamp) share a common structure. They SHALL contain the following two attributes:
- A payload of metadata to be signed
- An attribute containing the signature(s) of the payload, where each entry specifies:
- The public key identifier of the key being used to sign the payload
- A signature with this key over the payload
The payload differs depending on the role. However, the payload for all roles shares a common structure. It SHALL contain the following four attributes:
- An indicator of the type of role (Root, Targets, Snapshot, or Timestamp)
- An expiration date and time
- An integer version number, which SHOULD be incremented each time the metadata file is updated
- The role-specific metadata for the role indicated
The following sections describe the role-specific metadata. All roles SHALL follow the common structures described here.
5.2.2. Root metadata
A repository’s Root metadata distributes the public keys of the top-level Root, Targets, Snapshot, and Timestamp roles, as well as revocations of those keys. It SHALL contain two attributes:
- A representation of the public keys for all four roles. Each key SHALL have a unique public key identifier.
- An attribute mapping each role to (1) its public key(s), and (2) the threshold of signatures required for that role.
5.2.3. Targets metadata
The Targets metadata on a repository contains all of the information about images to be installed on ECUs. This includes filenames, hashes, file sizes, and MAY also include other useful information, such as what types of hardware are compatible with a particular image.
Targets metadata can also contain metadata about delegations, allowing one Targets role to delegate its authority to another. This means that an individual Targets metadata file might contain only metadata about delegations, only metadata about images, or some combination of the two. The details of how ECUs traverse the delegation tree to find valid metadata about images is specified in Section 188.8.131.52.
184.108.40.206. Metadata about images
To be available to install on clients, all images on the repository MUST have their metadata listed in a Targets role. Each Targets role MAY provide a list of some images on the repository. This list MUST provide, at a minimum, the following information about each image:
- The image filename
- The size of the image in bytes
- One or more hashes of the image file, along with the hashing function used
220.127.116.11.1. Custom metadata about images
In addition to the required metadata, Targets metadata files MAY contain extra metadata for images on the repository. This metadata can be customized for a particular use case. Examples of use cases for different types of custom metadata can be found in the Deployment Best Practices document ([DEPLOY]). However, there are a few important pieces of custom metadata that SHOULD be present in most implementations. In addition, there is one element in the custom metadata that MUST be present in the Targets metadata from the Director.
Custom metadata MAY also contain a demarcated field or section that MUST match whenever two pieces of metadata are checked against each other, such as when Targets metadata from the Director repository is checked against Targets metadata from the Image repository.
The information listed below SHOULD be provided for each image on both the Image repository and the Director repository. If a “MUST match section” is to be implemented, that is where this information SHOULD be placed.
- A release counter, to be incremented each time a new version of the image is released. This can be used to prevent rollback attacks even in cases where the Director repository is compromised.
- A hardware identifier, or list of hardware identifiers, representing models of ECUs with which the image is compatible. This can be used to ensure that an ECU cannot be ordered to install an incompatible image, even in cases where the Director repository is compromised.
The following information is CONDITIONALLY REQUIRED for each image on the Director repository IF that image is encrypted:
- Information about filenames, hashes, and file size of the encrypted image.
- Information about the encryption method, and other relevant information–for example, a symmetric encryption key encrypted by the ECU’s asymmetric key could be included in the Director repository metadata.
The following information MUST be provided from the Director repository for each image in the Targets metadata:
- An ECU identifier (such as a serial number), specifying the ECU that should install the image.
The Director repository MAY provide a download URL for the image file. This may be useful, for example, when the image is on a public CDN and the Director wishes to provide a signed URL.