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.

Sign up for GitHub

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

Rollback attacks and fast forward recovery #150

Open
wants to merge 25 commits into
base: master
Choose a base branch
from
Open

Rollback attacks and fast forward recovery #150

Changes from all commits
Commits
Show all changes
25 commits
Select commit Hold shift + click to select a range
0e76a17
Clarify how delegated roles are downloaded
erickt Dec 7, 2019
8a20ecf
Fix typos in client application workflow
lukpueh Jan 29, 2020
33c221b
Add freeze attack check for delegated targets
lukpueh Jan 29, 2020
4bceaf4
Adopt reporting wording for delegated targets
lukpueh Jan 29, 2020
869129c
Clarify recovery from ffwd on top-level roles
mnm678 Jan 22, 2020
0ca0b7e
Clarify recovery from ffwd on top-level targets
lukpueh Jan 29, 2020
6446585
Clarify recovery from ffwd on delegated targets
lukpueh Jan 30, 2020
1706edf
Add details about ffwd attacker goals
lukpueh Feb 4, 2020
bac0c55
Replace DELEGATE with DELEGATEE
lukpueh Feb 11, 2020
7726374
Revise rollback attack prevention and ffwd recovery again (WIP)
lukpueh Sep 1, 2020
3de7f6e
Remove delegated targets fast-forward check
mnm678 Feb 25, 2021
159c0e8
Remove redundant rollback checks
mnm678 Feb 25, 2021
c2e206f
Remove redundant description of delegated targests fast forward recovery
mnm678 Mar 4, 2021
495370d
Define DELEGATOR in targets workflow before the DFS loop
mnm678 May 13, 2021
d9e0596
Update tuf-spec.md
mnm678 May 13, 2021
eed4388
Re-order the client workflow
mnm678 May 20, 2021
be71c07
Fix typo and section cross-reference
mnm678 May 24, 2021
8652ff5
Make delegated targets freeze attack consistent
mnm678 May 24, 2021
180e9db
Update date and version
mnm678 May 24, 2021
9698015
Remove reference to TAP 3
mnm678 Aug 19, 2021
40e3e7c
Make the snapshot checks for delegations match top-level targets
mnm678 Aug 19, 2021
e50151d
Remove TAP 3 residual
mnm678 Aug 19, 2021
07a46db
Simplify fast-forward attack recovery
mnm678 Sep 10, 2021
e5c0729
Update tuf-spec.md
mnm678 Sep 13, 2021
5441368
Merge branch 'master' into client-verification
mnm678 Sep 13, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
95 changes: 70 additions & 25 deletions tuf-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3,7 +3,7 @@ Title: The Update Framework Specification
Shortname: TUF
Status: LS
Abstract: A framework for securing software update systems.
Date: 2021-09-07
Date: 2021-09-13
Editor: Justin Cappos, NYU
Editor: Trishank Karthik Kuppusamy, Datadog
Editor: Joshua Lock, VMware
Expand All @@ -16,7 +16,7 @@ Boilerplate: copyright no, conformance no
Local Boilerplate: header yes
Markup Shorthands: css no, markdown yes
Metadata Include: This version off, Abstract off
Text Macro: VERSION 1.0.25
Text Macro: VERSION 1.0.26
</pre>

