-
Notifications
You must be signed in to change notification settings - Fork 56
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
base: master
Are you sure you want to change the base?
Changes from 1 commit
0e76a17
8a20ecf
33c221b
4bceaf4
869129c
0ca0b7e
6446585
1706edf
bac0c55
7726374
3de7f6e
159c0e8
c2e206f
495370d
d9e0596
eed4388
be71c07
8652ff5
180e9db
9698015
40e3e7c
e50151d
07a46db
e5c0729
5441368
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -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) | ||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @hosseinsia thoughts? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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 | ||
mnm678 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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]]). | ||
|
||
|
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.
Let's link to our own copies.