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

Check timestamp/snapshot contains snapshot/targets description #226

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

Check timestamp/snapshot contains snapshot/targets description #226

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
e97d6ad
Check timestamp/snapshot contains snapshot/targets version
erickt May 19, 2022
440e099
Flesh out timestamp/snapshot rollback attack resistance
erickt May 19, 2022
cc41726
Bump date and version
erickt May 20, 2022
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
86 changes: 63 additions & 23 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: 2022-04-28
Date: 2022-05-20
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.30
Text Macro: VERSION 1.0.31
</pre>

Note: We strive to make the specification easy to implement, so if you come
Expand Down Expand Up @@ -1368,20 +1368,40 @@ it in the next step.

3. **Check for a rollback attack.**

1. The version number of the trusted timestamp metadata file, if
any, MUST be less than the version number of the new timestamp
metadata file. If the new timestamp metadata version is less than the trusted
timestamp metadata version, discard it, abort the update cycle, and
report the potential rollback attack. In case they are equal, discard the new
timestamp metadata and abort the update cycle. This is normal and it
shouldn't raise any error. The reason for aborting the update process is that
there shouldn't be any changes in the content of this, or any other metadata
files too, considering it has the same version as the already trusted one.
erickt marked this conversation as resolved.
Show resolved Hide resolved

2. The version number of the snapshot metadata file in the
1. The [=metapath/VERSION=] number of the trusted timestamp metadata file, if
any, MUST be less than the [=metapath/VERSION=] number of the new timestamp
metadata file. If the new timestamp metadata version is less than the
trusted timestamp metadata version, discard it, abort the update cycle, and
report the potential rollback attack. In case they are equal, discard the
new timestamp metadata and abort the update cycle. This is normal and it
shouldn't raise any error. The reason for aborting the update process is
that there shouldn't be any changes in the content of this, or any other
metadata files too, considering it has the same version as the already
trusted one.

2. The new timestamp metadata file's [=METAFILES=] object MUST only
contain the snapshot metadata file. If not, discard the new timestamp
metadata file, abort the cycle, and report the failure.

3. The [=metapath/VERSION=] number of the snapshot metadata file in the
trusted timestamp metadata file, if any, MUST be less than or equal to its
version number in the new timestamp metadata file. If not, discard the new
timestamp metadata file, abort the update cycle, and report the failure.
[=metapath/VERSION=] number in the new timestamp metadata file. If not,
discard the new timestamp metadata file, abort the update cycle, and report
the failure.

4. If the new timestamp metadata file's [=metapath/VERSION=] number of the
snapshot metadata file is equal to the [=metapath/VERSION=] numbers in the
trusted snapshot metadata file:

1. The [=metapath/LENGTH=] in the new timestamp metadata file, if any, MUST
be equal to the [=metapath/LENGTH=] in the trusted timestamp file, if any.
If not, discard the new timestamp metadata file, abort the cycle, and
Copy link
Member

Choose a reason for hiding this comment

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

Why do we discard the new timestamp metadata? Could an attacker later roll back the timestamp file?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'm not sure if it's necessarily resisting an attack, but more about enabling the optimization where we can skip downloading metadata if we already have it locally without putting our local trusted metadata in an inconsistent state (such as in #114 and #227).

It might be helpful if we work with an example. Say we have locally trusted metadata, with Timestamp T1 and Snapshot S1, which is at version N. The remote repository is at Timestamp T1 and Snapshot S2, which also is at version N.

When we perform a client update, we will:

  • Download T2
  • Verify it was signed correctly
  • Verify that T2's snapshot description's version >= the trusted snapshot S1's version

At this point we could decide that we we already have the trusted Snapshot S1, so we could abort the update workflow. However this would be incorrect, because it's possible that Snapshot S2 could have different content than Snapshot S1. If Timestamp T2 contains the optional length and/or hashes of Snapshot S2. This means that if we create a brand new client based off the local trusted metadata, we cannot use the length/hashes from Timestamp T2 to verify Snapshot S1. This would then force us to throw away the Snapshot S1 and download the new S2 version.

This patch tries to avoid this issue by enforcing that we cannot get into this state by treating Timestamp T2 as invalid, since it doesn't match what we already trust.

This would be especially handy if we implement transactional downloading of metadata in #69 to make sure the local metadata doesn't get into an incomplete state.

Copy link
Member

Choose a reason for hiding this comment

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

The remote repository is at Timestamp T1 and Snapshot S2, which also is at version N.

Did you mean T2? You do say the client downloads T2 below. I assume this is a typo here?

Just to make sure, do I understand correctly that in your example:

  • T1 describes S1
  • T2 describes S2
  • T2 has a higher version than T1
  • S2 has the same version as S1
  • S2 and S1 have different contents

This implies that the repo has incorrectly updated snapshot and timestamp, without bumping snapshot's version number, right?

Following you proposal, the client that already trusts T1 and S1 can only update, if the repo issues a new T2 (or higher) describing a new S2, with a version number higher than S1. Is that correct? If so, I think it's fair.

report the failure.

2. For each entry in the new timestamp metadata file's [=metapath/HASHES=]
dictionary, if the key is present in the trusted timestamp metadata file,
the values MUST be equal. If not, discard the new timestamp metadata
Copy link
Member

Choose a reason for hiding this comment

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

Same comment as above here.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was covered in the above comment, so lets track it there.

file, abort the cycle, and report the failure.

4. **Check for a freeze attack.** The expiration timestamp in the
new timestamp metadata file MUST be higher than the fixed update start time.
Expand Down Expand Up @@ -1425,14 +1445,34 @@ 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
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
the update cycle, and report the failure.
5. **Check for a rollback attack**.

1. The new snapshot metadata file's [=METAFILES=] object MUST contain a
[=snapshot/METAPATH=] entry for the targets metadata file, and all delegated targets
metadata files, if any, in the trusted snapshot metadata file. If not,
discard the new snapshot metadata file, abort the cycle, and report the
Copy link
Member

Choose a reason for hiding this comment

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

Do we need to discard the snapshot file in this case? Why?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was covered in the above comment, so lets track it there.

failure.

2. The [=metapath/VERSION=] number of the targets metadata file, and all
delegated targets metadata files, if any, in the trusted snapshot metadata
file MUST be less than or equal to its [=metapath/VERSION=] number in the
new snapshot metadata file. If not, discard the new snapshot metadata
file, abort the cycle, and report the failure.

3. If the new snapshot metadata file's [=metapath/VERSION=] number of the
targets metadata file, or any delegated targets metadata files, if any, are
equal to the [=metapath/VERSION=] numbers in the trusted targets metadata
file:

1. The [=metapath/LENGTH=] in the new snapshot metadata file, if any, MUST
be equal to the [=metapath/LENGTH=] in the trusted snapshot file, if any.
If not, discard the new snapshot metadata file, abort the cycle, and
report the failure.

2. For each entry in the new snapshot metadata file's [=metapath/HASHES=]
dictionary, if the key is present in the trusted snapshot metadata file,
the values MUST be equal. If not, discard the new snapshot metadata
file, abort the cycle, and report the failure.

6. **Check for a freeze attack**. The expiration timestamp in the
new snapshot metadata file MUST be higher than the fixed update start time.
Expand Down