From 0e76a175101f9b51077d53294741fb8693108680 Mon Sep 17 00:00:00 2001 From: Erick Tryzelaar Date: Fri, 6 Dec 2019 16:23:06 -0800 Subject: [PATCH 01/24] Clarify how delegated roles are downloaded Section 7 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 7 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 | 63 +++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 52 insertions(+), 11 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index f8030c5..4df7297 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1464,10 +1464,9 @@ it in the next step. 6. **Persist targets metadata**. The client MUST write the file to non-volatile storage as FILENAME.EXT (e.g. targets.json). -7. **Perform a pre-order depth-first search for metadata about the - desired target, beginning with the top-level targets role.** Note: If - any metadata requested in steps 5.6.7.1 - 5.6.7.2 cannot be downloaded nor - validated, end the search and report that the target cannot be found. +7. **Perform a preorder depth-first search for metadata about the + desired target.** Let TARGETS be the current metadata, beginning with the + top-level targets metadata role. 1. If this role has been visited before, then skip this role (so that cycles in the delegation graph are avoided). Otherwise, if an @@ -1479,13 +1478,55 @@ it in the next step. 2. Otherwise, recursively search the list of delegations in order of appearance. - 1. If the current delegation is a terminating delegation, - then jump to step [[#fetch-target]]. - - 2. Otherwise, if the current delegation is a - non-terminating delegation, continue processing the next delegation, if - any. Stop the search, and jump to step [[#fetch-target]] as soon as a delegation - returns a result. + 1. Let DELEGATE denote the current target role TARGETS is + delegating to. + + 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. + + 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. **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. + + 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. + + 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). Otherwise, discard it, end the search, + and report the target cannot be found. + + 7. If the current delegation is a terminating delegation, + then jump to step [[#fetch-target]].. + + 8. Otherwise, if the current delegation is a non-terminating + delegation, continue processing the next delegation, if any, by repeating + the preorder depth-first search with DELEGATE as the current TARGET role. + Stop the search, and jump to step [[#fetch-target]]. as soon as a + delegation returns a result. ## Fetch target ## {#fetch-target} From 8a20ecfd6cadac93886c1deb3ec7e3417ca2c6fd Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 11:52:51 +0100 Subject: [PATCH 02/24] Fix typos in client application workflow --- tuf-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 4df7297..900f7ef 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1481,14 +1481,14 @@ it in the next step. 1. Let DELEGATE denote the current target role TARGETS is delegating to. - 2. **Download the DELEGATE tarets metadata file**, up to either + 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 From 33c221bbc084de099c9f03943377d17f860bd6aa Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 12:13:07 +0100 Subject: [PATCH 03/24] 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 900f7ef..027b6bc 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1513,16 +1513,22 @@ it in the next step. metadata file is older than the trusted DELEGATE metadata file, discard it, end the search, and report the target cannot be found. - 6. If the current delegation is a multi-role delegation, + 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. + + 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. 7. If the current delegation is a terminating delegation, - then jump to step [[#fetch-target]].. + then jump to step [[#fetch-target]]. - 8. Otherwise, if the current delegation is a non-terminating + 9. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating the preorder depth-first search with DELEGATE as the current TARGET role. Stop the search, and jump to step [[#fetch-target]]. as soon as a From 4bceaf4e2d7463e8dc442c1df8347a22472b3b2e Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 12:22:36 +0100 Subject: [PATCH 04/24] 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 027b6bc..4024a44 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1498,32 +1498,30 @@ it in the next step. 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. **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. 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. 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. 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. 7. If the current delegation is a terminating delegation, then jump to step [[#fetch-target]]. From 869129cea68e16e78fb63e3b0687af2094f373cb Mon Sep 17 00:00:00 2001 From: marinamoore Date: Wed, 22 Jan 2020 12:41:11 -0500 Subject: [PATCH 05/24] 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 | 28 ++++++++++++++++++++-------- 1 file changed, 20 insertions(+), 8 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 4024a44..9fcacd2 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1327,16 +1327,28 @@ it in the next step. report the potential freeze attack. On the next update cycle, begin at step [[#update-root]] and version N of the root metadata file. -11. **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://theupdateframework.io/papers/prevention-rollback-attacks-atc2017.pdf) +11. **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. **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. + + 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. + + 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]]). From 0ca0b7e22c121907c2e731cb2611dd1a92101417 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Wed, 29 Jan 2020 15:26:33 +0100 Subject: [PATCH 06/24] 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 9fcacd2..4e43bc9 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1336,9 +1336,10 @@ it in the next step. paper](https://ssl.engineering.nyu.edu/papers/kuppusamy-mercury-usenix-2017.pdf) for more details. - 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. **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. 2. **Snapshot recovery** If a threshold of snapshot keys have been removed in the new trusted root metadata compared to the previous From 6446585648bcf55c5093cf8983b0b1bddc5ac00a Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Thu, 30 Jan 2020 12:36:00 +0100 Subject: [PATCH 07/24] 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 | 39 +++++++++++++++++++++++++-------------- 1 file changed, 25 insertions(+), 14 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 4e43bc9..bd99df2 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1435,7 +1435,6 @@ it in the next step. file. If the new snapshot metadata file is expired, discard it, abort the update cycle, and report the potential freeze attack. - 7. **Persist snapshot metadata**. The client MUST write the file to non-volatile storage as FILENAME.EXT (e.g. snapshot.json). @@ -1494,7 +1493,18 @@ it in the next step. 1. Let DELEGATE denote the current target role TARGETS is delegating to. - 2. **Download the DELEGATE targets metadata file**, up to either + 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. + + 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. **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 @@ -1507,39 +1517,40 @@ it in the next step. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - 3. **Check against snapshot metadata.** The hashes (if any), and + 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. **Check for an arbitrary software attack.** The new DELEGATE + 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. - 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. + 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. - 6. **Check for a freeze attack.** The latest known time + 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. - 7. If the current delegation is a multi-role delegation, + 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. - 7. If the current delegation is a terminating delegation, + 10. If the current delegation is a terminating delegation, then jump to step [[#fetch-target]]. - 9. Otherwise, if the current delegation is a non-terminating + 11. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating the preorder depth-first search with DELEGATE as the current TARGET role. Stop the search, and jump to step [[#fetch-target]]. as soon as a From 1706edf025a64ef76183525751448cac5fb79698 Mon Sep 17 00:00:00 2001 From: lukpueh Date: Tue, 4 Feb 2020 10:04:44 +0100 Subject: [PATCH 08/24] 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 bd99df2..e730b64 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1329,12 +1329,15 @@ it in the next step. 11. **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. **Targets recovery** If a threshold of targets keys have been removed in the new trusted root metadata compared to the previous trusted From bac0c55a2508a775815fe2be4499ea7a62ba62b6 Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Tue, 11 Feb 2020 10:32:06 +0100 Subject: [PATCH 09/24] 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 e730b64..18277c7 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1331,7 +1331,7 @@ it in the next step. when attackers arbitrarily increase the version numbers in any of the 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 + 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. @@ -1493,55 +1493,55 @@ it in the next step. 2. Otherwise, recursively search the list of delegations in order of appearance. - 1. Let DELEGATE denote the current target role TARGETS is + 1. Let DELEGATEE denote the current target role TARGETS is delegating to. 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. 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. **Download the DELEGATE targets metadata file**, up to either + 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. 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. - 6. **Check for an arbitrary software attack.** The new DELEGATE + 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. - 7. **Check for a rollback attack on the DELEGATE metadata.** - The version number of the trusted DELEGATE metadata file, if any, MUST be + 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 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 + 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. 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. 9. If the current delegation is a multi-role delegation, @@ -1555,7 +1555,7 @@ it in the next step. 11. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating - the preorder depth-first search with DELEGATE as the current TARGET role. + the preorder depth-first search with DELEGATEE as the current TARGET role. Stop the search, and jump to step [[#fetch-target]]. as soon as a delegation returns a result. From 7726374b89bae83eff1f1bdb25aa7e8997b8befb Mon Sep 17 00:00:00 2001 From: Lukas Puehringer Date: Tue, 1 Sep 2020 18:17:14 +0200 Subject: [PATCH 10/24] Revise rollback attack prevention and ffwd recovery again (WIP) --- tuf-spec.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 18277c7..0da533b 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1342,7 +1342,10 @@ it in the next step. 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 susceptible 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. 2. **Snapshot recovery** If a threshold of snapshot keys have been removed in the new trusted root metadata compared to the previous @@ -1423,10 +1426,9 @@ 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 +5. **Check for a rollback attack**. The version number of all targets metadata files in the + trusted snapshot metadata file, if any, MUST be less than or equal to 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 metadata file, abort From 3de7f6e9af902396f9d72300f7479615fc3f3c2e Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Wed, 24 Feb 2021 16:04:17 -0800 Subject: [PATCH 11/24] Remove delegated targets fast-forward check This removes the fast-forward check for delegated targets, and adds an explanation of fast-forward attack recovery for delegated targets to the snapshot fast-forward check. Signed-off-by: Marina Moore --- tuf-spec.md | 35 +++++++++++++++-------------------- 1 file changed, 15 insertions(+), 20 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 0da533b..fcb5e8c 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1329,14 +1329,14 @@ it in the next step. 11. **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. The attacker goal + timestamp, snapshot, targets, or delegated targets metadata. The attacker's 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) + version. To recover from a fast-forward attacks 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 + 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 @@ -1498,18 +1498,13 @@ it in the next step. 1. Let DELEGATEE denote the current target role TARGETS is delegating to. - 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. - - 3. **Check for a rollback attack via snapshot.** The version number of the + 2. **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. **Download the DELEGATEE targets metadata file**, up to either + 3. **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 @@ -1522,40 +1517,40 @@ it in the next step. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - 5. **Check against snapshot metadata.** The hashes (if any), and + 4. **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. - 6. **Check for an arbitrary software attack.** The new DELEGATEE + 5. **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. - 7. **Check for a rollback attack on the DELEGATEE metadata.** + 6. **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 DELEGATE 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. - 8. **Check for a freeze attack.** The latest known time + 7. **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. - 9. If the current delegation is a multi-role delegation, + 8. 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. - 10. If the current delegation is a terminating delegation, + 9. If the current delegation is a terminating delegation, then jump to step [[#fetch-target]]. - 11. Otherwise, if the current delegation is a non-terminating + 10. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating the preorder depth-first search with DELEGATEE as the current TARGET role. Stop the search, and jump to step [[#fetch-target]]. as soon as a From 159c0e85929204f96375419ae6278842cabed939 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Wed, 24 Feb 2021 16:44:19 -0800 Subject: [PATCH 12/24] Remove redundant rollback checks All targets metadata versions are checked for a rollback attack during snapshot metadata verification, therefore these checks are not needed during the targets metadata verification. These checks were in place to allow for fast forward attack recovery for delegated targets metadata. A previous commit added an explanation of how to recover from this attack. Namely, by replacing the snapshot key to trigger the fast-forward attack prevention during root metadata verification. Signed-off-by: Marina Moore --- tuf-spec.md | 27 +++++++-------------------- 1 file changed, 7 insertions(+), 20 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index fcb5e8c..b7bd6aa 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1498,13 +1498,7 @@ it in the next step. 1. Let DELEGATEE denote the current target role TARGETS is delegating to. - 2. **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. - - 3. **Download the DELEGATEE targets metadata file**, up to either + 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 @@ -1517,40 +1511,33 @@ it in the next step. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - 4. **Check against snapshot metadata.** The hashes (if any), and + 3. **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. - 5. **Check for an arbitrary software attack.** The new DELEGATEE + 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. - 6. **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 DELEGATE 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. - - 7. **Check for a freeze attack.** The latest known time + 5. **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. - 8. If the current delegation is a multi-role delegation, + 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). Otherwise, abort the update cycle, and report the failure. - 9. If the current delegation is a terminating delegation, + 7. If the current delegation is a terminating delegation, then jump to step [[#fetch-target]]. - 10. Otherwise, if the current delegation is a non-terminating + 8. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating the preorder depth-first search with DELEGATEE as the current TARGET role. Stop the search, and jump to step [[#fetch-target]]. as soon as a From c2e206f2c707f250d192afeed1ee94f90b4c96bd Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 4 Mar 2021 11:30:48 -0800 Subject: [PATCH 13/24] Remove redundant description of delegated targests fast forward recovery The description of fast forward attack recovery for delegated targets was added to the previous paragraph, and so the description is redundant. Signed-off-by: Marina Moore --- tuf-spec.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index b7bd6aa..b20998e 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1342,10 +1342,8 @@ it in the next step. 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 delegated targets are susceptible 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. + 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 @@ -1426,7 +1424,8 @@ 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 all targets metadata files in the +5. **Check for a rollback attack**. The version number of all targets metadata + files in the trusted snapshot metadata file, if any, MUST be less than or equal to their version numbers in the new snapshot metadata file. Furthermore, any targets metadata filename that was listed in the trusted snapshot metadata file, if From 495370d2d0a649a1a52d09001f94bcb0ba1c905a Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 13 May 2021 12:03:18 -0700 Subject: [PATCH 14/24] Define DELEGATOR in targets workflow before the DFS loop Use DELEGATOR instead of TARGETS during the DFS for clarity Signed-off-by: Marina Moore Co-authored-by: Trishank Karthik Kuppusamy --- tuf-spec.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index b20998e..572c59a 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1481,7 +1481,7 @@ it in the next step. non-volatile storage as FILENAME.EXT (e.g. targets.json). 7. **Perform a preorder depth-first search for metadata about the - desired target.** Let TARGETS be the current metadata, beginning with the + desired target.** Let DELEGATOR refer to the current top-level targets metadata role. 1. If this role has been visited before, then skip this role @@ -1494,8 +1494,8 @@ it in the next step. 2. Otherwise, recursively search the list of delegations in order of appearance. - 1. Let DELEGATEE denote the current target role TARGETS is - delegating to. + 1. Let DELEGATEE denote + the current target role DELEGATOR is delegating to. 2. **Download the DELEGATEE targets metadata file**, up to either the number of bytes specified in the snapshot metadata file, or some Z @@ -1518,7 +1518,7 @@ it in the next step. 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 + DELEGATOR metadata file. If the new DELEGATEE metadata file is not signed as required, abort the update cycle, and report the failure. 5. **Check for a freeze attack.** The latest known time @@ -1538,7 +1538,7 @@ it in the next step. 8. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating - the preorder depth-first search with DELEGATEE as the current TARGET role. + the preorder depth-first search with the DELEGATEE as the DELEGATOR. Stop the search, and jump to step [[#fetch-target]]. as soon as a delegation returns a result. From d9e059603b330afcad37cfe664836c1370cca2d1 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 13 May 2021 13:28:54 -0700 Subject: [PATCH 15/24] Update tuf-spec.md Co-authored-by: Trishank Karthik Kuppusamy --- tuf-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tuf-spec.md b/tuf-spec.md index 572c59a..7e22524 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1539,7 +1539,7 @@ it in the next step. 8. Otherwise, if the current delegation is a non-terminating delegation, continue processing the next delegation, if any, by repeating the preorder depth-first search with the DELEGATEE as the DELEGATOR. - Stop the search, and jump to step [[#fetch-target]]. as soon as a + Stop the search, and jump to step [[#fetch-target]] as soon as a delegation returns a result. ## Fetch target ## {#fetch-target} From eed438881f19d8e449bd478bfc7d14a9d7fa232d Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 20 May 2021 12:14:34 -0700 Subject: [PATCH 16/24] Re-order the client workflow This commit moves the rollback checks for delegated roles to after the description of multi-role delegations to make it clear that these checks should be done for each role in the multi-role delegation. Signed-off-by: Marina Moore --- tuf-spec.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 7e22524..beb88cd 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1494,10 +1494,17 @@ it in the next step. 2. Otherwise, recursively search the list of delegations in order of appearance. - 1. Let DELEGATEE denote + 1. If the current delegation is a multi-role delegation, + recursively visit each delegated 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. + + 2. Let DELEGATEE denote the current target role DELEGATOR is delegating to. - 2. **Download the DELEGATEE targets metadata file**, up to either + 3. **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 @@ -1510,29 +1517,23 @@ it in the next step. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - 3. **Check against snapshot metadata.** The hashes (if any), and + 4. **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. **Check for an arbitrary software attack.** The new DELEGATEE + 5. **Check for an arbitrary software attack.** The new DELEGATEE metadata file MUST have been signed by a threshold of keys specified in the DELEGATOR metadata file. If the new DELEGATEE metadata file is not signed as required, abort the update cycle, and report the failure. - 5. **Check for a freeze attack.** The latest known time + 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. - 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). Otherwise, abort the update cycle, and - report the failure. - 7. If the current delegation is a terminating delegation, then jump to step [[#fetch-target]]. From be71c07b2660bc129f3eb803266450236fa02330 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 24 May 2021 14:07:10 -0700 Subject: [PATCH 17/24] Fix typo and section cross-reference Signed-off-by: Marina Moore --- tuf-spec.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index beb88cd..d9c56bc 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1332,7 +1332,7 @@ it in the next step. timestamp, snapshot, targets, or delegated targets metadata. The attacker's 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 a fast-forward attacks after the repository has been + 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 fast-forward attack, the snapshot role's keys should be replaced. Please see @@ -1509,7 +1509,8 @@ it in the next step. 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 found, end the search and report the target cannot be found. If - consistent snapshots are not used (see Section 7), then the filename used + consistent snapshots are not used (see Section + [[#consistent-snapshots]]), 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 From 8652ff569671bc021d6730ea8f90527e028bfcff Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 24 May 2021 14:09:55 -0700 Subject: [PATCH 18/24] Make delegated targets freeze attack consistent Other freeze attack checks state that the listed timestamp must be higher than the fixed update start time. Use the same wording in the delegated targets freeze attack check. Signed-off-by: Marina Moore --- tuf-spec.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index d9c56bc..b8220f2 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1529,9 +1529,9 @@ it in the next step. DELEGATOR metadata file. If the new DELEGATEE metadata file is not signed as required, abort the update cycle, and report the failure. - 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 + 6. **Check for a freeze attack.** The expiration timestamp in new + DELEGATEE metadata file MUST be higher than the fixed update start time. + 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. From 180e9db5c8ddf42612067b9d06958a5300d68c2b Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 24 May 2021 14:30:19 -0700 Subject: [PATCH 19/24] Update date and version Signed-off-by: Marina Moore --- tuf-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index b8220f2..119cdc1 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -3,7 +3,7 @@ Title: The Update Framework Specification Shortname: TUF Status: LS Abstract: A framework for securing software update systems. -Date: 2021-07-13 +Date: 2021-08-12 Editor: Justin Cappos, NYU Editor: Trishank Karthik Kuppusamy, Datadog Editor: Joshua Lock, VMware @@ -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.20 +Text Macro: VERSION 1.0.21 Note: We strive to make the specification easy to implement, so if you come From 9698015e41d65bd9b01f2e1f7e5d4ed6cc2e2c9f Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 19 Aug 2021 12:21:37 -0400 Subject: [PATCH 20/24] Remove reference to TAP 3 Signed-off-by: Marina Moore --- tuf-spec.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 119cdc1..c7b07b5 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1494,12 +1494,7 @@ it in the next step. 2. Otherwise, recursively search the list of delegations in order of appearance. - 1. If the current delegation is a multi-role delegation, - recursively visit each delegated 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. + 1. Abort the update cycle, and report the failure. 2. Let DELEGATEE denote the current target role DELEGATOR is delegating to. From 40e3e7c96306371cf76f4010e9b42ffffc39b015 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 19 Aug 2021 12:31:06 -0400 Subject: [PATCH 21/24] Make the snapshot checks for delegations match top-level targets Separates the snapshot checks into hash checks and version checks, and updates the order of these check so that the process matches what is done for top-level targets metadata Signed-off-by: Marina Moore --- tuf-spec.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index c7b07b5..9532d1c 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1514,8 +1514,8 @@ it in the next step. file to non-volatile storage as FILENAME.EXT. 4. **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 + version number (if any) of the new DELEGATEE 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 DELEGATEE metadata file does not match, abort the update cycle, and report the failure. From e50151d9df632299ddea364c4f44fe8ca9c10184 Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Thu, 19 Aug 2021 16:54:30 -0400 Subject: [PATCH 22/24] Remove TAP 3 residual Signed-off-by: Marina Moore --- tuf-spec.md | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 9532d1c..71b1f32 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1494,12 +1494,10 @@ it in the next step. 2. Otherwise, recursively search the list of delegations in order of appearance. - 1. Abort the update cycle, and report the failure. - - 2. Let DELEGATEE denote + 1. Let DELEGATEE denote the current target role DELEGATOR is delegating to. - 3. **Download the DELEGATEE targets metadata file**, up to either + 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 @@ -1513,17 +1511,22 @@ it in the next step. in the snapshot metadata file. In either case, the client MUST write the file to non-volatile storage as FILENAME.EXT. - 4. **Check against snapshot metadata.** The hashes (if any), and - version number (if any) of the new DELEGATEE metadata file MUST match the - trusted snapshot metadata. This is done, in part, to prevent a mix-and-match + 3. **Check against snapshot role's hash.** The hashes of the new DELEGATEE + metadata file MUST match the hashes, if any, 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. - 5. **Check for an arbitrary software attack.** The new DELEGATEE + 4. **Check for an arbitrary software attack.** The new DELEGATEE metadata file MUST have been signed by a threshold of keys specified in the DELEGATOR metadata file. If the new DELEGATEE metadata file is not signed as required, abort the update cycle, and report the failure. + 5. **Check against snapshot role's version**. The version number of the new + DELEGATEE metadata file MUST match the version number, if any, listed in + the trusted snapshot metadata. If the versions do not match, discard it, + abort the update cycle, and report the failure. + 6. **Check for a freeze attack.** The expiration timestamp in new DELEGATEE metadata file MUST be higher than the fixed update start time. If so, the new DELEGATEE file becomes the trusted DELEGATEE From 07a46db99e38263b860fc6184c6d1d4bc12a6c7b Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Fri, 10 Sep 2021 17:21:32 -0400 Subject: [PATCH 23/24] Simplify fast-forward attack recovery Require that the snapshot keys are replaced for fast-forward attack recovery. This commit also simplifies the key rotation check by deleting the snapshot metadata if a threshold of new keys cannot verify the old snapshot metadata. Signed-off-by: Marina Moore --- tuf-spec.md | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-) diff --git a/tuf-spec.md b/tuf-spec.md index 71b1f32..ce7f0bc 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -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 + 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]]). From e5c0729053a975c0e0cbe151b0c979717bf23a7c Mon Sep 17 00:00:00 2001 From: Marina Moore Date: Mon, 13 Sep 2021 15:10:11 -0400 Subject: [PATCH 24/24] Update tuf-spec.md Co-authored-by: Hossein Siadati <87046468+hosseinsia@users.noreply.github.com> --- tuf-spec.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tuf-spec.md b/tuf-spec.md index ce7f0bc..d31f168 100644 --- a/tuf-spec.md +++ b/tuf-spec.md @@ -1340,7 +1340,7 @@ it in the next step. for more details on fast-forward attacks. 1. **Snapshot recovery** If the trusted snapshot metadata cannot be - validating using a threshold of snapshot keys from the new trusted root + validated using a threshold of snapshot keys from the new trusted root metadata, delete the trusted snapshot and timestamp metadata files.