Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Spec - 4.4 - Client parses snapshot.json with the length/hash of root.json (but not of other metadata) #14

Closed
heartsucker opened this issue Apr 13, 2017 · 5 comments

Comments

@heartsucker
Copy link
Contributor

Currently the internal API requires the hash/length to exist for all metadata. This breaks the spec (but was easy to write for the bootstrap period of this lib).

@heartsucker
Copy link
Contributor Author

@trishankkarthik I have a question about this part of the spec. Since it's not specified anywhere, do clients need to verify that the downloaded metadata matches the hash/size specified in snapshot.json / timestamp.json?

@trishankkarthik
Copy link

trishankkarthik commented Apr 26, 2017

Hello, @heartsucker! Yes, we really do need to specify this in the TUF specification. I have tried clarifying the precise steps that a client update workflow entails in explaining full verification for Uptane. Even there, a few minor steps are missing. Let me try to recap the "complete" workflow here.

  1. Download the root metadata file, up to some predetermined number of bytes (because the size is unknown).
    1.1. Check signatures. It must have been signed by a threshold of keys specified in the previous root metadata file.
    1.2. Check for a rollback attack. The version number of the previous root metadata file must be less than or equal to the version number of this root metadata file.
    1.3. Check for a freeze attack. The latest known time should be lower than the expiration timestamp in this metadata file.
    1.4. If the the timestamp and / or snapshot keys have been rotated, then delete the previous 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 for more details (to be published soon).

  2. Download the timestamp metadata file, up to some predetermined number of bytes (because the size is unknown.)
    2.1. Check signatures. It must have been signed by a threshold of keys specified in the root metadata file.
    2.2. Check for a rollback attack. The version number of the previous timestamp metadata file, if any, must be less than or equal to the version number of this timestamp metadata file.
    2.3. Check for a freeze attack. The latest known time should be lower than the expiration timestamp in this metadata file.

  3. Download and check the snapshot metadata file, up to the number of bytes specified in the timestamp metadata file.
    3.1. Check against timestamp metadata. The hashes, and version number of this metadata file must match the timestamp metadata.
    3.2. Check signatures. It must have been signed by a threshold of keys specified in the previous root metadata file.
    3.3. Check for a rollback attack.
    3.3.1. The version number of the previous snapshot metadata file, if any, must be less than or equal to the version number of this snapshot metadata file.
    3.3.2. The version number of the targets metadata file, and all delegated targets metadata files (if any), in the previous snapshot metadata file, if any, must be less than or equal to its version number in this snapshot metadata file. Furthermore, any targets metadata filename that was listed in the previous snapshot metadata file, if any, must continue to be listed in this snapshot metadata file.
    3.4. Check for a freeze attack. The latest downloaded time should be lower than the expiration timestamp in this metadata file.

  4. Download and check the top-level targets metadata file, up to either the number of bytes specified in the snapshot metadata file, or some predetermined number.
    4.1. Check against snapshot metadata. The hashes (if any), and version number of this metadata file must match the snapshot metadata. This is done, in part, to prevent a mix-and-match attack by man-in-the-middle attackers.
    4.2. Check for an arbitrary software attack. This metadata file must have been signed by a threshold of keys specified in the latest root metadata file.
    4.3. Check for a rollback attack. The version number of the previous targets metadata file, if any, must be less than or equal to the version number of this targets metadata file.
    4.4. Check for a freeze attack. The latest downloaded time should be lower than the expiration timestamp in this metadata file.
    4.5. Perform a preorder depth-first search for metadata about the desired target.
    4.5.1. If this file contains metadata about the desired target, then go to step 5.
    4.5.2. Otherwise, recursively search the list of delegations in order of appearance.
    4.5.2.1. If it 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 it).
    4.5.2.2. If it is a terminating delegation, then jump to step 5.
    4.5.2.3. Otherwise, if it 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.

  5. Verify the desired target against its targets metadata.
    5.1. If there is no targets metadata about this target, then report that there is no such target.
    5.2. Otherwise, download the target (up to the number of bytes specified in the targets metadata), and verify that its hashes match the targets metadata.

I think I got the basics, though I may have missed something (away at a conference on updates for IoT), so please let me know if you spot a mistake!

Even here, some details are missing, such as:

  • Downloading and verifying the complete chain of root metadata files. (Maybe @ecordell or yourself could help here?)
  • Following the map file, but the pseudocode is already there...

Will expand over time...

@heartsucker
Copy link
Contributor Author

@trishankkarthik Awesome, thanks for the detailed response!

@trishankkarthik
Copy link

No problem. Tracking the larger issue of adding more details in the spec in this PR. Let us know if there's anything else we can help with!

@heartsucker
Copy link
Contributor Author

Note: work is on branch snapshot-verify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants