Before testing the MUSTs and SHALLs described in the uptane standards, we should consider the following design requirements:
- 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.
- Implement or configure the Image Repository, Director Repository, Repository tools for generating Uptane-specific metadata about image, public key infrastructure (Root, Timestamp, Snapshot, Target),in-vehicle client on a Primary ECU ,and a client or library on each Secondary ECU
| Reference Number | Section | Control | Test Description |
|---|---|---|---|
| 5.1.1 | The Root Role | A repository’s Root role SHALL be responsible for a Certificate Authority | Verify if the Root role is Certificate Authority for the Uptane ecosystem as it distributes public keys for verifying all the other roles’ metadata |
| 5.1.1 | The Root Role | A repository’s Root role SHALL produce and sign Root metadata | Verify the metadata produced by the Root role |
| 5.1.1 | The Root Role | A repository’s Root role SHALL sign the public keys used to verify the metadata produced by the Timestamp, Snapshot, and Targets roles. | Verify if the Root role signs metadata that distributes and revokes public keys used to verify the root, timestamp, snapshot, and targets role metadata. |
| 5.1.1 | The Root Role | A repository’s Root role SHALL revoke keys for the other roles, in case of compromise. | Verify if the Root role has access to revoke keys for other roles, in case of a compromise |
| 5.1.2 | The Target's Role | A repository’s Targets role SHALL produce and sign metadata about images and delegations | Verify the metadata produced by the Target role and validate the signatures |
| 5.1.2.1 | Delegations | 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. | Conditional MUST: Verify for delegated targets. The delegated targets MUST provide the following information : (a)A list of public keys of all delegatees. Each key should have a unique public key identifier and a key type. (b) A list of the filenames to which this role applies (c) An optional list of the hardware identifiers to which this role applies. (d) An indicator of whether or not this is a terminating delegation (e) A list of the roles to which this delegation applies |
| 5.1.2.1 | Delegations | 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 | Verify if the delegations are prioritized |
| 5.1.2.1 | Delegations | 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. | Verify if there are terminating delegations |
| 5.1.2.1 | Delegations | 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. | Identify all multi-role delegation and check if each of the delegatee roles sign the same metadata |
| 5.1.2.1 | Delegations | Delegations only apply to the Image repository. The Targets role on the Director repository MUST NOT delegate metadata signing responsibility | Access to assign delegations in the Director Repository should be denied by default |
| 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 | Verify if the Snapshot Role signs metadata about all Targets metadata |
| 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 | Verify if the Timestamp role signs the metadata about the Snapshot metadata file and checks for new metadata or images on the repository |
| 5.2 | Metadata Structures | 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 | Verify if all strings are encoded in Unicode Format for Network Interchange |
| 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: (a) The value of the public key itself (b) The public key cryptographic algorithm (c) The particular scheme used to verify the signature. (d) OR a secure hash over at least the above components | Verify if every public key is represented using a public key identifier |
| 5.2.1 | Common Metadata Structures | All four Uptane roles (Root, Targets, Snapshot, and Timestamp) share a common structure. They SHALL contain the following two attributes: (a) A payload of metadata to be signed (b) 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 | Verify if all four Uptane roles (Root,Target,Snapshot, and Timestamp) contain the following attributes : (1) Payload of metadata to be signed (2) Signature of the Payload that included the Public Key Idetifier of the Key being used to sign the payload |
| 5.2.1 | Common Metadata Structures | The payload differs depending on the role. However, the payload for all roles shares a common structure. It SHALL contain the following four attributes : (1) An indicator of the type of role (2) An expiration date and time (3) An integer version number, which SHOULD be incremented each time the metadata file is updated, (4) The role-specific metadata for the role indicated | Identify the payloads for all four roles (Root,Target,Snapshot, and Timestamp) and check if the following attributes are present : (1) Type of role (2) Expiration date and time (3) Version Number (4) The role specific metadata |
| 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 | Verify the repository's root metadata, such that it contains the following attributes for all four Uptane roles : (1) Public keys with associated unique Public Key Identifier (2) An attribute mapping each role to its public key and the threshold of signatures required for that role |
| 5.2.3.1 | 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: (1) Image Filename (2) Size of the Image (3) One or more hashes of the image file, along with the hashing function used | (1) Verify if all images on the repository have their metadata listed in a Targets role to be available to install on clients (2)Verify if the Targets role provides a list of some images on the repository (3) If yes, does the list of images in the Targets role provides the following information about the images : (a) Image Filename (b) Size of the image (c) One or more hashes of the image file |
| 5.2.3.1.1 | Custom Metadata about Images | 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: (1) A release counter, to be incremented each time a new version of the image is released (2) A hardware identifier, or list of hardware identifiers, representing models of ECUs with which the image is compatible | In the Image Repository and the Director Repository verify if the following information pertaining to the Image is present : (1) A release counter, to be incremented each time a new version of the image is released (2) A hardware identifier, or list of hardware identifiers, representing models of ECUs with which the image is compatible. Take a few sample images and check for compatibility with the ECU's as per the organization's infrastructure design |
| 5.2.3.1.1 | Custom Metadata about Images | The following information MUST be provided for each image in the Targets metadata from the Director repository:An ECU identifier (such as a serial number), specifying the ECU that should install the image | In the Director Repository verify if an ECU Identifier is present for each image in the Targets metadata. Validate if the correct ECU identifier is mapped to the image in the Targets metadata |
| 5.2.3.2 | Metadata About Delegations | A metadata file MAY contain more than one delegation and MUST keep the delegations in prioritized order. | Verify if the delegations are maintained in the prioritized order for each metadata file and if the signatures are acquired as per the order |
| 5.2.3.2 | Metadata About Delegations | A list of delegations MUST provide the following information: (1) A list of public keys of all delegatees. Each key should have a unique public key identifier and a key type (2) A list of delegations, each of which contains: A list of the filenames to which this role applies, An optional list of the hardware identifiers to which this role applies, An indicator of whether or not this is a terminating delegation, A list of the roles to which this delegation applies (A name for the role , The key identifiers for each key this role uses, A threshold of keys that must sign for this role) | The delegated targets MUST provide the following information : (a) A list of public keys of all delegatees. Each key should have a unique public key identifier and a key type. (b) A list of the filenames to which this role applies © An optional list of the hardware identifiers to which this role applies. (d) An indicator of whether or not this is a terminating delegation (e) A list of the roles to which this delegation applies |
| 5.2.4 | Snapshot Metadata | For each Targets metadata file on the repository, the Snapshot metadata SHALL contain the following information: The filename and version number of each Target metadata file on the repository | Verify if the Snapshot metadata contains the filename and version number of each Target metadata file on the repository |
| 5.2.5 | Timestamp Metadata | The Timestamp metadata SHALL contain the following information: The filename and version number of the latest Snapshot metadata on the repository, One or more hashes of the Snapshot metadata file, along with the hashing function used. | Verify if the Timestamp metadata contains the filename and version number of the Snapshot metadata on the repository. Also, validate the hashing function used for the Snapshot metadata file by verifying one or more hashes. |
| 5.2.6 | Repository Mapping Metadata | Repository mapping metadata, or the equivalent informational content, MUST be present on all Primary ECUs, and MUST contain the following information: (1) A list of repository names and one or more URLs at which the named repository can be accessed. At a minimum, this MUST include the Director and Image repositories.(2) A list of mappings of image paths to repositories (A list of image paths, A list of repositories that MUST sign the Targets metadata for the image paths) | (1) Identify all primary ECU's (2) Verify if all primary ECU's contain the following information : (a) A list of repository names and one or more URLs. At a minimum, this MUST include the Director and Image repositories (b) A list of mappings of image paths to repositories |
| 5.2.7 | Rules for filenames in repositories and metadata | Unless stated otherwise, all files SHALL be written to repositories in accordance with the following two rules: (1) Metadata filenames SHALL be qualified with version numbers (2) The file MUST be written to the repository using n different filenames, one for each hash digest listed in its corresponding Targets metadata. | (1) Check if rules are defined for writing files to repositories (2) If yes, verify if the Metadata filenames are qualified with version numbers (3) Check if different file names are used for writing the file to the repository, one for each hash digest listed in its corresponding Targets metadata |
| 5.3 | Server / repository implementation requirements | An Uptane implementation SHALL make the following services available to vehicles: Image Repository, Director Repository. Additionally, an Uptane implementation requires ECUs to have a secure way to know the current time. | Verify if services like Image Repository and Director Repository are available to vehicles as part of the Uptane implementation |
| 5.3.1 | Image Repository | The Image repository SHALL expose an interface permitting the download of metadata and images. This interface SHOULD be public. | (1) Verify if the image repository exposes an interface to permit download of metadata and images (2) Verify if the interface is public |
| 5.3.1 | Image Repository | The Image repository SHALL require authorization for writing metadata and images. | Verify if aproval gates are defined for the Image repository in order to write metadata and images. Verify the number of people who have write access to the Image Repository and check if there is a process to track, control, prevent, correct, and secure access to the repository |
| 5.3.1 | Image Repository | 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 | (1) Verify if there is a defined process to allow access to users to upload images and their associated metadata.(2) Validate if the Image repository verifies the authorizations by checking the chain of delegations (3) Check if the Image Repository allows an unauthorized user to write images and metadata in the Image Repository |
| 5.3.1 | Image Repository | 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. | (1) Verify if the Image Repository has implemented storage with permissions to write image file (2) Check if access to the storage is restricted (3) Check if the image file in the storage uses unique filename to later read the same file using the same name |
| 5.3.2 | Director Repository | 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 in the repository. | (1) Verify if the Director Repository has an exposed interface for primaries to upload vehicle version manifests (2) Verify if specific security safeguards are in place to prevent compromise of information via the exposed interface (3) Check if the Interface is public (4) Identify the ECU's that require the images to be encrypted (5) Verify if the images are either encrypted on-the-fly or by storing encrypted images in the repository for all the ECU's that require encryption |
| 5.3.2 | Director 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. | (1) Verify if the Director Repository has implemented storage which permits an automated service to write generated metadata files (2) Check if access to the storage is restricted to the automated service |
| 5.3.2.1 | Directing installation of images on vehicles | A Director repository MUST conform to the following six-step process for directing the installation of software images on a vehicle : (1) The Director SHOULD first identify the vehicle. This MAY be done when the Director receives a vehicle version manifest sent by a Primary , decodes the manifest, and determines the unique vehicle identifier.(2) Using the vehicle identifier, the Director queries its inventory database (3) The Director SHALL check the manifest for accuracy compared to the information in the inventory database. If any of the required checks fail, the Director MAY drop the request. (4) The Director extracts information about currently installed images from the vehicle version manifest.(5) The Director MAY encrypt images for ECUs that require it (6) The Director generates new metadata representing the desired set of images to be installed on the vehicle, based on the dependency resolution in step 4 | The Director repository should implement the following steps for installing software images on the vehicle : (1) Identify the vehicle, with help of the vehicle version manifest sent by the primary ECU. Upon receiving the manifest, check if the vehicle decoded the manifest and acquires the unique vehicle identifier (2) Validate the vehicle identifier by querying the inventory database (3) Check the manifest for accuracy compared to the information in the inventory database. Verify if the Director drops the request if any of the required checks fail (4) Verify if information about currently installed images from the vehicle version manifest is present (5) Verify if the Director encrypts images for ECUs that require it (6) Verify if the director generates new metadata representing the desired set of images to be installed on the vehicle |
| 5.3.2.2 | Inventory Database | The Director SHALL use a private inventory database to store information about ECUs and vehicles. An implementor MAY use any durable database for this purpose | Verify the security safeguards for the inventory database, as it stores information about ECUs and Vehicles |
| 5.3.2.2 | Inventory Database | The inventory database MUST record the following pieces of information per ECU : (1) A unique identifier (2) The vehicle identifier the ECU is associated with (3) An ECU key (symmetric or asymmetric; for asymmetric keys, only the public part SHOULD be stored) (4) The ECU key identifier (5) Whether the ECU is a Primary or a Secondary (6) A hardware identifier for each ECU to protect against the possibility of directing the ECU to install incompatible firmware. | Verify if the inventory database records the following information per ECU : (1) A unique identifier (2) The vehicle identifier the ECU is associated with (3) An ECU key (symmetric or asymmetric; for asymmetric keys, only the public part SHOULD be stored) (4) The ECU key identifier (5) Whether the ECU is a Primary or a Secondary (6) A hardware identifier for each ECU to protect against the possibility of directing the ECU to install incompatible firmware |
| 5.4 | In-vehicle implementation requirements | 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. | (1) Verify if the ECU is able to download and verify Image metadata and image binaries before installing a new image (2) Verify the process established to validate the current time, or a sufficiently recent attestation of the time |
| 5.4 | In-vehicle implementation requirements | 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. | (1) Verify if the Primary ECU is performing full verification to verify image metadata (2) Verify if the secondary ECUs are performing full verification/partial verification |
| 5.4 | In-vehicle implementation requirements | ECUs MUST have a secure source of time. An OEM/Uptane implementor MAY use any external source of time that is demonstrably secure. | Verify the if the implementor is using external source of time. Validate if the source is secure with the help of digital signatures |
| 5.4.1 | Build-time prerequisite requirements for ECUs | 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: (1) A sufficiently recent copy of required Uptane metadata at the time of manufacture or install. (2) The current time, or a secure attestation of a sufficiently recent time. (3) An ECU key. This is a private key, unique to the ECU, used to sign ECU version manifests and decrypt images. | Verify if the ECU is capable of receiving Uptane updates: (1) Check if Uptane metadata was provisioned at the time it is manufactured or installed in the vehicle (2) Verify if the time server is secure and is not prone to man in the middle attack e.g. NTPSec and Ntimed two variants of "secure" NTP (3) Verify if the ECU key was present at the time Uptane was first installed |
| 5.4.2 | What the Primary does | A Primary downloads, verifies, and distributes the latest time, metadata and images. To do so, it SHALL perform the following seven steps: (1) Construct and send vehicle version manifest (2) Download and check current time (3) Download and verify metadata (4) Download and verify images (5) OPTIONAL: Send latest time to secondaries (6) Send metadata to Secondaries (7) Send images to Secondaries | Primary dowloads verifies and distributes latest time, metadata and images. Hence perform the following : (1) Verify if the vehicle version manifest is sent (2) Verify the current time (3) Check if the downloaded metadata has a defined process for verification (4) Check if the downloaded images has a defined process for verification (5) Verify if the latest time is sent to secondaries (6) If yes, verify if metadata and images are sent to secondaries if they are required to be sent |
| 5.4.2.1 | Construct and send vehicle version manifest | The Primary SHALL build a vehicle version manifest as described in Section 5.4.2.1.1 | Verify if the primary builds a vehicle version as desribed in the standards |
| 5.4.2.1 | Construct and send vehicle version manifest | 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. | Verify the manifest to check if the full manifest is sent or a difference of the manifest is sent. To do so verify the metadata sent in the previous manifest and the metadata sent in the latest manifest |
| 5.4.2.1.1 | Vehicle version manifest | The vehicle version manifest is a metadata structure that MUST contain the following information: (1) An attribute containing the signature(s) of the payload (2) A Payload Containing : The ECU’s unique identifier; The filename, length, and hashes of its currently installed image; An indicator of any detected security attack; The latest time the ECU can verify at the time this version report was generated; A cryptographic nonce | Verify the vehicle version manifest, such that it contains the following in the metadata structure : (1) An attribute containing the signature(s) of the payload (2) A Payload Containing : The ECU’s unique identifier; The filename, length, and hashes of its currently installed image; An indicator of any detected security attack; The latest time the ECU can verify at the time this version report was generated; A cryptographic nonce |
| 5.4.2.2 | Download and check current time | The Primary SHALL load the current time from a secure source | Verify if the time server is secure and is not prone to man in the middle attack e.g. NTPSec and Ntimed two variants of “secure” NTP (3) Verify if the ECU key was present at the time Uptane was first installed |
| 5.4.2.2 | Download and verify metadata | The Primary SHALL download metadata for all targets and perform a full verification | Verify if the Primary downloads metadata for all targets and performs a full verification |
| 5.4.2.4 | Download and verify images | 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. | Check if the Primary downloads and verify images for itself and for all of its associated Secondaries. To check the integrity of the images (1) Verify the hash value in the image against the hash specified in the Director’s Targets metadata for that image |
| 5.4.2.4 | Download and verify images | If the primary has received multiple hashes for a given image binary via targets role (see Section 5.2.3.1) then it SHALL verify every hash for this image despite the fact that just one hash is enough to obtain the image itself. | (1) Identify if the primary has received single has or multiple hash for the image binary (2) Verify if the image binary has been received by authentic source (targets role) (3) If its multiple hashes does the primary verify every hash for this image |
| 5.4.2.6 | Send metadata to Secondaries | 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 | (1) Verify if the primary sends its latest downloaded metadata to all of its associated Secondaries (2) Verify if complete verification of the metadata is performed by the secondary |
| 5.4.2.6 | Send metadata to Secondaries | 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 | (1) Verify if primary performs delegation resolution in order to determine the minimum set of metadata files to sent to each Secondary |
| 5.4.2.7 | Send images to Secondaries | The Primary SHALL send the latest image to each of its associated Secondaries that have storage to receive it. | (1) Identify the secondaries that have storage (2) Check if the primary sends the latest image to each of its associated Secondaries that have storage to receive it |
| 5.4.2.7 | Send images to Secondaries | 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 | (1) Identify the secondaries without storage (2) Verify if the Primary waits for a request from the Secondary to stream the new image file to it, prior to first registration (3) Check if the secondary verifies metadata sent in the previous step |
| 5.4.3 | Installing images on Primary or Secondary ECUs | An ECU SHALL perform the following steps when attempting to install a new image: (1) Verify latest attested time (2) Verify metadata (3) Download latest image (4) Verify image (5) Install image (6) Create and send version report | Before the ECU installs a new image (1) Does it verify latest attested time (2) Does it verify metadata (3) Does it download latest image, verify the previous image (4) Does it install the image (5) Does it create and send version report, verify all the reports that the ECU has sent so far to eliminate exceptions |
| 5.4.3.1 | Load and verify the latest attested time | The ECU SHALL load and verify the current time, or the most recent securely attested time. | Verify if the ECU loads the current time, verify the secure souce of time i.e. the time server |
| 5.4.3.3 | Download latest image | 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 | (1) Verify and identify the ECU's that have secondary storage (2) 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 (3) Verify if the latest image was downloaded from an authentic source i.e. the primary |
| 5.4.3.3 | Download latest image | The filename used to identify the latest known image (i.e., the file to request from the Primary) SHALL be determined as follows: (1) Load the Targets metadata file from the Director repository.(2) Find the Targets metadata associated with this ECU identifier.(3) Construct the Image filename using the rule in Section 5.2.7, or use the download URL specified in the Director metadata. (4) If there is no Targets metadata about this image, abort the update cycle and report that there is no such image. | To determine the latest known image perform the following verifications (1) Load the Targets metadata file from the Director repository.(2) Find the Targets metadata associated with this ECU identifier.(3) Construct the Image filename using the rule in Section 5.2.7, or use the download URL specified in the Director metadata. (4) If there is no Targets metadata about this image, abort the update cycle and report that there is no such image |
| 5.4.3.3 | Download latest image | When the Primary responds to the download request, the ECU SHALL overwrite its current image with the downloaded image from the Primary. | Verify if the ECU overwrites its current image with the downloaded image from the Primary, if the Primary responds to the download request |
| 5.4.3.4 | Verify image | The ECU SHALL verify that the latest image matches the latest metadata as follows: (1) Load the latest Targets metadata file from the Director (2) Find the Targets metadata associated with this ECU identifier. (3) Check that the hardware identifier in the metadata matches the ECUs hardware identifier. (4) Check that the image filename is valid for this ECU. This MAY be a comparison against a wildcard path, which restricts the ECUs to which a delegation will apply. (5) Check that the release counter of the image in the previous metadata, if it exists, is less than or equal to the release counter in the latest metadata. (6) If the image is encrypted, decrypt the image with a decryption key (7) Check that the hash of the image matches the hash in the metadata. | To compare if the latest image matches the latest metadata : (1) Load the latest Targets metadata file from the Director (2) Find the Targets metadata associated with this ECU identifier. (3) Check that the hardware identifier in the metadata matches the ECUs hardware identifier. (4) Check that the image filename is valid for this ECU. This MAY be a comparison against a wildcard path, which restricts the ECUs to which a delegation will apply. (5) Check that the release counter of the image in the previous metadata, if it exists, is less than or equal to the release counter in the latest metadata. (6) If the image is encrypted, decrypt the image with a decryption key (7) Check that the hash of the image matches the hash in the metadata |
| 5.4.3.4 | Verify image | If the image is encrypted, decrypt the image with a decryption key to be chosen as follows: (1) If the ECU key is a symmetric key, the ECU SHALL use the ECU key for image decryption. (2) If the ECU key is asymmetric, the ECU SHALL check the Targets metadata for an encrypted symmetric key. If such a key is found, the ECU SHALL decrypt the symmetric key using its ECU key, and use the decrypted symmetric key for image decryption. (3) If the ECU key is asymmetric and there is no symmetric key in the target metadata, the ECU SHALL use its ECU key for image decryption. | Verify if the decryption key (to decrypt the image) is chosen as follows : (1) If the ECU key is a symmetric key, the ECU SHALL use the ECU key for image decryption. (2) If the ECU key is asymmetric, the ECU SHALL check the Targets metadata for an encrypted symmetric key. If such a key is found, the ECU SHALL decrypt the symmetric key using its ECU key, and use the decrypted symmetric key for image decryption. (3) If the ECU key is asymmetric and there is no symmetric key in the target metadata, the ECU SHALL use its ECU key for image decryption. |
| 5.4.3.4 | Verify image | If the ECU has secondary storage, the checks SHOULD be performed on the image in secondary storage before it is installed. | (1) Identify ECU's with secondary storage (2) Verify if checks are performed on the image in the secondary storage before they are installed |
| 5.4.3.5 | Install image | 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) | Verify if the preconditions are met before the ECU attempts to install the update. 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) |
| 5.4.3.6 | Create and send version report | 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. | (1) Verify if the ECU sends a version report to the primary (2) Verify if the primary writes the version reports it receives to disk and associate them with the Secondaries that sent them (3) If the ECU is the primary, check if it saves it to the disk |
| 5.4.4.1 | Partial verification | In order to perform partial verification, an ECU SHALL perform the following steps: (1) Load and verify the current time or the most recent securely attested time. (2) Download and check the Targets metadata file from the Director repository | (1) Identify if the ECU performs full verification or partial verification (2) If it performs full verification does it Load and verify the current time or the most recent securely attested time (3) And, does it download and check the Targets metadata file from the Director repository |
| 5.4.4.2 | Full verification | 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. | Verify if all the image paths are signed by both repositories (Director and Image) |
| 5.4.4.2 | Full verification | In order to perform full verification, an ECU SHALL perform the following steps: (1) Load and verify the current time or the most recent securely attested time (2) Download and check the Root metadata file from the Director repository (3) Download and check the Timestamp metadata file from the Director repository (4) Download and check the Snapshot metadata file from the Director repository (5) Download and check the Targets metadata file from the Director repository (6) Download and check the Root metadata file from the Image repository (7) Download and check the Timestamp metadata file from the Image repository (8) Download and check the Snapshot metadata file from the Image repository (9) Download and check the top-level Targets metadata file from the Image repository (10) Verify that Targets metadata from the Director and Image repositories match. A Primary ECU MUST perform this check on metadata for all images listed in the Targets metadata file from the Director repository downloaded in step 6. A Secondary ECU MAY elect to perform this check only on the metadata for the image it will install. | Identify the ECU's that perform full verification and check if the following steps are performed (1) Load and verify the current time or the most recent securely attested time (2) Download and check the Root metadata file from the Director repository (3) Download and check the Timestamp metadata file from the Director repository (4) Download and check the Snapshot metadata file from the Director repository (5) Download and check the Targets metadata file from the Director repository (6) Download and check the Root metadata file from the Image repository (7) Download and check the Timestamp metadata file from the Image repository (8) Download and check the Snapshot metadata file from the Image repository (9) Download and check the top-level Targets metadata file from the Image repository (10) Verify that Targets metadata from the Director and Image repositories match. A Primary ECU MUST perform this check on metadata for all images listed in the Targets metadata file from the Director repository downloaded in step 6. A Secondary ECU MAY elect to perform this check only on the metadata for the image it will install |
| 5.4.4.2 | Full verification | To check that the metadata for an image matches, complete the following procedure: (1) Locate and download a Targets metadata file from the Image repository that contains an image with exactly the same file name listed in the Director metadata (2) Check that the Targets metadata from the Image repository matches the Targets metadata from the Director repository | To verify if the the metadata for an image matches, perform the following checks (1) Locate and download a Targets metadata file from the Image repository that contains an image with exactly the same file name listed in the Director metadata (2) Check that the Targets metadata from the Image repository matches the Targets metadata from the Director repository |
| 5.4.4.2 | Full verification | 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 (e.g. rollback, freeze, arbitrary software, etc.), the ECU SHOULD return an error code that indicates the type of attack. | (1) Verify if the ECU is configured to fail safe (2) Does the ECU return an error code indicating the failure if any step fails (3) Verify if a check for a specific type of security attack fails (e.g. rollback, freeze, arbitrary software, etc.), does the ECU return an error code that indicates the type of attack. |
| 5.4.4.2 | Full verification | If the ECU performing the verification is the Primary ECU, it SHOULD also ensure that the Targets metadata from the Director repository doesn’t contain any ECU identifiers for ECUs not actually present in the vehicle | (1) Identify the ECU performing the verification (2) If the ECU performing the verification is the Primary ECU, does it ensure that the Targets metadata from the Director repository doesn’t contain any ECU identifiers for ECUs not actually present in the vehicle |
| 5.4.4.3 | How to check Root metadata | To properly check Root metadata, an ECU SHOULD: (1) Load the previous Root metadata file. (2) Update to the latest Root metadata file. (3) Check that the current (or latest securely attested) time is lower than the expiration timestamp in the latest Root metadata file. (4) If the Timestamp and/or Snapshot keys have been rotated, delete the previous Timestamp and Snapshot metadata files. | Verify if the ECU checks the Root metadata (1)Load the previous Root metadata file. (2) Update to the latest Root metadata file. (3) Check that the current (or latest securely attested) time is lower than the expiration timestamp in the latest Root metadata file. (4) If the Timestamp and/or Snapshot keys have been rotated, delete the previous Timestamp and Snapshot metadata files. |
| 5.4.4.4 | How to check Timestamp metadata | To properly check Timestamp metadata, an ECU SHOULD: (1) Download up to Y number of bytes. The value for Y is set by the implementor. For example, Y may be tens of kilobytes. The filename used to download the Timestamp metadata file is of the fixed form FILENAME.EXT (e.g., timestamp.json). (2) Check that it has been signed by the threshold of keys specified in the latest Root metadata file. (3) Check that the version number of the previous Timestamp metadata file, if any, is less than or equal to the version number of this Timestamp metadata file. (4) Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Timestamp metadata file. | To verify timestamp metadata (1) The ECU should Download up to Y number of bytes (2) Verify if the bytes are signed by the threshold of keys specified in the latest Root metadata file (3) Check that the version number of the previous Timestamp metadata file, if any, is less than or equal to the version number of this Timestamp metadata file (4) Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Timestamp metadata file. |
| 5.4.4.5 | How to check Snapshot metadata | To properly check Snapshot metadata, an ECU SHOULD: (1) Download up to the number of bytes specified in the Timestamp metadata file, constructing the metadata filename (2) The hashes and version number of the new Snapshot metadata file MUST match the hashes and version number listed in Timestamp metadata. (3) Check that it has been signed by the threshold of keys specified in the latest Root metadata file. If the new Snapshot metadata file is not signed as required, discard it (4) Check that the version number of the previous Snapshot metadata file, if any, is less than or equal to the version number of this Snapshot metadata file. If this Snapshot metadata file is older than the previous Snapshot metadata file, discard it (5) Check that the version number listed by the previous Snapshot metadata file for each Targets metadata file is less than or equal to its version number in this Snapshot metadata file. (6) Check that each Targets metadata filename listed in the previous Snapshot metadata file is also listed in this Snapshot metadata file. (7) Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Snapshot metadata file. | To verify Snapshot metadata, the ECU should (1) Download up to the number of bytes specified in the Timestamp metadata file, constructing the metadata filename (2) The hashes and version number of the new Snapshot metadata file MUST match the hashes and version number listed in Timestamp metadata. (3) Check that it has been signed by the threshold of keys specified in the latest Root metadata file. If the new Snapshot metadata file is not signed as required, discard it (4) Check that the version number of the previous Snapshot metadata file, if any, is less than or equal to the version number of this Snapshot metadata file. If this Snapshot metadata file is older than the previous Snapshot metadata file, discard it (5) Check that the version number listed by the previous Snapshot metadata file for each Targets metadata file is less than or equal to its version number in this Snapshot metadata file. (6) Check that each Targets metadata filename listed in the previous Snapshot metadata file is also listed in this Snapshot metadata file. (7) Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Snapshot metadata file. |
| 5.4.4.6 | How to check Targets metadata | To properly check Targets metadata, an ECU SHOULD: (1) Download up to Z number of bytes, constructing the metadata filename (2) The version number of the new Targets metadata file MUST match the version number listed in the latest Snapshot metadata. (3) Check that the Targets metadata has been signed by the threshold of keys specified in the relevant metadata file (Checks for an arbitrary software attack) (4) Check that the version number of the previous Targets metadata file, if any, is less than or equal to the version number of this Targets metadata file.(5) Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Targets metadata file. (6) If checking Targets metadata from the Director repository, verify that there are no delegations. (7) If checking Targets metadata from the Director repository, check that no ECU identifier is represented more than once | To verify Targets metadata, an ECU SHOULD: (1) Download up to Z number of bytes, constructing the metadata filename (2) The version number of the new Targets metadata file MUST match the version number listed in the latest Snapshot metadata. (3) Check that the Targets metadata has been signed by the threshold of keys specified in the relevant metadata file (Checks for an arbitrary software attack) (4) Check that the version number of the previous Targets metadata file, if any, is less than or equal to the version number of this Targets metadata file.(5) Check that the current (or latest securely attested) time is lower than the expiration timestamp in this Targets metadata file. (6) If checking Targets metadata from the Director repository, verify that there are no delegations. (7) If checking Targets metadata from the Director repository, check that no ECU identifier is represented more than once |
| 5.4.4.7 | How to resolve delegations | 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. | Verify if the ECU locates the metadata file(s) for the role (or roles) that have the authority to sign the image to appropriately check Targets metadata for an image |
| 5.4.4.7 | How to resolve delegations | All delegations MUST be resolved using the following recursive procedure, beginning with the top-level Targets metadata file : (1) Download the current metadata file, and check it following the procedure in Section 5.4.4.6. (2) If the current metadata file contains signed metadata about the image, end the delegation resolution and return the metadata to be checked. (3) If the current metadata file was reached via a terminating delegation and does not contain signed metadata about the image, abort the delegation resolution for this image and return an error indicating that image metadata could not be found. (4) Search the list of delegations, in listed order for each delegation: (a) Check if the delegation applies to the image being processed. For the delegation to apply, it MUST include the hardware identifier of the target, and the target name must match one of the delegation’s image paths. (b) If the delegation is a multi-role delegation, follow the procedure described in Section 5.4.4.8. (c) If the delegation is a normal delegation, perform delegation resolution, starting at step a. (5) If the end of the list of delegations in the top-level metadata is reached without finding valid image metadata, return an error indicating that image metadata could not be found. | Verify if the all delegations are resolves as per the given procedures |