-
Notifications
You must be signed in to change notification settings - Fork 8
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
Comments
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 |
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. |
@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" 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. |
@mnm678 or someone, can you address the comments above. |
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. |
Consider this for 2.2. |
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. |
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. |
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 |
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. |
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. |
Closing this with the opening of Issue #149 |
From https://uptane.github.io/deployment-considerations/repositories.html#changes-to-the-director-repository:
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:
How should this cycle be broken?
The text was updated successfully, but these errors were encountered: