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

Rollback attacks and fast forward recovery #150

Open
wants to merge 25 commits into
base: master
Choose a base branch
from
Open
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
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
18 changes: 4 additions & 14 deletions tuf-spec.md
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
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. **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
Member

Choose a reason for hiding this comment

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

@hosseinsia thoughts?

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.

validating using a threshold of snapshot keys from the new trusted root
metadata, delete the trusted snapshot and timestamp metadata
files.

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