Clarify rollback attack prevention and fast-forward attack recovery #86
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -1133,15 +1133,34 @@ repo](https://github.com/theupdateframework/specification/issues). | |
| cycle, report the potential freeze attack. On the next update cycle, begin | ||
| at step 0 and version N of the root metadata file. | ||
|
|
||
| * **1.9**. **Fast-forward attack recovery** A _fast-forward attack_ happens | ||
| when attackers arbitrarily increase the version numbers in any of the | ||
| timestamp, snapshot, targets, or delegated targets metadata. The attacker goal | ||
| is to cause clients to refuse to update the metadata later because the attacker's | ||
| listed metadata version number (possibly MAX_INT) is greater than the new valid | ||
| version. To recover from | ||
| fast-forward attacks after the repository has been compromised and recovered, | ||
| certain metadata files need to be deleted as specified in this section. | ||
| Please see [the Mercury | ||
| paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf) | ||
| for more details on fast-forward attacks. | ||
|
|
||
| * **1.9.1**. **Targets recovery** If a threshold of targets keys have been | ||
| removed in the new trusted root metadata compared to the previous trusted | ||
| root metadata, delete the old top-level targets and snapshot metadata | ||
| files. Note that delegated targets are suceptible to fast forward attacks, | ||
| because snapshot must be checked before a key rotation in the delegating | ||
| target role is known to the client. To fix this, nuke delegation or make | ||
| repository rotate the the snapshot key. | ||
|
|
||
| * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys have | ||
| been removed in the new trusted root metadata compared to the previous | ||
| trusted root metadata, delete the old snapshot and timestamp metadata | ||
| files. | ||
|
|
||
| * **1.9.3**. **Timestamp recovery** If a threshold of timestamp keys have | ||
| been removed from the new trusted root metadata compared to the previous | ||
| trusted root metadata, delete the old timestamp metadata file. | ||
|
|
||
| * **1.10**. **Set whether consistent snapshots are used as per the trusted | ||
| root metadata file** (see Section 4.3). | ||
|
|
@@ -1207,14 +1226,13 @@ non-volatile storage as FILENAME.EXT. | |
| metadata file, discard it, abort the update cycle, and report the potential | ||
| rollback attack. | ||
|
|
||
| * **3.3.2**. The version number of all targets metadata files in | ||
| the trusted snapshot metadata file, if any, MUST be less than or equal to | ||
| their version numbers in the new snapshot metadata file. Furthermore, any | ||
| targets metadata filename that was listed in the trusted snapshot metadata | ||
| file, if any, MUST continue to be listed in the new snapshot metadata file. | ||
|
There was a problem hiding this comment. Hold on, why are we not checking that every version number for every targets metadata file (including delegations) in the previous snapshot, if any, is <= the current metadata file? There was a problem hiding this comment. It's described in detail in the corresponding commit message (65e042d). The TLDR is, at this point in the process we don't know if any delegated targets keys were removed and we thus need to skip the rollback check. There was a problem hiding this comment. Hmmm, this basically breaks the workflow described in the Mercury paper, unless we're doing it elsewhere. There was a problem hiding this comment. The check in 4.5.2.7 looks for rollback attacks on delegated targets. Does that cover the workflow from the Mercury paper? There was a problem hiding this comment. Doesn't look like it, because Mercury prescribes checking vernum of every targets metadata file. There was a problem hiding this comment. All targets files. Isn't this the Mercury workflow for snapshot? There was a problem hiding this comment. @trishankatdatadog If a fast forward attack occurs in a delegated targets file, does root still rotate timestamp and snapshot? This may require coordination between an independent developer who owns the delegated target and the repository manager which could slow the recovery time. If the root still rotates, then the check in 4.5.2.7 could be moved back up here. There was a problem hiding this comment. I see. Hmm, this requires careful thinking and modeling. I want to make sure we cover all of our bases. Right now, it doesn't look like it, but maybe I'm wrong. There was a problem hiding this comment. Thanks for helping to clarify, @mnm678!
Can you elaborate, @trishankatdatadog? Why does it not look like we cover all of our bases? Maybe we should discuss this in person? There was a problem hiding this comment. Yes, I think we need a meeting. |
||
| If any of these conditions are not met, discard the new snapshot metadadata | ||
| file, abort the update cycle, and report the failure. | ||
|
|
||
| * **3.4**. **Check for a freeze attack.** The latest known time should be | ||
| lower than the expiration timestamp in the new snapshot metadata file. If | ||
|
|
@@ -1245,38 +1263,86 @@ non-volatile storage as FILENAME.EXT. | |
| trusted root metadata file. If the new targets metadata file is not signed | ||
| as required, discard it, abort the update cycle, and report the failure. | ||
|
|
||
| * **4.3**. **Check for a rollback attack.** The version number of the trusted | ||
| targets metadata file, if any, MUST be less than or equal to the version | ||
| number of the new targets metadata file. If the new targets metadata file is | ||
| older than the trusted targets metadata file, discard it, abort the update | ||
| cycle, and report the potential rollback attack. | ||
|
|
||
| * **4.4**. **Check for a freeze attack.** The latest known time should be | ||
| lower than the expiration timestamp in the new targets metadata file. If so, | ||
| the new targets metadata file becomes the trusted targets metadata file. If | ||
| the new targets metadata file is expired, discard it, abort the update cycle, | ||
| and report the potential freeze attack. | ||
|
|
||
| * **4.5**. **Perform a preorder depth-first search for metadata about the | ||
| desired target.** Let TARGETS be the current metadata, beginning with the | ||
| top-level targets metadata role. | ||
|
|
||
| * **4.5.1**. If this role has been visited before, then skip this role (so | ||
| that cycles in the delegation graph are avoided). Otherwise, if an | ||
| application-specific maximum number of roles have been visited, then go to | ||
| step 5 (so that attackers cannot cause the client to waste excessive | ||
| bandwidth or time). Otherwise, if this role contains metadata about the | ||
| desired target, then go to step 5. | ||
|
|
||
| * **4.5.2**. Otherwise, recursively search the list of delegations in order | ||
| of appearance. | ||
|
|
||
| * **4.5.2.1**. Let DELEGATEE denote the current target role TARGETS is | ||
| delegating to. | ||
|
|
||
| * **4.5.2.2**. **Download the DELEGATEE targets metadata file**, up to either | ||
| the number of bytes specified in the snapshot metadata file, or some Z | ||
| number of bytes. The value for Z is set by the authors of the application | ||
| using TUF. For example, Z may be tens of kilobytes. IF DELEGATEE cannot be | ||
| found, end the search and report the target cannot be found. If | ||
| consistent snapshots are not used (see Section 7), then the filename used | ||
| to download the targets metadata file is of the fixed form FILENAME.EXT | ||
| (e.g., delegated_role.json). Otherwise, the filename is of the form | ||
| VERSION_NUMBER.FILENAME.EXT (e.g., 42.delegated_role.json), where | ||
| VERSION_NUMBER is the version number of the DELEGATEE metadata file listed | ||
| in the snapshot metadata file. In either case, the client MUST write the | ||
| file to non-volatile storage as FILENAME.EXT. | ||
|
|
||
| * **4.5.2.3**. **Check against snapshot metadata.** The hashes and | ||
| version number of the new DELEGATEE metadata file MUST match the hashes | ||
| (if any) and version number listed in the trusted snapshot metadata. This | ||
| is done, in part, to prevent a mix-and-match attack by man-in-the-middle | ||
| attackers. If the new DELEGATEE metadata file does not match, abort the | ||
| update cycle, and report the failure. | ||
|
|
||
| * **4.5.2.4**. **Check for an arbitrary software attack.** The new DELEGATEE | ||
| metadata file MUST have been signed by a threshold of keys specified in the | ||
| TARGETS metadata file. If the new DELEGATEE metadata file is not signed | ||
| as required, abort the update cycle, and report the failure. | ||
|
|
||
| * **4.5.2.5**. **Check for a rollback attack.** | ||
| The version number of the trusted DELEGATEE metadata file, if any, MUST be | ||
| less than or equal to the version number of the new DELEGATEE metadata | ||
| file. If the new DELEGATEE metadata file is older than the trusted | ||
| DELEGATEE metadata file abort the update cycle, and report the potential | ||
| rollback attack. | ||
|
|
||
| * **4.5.2.6**. **Check for a freeze attack.** The latest known time | ||
| should be lower than the expiration timestamp in the new DELEGATEE | ||
| metadata file. If so, the new DELEGATEE file becomes the trusted DELEGATEE | ||
| file. If the new DELEGATEE metadata file is expired, abort the update | ||
| cycle, and report the potential freeze attack. | ||
|
|
||
| * **4.5.2.7**. If the current delegation is a multi-role delegation, | ||
| recursively visit each role, and check that each has signed exactly the | ||
| same non-custom metadata (i.e., length and hashes) about the target (or | ||
| the lack of any such metadata). Otherwise, abort the update cycle, and | ||
| report the failure. | ||
|
|
||
| * **4.5.2.8**. If the current delegation is a terminating delegation, | ||
| then jump to step 5. | ||
|
|
||
| * **4.5.2.9**. Otherwise, if the current delegation is a non-terminating | ||
| delegation, continue processing the next delegation, if any, by repeating | ||
| step 4.5 with DELEGATEE as the current TARGET role. Stop the search, and | ||
| jump to step 5 as soon as a delegation returns a result. | ||
|
There was a problem hiding this comment. Would it perhaps be a little clearer if 4.5.2.10 said something like
and remove the "Stop the search, ..." sentence from 4.5.2.11 ? Is there a logical difference in having this part here rather than 4.5.2.10 that I'm missing? |
||
|
|
||
| **5**. **Verify the desired target against its targets metadata**. | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You talk about top-level targets below, but not here. Do you mean to differentiate them? Does any delegated role's key loss result in the top-level targets file being deleted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do mean top-level targets keys here too. I thought that might be clear, because root metadata only lists top-level targets keys.
Regarding your other question, why would we delete the top-level targets file if any delegated role's key is lost? There is a detailed explanation about ffwd-recovery when delegated targets keys have been compromised in the commit message of 65e042d. Does that answer your question?