Note: We strive to make the specification easy to implement, so if you come
Expand Down Expand Up @@ -1334,15 +1334,22 @@ it in the next step.
report the potential freeze attack. On the next update cycle, begin at step
[[#update-root]] and version N of the root metadata file.

11. **If the timestamp and / or snapshot keys have been rotated, then delete the
trusted timestamp and snapshot metadata files.** This is done
in order to recover from fast-forward attacks after the repository has been
compromised and recovered. A *fast-forward attack* happens when attackers
arbitrarily increase the version numbers of: (1) the timestamp metadata, (2)
the snapshot metadata, and / or (3) the targets, or a delegated targets,
metadata file in the snapshot metadata. Please see [the Mercury
paper](https://theupdateframework.io/papers/prevention-rollback-attacks-atc2017.pdf)
for more details.
11. **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's 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 a fast-forward attack after the repository has been
compromised and recovered, certain metadata files need to be deleted as
specified in this section. If a targets file is subjected to a
fast-forward attack, the snapshot role's keys should be replaced. Please see
[the Mercury paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[the Mercury paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf)
[the Mercury paper](https://theupdateframework.io/papers/prevention-rollback-attacks-atc2017.pdf)

Let's link to our own copies.

for more details on fast-forward attacks.

1. **Snapshot recovery** If the trusted snapshot metadata cannot be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hosseinsia thoughts?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is clever. I like it! So at least a combination of non-revoked keys should have signed the metadata?
And an attacker who uses the compromised keys to sign metadata won't succeed.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: we don't clearly define what a trusted metadata file is, see #179. Given the implications via this PR and the importance of that term for rollback attack protection, we should address that.

validated using a threshold of snapshot keys from the new trusted root
metadata, delete the trusted snapshot and timestamp metadata
files.
Comment on lines +1349 to +1352
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the core idea here is correct but I'm still not sure it makes sense to put the heuristic part into the client (that client must revoke trust on a correctly signed, valid timestamp just because snapshot is not signed). If snapshot key has been compromised and used to create snapshot version 1billion and timestamp process has accepted that into a timestamp, what prevents us from saying that the timestamp keys must then be rotated to enable rollback?

The client workflow is already complicated and quite tricky to implement: much more difficult than reading the spec text implies. Every addition like this makes it more complex, and it feels like things are added to client workflow partly because the repository workflows are not defined so things can't be added there.

I think the well defined ffwd recoveries are based on the repository rotating keys, and client taking care to not use untrusted metadata to do rollback checks:

  • if snapshot version must be rolled back, timestamp keys must be rotated (meaning timestamp keys should be modified so that all timestamps with "compromised snapshot versions" are no longer correctly signed, and will not be used for rollback checks by the client
  • if any targets versions must be rolled back (or removed from snapshot), snapshot keys must be rotated (meaning snapshot keys should be modified so that all snapshots with "compromised targets data" are no longer correctly signed, and will not be used for rollback checks by the client

For the client this creates basically no complexity: it just follows the basic rule, only believe trusted, correctly signed metadata. I don't think it puts an unfair burden on the repository either:

  • Some of its keys have been compromised
  • the online processes failed to prevent the ffwd (especially targets ffwd should be completely preventable)
  • we're only asking for online key rotation

The second issue is a nitpick and I don't expect you to change this as it uses language already in the spec but I'll mention it: my opinion is that we should stop talking about "deleting files", or at least make that a secondary aspect: what is important is that the client should not consider the metadata trusted anymore (in practice, we might want to say out loud why exactly we do this: the existing, now untrusted, metadata should not be used to do rollback checks on the new metadata)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In fact, how would this heuristic even work in practice:

  • client has a timestamp with snapshot version==1billion
  • client starts a refresh, downloads root, then downloads new timestamp with snapshot version==1
  • client sees a rollback attack, stops the update and never even downloads the snapshot that would include the heuristic that would make the valid timestamp now invalid

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree that we should separate back out the timestamp vs snapshot recovery. Looking at it again, I actually don't think this check is in the right place in the workflow. I think the timestamp recovery should happen when the timestamp is downloaded, not as part of the root metadata workflow, and the same for snapshot. Especially as it is no longer tied to anything in the previous root metadata file.

It would be great to have separate documentation for the repository workflow. Right now all the advise for managing a fast forward attack (and a lot of other pieces) is buried here in the client workflow.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Friends, but this is where and what we recommend in the Mercury paper. See "5.3 Recovering from a repository compromise" on page 7.

This is getting contentious enough (for good reasons) that I'm not sure that endless cycles of reviews and comments would do sufficient justice. A meeting hasn't solved the problem either. Perhaps it's time for the BDFL to step in and make a decision one way or another? @JustinCappos

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be great to have separate documentation for the repository workflow. Right now all the advise for managing a fast forward attack (and a lot of other pieces) is buried here in the client workflow.

💯 I've filed #186 to track this

The second issue is a nitpick and I don't expect you to change this as it uses language already in the spec but I'll mention it: my opinion is that we should stop talking about "deleting files", or at least make that a secondary aspect: what is important is that the client should not consider the metadata trusted anymore (in practice, we might want to say out loud why exactly we do this: the existing, now untrusted, metadata should not be used to do rollback checks on the new metadata)

Added this notion of changing from "delete file" to "stop trusting" to #103

Friends, but this is where and what we recommend in the Mercury paper. See "5.3 Recovering from a repository compromise" on page 7.

Mercury tells us "the online keys used to sign snapshot metadata can be revoked and replaced with new keys." and "The root-of-trust metadata indicates which keys can be trusted for verifying metadata files, including snapshot metadata files. This leads to a seamless and automatic recovery from fast-forward attacks after a repository compromise."

This seems to state that root metadata indicates which keys can be used for verifying trusted metadata. That is, that key rotation is the correct way to recover from fast-forward attacks and that rollback protection is only provided for top-level metadata which is trusted by the current root metadata.


12. **Set whether consistent snapshots are used as per the trusted**
root metadata file (see [[#file-formats-root]]).
Expand Down Expand Up @@ -1416,10 +1423,10 @@ it in the next step.
in the trusted timestamp metadata. If the versions do not match, discard the
new snapshot metadata, abort the update cycle, and report the failure.

5. **Check for a rollback attack**. The version number of the targets
metadata file, and all delegated targets metadata files, if any, in the
trusted snapshot metadata file, if any, MUST be less than or equal to its
version number in the new snapshot metadata file. Furthermore, any targets
5. **Check for a rollback attack**. 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. If any of
these conditions are not met, discard the new snapshot metadata file, abort
Expand All @@ -1431,7 +1438,6 @@ it in the next step.
file. If the new snapshot metadata file is expired, discard it, abort the
update cycle, and report the potential freeze attack.


7. **Persist snapshot metadata**. The client MUST write the file to
non-volatile storage as FILENAME.EXT (e.g. snapshot.json).

Expand Down Expand Up @@ -1475,10 +1481,9 @@ it in the next step.
6. **Persist targets metadata**. The client MUST write the file to
non-volatile storage as FILENAME.EXT (e.g. targets.json).

7. **Perform a pre-order depth-first search for metadata about the
desired target, beginning with the top-level targets role.** Note: If
any metadata requested in steps 5.6.7.1 - 5.6.7.2 cannot be downloaded nor
validated, end the search and report that the target cannot be found.
7. **Perform a preorder depth-first search for metadata about the
desired target.** Let DELEGATOR refer to the current
top-level targets metadata role.
Comment on lines +1485 to +1486
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
desired target.** Let DELEGATOR refer to the current
top-level targets metadata role.
desired target.** Let DELEGATOR refer to the
top-level targets metadata role.

At first I thought we were re-defining top-level targets metadata for each cycle, but then I realised by current you just mean the current trusted. I think that's implicit but either a) let's drop current or b) let's make it explicit


1. If this role has been visited before, then skip this role
(so that cycles in the delegation graph are avoided). Otherwise, if an
Expand All @@ -1490,13 +1495,53 @@ it in the next step.
2. Otherwise, recursively search the list of delegations in
order of appearance.

1. If the current delegation is a terminating delegation,
1. Let DELEGATEE denote
the current target role DELEGATOR is delegating to.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't this be an error instead of just "not found": there was a delegation but metadata for the delegated role could not be downloaded, this sounds like a repository error to me

consistent snapshots are not used (see Section
[[#consistent-snapshots]]), 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.

3. **Check against snapshot role's hash.** The hashes of the new DELEGATEE
metadata file MUST match the hashes, if any, 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. **Check for an arbitrary software attack.** The new DELEGATEE
metadata file MUST have been signed by a threshold of keys specified in the
DELEGATOR metadata file. If the new DELEGATEE metadata file is not signed
as required, abort the update cycle, and report the failure.

5. **Check against snapshot role's version**. The version number of the new
DELEGATEE metadata file MUST match the version number, if any, listed in
the trusted snapshot metadata. If the versions do not match, discard it,
abort the update cycle, and report the failure.

6. **Check for a freeze attack.** The expiration timestamp in new
DELEGATEE metadata file MUST be higher than the fixed update start time.
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.

7. If the current delegation is a terminating delegation,
then jump to step [[#fetch-target]].

2. Otherwise, if the current delegation is a
non-terminating delegation, continue processing the next delegation, if
any. Stop the search, and jump to step [[#fetch-target]] as soon as a delegation
returns a result.
8. Otherwise, if the current delegation is a non-terminating
delegation, continue processing the next delegation, if any, by repeating
the preorder depth-first search with the DELEGATEE as the DELEGATOR.
Stop the search, and jump to step [[#fetch-target]] as soon as a
delegation returns a result.

## Fetch target ## {#fetch-target}

Expand Down