Skip to content

Rollback attacks and fast forward recovery #150

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

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

Rollback attacks and fast forward recovery #150

Changes from 1 commit
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
Jan 29, 2020
33c221b
Add freeze attack check for delegated targets
Jan 29, 2020
4bceaf4
Adopt reporting wording for delegated targets
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
Jan 29, 2020
6446585
Clarify recovery from ffwd on delegated targets
Jan 30, 2020
1706edf
Add details about ffwd attacker goals
lukpueh Feb 4, 2020
bac0c55
Replace DELEGATE with DELEGATEE
Feb 11, 2020
7726374
Revise rollback attack prevention and ffwd recovery again (WIP)
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
18 changes: 4 additions & 14 deletions tuf-spec.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1334,26 +1334,16 @@ it in the next step.
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 delegated targets file is subjected to a
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
Copy Markdown
Member

@joshuagl joshuagl Sep 21, 2021

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. **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 this only applies to top-level targets metadata whose
keys are listed in root metadata.

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
1. **Snapshot recovery** If the trusted snapshot metadata cannot be
Copy link
Copy Markdown
Contributor

@trishankatdatadog trishankatdatadog Sep 13, 2021

Choose a reason for hiding this comment

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

@hosseinsia thoughts?

Copy link
Copy Markdown

@hosseinsia hosseinsia Sep 13, 2021

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

@joshuagl joshuagl Sep 21, 2021

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.

validating 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
Copy Markdown
Member

@jku jku Sep 17, 2021

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

@jku jku Sep 17, 2021

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
Copy Markdown
Collaborator Author

@mnm678 mnm678 Sep 17, 2021

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
Copy Markdown
Contributor

@trishankatdatadog trishankatdatadog Sep 17, 2021

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

@joshuagl joshuagl Sep 21, 2021

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.


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.

12. **Set whether consistent snapshots are used as per the trusted**
root metadata file (see [[#file-formats-root]]).

Expand Down