From 64d1bcf3c7884ee018c5736d701a42e60c2fefdc Mon Sep 17 00:00:00 2001 From: marinamoore Date: Wed, 22 Jan 2020 12:41:11 -0500 Subject: [PATCH 1/4] Clarify what files to delete after ffwd attack Clarify what files to delete in various situations to recover from a fast-forward attack. In addition, this adds additional rollback protection in the event of a timestamp compromise. --- tuf-spec.md | 53 +++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 37 insertions(+), 16 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 7e7225c..7a78191 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1116,16 +1116,26 @@ repo](https://github.com/theupdateframework/specification/issues). cycle, report the potential freeze attack. On the next update cycle, begin at step 0 and version N of the root metadata file. - * **1.9**. **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://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf) + * **1.9**. **Fast-forward attack recovery** 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. To recover from fast-forward + attacks after the repository has been compromised and recovered, certain + metadata files need to be deleted as specified in this section. Please see + [the Mercury paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf) for more details. + * **1.9.1**. **Targets recovery** If a threshold of targets keys are removed + from the root metadata, delete the old targets, snapshot, and timestamp + metadata files. + + * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys are + removed from the root metadata, delete the old snapshot and timestamp + metadata files. + + * **1.9.3**. **Timestamp recovery** If a threshold of timestamp keys are + removed from the root metadata, delete the old timestamp metadata file. + * **1.10**. **Set whether consistent snapshots are used as per the trusted root metadata file** (see Section 4.3). @@ -1222,36 +1232,47 @@ non-volatile storage as FILENAME.EXT. trusted root metadata file. If the new targets metadata file is not signed as required, discard it, abort the update cycle, and report the failure. - * **4.3**. **Check for a freeze attack.** The latest known time should be + * **4.3**. **Check for a rollback attack.** The version number of the trusted + targets metadata file, if any, MUST be less than or equal to the version + number of the new targets metadata file. If the new targets metadata file is + older than the trusted targets metadata file, discard it, abort the update + cycle, and report the potential rollback attack. + + * **4.4**. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in the new targets metadata file. If so, the new targets metadata file becomes the trusted targets metadata file. If the new targets metadata file is expired, discard it, abort the update cycle, and report the potential freeze attack. - * **4.4**. **Perform a preorder depth-first search for metadata about the + * **4.5**. **Fast-forward attack recovery** If a threshold of delegated + targets keys for a role are removed from the delegating targets metadata, + delete the old delegated targets metadata for that role along with the + snapshot and timestamp metadata. + + * **4.6**. **Perform a preorder depth-first search for metadata about the desired target, beginning with the top-level targets role.** Note: If any metadata requested in steps 4.4.1 - 4.4.2.3 cannot be downloaded nor validated, end the search and report that the target cannot be found. - * **4.4.1**. If this role has been visited before, then skip this role (so + * **4.6.1**. If this role has been visited before, then skip this role (so that cycles in the delegation graph are avoided). Otherwise, if an application-specific maximum number of roles have been visited, then go to step 5 (so that attackers cannot cause the client to waste excessive bandwidth or time). Otherwise, if this role contains metadata about the desired target, then go to step 5. - * **4.4.2**. Otherwise, recursively search the list of delegations in order + * **4.6.2**. Otherwise, recursively search the list of delegations in order of appearance. - * **4.4.2.1**. If the current delegation is a multi-role delegation, + * **4.6.2.1**. If the current delegation is a multi-role delegation, recursively visit each role, and check that each has signed exactly the same non-custom metadata (i.e., length and hashes) about the target (or the lack of any such metadata). - * **4.4.2.2**. If the current delegation is a terminating delegation, + * **4.6.2.2**. If the current delegation is a terminating delegation, then jump to step 5. - * **4.4.2.3**. Otherwise, if the current delegation is a non-terminating + * **4.6.2.3**. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any. Stop the search, and jump to step 5 as soon as a delegation returns a result. @@ -1381,7 +1402,7 @@ non-volatile storage as FILENAME.EXT. snapshots are not written by the repository, then the attribute may either be left unspecified or be set to the False value. Otherwise, it must be set to the True value. - + Regardless of whether consistent snapshots are ever used or not, all released versions of root metadata files should always be provided so that outdated clients can update to the latest available root. From 886fe69a6de66cf4e6161e7ce860087de8389aed Mon Sep 17 00:00:00 2001 From: marinamoore Date: Thu, 23 Jan 2020 10:51:37 -0500 Subject: [PATCH 2/4] Ffwd can happen in various places, not just snapshot --- tuf-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 7a78191..51297cd 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -214,7 +214,7 @@ repo](https://github.com/theupdateframework/specification/issues). * This version (1.0.0) of the specification adheres to the following TAPS: - - [TAP 3](https://github.com/theupdateframework/taps/blob/master/tap3.md): + - [TAP 3](https://github.com/theupdateframework/taps/blob/master/tap3.md): Multi Role Delegations - [TAP 4](https://github.com/theupdateframework/taps/blob/master/tap4.md): Multiple Repository Consensus on entrusted targets @@ -1119,7 +1119,7 @@ repo](https://github.com/theupdateframework/specification/issues). * **1.9**. **Fast-forward attack recovery** 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. To recover from fast-forward + targets, metadata file. To recover from fast-forward attacks after the repository has been compromised and recovered, certain metadata files need to be deleted as specified in this section. Please see [the Mercury paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf) From 5b2c323be34b2989c3fa1daf5abb259a3031cac4 Mon Sep 17 00:00:00 2001 From: marinamoore Date: Thu, 23 Jan 2020 15:02:46 -0500 Subject: [PATCH 3/4] Check for ffwd attack during preorder DFS --- tuf-spec.md | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 51297cd..3483893 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1126,8 +1126,8 @@ repo](https://github.com/theupdateframework/specification/issues). for more details. * **1.9.1**. **Targets recovery** If a threshold of targets keys are removed - from the root metadata, delete the old targets, snapshot, and timestamp - metadata files. + from the root metadata, delete the old top-level targets, snapshot, and + timestamp metadata files. * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys are removed from the root metadata, delete the old snapshot and timestamp @@ -1244,35 +1244,35 @@ non-volatile storage as FILENAME.EXT. the new targets metadata file is expired, discard it, abort the update cycle, and report the potential freeze attack. - * **4.5**. **Fast-forward attack recovery** If a threshold of delegated - targets keys for a role are removed from the delegating targets metadata, - delete the old delegated targets metadata for that role along with the - snapshot and timestamp metadata. - - * **4.6**. **Perform a preorder depth-first search for metadata about the + * **4.5**. **Perform a preorder depth-first search for metadata about the desired target, beginning with the top-level targets role.** Note: If any metadata requested in steps 4.4.1 - 4.4.2.3 cannot be downloaded nor validated, end the search and report that the target cannot be found. - * **4.6.1**. If this role has been visited before, then skip this role (so + * **4.5.1**. If this role has been visited before, then skip this role (so that cycles in the delegation graph are avoided). Otherwise, if an application-specific maximum number of roles have been visited, then go to step 5 (so that attackers cannot cause the client to waste excessive bandwidth or time). Otherwise, if this role contains metadata about the desired target, then go to step 5. - * **4.6.2**. Otherwise, recursively search the list of delegations in order + * **4.5.2**. Otherwise, recursively search the list of delegations in order of appearance. - * **4.6.2.1**. If the current delegation is a multi-role delegation, + * **4.5.2.1**. **Fast-forward attack recovery** If a threshold of + delegated targets keys for the current delegation are removed from the + delegating targets metadata, delete the old delegated targets metadata for + the current delegation along with the snapshot and timestamp metadata. + + * **4.5.2.1**. If the current delegation is a multi-role delegation, recursively visit each role, and check that each has signed exactly the same non-custom metadata (i.e., length and hashes) about the target (or the lack of any such metadata). - * **4.6.2.2**. If the current delegation is a terminating delegation, + * **4.5.2.2**. If the current delegation is a terminating delegation, then jump to step 5. - * **4.6.2.3**. Otherwise, if the current delegation is a non-terminating + * **4.5.2.3**. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any. Stop the search, and jump to step 5 as soon as a delegation returns a result. From 64305b36ae5d2829c70f7bf1d317f7a948571b83 Mon Sep 17 00:00:00 2001 From: marinamoore Date: Fri, 24 Jan 2020 12:13:03 -0500 Subject: [PATCH 4/4] Clarify that top-level targets and delgated targets can both delegate --- tuf-spec.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 3483893..d1bc41d 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1261,8 +1261,11 @@ non-volatile storage as FILENAME.EXT. * **4.5.2.1**. **Fast-forward attack recovery** If a threshold of delegated targets keys for the current delegation are removed from the - delegating targets metadata, delete the old delegated targets metadata for - the current delegation along with the snapshot and timestamp metadata. + delegating targets metadata (either the top-level targets or delegated + targets metadata that provided the current delegation), delete the old + delegated targets metadata for the current delegation along with the + snapshot and timestamp metadata. Skip this step if the current delegation + is the top-level targets role. * **4.5.2.1**. If the current delegation is a multi-role delegation, recursively visit each role, and check that each has signed exactly the