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

Use TUF metadata formats for signing index commits #7

Open
wants to merge 1 commit into
base: signing-registry-commits
from

Conversation

@tarcieri
Copy link

commented Aug 29, 2018

Rendered

This PR adapts rust-lang#2474 to use file schemas (serialized as TOML) and role names from The Update Framework (TUF):

  • keys TOML => root.toml
  • can-rotate privilege => TUF root role
  • can-commit privilege => TUF timestamp role

It should be a fairly close to a 1:1 mapping of TUF concepts to the original approach, and otherwise continues to use OpenPGP public keys, fingerprints, and signatures on git commits. The main differences are:

  • keys TOML (i.e. root.toml) has a different schema
  • root.toml is checked into the repository as opposed to being stored in an annotated tag (tagged commits can be signed ala git tag -s)
  • when @bors commits to the index, it would also modify a timestamp.json file, bumping a version number and expires date
  • key rotation tags are prefixed with root-rotation- and the counter starts from 1 instead of 0 per the TUF spec

Other than that, it should pretty much be the same idea.

Omitted for now are TUF's targets role and snapshot roles. The targets role could provide end-to-end crate integrity, but is a much more substantial undertaking in hopes of keeping an initial index signing simple. The value of the snapshot role in a git-based system is debatable. It might be worth including for compatibility with existing TUF implementations (e.g. rust-tuf), but this PR omits it for now (if you feel strongly about including it, please leave a note and I can update the PR).

verified_registry_commits: TUF metadata formats
Changes the file formats for withoutboats' proposed
`verified_registry_commits` feature for signing Cargo indexes to use
formats and concepts from The Update Framework.
@trishankatdatadog

This comment has been minimized.

Copy link

commented Aug 29, 2018

Thanks very much, Tony! 👍

I would strongly recommend leaving the snapshot, and targets roles (with empty targets) just so you would not have to add special cases to the TUF client update workflow.

In any case, this is a great start :)

Authority for signing the index is separated into 2 different roles: root
and timestamp, which each have their own metadata file and signing keys:

[3. The repository]:

This comment has been minimized.

Copy link
@tarcieri

tarcieri Aug 29, 2018

Author

Whoops, forgot to delete this

@withoutboats

This comment has been minimized.

Copy link
Owner

commented Aug 29, 2018

Other than that, it should pretty much be the same idea.

Then how is it better? Given that almost all of these changes are superficial and inconsequential for security, this is why I am honestly very suspicious of all the TUF advocacy I have experienced: I am inclined to believe that this is about a win for TUF rather than improving the security of our infrastructure.

@tarcieri

This comment has been minimized.

Copy link
Author

commented Aug 29, 2018

Then how is it better?

The full benefits would come after the targets role is implemented and can be used for end-to-end-crate integrity (via delegated targets).

Beyond that though, TUF is well-specified and has detailed descriptions of e.g. its verification workflows, for example:

https://github.com/theupdateframework/specification/blob/master/tuf-spec.md#5-detailed-workflows

- **`timestamp` and `root` roles combined**: this RFC describes a setup where
in practice all `root` keys would also be authorized as `timestamp` keys,
which allows us to enforce the property that all commits are signed by the
`timestamp` role. There is no security advantage to separating them (at least

This comment has been minimized.

Copy link
@arielb1

arielb1 Sep 1, 2018

If the timestamp key is used to ensure "transparency" (i.e., to prevent the creation of 2 separate commit chains), then we have to require an "old timestamp" signature on all commits.

This comment has been minimized.

Copy link
@tarcieri

tarcieri Sep 1, 2018

Author

In general preventing duplicity in systems like this is difficult (see similar concerns regarding CT logs, auditors, gossip protocols, etc).

That said, I don't follow what you're saying. A signature over a git commit covers the current tree in addition to the parent OID, which is the SHA-1 digest of the previous commit's tree, parent, and the full OpenPGP signature over that commit (provided it's there), i.e. each commit signature is over the entire repository history including the signature on the previous commit.

This comment has been minimized.

Copy link
@arielb1

arielb1 Sep 1, 2018

The idea is to have the timestamp key is stored in a manner that makes it hard for an attacker to create unlogged signatures (I think Amazon offers an HSM module that does that). If we can find such a service, it would be worth to put the timestamp key in it.

In that case, we don't want a compromised root key to bypass the "anti-duplicity" feature of the timestamp key.

This comment has been minimized.

Copy link
@tarcieri

tarcieri Sep 1, 2018

Author

Using cloud HSM or KMS services on any of the major cloud vendors (e.g. AWS, GCP, Azure) would likely require using a different signature algorithm than Ed25519, e.g. ECDSA over P-256. ECDSA has wide support among cloud KMS services, HSMs, and PIV devices such as YubiKey 4s.

That said, there are several hardware options for Ed25519 key storage. YubiHSM2s support Ed25519, as do a number of cryptocurrency hardware wallets (e.g. Ledger), although whether that's a practical deployment option for something like @bors seems questionable.

This comment has been minimized.

Copy link
@arielb1

arielb1 Sep 1, 2018

In that case, why not allow for verification with that signature algorithm? It feels like something we can set up basically today.

It seems likely that a threshold of the root keys will not have a strong audit mechanism, and setting up separate "root", "root+audit", and "timestamp+audit" keys feels like a PITA.

This comment has been minimized.

Copy link
@tarcieri

tarcieri Sep 1, 2018

Author

I think ECDSA support is worth considering. FWIW I support it in Signatory.

@arielb1

This comment has been minimized.

Copy link

commented Sep 1, 2018

I suppose the verification rules here are as following:

  1. Define the "principal chain" of "principal commits" to be the list of commits starting from HEAD and extending by following the first ancestor of each commit, ordered such that the first commit is the "verification initial commit", whose hash is pre-distributed, and the final/last commit is HEAD.
  2. The hash of one of the principal commits, the "verification initial commit", is pre-distributed (that does not have to be the same as the Git initial commit, i.e. it can have a parent). It forms the root of trust of the system.
  3. Every principal commit must have a git commit signature. The key that signed the commit must be a timestamp key in that commit's root.toml, and in all principal commits other than the verification initial commit, in the previous commit's root.toml.
  4. If root.toml in a commit differs from root.toml in that commit's parent, that commit must be signed by a tag signature by a root keys in the parent's root.toml.
  5. timestamp.toml & root.toml must be valid TOML files of the right format in every principal commit.
  6. The version field in timestamp.toml must increase by 1 between succeeding commits. The version field in root.toml must increase (not necessarily by 1) every time root.toml changes.
  7. Non-principal commits (i.e., commits that are only the "second" ancestors of a principal commit) don't have to be signed, but are verified indirectly because they are a part of the Merkle tree.

I could write them in pseudo- code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.