[FOTA] Tech key point: ECU verifying and Decrpting

A Primary downloads, verifies, and distributes the latest time, metadata, and images. To do so, it SHALL perform the following seven steps:

  • Construct and send vehicle version manifest

  • Download and check current time

  • Download and verify metadata

  • Download and verify images

  • Send the latest time to Secondaries

  • Send metadata to Secondaries

  • Send images to Secondaries

An ECU (whatever primaries or secondaries) SHALL perform the following steps when attempting to install a new image:

  • Verify latest attested time.

  • Verify metadata

  • Download latest image

  • Verify image

  • Install image

  • Create and send version report

1. Primaies

  • Construct and send vehicle version manifest

  • Download and check the current time

  • Download and verify metadata

  • Download and verify images

The primary flow is shown in the following figure:

1.2 Construct and send vehicle version manifest

The Primary SHALL build a vehicle version manifest as described in https://app.gitbook.com/o/eTBeA3vhkOtihTJASkhd/s/tqiX1ZbXhRorHX3bwk1r/~/changes/43/design/fota/fota-module-of-ecus-fota-unit-design/fota-tech-key-point-metadata-management

Once the complete manifest is built, the Primary can 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 could 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.

Vehicle Manifest

Secondaries can send their version reports at any time so that they are already stored on the Primary when it wishes to check for updates. Alternatively, the Primary can request a version report from each Secondary at the time of the update check.

The vehicle version manifest is a metadata structure that SHALL contain the following information:

  • An attribute containing the signature(s) of the payload, each specified by:

    • The public key identifier of the key being used to sign the payload

    • The signing method (i.e., ed25519, rsassa-pss, etc.)

    • A hash of the payload to be signed

    • The hashing function used (i.e., SHA3-256, SHA-512/224, etc.)

    • The signature of the hash

  • A payload representing the installed versions of each software image on the vehicle. This payload SHALL contain:

    • The vehicle’s unique identifier (e.g., the VIN)

    • The Primary ECU’s unique identifier (e.g., the serial number)

    • A list of ECU version reports as specified in Section 5.4.2.1.2

A vehicle manifest example is shown in the following code block:

{
  "signed":{
      "vin": "VINTESTCODEDEADBEE",
      "OEM": "AUTOX",
      "model": "XERO",
      "ecu_version_manifests": {
        "DC1": [{
          "ecu_name": "VDU",
          "ecu_serial": "1q2w3e44efe",
          "hardware_id": "0xdeadbeef",
          "firmware_version": "1.0.1",
          "firmware_sha256hash": "d47ec6a4b942939a1a6138c99227d06bc23203055a65492f0ab33781c0f8b746",
          "firmware_length": 1024000,
          "bootloader_version": "1.1.1",
          "bootloader_sha256hash": "c94867b062852139e536d1c427753104ff069d9f1cff42a1029b7ed1f3adc61d",
          "bootloader_length": 1024000,
          "os_version": "Linux kernel xxx",
          "last_report_time": "2023-07-20-14:00",
          "nonce": "t3af4yah4yag4yqat43qg",
          "denpendencies": [
            {
              "name": “xxx”,
              "verson": "0.1.1"
            }
          ]
        }],
        "DC2":[],
        "DC3":[],
        "primary_ecu":{
        }
      }
  },
   "signature": {
      "keyid": "primary_ecu_key",
      "method": "sha256WithRSAEncryption", 
      "sig": "f417...signature..."
   }
}

ECU version manifest

An ECU version report is a metadata structure that SHALL contain the following information:

  • An attribute containing the signature(s) of the payload, each specified by:

    • The public key identifier of the key being used to sign the payload

    • The signing method (i.e., ed25519, rsassa-pss, etc.)

    • A hash of the payload to be signed

    • The hashing function used (i.e., SHA3-256, SHA-512/224, etc.)

    • The signature of the hash

  • A payload containing:

    • The ECU’s unique identifier (e.g., the serial number)

    • The filename, length, and hashes of its currently installed image (i.e., the non-custom Targets metadata for this particular image)

    • An indicator of any detected security attack

    • The latest time the ECU can verify at the time this version report was generated

    • A nonce or counter to prevent a replay of the ECU version report. This value SHALL change each update cycle.

An ECU version manifest example is shown in the following code block:

{
  "signed": {
      "ecu_name": "VDU",
      "ecu_serial": "1q2w3e44efe",
      "hardware_id": "0xdeadbeef",
      "firmware_version": "1.0.1",
      "firmware_sha256hash": "d47ec6a4b942939a1a6138c99227d06bc23203055a65492f0ab33781c0f8b746",
      "firmware_length": 1024000,
      "bootloader_version": "1.1.1",
      "bootloader_sha256hash": "c94867b062852139e536d1c427753104ff069d9f1cff42a1029b7ed1f3adc61d",
      "bootloader_length": 1024000,
      "os_version": "Linux kernel xxx",
      "last_report_time": "2023-07-20-14:00",
      "nonce": "t3af4yah4yag4yqat43qg",
      "denpendencies": [
        {
          "name": “xxx”,
          "verson": "0.1.1"
        }
      ]
  },
  "signature": {
      "keyid": "ecu_key",
      "method": "sha256WithRSAEncryption", 
      "sig": "f417...signature..."
  }
}

1.3 Download and check the current time

