Clarify rollback attack prevention and fast-forward attack recovery #86

This reverts commit 2eccb59. 2eccb59 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.

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?

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.

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.

Clarify what files to delete or untrust in various situations to recover from a fast-forward attack on top-level metadata.

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.

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.

Co-Authored-By: Justin Cappos <[email protected]> Co-Authored-By: Joshua Lock <[email protected]>

@trishankatdatadog

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.

Clarify that the hashes of delegated targets metadata in snapshot metadata are optional and should only be match checked by the client if present.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Clarify rollback attack prevention and fast-forward attack recovery #86

Clarify rollback attack prevention and fast-forward attack recovery #86

Commits on Sep 1, 2020