Uptane Standard for Design and Implementation v.1.1.0
uptane-standard-design
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.
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.
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.
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
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]
A standards document that can guide the safe design, integration, and deployment of Uptane in vehicles is needed at this time because:
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:
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.
The following use cases provide a number of scenarios illustrating the manner in which software updates could be accomplished using Uptane.
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:
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.
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.
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:
The following topics will not be addressed in this document, as they represent threats outside the scope of Uptane:
The design requirements for this document are governed by the following principal parameters:
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).
We assume that attackers may want to achieve one or more of the following goals, in increasing order of severity:
Uptane is designed with resilience to compromise in mind. We assume that attackers may develop one or more of the following capabilities:
Uptane’s threat model includes the following types of attacks, organized according to the attacker goals listed in Section 4.1.
An attacker seeking to deny the installation of updates may attempt one or more of the following strategies:
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:
Full control of a vehicle, or one or more ECUs within a vehicle, is the most severe threat.
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:
A repository contains images and metadata. Each role has a particular type of metadata associated with it, as described in Section 5.2.
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.
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 5.2.3.2.
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.
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.
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.
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.
Every public key MUST be represented using a public key identifier. A public key identifier is EITHER all of the following:
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:
The payload differs depending on the role. However, the payload for all roles shares a common structure. It SHALL contain the following four attributes:
The following sections describe the role-specific metadata. All roles SHALL follow the common structures described here.
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:
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 5.4.4.7.
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:
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.
The following information is CONDITIONALLY REQUIRED for each image on the Director repository IF that image is encrypted:
The following information MUST be provided from the Director repository for each image in the Targets metadata:
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.
A Targets metadata file on the Image repository (but not the Director repository) MUST be able to delegate signing authority to other entities. For example, it could delegate signing authority for a particular ECU’s firmware to that ECU’s supplier. A metadata file MAY contain any number of delegations and MUST keep the delegations in prioritized order.
Any metadata file with delegations MUST provide the following information:
Note that any Targets metadata file stored on the Image repository may contain delegations, and these delegations can be in chains of arbitrary length.
The Snapshot metadata lists version numbers and filenames of all Targets metadata files. It protects against mix-and-match attacks if a delegated supplier key is compromised.
For each Targets metadata file on the repository, the Snapshot metadata SHALL contain the following information:
The Snapshot metadata MAY also list the Root metadata filename and version number for the purpose of backward compatibility. Historically, this was a requirement in TUF, but it is no longer required and does not provide a significant security benefit.
The Timestamp metadata SHALL contain the following information:
As described in the introduction to Section 5, Uptane requires a Director repository and an Image repository. However, it is possible to have an Uptane-compliant implementation that has more than two repositories.
Repository mapping metadata informs a Primary ECU about which repositories to trust for images or image paths. [TAP-4] describes how to make use of more complex repository mapping metadata in order to have more than the two required repositories.
Repository mapping metadata, or the equivalent informational content, MUST be present on all Primary ECUs, and MUST contain the following information:
For example, in the most basic Uptane case, the repository mapping metadata would contain:
Note that the metadata need not be in the form of a metadata file. For example, in the basic case where there is only one Director and one Image repository, and all images need to have signed metadata from both repositories, it would be sufficient to have a configuration file with URLs for the two repositories and a client that always checks for metadata matches between them. In this case, no explicit mapping would be defined, because the mapping is defined as part of the Uptane client implementation.
The Uptane Deployment Best Practices document ([DEPLOY]) provides more guidance on how to implement repository mapping metadata for more complex use cases. It also discusses strategies for updating repository mapping metadata, if required.
There is a difference between the filename in a metadata file or an ECU, and the filename on a repository. This difference exists in order to avoid race conditions, where metadata and images are read from, and written to, at the same time. For more details, the reader should read the TUF specification [TUF-spec] and PEP 458 [PEP-458].
Unless stated otherwise, all files SHALL be written to repositories in accordance with the following two rules:
For example:
An Uptane implementation SHALL make the following services available to vehicles:
Additionally, an Uptane implementation requires ECUs to have a secure way to know the current time.
The Image repository exists to allow an OEM and/or its suppliers to upload images and their associated metadata. It makes these images and their metadata available to vehicles. The Image repository is designed to be primarily controlled by human actors, and updated relatively infrequently.
The Image repository SHALL expose an interface permitting the download of metadata and images. This interface SHOULD be public.
The Image repository SHALL require authorization for writing metadata and images.
The Image repository SHALL provide a method for authorized users to upload images and their associated metadata. It SHALL check that a user writing metadata and images is authorized to do so for that specific image by checking the chain of delegations as described in Section 5.2.3.2.
The Image repository SHALL implement storage which permits authorized users to write an image file using a unique filename, and later read the same file using the same name. It MAY use any filesystem, key-value store, or database that fulfills this requirement.
The Image repository MAY require authentication for read access.
The Director repository instructs ECUs as to which images should be installed by producing signed metadata on demand. Unlike the Image repository, it is mostly controlled by automated, online processes. It also consults a private inventory database containing information on vehicles, ECUs, and software revisions.
The Director repository SHALL expose an interface for Primaries to upload vehicle version manifests (Section 5.4.2.1.1) and download metadata. This interface SHOULD be public. The Director MAY encrypt images for ECUs that require them, either by encrypting on-the-fly or by storing encrypted images on the repository.
The Director repository SHALL implement storage which permits an automated service to write generated metadata files. It MAY use any filesystem, key-value store, or database that fulfills this requirement.
A Director repository MUST conform to the following six-step process for directing the installation of software images on a vehicle.
The Director SHALL use a private inventory database to store information about ECUs and vehicles. An implementer MAY use any durable database for this purpose.
The inventory database MUST record the following pieces of information:
The inventory database MAY record other information about ECUs and vehicles. It SHOULD record a hardware identifier for each ECU to protect against the possibility of directing the ECU to install incompatible firmware.
An Uptane-compliant ECU SHALL be able to download and verify image metadata and image binaries before installing a new image and MUST have a secure way of verifying the current time, or a sufficiently recent attestation of the time.
All ECUs SHOULD monitor the download speed of image metadata and image binaries to detect and respond to a slow retrieval attack. If the download is slower than a pre-defined threshold, the ECU SHOULD send an alert to the Director repository, for example as part of the next vehicle version manifest.
Each ECU receiving over-the-air updates in a vehicle is either a Primary or a Secondary ECU. A Primary ECU collects and delivers vehicle manifests to the Director (Section 5.4.2.1.1) that contain information about which images have been installed on ECUs in the vehicle. It also verifies the time and downloads and verifies the latest metadata and images for itself and for its Secondaries. A Secondary ECU verifies the time, and downloads and verifies the latest metadata and images for itself from its associated Primary ECU. It also sends signed information about its installed images to its associated Primary.
All ECUs MUST verify image metadata as specified in Section 5.4.4 before installing an image or making it available to other ECUs. A Primary ECU MUST perform full verification (Section 5.4.4.2). A Secondary ECU SHOULD perform full verification if possible. If a Secondary cannot perform full verification, it SHALL, at the very least, perform partial verification. In addition, it MAY also perform some steps from the full verification process. See the Uptane Deployment Best Practices document ([DEPLOY]) for a discussion of how to choose between partial and full verification.
ECUs MUST have a secure source of time. An OEM/Uptane implementer MAY use any external source of time that is demonstrably secure. The Uptane Deployment Best Practices document ([DEPLOY]) describes one way to implement an external time server to cryptographically attest time, as well as the security properties required.
For an ECU to be capable of receiving Uptane-secured updates, it MUST have the following data provisioned at the time it is manufactured or installed in the vehicle:
A Primary downloads, verifies, and distributes the latest time, metadata, and images. To do so, it SHALL perform the following seven steps:
Note that the subsequent sections concerning requirements for a Primary do not prohibit implementing Primary capabilities on an ECU that does not communicate directly with the Uptane repositories. This allows for implementations to have multiple ECUs within the vehicle performing functions equivalent to a Primary. If multiple such Primaries are included within a vehicle, each Secondary ECU SHALL have a single Primary responsible for providing its updates.
The Primary SHALL build a vehicle version manifest as described in Section 5.4.2.1.1.
Once the complete manifest is built, the Primary MAY send the manifest to the Director repository. However, it is not strictly required that the Primary send the manifest until step three. If permitted by the implementation, a Primary MAY send only a diff of the manifest to save bandwidth. If an implementation permits diffs, the Director SHOULD have a way to request a full manifest.
Secondaries MAY send their version report at any time so that it is already stored on the Primary when it wishes to check for updates. Alternatively, the Primary MAY request a version report from each Secondary at the time of the update check.
The vehicle version manifest is a metadata structure that MUST contain the following information:
Note that one of the ECU version reports should be the version report for the Primary itself.
An ECU version report is a metadata structure that MUST contain the following information:
The Primary SHALL load the current time from a secure source.
The Primary SHALL download metadata for all targets and perform a full verification on it as specified in Section 5.4.4.2.
The Primary SHALL download and verify images for itself and for all of its associated Secondaries. Images SHALL be verified by checking that the hash of the image file matches the hash specified in the Director’s Targets metadata for that image.
There may be several different filenames that all refer to the same image binary, as described in Section 5.2.7. If the Primary has received multiple hashes for a given image binary via the Targets role (see Section 5.2.3.1) then it SHALL verify every hash for this image even though the image is identified by a single hash as part of its filename.
Unless the Secondary ECU has its own way of verifying the time or does not have the capacity to verify a time message, the Primary is CONDITIONALLY REQUIRED to send the time to each ECU. The Secondary will verify the time message, then overwrite its current time with the received time.
The Primary SHALL send its latest downloaded metadata to all of its associated Secondaries. The metadata it sends to each Secondary MUST include all of the metadata required for verification on that Secondary. For full verification Secondaries, this includes the metadata for all four roles from both repositories, plus any delegated Targets metadata files the Secondary will recurse through to find the proper delegation. For partial verification Secondaries, this MAY include fewer metadata files; at a minimum, it includes only the Targets metadata file from the Director repository.
The Primary SHOULD determine the minimal set of metadata files to send to each Secondary by performing delegation resolution as described in Section 5.4.4.2.
Each Secondary SHALL store the latest copy of all metadata required for its own verification.
The Primary SHALL send the latest image to each of its associated Secondaries that have storage to receive it.
For Secondaries without storage, the Primary SHOULD wait for a request from the Secondary to stream the new image file to it. The Secondary will send the request once it has verified the metadata sent in the previous step.
An ECU SHALL perform the following steps when attempting to install a new image:
IF the ECU has the capability to verify a time message, the ECU is CONDITIONALLY REQUIRED to load and verify the current time, or the most recent securely attested time.
The ECU SHALL verify the latest downloaded metadata (Section 5.4.4) using either full or partial verification. If the metadata verification fails for any reason, the ECU SHALL jump to the final step (Section 5.4.3.6).
If the ECU does not have secondary storage, i.e., buffer storage to temporarily store the latest image before installing it, it SHALL download the latest image from the Primary. (If the ECU has secondary storage, it will already have the latest image in its secondary storage as specified in Section 5.4.2.7, and should skip to the next step.) The ECU MAY first create a backup of its previous working image and store it elsewhere (e.g., the Primary).
The filename used to identify the latest known image (i.e., the file to request from the Primary) SHALL be determined as follows:
When the Primary responds to the download request, the ECU SHALL overwrite its current image with the downloaded image from the Primary.
If any part of this step fails, the ECU SHALL jump to the final step (Section 5.4.3.6).
The ECU SHALL verify that the latest image matches the latest metadata as follows:
If the ECU has secondary storage, the checks SHOULD be performed on the image in secondary storage before it is installed.
When checking hashes, the ECU SHOULD additionally check that the length of the image matches the length listed in the metadata.
NOTE: Verifying image size along with the hashes will become a requirement in a future version of the Uptane Standard.
NOTE: See [DEPLOY] for guidance on how to deal with Secondary ECU failures for ECUs that do not have secondary storage.
If any step fails, the ECU SHALL jump to the final step (Section 5.4.3.6).
The ECU SHALL attempt to install the update. This installation SHOULD occur at a time when all pre-conditions are met. These pre-conditions MAY include ensuring the vehicle is in a safe environment for install (e.g., the vehicle is parked when updating a specific ECU). Another pre-condition MAY include ensuring the ECU has a backup of its current image and metadata in case the current installation fails.
The ECU SHALL create a version report as described in Section 5.4.2.1.2, and send it to the Primary (or simply save it to disk, if the ECU is a Primary). The Primary SHOULD write the version reports it receives to disk and associate them with the Secondaries that sent them.
A Primary ECU MUST perform full verification of metadata. A Secondary ECU SHOULD perform full verification of metadata. If a Secondary cannot perform full verification, it SHALL, at the very least, perform partial verification.
If a step in the following workflows does not succeed (e.g., the update is aborted because a new metadata file was not signed), an ECU SHOULD still be able to update again in the future. Errors raised during the update process SHOULD NOT leave ECUs in an unrecoverable state.
In order to perform partial verification, an ECU SHALL perform the following steps:
Note that this verification procedure is the smallest set of Uptane checks permissible for an Uptane Secondary ECU. An ECU MAY additionally implement more metadata checks.
For example, an ECU MAY also fetch and verify Root metadata from the Director (following the procedure in Section 5.4.4.3) before checking Targets metadata. Performing this additional check would provide the ECU with a secure way to receive and validate a rotation of the Director’s Targets key.
See [DEPLOY] for more discussion on this topic.
Full verification of metadata means that the ECU checks that the Targets metadata about images from the Director repository matches the Targets metadata about the same images from the Image repository. This provides resilience to a key compromise in the system.
Full verification MUST be performed by Primary ECUs and SHOULD be performed by Secondary ECUs. In the following instructions, whenever an ECU is directed to download metadata, it applies only to Primary ECUs.
Before starting full verification, the repository mapping metadata MUST be consulted to determine where to download metadata from. This procedure assumes the basic Uptane case: there are only two repositories (Director and Image), and all image paths are required to be signed by both repositories. If a more complex repository layout is being used, refer to [DEPLOY] for guidance on how to determine where metadata should be downloaded from.
In order to perform full verification, an ECU SHALL perform the following steps:
If any step fails, the ECU MUST return an error code indicating the failure. If a check for a specific type of security attack fails (i.e., rollback, freeze, arbitrary software, etc.), the ECU SHOULD return an error code that indicates the type of attack.
To properly check Root metadata, an ECU SHOULD:
To properly check Timestamp metadata, an ECU SHOULD:
To properly check Snapshot metadata, an ECU SHOULD:
To properly check Targets metadata, an ECU SHOULD:
To properly check Targets metadata for an image, an ECU MUST locate the metadata file(s) for the role (or roles) that have the authority to sign the image. This metadata might be located in the top-level Targets metadata, but it also may be delegated to another role or to multiple roles. Therefore, all delegations MUST be resolved using the following recursive procedure, beginning with the top-level Targets metadata file.
It is possible to delegate signing authority to multiple delegated roles as described in [TAP-3]. Each multi-role delegation effectively contains a list of ordinary delegations, plus a threshold of those roles that must be in agreement about the non-custom metadata for the image. All multi-role delegations MUST be resolved using the following procedure. Note that there may be sub-delegations inside multi-role delegations.
[CR-OTA] | Barry, K., "Automakers Embrace Over-the-Air Updates, but Can We Trust Digital Car Repair?", April 2018. |
[DEPLOY] | Members of the Uptane Community, ., "Uptane Deployment Best Practices", n.d.. |
[IN-TOTO] | "in-toto: A framework to secure the integrity of software supply chains", October 2018. |
[MERCURY] | Kuppusamy, T., Diaz, V. and J. Cappos, "Mercury: Bandwidth-Effective Prevention of Rollback Attacks Against Community Repositories", ISBN 978-1-931971-38-6, July 2017. |
[PEP-458] | Kuppusamy, T., Diaz, V., Stufft, D. and J. Cappos, "PEP 458 -- Surviving a Compromise of PyPI", September 2013. |
[UPTANEESCAR] | Kuppusamy, T., Brown, A., Awwad, S., McCoy, D., Bielawski, R., Mott, C., Lauzon, S., Weimerskirch, A. and J. Cappos, "Securing Software Updates for Automobiles", October 2016. |
[USATODAY] | O'Donnell, B., "Your average car is a lot more code-driven than you think", June 2016. |