The Primary SHALL load the current time from a secure source. About the secure source, please refer to https://carloss-organization-4.gitbook.io/tech/design/fota/fota-module-of-ecus-fota-unit-design/fota-tech-key-point-time-server

The flow of the secure source(time server) in the ECU interactions is shown in the following sequence diagram:

1.4 Download and verify metadata

The Primary SHALL download metadata for all targets and perform a full verification 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.

In order to perform full verification, an ECU SHALL perform the following steps:

About Time Server:

  1. Load and verify the current time or the most recent securely attested time;

About Director Repository

  1. Download and check the Root metadata file from the Director repository;

  2. Download and check the Timestamp metadata file from the Director repository;

  3. Check the previously downloaded Snapshot metadata file from the Directory repository:

    1. If the hashes and version number of that file match the hashes and version number listed in the new Timestamp metadata, there are no new updates and the verification process SHALL be stopped and considered complete.

    2. Otherwise, download and check the Snapshot metadata file from the Director repository;

  4. Download and check the Targets metadata file from the Director repository;

    1. If the Targets metadata from the Directory repository indicates that there are no new targets that are not already currently installed, the verification process SHALL be stopped and considered complete.

    2. Otherwise, to step 6.

  5. Download and check the Root metadata file from the Image repository;

  6. Download and check the Timestamp metadata file from the Image repository;

  7. Check the previously downloaded Snapshot metadata file from the Image repository:

    1. f the hashes and version number of that file match the hashes and version number listed in the new Timestamp metadata, the ECU SHALL skip to the last step

    2. Otherwise, download and check the Snapshot metadata file from the Image repository;

  8. Download and check the top-level Targets metadata file from the Image repository;

About Primary ECU

  1. Verify that Targets metadata from the Director and Image repositories match:

    1. A Primary ECU SHALL perform this check on metadata for all images listed in the Targets metadata file from the Director repository downloaded in step 6;

  2. A Secondary ECU can elect to perform this check only on the metadata for the image it will install.

About How to check the metadata matching

Note, To check that the metadata for an image matches, complete the following procedure:

  • Check that the non-custom metadata (i.e., length and hashes) of the unencrypted or encrypted image are the same in both sets of metadata.

  • Note: the Primary is responsible for validating encrypted images and associated metadata. The target ECU (Primary or Secondary) is responsible for validating the unencrypted image and associated metadata.

  • Check that all SHALL match custom metadata (e.g., hardware identifier and release counter) are the same in both sets of metadata.

  • Check that the release counter, if one is used, in the previous Targets metadata file is less than or equal to the release counter in this Targets metadata file.

If any step fails, the ECU SHALL 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.

1.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.

About the image file name setting, please refer to https://uptane.github.io/papers/uptane-standard.2.0.0.html#metadata_filename_rules

2. Secondaries

The primary with the secondaries is shown in the following figure. We suppose that the UDS protocol is used in the communication between the primary and secondaries:

The flow of the secondaries is shown in the following figure:

2.1 Receiving the latest time from the primary

The Primary SHOULD send the time to each ECU. If the ECU has limited secondary storage, i.e., insufficient buffer storage to temporarily store the latest image before installing it, it SHALL download the latest image from the Primary.

2.2 Receiving parsed metadata from the primary

The Primary SHALL send its latest downloaded metadata to all of its associated Secondaries. The metadata it sends to each Secondary SHALL 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 could include fewer metadata files; at a minimum, it includes only the Targets metadata file from the Director repository.

Each Secondary SHALL store the latest copy of all metadata required for its own verification.

The filename used to identify the latest known image (i.e., the file to request from the Primary) SHALL be determined as follows:

  • Load the Targets metadata file from the Director repository.

  • Find the Targets metadata associated with this ECU identifier.

  • Construct the Image filename using the rule in Section 5.2.7, or use the download URL specified in the Director metadata.

  • If there is no Targets metadata about this image, abort the update cycle and report that there is no such image. Additionally, in the case of failure, the ECU SHALL retain its previous Targets metadata instead of using the new Targets metadata. Otherwise, download the image (up to the number of bytes specified in the Targets metadata) and verify it according to Section 5.4.3.4.

2.3 Receiving parsed images from the primary

The Primary SHALL send the latest image to each of its associated Secondaries that have sufficient storage to receive it. For Secondaries without sufficient storage to store a copy of the image, 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.

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 ECU’s hardware identifier.

  4. Check that the image filename is valid for this ECU. This could 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 to be chosen as follows:

    • If the ECU key is a symmetric key, the ECU SHALL use the ECU key for image decryption.

    • 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.

    • If the ECU key is asymmetric and there is no symmetric key in the Targets metadata, the ECU SHALL use its ECU key for image decryption.

  7. Check that all hashes listed in the metadata match the corresponding hashes of the image.

If the ECU has enough secondary storage capacity to store the image, the checks SHOULD be performed on the image in secondary storage before it is installed.

2.4 Install the image and Create, send the version report

The ECU SHALL attempt to install the update. This installation SHOULD occur at a time when all pre-conditions are met. These pre-conditions could include ensuring the vehicle is in a safe environment for an installation (e.g., the vehicle is parked when updating a specific ECU). Other pre-conditions could 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.

2.5 Summary

The secondary flow can be summarized by the following figure:

上一页[FOTA] Tech key point: metadata management下一页[FOTA] Tech key point: time server

最后更新于