Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Chicken-and-egg problem with Director Root metadata verification and latest time verification #137

Closed
cchalm opened this issue Sep 23, 2022 · 12 comments

Comments

@cchalm
Copy link

cchalm commented Sep 23, 2022

From https://uptane.github.io/deployment-considerations/repositories.html#changes-to-the-director-repository:

If an external time source is in use, a representation of its public key is CONDITIONALLY REQUIRED in Director repository Root metadata.

If the public key for an external time source is specified in the Director Root metadata, then having a verified copy of the latest Director Root metadata is required to verify the time. Verifying the Director Root metadata requires checking that it has not expired, which requires a verified time. In short:

  • Can't verify the time without the Director Root metadata
  • Can't verify the Director Root metadata without the time

How should this cycle be broken?

@jhdalek55
Copy link
Collaborator

jhdalek55 commented Dec 6, 2022

This was briefly discussed in the 12/6 Uptane Standards Meeting. @mnm678 noted that TUF provides a solution to this issue via an option codified in theupdateframework/specification@e645837 that "introduces a fixed notion of time for the duration of the client update workflow, bounded by an application defined maximum duration for the update. It is further recommended that the maximum duration is set to the same time period at
which the repository re-signs the timestamp metadata." A pull request that mentions how this works for TUF would resolve this issue.

@mnm678
Copy link
Collaborator

mnm678 commented Dec 6, 2022

The problem with a secure source of time and root metadata is actually already addressed by the standard. In the How to check Root metadata section, it specifies that root metadata will be updated before the time is checked. While a compromised root would be able to perform a freeze attack, a compromise of root can do much worse and is out of scope of the standard.

The TUF issue is a related issue about the time for the update as a whole, which we should discuss as part of bringing TUF and Uptane into alignment.

@cchalm
Copy link
Author

cchalm commented Dec 6, 2022

@jhdalek55 I think I'm missing something - it's not clear to me how that change to the TUF standard addresses the issue being discussed. An attacker with control of the time server's private key could spoof the current time for the purpose of both bypassing timestamp metadata expiration and (independently) spoofing the duration of the client update workflow. I don't see how they would be encumbered by the elapsed time check.

@mnm678 Compromise of the root private key is not necessary to perform a freeze attack using this chicken-and-egg loophole, an attacker can accomplish it with only the time server private key and middleman access between the Director and the vehicle. They would use the middleman access to deny knowledge of new Root metadata versions and the time server private key to indefinitely prolong the life of the desired Root metadata version. While the attacker could not sign new Root metadata, they could render the Root key holder(s) powerless to rotate compromised keys potentially forever, which is plenty dangerous.

The quoted section of the standard, I think, illustrates the problem rather than addressing it. Step 3, after the N -> N+1 iteration process, states:

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

"Check" how? If using a time server as suggested in the deployment considerations (quoted in the issue description), the implementation must verify the time using a key authorized by the very same Root metadata that we are attempting to use the time to verify, which is cyclic.

@jhdalek55
Copy link
Collaborator

@mnm678 or someone, can you address the comments above.

@mnm678
Copy link
Collaborator

mnm678 commented Jan 3, 2023

There are two parts to this: a short-term and long-term way to handle it.

The attack mentioned here only works if timeserver is compromised for a long period of time. The vehicle will look for new root metadata and check expiration on each update cycle, so whenever the timeserver is recovered, this attack would be ended.

Further, the timeserver setup in the deployment considerations is a suggestion, and will soon be replaced with international standards for time servers (NTP v5), which will be finalized soon and have a separate root of trust for the time server.

@jhdalek55
Copy link
Collaborator

Consider this for 2.2.

@cchalm
Copy link
Author

cchalm commented Jan 26, 2023

...whenever the timeserver is recovered, this attack would be ended.

In a situation where an attacker has the timeserver private key, recovering the timeserver requires rotating the timeserver key, which requires updating root metadata. If the attacker also has middleman access sufficient to spoof a "no root metadata version N+1" response to vehicles, they can prevent the timeserver key rotation indefinitely. In other words, the attacker can make it impossible to recover the timeserver.

For the long-term solution, I'm curious to know how the separate root of trust will itself avoid this cyclic verification issue. It seems like a secure source of time must derive trust in a way that doesn't rely on time, otherwise it will always hit this problem.

@mnm678
Copy link
Collaborator

mnm678 commented Jan 30, 2023

It is only unrecoverable as long as the attacker has MitM access as well as the timeserver key. If control over the network is re-established the original owner of the timeserver key could distribute the correct timestamp.

For the long-term solution, the idea is to use a root of trust outside of Uptane, as decided on by the standards groups working on NTP v5. This would then provide a source of time that is outside of Uptane, and not subject to the tradeoff you describe here.

@jhdalek55
Copy link
Collaborator

This has tentatively been slated for 2.2.0, but I'm assuming that is to resolve the larger issues connected to NTP v.5. But can we better clarify that the attack mentioned above is only a real threat if the the vehicle is offline for an extended amount of time and if the attacker has MitM access as well as the timeserver key. Can we resolve at least this much for V.2.1.0

@cchalm
Copy link
Author

cchalm commented Mar 14, 2023

It occurs to me now that the attacker capabilities I mentioned in my comments above (sign+serve malicious timeserver responses and deny the existence of Root metadata N+1) are sufficient to perpetually deny Root metadata rotation regardless of the cyclic verification problem in the title.

While the abstract problem (document contains information used to verify itself) still concerns me, I can't think of any specific attacks this expiration verification process would enable.

@jhdalek55
Copy link
Collaborator

jhdalek55 commented Mar 28, 2023

At the 3/28/23 meeting it was decided that the specific question raised here has been answered, even though the larger issue of secure time it alludes to remains unanswered. Therefore, we will close this issue and open another when we can add a reference to NTP v5.

@jhdalek55
Copy link
Collaborator

Closing this with the opening of Issue #149

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants