From 0ecf9801f188514a2b9217473d721ed4cc649b4a Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 11:39:08 +0100 Subject: [PATCH 01/12] Revert "Remove 2nd targets rollback attack check" This reverts commit 2eccb595628471bcee820f61faa64c2b96a3df60. 2eccb595628471bcee820f61faa64c2b96a3df60 removed rollback attack check for top-level targets file, which is (1) redundant and (2) prevents recovery from a fast-forward attack (see commit message for details). This commit reverts the change, because the redundancy (1) is actually desired, so that an attacker does not only have to compromise timestamp, but snapshot and (delegated) targets too, in order to launch rollback attacks. Fast-forward attack recovery (2) shall be fixed in a subsequent comment. --- tuf-spec.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index f24d683..6f9abcc 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1245,36 +1245,42 @@ 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**. **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 + any metadata requested in steps 4.5.1 - 4.5.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.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.4.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.4.2.1**. If the current delegation is a multi-role delegation, + * **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.4.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.4.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 75ac163d22a4afb4332b38008d77470cc801f63f Mon Sep 17 00:00:00 2001 From: Erick Tryzelaar Date: Fri, 6 Dec 2019 16:23:06 -0800 Subject: [PATCH 02/12] Clarify how delegated roles are downloaded Section 5.4.5 is a little vague how on delegated targets are fetched and validated. This updates that section to use the same logic and verification process as downloading the top-level targets role to be explicit. One thing to point out though is that the old section 4.5 suggests that we don't report verification errors to the user. I've preserved this in my explicit version. I imagine users would still be notified if their delegated roles may be undergoing an attack. Is this intentional, or should I switch to the "abort the update cycle, and report the potential rollback attack"-style phrasing used elsewhere in the spec? --- tuf-spec.md | 54 ++++++++++++++++++++++++++++++++++++++++++++--------- 1 file changed, 45 insertions(+), 9 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 6f9abcc..a4280ea 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1258,9 +1258,8 @@ non-volatile storage as FILENAME.EXT. and report the potential freeze attack. * **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.5.1 - 4.5.2.3 cannot be downloaded nor - validated, end the search and report that the target cannot be found. + desired target.** Let TARGETS be the current metadata, beginning with the + top-level targets metadata role. * **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 @@ -1272,17 +1271,54 @@ non-volatile storage as FILENAME.EXT. * **4.5.2**. Otherwise, recursively search the list of delegations in order of appearance. - * **4.5.2.1**. If the current delegation is a multi-role delegation, + * **4.5.2.1**. Let DELEGATE denote the current target role TARGETS is + delegating to. + + * **4.5.2.2**. **Download the DELEGATE tarets metadata file**, up to either + the number of bytes specified in the snapshot metadata file, or some Z + number of bytes. The value for Z is set by the authors of the application + using TUF. For example, Z may be tens of kilobytes. IF DELEGATE cannot be + found, end the search and report the target cannot be found. If + consistent snapshots are not used (see Section 7), then the filename used + to download the targets metadata file is of the fixed form FILENAME.EXT + (e.g., delegated_rol.json). Otherwise, the filename is of the form + VERSION_NUMBER.FILENAME.EXT (e.g., 42.delegated_role.json), where + VERSION_NUMBER is the version number of the DELEGATE metadata file listed + in the snapshot metadata file. In either case, the client MUST write the + file to non-volatile storage as FILENAME.EXT. + + * **4.5.2.3**. **Check against snapshot metadata.** The hashes (if any), and + version number of the new DELEGATE metadata file MUST match the trusted + snapshot metadata. This is done, in part, to prevent a mix-and-match + attack by man-in-the-middle attackers. If the new DELEGATE metadata file + does not match, discard it, end the search, and report the target cannot + be found. + + * **4.5.2.4**. **Check for an arbitrary software attack.** The new DELEGATE + metadata file MUST have been signed by a threshold of keys specified in the + TARGETS metadata file. If the new DELEGATE metadata file is not signed + as required, discard it, end the search, and report the target cannot be + found. + + * **4.5.2.5**. **Check for a rollback attack.** The version number of the + trusted DELEGATE metadata file, if any, MUST be less than or equal to the + version number of the new DELEGATE metadata file. If the new DELEGATE + `metadata file is older than the trusted DELEGATE metadata file, discard + it, end the search, and report the target cannot be found. + + * **4.5.2.6**. 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). + the lack of any such metadata). Otherwise, discard it, end the search, + and report the target cannot be found. - * **4.5.2.2**. If the current delegation is a terminating delegation, + * **4.5.2.7**. If the current delegation is a terminating delegation, then jump to step 5. - * **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. + * **4.5.2.8**. Otherwise, if the current delegation is a non-terminating + delegation, continue processing the next delegation, if any, by repeating + step 4.5 with DELEGATE as the current TARGET role. Stop the search, and + jump to step 5 as soon as a delegation returns a result. **5**. **Verify the desired target against its targets metadata**. From 329361a4729fc4be4eb95478b9ba1d775c49608e Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 11:52:51 +0100 Subject: [PATCH 03/12] Fix typos in client application workflow --- tuf-spec.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index a4280ea..365c980 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1274,14 +1274,14 @@ non-volatile storage as FILENAME.EXT. * **4.5.2.1**. Let DELEGATE denote the current target role TARGETS is delegating to. - * **4.5.2.2**. **Download the DELEGATE tarets metadata file**, up to either + * **4.5.2.2**. **Download the DELEGATE targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some Z number of bytes. The value for Z is set by the authors of the application using TUF. For example, Z may be tens of kilobytes. IF DELEGATE cannot be found, end the search and report the target cannot be found. If consistent snapshots are not used (see Section 7), then the filename used to download the targets metadata file is of the fixed form FILENAME.EXT - (e.g., delegated_rol.json). Otherwise, the filename is of the form + (e.g., delegated_role.json). Otherwise, the filename is of the form VERSION_NUMBER.FILENAME.EXT (e.g., 42.delegated_role.json), where VERSION_NUMBER is the version number of the DELEGATE metadata file listed in the snapshot metadata file. In either case, the client MUST write the @@ -1303,7 +1303,7 @@ non-volatile storage as FILENAME.EXT. * **4.5.2.5**. **Check for a rollback attack.** The version number of the trusted DELEGATE metadata file, if any, MUST be less than or equal to the version number of the new DELEGATE metadata file. If the new DELEGATE - `metadata file is older than the trusted DELEGATE metadata file, discard + metadata file is older than the trusted DELEGATE metadata file, discard it, end the search, and report the target cannot be found. * **4.5.2.6**. If the current delegation is a multi-role delegation, From c36e0c047fe2886d9035c0aa7719a615e298291b Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 12:13:07 +0100 Subject: [PATCH 04/12] Add freeze attack check for delegated targets A recent commit added a detailed verification workflow for delegated targets, including check against snapshot, and signature and version check. This commit adds the missing freeze attack (i.e. timestamp) check. --- tuf-spec.md | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 365c980..6cb76b6 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1306,16 +1306,22 @@ non-volatile storage as FILENAME.EXT. metadata file is older than the trusted DELEGATE metadata file, discard it, end the search, and report the target cannot be found. - * **4.5.2.6**. If the current delegation is a multi-role delegation, + * **4.5.2.6**. **Check for a freeze attack.** The latest known time + should be lower than the expiration timestamp in the new DELEGATE + metadata file. If so, the new DELEGATE file becomes the trusted DELEGATE + file. If the new DELEGATE metadata file is expired, discard it, end the + search, and report the target cannot be found. + + * **4.5.2.7**. 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). Otherwise, discard it, end the search, and report the target cannot be found. - * **4.5.2.7**. If the current delegation is a terminating delegation, + * **4.5.2.8**. If the current delegation is a terminating delegation, then jump to step 5. - * **4.5.2.8**. Otherwise, if the current delegation is a non-terminating + * **4.5.2.9**. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating step 4.5 with DELEGATE as the current TARGET role. Stop the search, and jump to step 5 as soon as a delegation returns a result. From e4a6f9ed9ed755a519153ceb24d6b77a1e968d7b Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 12:22:36 +0100 Subject: [PATCH 05/12] Adopt reporting wording for delegated targets Recent commits added a detailed verification workflow for delegated targets, including check against snapshot, and signature, version and timestamp checks. This commit adopts the failure reporting phrasing used elsewhere in the client workflow. --- tuf-spec.md | 16 +++++++--------- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 6cb76b6..6d06012 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1291,32 +1291,30 @@ non-volatile storage as FILENAME.EXT. version number of the new DELEGATE metadata file MUST match the trusted snapshot metadata. This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. If the new DELEGATE metadata file - does not match, discard it, end the search, and report the target cannot - be found. + does not match, abort the update cycle, and report the failure. * **4.5.2.4**. **Check for an arbitrary software attack.** The new DELEGATE metadata file MUST have been signed by a threshold of keys specified in the TARGETS metadata file. If the new DELEGATE metadata file is not signed - as required, discard it, end the search, and report the target cannot be - found. + as required, abort the update cycle, and report the failure. * **4.5.2.5**. **Check for a rollback attack.** The version number of the trusted DELEGATE metadata file, if any, MUST be less than or equal to the version number of the new DELEGATE metadata file. If the new DELEGATE metadata file is older than the trusted DELEGATE metadata file, discard - it, end the search, and report the target cannot be found. + it, abort the update cycle, and report the potential rollback attack. * **4.5.2.6**. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in the new DELEGATE metadata file. If so, the new DELEGATE file becomes the trusted DELEGATE - file. If the new DELEGATE metadata file is expired, discard it, end the - search, and report the target cannot be found. + file. If the new DELEGATE metadata file is expired, abort the update + cycle, and report the potential freeze attack. * **4.5.2.7**. 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). Otherwise, discard it, end the search, - and report the target cannot be found. + the lack of any such metadata). Otherwise, abort the update cycle, and + report the failure. * **4.5.2.8**. If the current delegation is a terminating delegation, then jump to step 5. From b677f6a8abbb353c0a285b2fe07861fce2a29aef Mon Sep 17 00:00:00 2001 From: marinamoore Date: Wed, 22 Jan 2020 12:41:11 -0500 Subject: [PATCH 06/12] Clarify recovery from ffwd on top-level roles Clarify what files to delete or untrust in various situations to recover from a fast-forward attack on top-level metadata. --- tuf-spec.md | 26 +++++++++++++++++++------- 1 file changed, 19 insertions(+), 7 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 6d06012..4c69b1a 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1133,16 +1133,28 @@ 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 + * **1.9**. **Fast-forward attack recovery** A _fast-forward attack_ happens + when attackers arbitrarily increase the version numbers in any of the + timestamp, snapshot, targets, or delegated targets 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 top-level targets, snapshot, and + timestamp metadata files. + + * **1.9.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 + files. + + * **1.9.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. + * **1.10**. **Set whether consistent snapshots are used as per the trusted root metadata file** (see Section 4.3). From fa2d263169db91907d1bdaea24af9ac1503e155c Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 15:26:33 +0100 Subject: [PATCH 07/12] Clarify recovery from ffwd on top-level targets To recover from a fast-forward attack on the top-level targets metadata, only targets and snapshot (not timestamp) metadata must be untrusted/deleted. Targets, because it was attacker controlled, and snapshot, because it unwittingly might have unwittingly recorded the attacker controlled targets version. --- tuf-spec.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 4c69b1a..8e6ea74 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1142,9 +1142,10 @@ repo](https://github.com/theupdateframework/specification/issues). 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 top-level targets, snapshot, and - timestamp metadata files. + * **1.9.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. * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys have been removed in the new trusted root metadata compared to the previous From 65e042d35d74a995a96f9de540a440de0e1bbe90 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Thu, 30 Jan 2020 12:36:00 +0100 Subject: [PATCH 08/12] Clarify recovery from ffwd on delegated targets Akin to the recovery from fast-forward attacks on the top-level targets role, if a delegated targets role has been compromised, the previously trusted delegated targets metadata and the previously trusted snapshot metadata must be deleted. This must happen so that the rollback attack check (*), which makes sure that the version number of the new delegated targets is higher (or equal) than that of the old does not prevent updates after an ffwd attack. For the top-level targets metadata ffwd recovery logic is performed based on key removals in the root metadata and thus can happen before downloading the snapshot metadata. For delegated targets, on the other hand, where the keys are defined by delegating targets role(s) and not in the root metadata, ffwd recovery logic can only be performed after the delegating targets have been downloaded. (*) Note that there are two targets role rollback checks. One is based on the snapshot metadata, to fail early, i.e. before a potentially compromised (delegated) targets metadata is downloaded, and the other is based directly on the (delegated) targets metadata, so that an attacker needs to compromise snapshot and (delegated) targets keys, to successfully perform a rollback attack. This commit updates the client workflow according to above observations. --- tuf-spec.md | 53 ++++++++++++++++++++++++++++++++--------------------- 1 file changed, 32 insertions(+), 21 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 8e6ea74..2cdf711 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1220,14 +1220,13 @@ non-volatile storage as FILENAME.EXT. metadata file, discard it, abort the update cycle, and report the potential rollback attack. - * **3.3.2**. 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 metadadata file, abort the update cycle, - and report the failure. + * **3.3.2**. The version number of the top-level targets metadata file, 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 metadadata + file, abort the update cycle, and report the failure. * **3.4**. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in the new snapshot metadata file. If @@ -1287,7 +1286,18 @@ non-volatile storage as FILENAME.EXT. * **4.5.2.1**. Let DELEGATE denote the current target role TARGETS is delegating to. - * **4.5.2.2**. **Download the DELEGATE targets metadata file**, up to either + * **4.5.2.2**. **Fast-forward attack recovery.** If a threshold of + delegated targets keys for the current delegation are removed from the + TARGETS metadata, delete the trusted DELEGATE metadata, if any, and the + previously trusted snapshot metadata. + + * **4.5.2.3**. **Check for a rollback attack via snapshot.** The version number of the + DELEGATE metadata in the previous trusted snapshot metadata, if any, MUST + be less than or equal to its version number in the new trusted snapshot + metadata. If this is not the case, abort the update cycle, and report the + potential rollback attack. + + * **4.5.2.4**. **Download the DELEGATE targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some Z number of bytes. The value for Z is set by the authors of the application using TUF. For example, Z may be tens of kilobytes. IF DELEGATE cannot be @@ -1300,39 +1310,40 @@ non-volatile storage as FILENAME.EXT. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - * **4.5.2.3**. **Check against snapshot metadata.** The hashes (if any), and + * **4.5.2.5**. **Check against snapshot metadata.** The hashes (if any), and version number of the new DELEGATE metadata file MUST match the trusted - snapshot metadata. This is done, in part, to prevent a mix-and-match + snapshot metadata, if any. This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. If the new DELEGATE metadata file does not match, abort the update cycle, and report the failure. - * **4.5.2.4**. **Check for an arbitrary software attack.** The new DELEGATE + * **4.5.2.6**. **Check for an arbitrary software attack.** The new DELEGATE metadata file MUST have been signed by a threshold of keys specified in the TARGETS metadata file. If the new DELEGATE metadata file is not signed as required, abort the update cycle, and report the failure. - * **4.5.2.5**. **Check for a rollback attack.** The version number of the - trusted DELEGATE metadata file, if any, MUST be less than or equal to the - version number of the new DELEGATE metadata file. If the new DELEGATE - metadata file is older than the trusted DELEGATE metadata file, discard - it, abort the update cycle, and report the potential rollback attack. + * **4.5.2.7**. **Check for a rollback attack on the DELEGATE metadata.** + The version number of the trusted DELEGATE metadata file, if any, MUST be + less than or equal to the version number of the new DELEGATE metadata + file. If the new DELEGATE metadata file is older than the trusted + DELEGATE metadata file abort the update cycle, and report the potential + rollback attack. - * **4.5.2.6**. **Check for a freeze attack.** The latest known time + * **4.5.2.8**. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in the new DELEGATE metadata file. If so, the new DELEGATE file becomes the trusted DELEGATE file. If the new DELEGATE metadata file is expired, abort the update cycle, and report the potential freeze attack. - * **4.5.2.7**. If the current delegation is a multi-role delegation, + * **4.5.2.9**. 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). Otherwise, abort the update cycle, and report the failure. - * **4.5.2.8**. If the current delegation is a terminating delegation, + * **4.5.2.10**. If the current delegation is a terminating delegation, then jump to step 5. - * **4.5.2.9**. Otherwise, if the current delegation is a non-terminating + * **4.5.2.11**. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating step 4.5 with DELEGATE as the current TARGET role. Stop the search, and jump to step 5 as soon as a delegation returns a result. From a06c5a8721bdbd35cce25aa669b12ef4cae220b3 Mon Sep 17 00:00:00 2001 From: lukpueh Date: Tue, 4 Feb 2020 10:04:44 +0100 Subject: [PATCH 09/12] Add details about ffwd attacker goals Co-Authored-By: Justin Cappos Co-Authored-By: Joshua Lock --- tuf-spec.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 2cdf711..4b941b1 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1135,12 +1135,15 @@ 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 in any of the - timestamp, snapshot, targets, or delegated targets metadata. To recover from + timestamp, snapshot, targets, or delegated targets metadata. The attacker goal + is to cause clients to refuse to update the metadata later because the attacker's + listed metadata version number (possibly MAX_INT) is greater than the new valid + version. 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. + for more details on fast-forward attacks. * **1.9.1**. **Targets recovery** If a threshold of targets keys have been removed in the new trusted root metadata compared to the previous trusted From e96f1e820be7893b1acf1eafb48017e17f9afe14 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Tue, 11 Feb 2020 10:32:06 +0100 Subject: [PATCH 10/12] Replace DELEGATE with DELEGATEE Following @trishankatdatadog's and @jhdalek55's suggestion, according to which, a delegate, when used as a noun, generally implies a person. "Delegatee" is defined as "someone or something to which something is delegated." In this case, when the responsibility for signing is being granted to a different entity, "delegatee" more clearly conveys this concept. --- tuf-spec.md | 38 +++++++++++++++++++------------------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 4b941b1..88575f8 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1286,55 +1286,55 @@ non-volatile storage as FILENAME.EXT. * **4.5.2**. Otherwise, recursively search the list of delegations in order of appearance. - * **4.5.2.1**. Let DELEGATE denote the current target role TARGETS is + * **4.5.2.1**. Let DELEGATEE denote the current target role TARGETS is delegating to. * **4.5.2.2**. **Fast-forward attack recovery.** If a threshold of delegated targets keys for the current delegation are removed from the - TARGETS metadata, delete the trusted DELEGATE metadata, if any, and the + TARGETS metadata, delete the trusted DELEGATEE metadata, if any, and the previously trusted snapshot metadata. * **4.5.2.3**. **Check for a rollback attack via snapshot.** The version number of the - DELEGATE metadata in the previous trusted snapshot metadata, if any, MUST + DELEGATEE metadata in the previous trusted snapshot metadata, if any, MUST be less than or equal to its version number in the new trusted snapshot metadata. If this is not the case, abort the update cycle, and report the potential rollback attack. - * **4.5.2.4**. **Download the DELEGATE targets metadata file**, up to either + * **4.5.2.4**. **Download the DELEGATEE targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some Z number of bytes. The value for Z is set by the authors of the application - using TUF. For example, Z may be tens of kilobytes. IF DELEGATE cannot be + using TUF. For example, Z may be tens of kilobytes. IF DELEGATEE cannot be found, end the search and report the target cannot be found. If consistent snapshots are not used (see Section 7), then the filename used to download the targets metadata file is of the fixed form FILENAME.EXT (e.g., delegated_role.json). Otherwise, the filename is of the form VERSION_NUMBER.FILENAME.EXT (e.g., 42.delegated_role.json), where - VERSION_NUMBER is the version number of the DELEGATE metadata file listed + VERSION_NUMBER is the version number of the DELEGATEE metadata file listed in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. * **4.5.2.5**. **Check against snapshot metadata.** The hashes (if any), and - version number of the new DELEGATE metadata file MUST match the trusted + version number of the new DELEGATEE metadata file MUST match the trusted snapshot metadata, if any. This is done, in part, to prevent a mix-and-match - attack by man-in-the-middle attackers. If the new DELEGATE metadata file + attack by man-in-the-middle attackers. If the new DELEGATEE metadata file does not match, abort the update cycle, and report the failure. - * **4.5.2.6**. **Check for an arbitrary software attack.** The new DELEGATE + * **4.5.2.6**. **Check for an arbitrary software attack.** The new DELEGATEE metadata file MUST have been signed by a threshold of keys specified in the - TARGETS metadata file. If the new DELEGATE metadata file is not signed + TARGETS metadata file. If the new DELEGATEE metadata file is not signed as required, abort the update cycle, and report the failure. - * **4.5.2.7**. **Check for a rollback attack on the DELEGATE metadata.** - The version number of the trusted DELEGATE metadata file, if any, MUST be - less than or equal to the version number of the new DELEGATE metadata - file. If the new DELEGATE metadata file is older than the trusted - DELEGATE metadata file abort the update cycle, and report the potential + * **4.5.2.7**. **Check for a rollback attack on the DELEGATEE metadata.** + The version number of the trusted DELEGATEE metadata file, if any, MUST be + less than or equal to the version number of the new DELEGATEE metadata + file. If the new DELEGATEE metadata file is older than the trusted + DELEGATEE metadata file abort the update cycle, and report the potential rollback attack. * **4.5.2.8**. **Check for a freeze attack.** The latest known time - should be lower than the expiration timestamp in the new DELEGATE - metadata file. If so, the new DELEGATE file becomes the trusted DELEGATE - file. If the new DELEGATE metadata file is expired, abort the update + should be lower than the expiration timestamp in the new DELEGATEE + metadata file. If so, the new DELEGATEE file becomes the trusted DELEGATEE + file. If the new DELEGATEE metadata file is expired, abort the update cycle, and report the potential freeze attack. * **4.5.2.9**. If the current delegation is a multi-role delegation, @@ -1348,7 +1348,7 @@ non-volatile storage as FILENAME.EXT. * **4.5.2.11**. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating - step 4.5 with DELEGATE as the current TARGET role. Stop the search, and + step 4.5 with DELEGATEE as the current TARGET role. Stop the search, and jump to step 5 as soon as a delegation returns a result. **5**. **Verify the desired target against its targets metadata**. From 5ef7a9c067df5ba39ec92eb9b4e9f1080afe8575 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Fri, 6 Mar 2020 10:33:50 +0100 Subject: [PATCH 11/12] Clarify delegated targets optional hash check Clarify that the hashes of delegated targets metadata in snapshot metadata are optional and should only be match checked by the client if present. --- tuf-spec.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 88575f8..14b9198 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1313,11 +1313,12 @@ non-volatile storage as FILENAME.EXT. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - * **4.5.2.5**. **Check against snapshot metadata.** The hashes (if any), and - version number of the new DELEGATEE metadata file MUST match the trusted - snapshot metadata, if any. This is done, in part, to prevent a mix-and-match - attack by man-in-the-middle attackers. If the new DELEGATEE metadata file - does not match, abort the update cycle, and report the failure. + * **4.5.2.5**. **Check against snapshot metadata.** The hashes and + version number of the new DELEGATEE metadata file MUST match the hashes + (if any) and version number listed in the trusted snapshot metadata. This + is done, in part, to prevent a mix-and-match attack by man-in-the-middle + attackers. If the new DELEGATEE metadata file does not match, abort the + update cycle, and report the failure. * **4.5.2.6**. **Check for an arbitrary software attack.** The new DELEGATEE metadata file MUST have been signed by a threshold of keys specified in the From 1af5d034b697f3d9e594c842eb2d133f519e40c0 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Tue, 1 Sep 2020 18:17:14 +0200 Subject: [PATCH 12/12] Revise rollback attack prevention and ffwd recovery again (WIP) --- tuf-spec.md | 36 ++++++++++++++---------------------- 1 file changed, 14 insertions(+), 22 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 14b9198..da8792d 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1148,7 +1148,10 @@ repo](https://github.com/theupdateframework/specification/issues). * **1.9.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. + files. Note that delegated targets are suceptible to fast forward attacks, + because snapshot must be checked before a key rotation in the delegating + target role is known to the client. To fix this, nuke delegation or make + repository rotate the the snapshot key. * **1.9.2**. **Snapshot recovery** If a threshold of snapshot keys have been removed in the new trusted root metadata compared to the previous @@ -1223,9 +1226,9 @@ non-volatile storage as FILENAME.EXT. metadata file, discard it, abort the update cycle, and report the potential rollback attack. - * **3.3.2**. The version number of the top-level targets metadata file, in + * **3.3.2**. The version number of all targets metadata files 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 + their version numbers 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 metadadata @@ -1289,18 +1292,7 @@ non-volatile storage as FILENAME.EXT. * **4.5.2.1**. Let DELEGATEE denote the current target role TARGETS is delegating to. - * **4.5.2.2**. **Fast-forward attack recovery.** If a threshold of - delegated targets keys for the current delegation are removed from the - TARGETS metadata, delete the trusted DELEGATEE metadata, if any, and the - previously trusted snapshot metadata. - - * **4.5.2.3**. **Check for a rollback attack via snapshot.** The version number of the - DELEGATEE metadata in the previous trusted snapshot metadata, if any, MUST - be less than or equal to its version number in the new trusted snapshot - metadata. If this is not the case, abort the update cycle, and report the - potential rollback attack. - - * **4.5.2.4**. **Download the DELEGATEE targets metadata file**, up to either + * **4.5.2.2**. **Download the DELEGATEE targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some Z number of bytes. The value for Z is set by the authors of the application using TUF. For example, Z may be tens of kilobytes. IF DELEGATEE cannot be @@ -1313,41 +1305,41 @@ non-volatile storage as FILENAME.EXT. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - * **4.5.2.5**. **Check against snapshot metadata.** The hashes and + * **4.5.2.3**. **Check against snapshot metadata.** The hashes and version number of the new DELEGATEE metadata file MUST match the hashes (if any) and version number listed in the trusted snapshot metadata. This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers. If the new DELEGATEE metadata file does not match, abort the update cycle, and report the failure. - * **4.5.2.6**. **Check for an arbitrary software attack.** The new DELEGATEE + * **4.5.2.4**. **Check for an arbitrary software attack.** The new DELEGATEE metadata file MUST have been signed by a threshold of keys specified in the TARGETS metadata file. If the new DELEGATEE metadata file is not signed as required, abort the update cycle, and report the failure. - * **4.5.2.7**. **Check for a rollback attack on the DELEGATEE metadata.** + * **4.5.2.5**. **Check for a rollback attack.** The version number of the trusted DELEGATEE metadata file, if any, MUST be less than or equal to the version number of the new DELEGATEE metadata file. If the new DELEGATEE metadata file is older than the trusted DELEGATEE metadata file abort the update cycle, and report the potential rollback attack. - * **4.5.2.8**. **Check for a freeze attack.** The latest known time + * **4.5.2.6**. **Check for a freeze attack.** The latest known time should be lower than the expiration timestamp in the new DELEGATEE metadata file. If so, the new DELEGATEE file becomes the trusted DELEGATEE file. If the new DELEGATEE metadata file is expired, abort the update cycle, and report the potential freeze attack. - * **4.5.2.9**. If the current delegation is a multi-role delegation, + * **4.5.2.7**. 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). Otherwise, abort the update cycle, and report the failure. - * **4.5.2.10**. If the current delegation is a terminating delegation, + * **4.5.2.8**. If the current delegation is a terminating delegation, then jump to step 5. - * **4.5.2.11**. Otherwise, if the current delegation is a non-terminating + * **4.5.2.9**. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating step 4.5 with DELEGATEE as the current TARGET role. Stop the search, and jump to step 5 as soon as a delegation returns a result.