Vulnerability: Time attestation tampering (from Univ. of Iowa report)

[Yasho-Bapat]

This vulnerability was highlighted in the University of Iowa report on Uptane's vulnerabilities.

Description
It highlights that an adversary can block an ECU's access to the current time by dropping the message containing the latest time, either between the external source of time and the Primary ECU. or between the Primary and Secondary ECUs.
There is also no indication to abort the update process if the latest time attestation is absent or invalid. This could be interpreted as that the verification process can continue without the ECU updating its clock, so the most recent securely attested time would be the same as the previous update cycle, keeping the door open for a freeze attack.

[tkfu]

We discussed this in detail at the 03/12/2024 standards committee meeting; I'll attempt to summarize our conclusions and our planned path forward.

One thing that's important to understand is that Uptane's model includes both ECUs that have an internal RTC and ECUs that do not. Additionally, we assume that most secondary ECUs do not have the capability to make network requests outside of the vehicle; to get verified time, then, they must rely on an internal source.

This vulnerability arises from some language we have in deployment considerations:

If the response of the external time source meets verification criteria, update the Primary ECU’s clock and retain the time source response for distribution to Secondary ECUs. If it fails to meet this criteria, discard the response and continue the procedure without an updated time.

Our intent in writing this was to allow some flexibility in the case that the primary does have some verified time, but wasn't able to get a response from the timeserver at the moment the protocol is being executed. Because the primary will have a real-time clock, the idea is that the primary can still safely continue the update procedure as long as none of the metadata is expired according to its own RTC. An ECU with no RTC has no such recourse, and thus must validate the time from a trusted source (ideally, two or more independently trusted sources) every time it verifies any metadata. One such trusted source can be the Uptane primary, but it could also be a domain controller or some other ECU in the vehicle that the ECU without an RTC is designated to trust.

It should also be noted here, for historical purposes, that draft versions of Uptane (pre-1.0) mandated the existence of a time server, and the time server was integrated into the protocol. That was deemed impractical for real-world deployments, so we removed it and replaced it with the present language.

However, we clearly have some inconsistencies in the present version of the standard:

• in 5.4. In-vehicle implementation requirements, we say:

An Uptane-conformant ECU SHALL be able to download and verify image metadata and image binaries before installing a new image and SHALL have a secure way of verifying the current time, or a sufficiently recent attestation of the time.

• in 5.4.3. Installing images on Primary or Secondary ECUs, we say:

An ECU SHALL perform the following steps when attempting to install a new image:

1. Verify latest attested time. This is optional if the ECU does not have the capacity to verify a time message (Section 5.4.3.1)

• in 5.4.3.1. Load and verify the latest attested time, we say:

IF the ECU has the capability to verify a time message, the ECU SHOULD load and verify the current time, or the most recent securely attested time.

• in 5.4.4.1. Partial verification, we say:

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.

• in 5.4.4.2. Full verification, we say:

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.

• In each of the role-specific metadata verification procedures, we say:

Check that the current (or latest securely attested) time is lower than the expiration timestamp in this (Root/Timestamp/Snapshot/Targets) metadata file. (Checks for a freeze attack.)

[tkfu]

I believe our intent with the language in 5.4.3.1, where the ECU SHOULD (instead of SHALL) load and verify the current time, was in reference to a secure time source external to the vehicle. I think we need to clarify this point, so that there is a clear hierarchy: if possible, ECUs SHOULD verify their time from a source external to the vehicle on every cycle. But because that's not always practical, an implementor MAY choose to have the ECU rely on their own conception of a secure source of time, like a trusted source inside the vehicle. Of course, that in-vehicle source itself needs to verify its clock using appropriately secure measures like NTS, but the secondary relying on the in-vehicle source is not required to establish end-to-end trust with the time server.

This clarification would drastically reduce the attack surface for freeze attacks.