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

AuthZ for signing key usage #111

Open
tarcieri opened this Issue Nov 22, 2018 · 0 comments

Comments

Projects
None yet
1 participant
@tarcieri
Copy link
Collaborator

tarcieri commented Nov 22, 2018

tmkms is presently a signing oracle with no AuthN/AuthZ, and though it establishes an outbound TCP connection, it will connect to any remote peer that implements the Secret Connection protocol, i.e. while Secret Connection provides AuthN in the form of Ed25519 certificates, there is presently no AuthZ around which peers can connect to the KMS or use specific keys whatsoever.

Some mechanism is needed to authorize which remote peers are allowed to use which keys, e.g. some sort of Access Control List in the configuration. While there are other methods of AuthZ which might be interesting (ocap or other credential-centric systems), for now an ACL is probably the simplest.

@zmanian had suggested tagging each key in the signing keyring with a chain ID (which was already sort of happing in an ad hoc, stringly typed manner), in which case I think the ACL can map peer IDs to chain IDs they are validators for.

This is definitely a launch blocker, but also shouldn't be that difficult to implement. We already tag validators in the configuration with their chain_id, e.g.

[[validator]]
addr = "tcp://example1.example.com:26658"
chain_id = "gaia-9000"
reconnect = true
secret_key = "path/to/secret_connection.key"

The next steps to me for an ACL based solution would be:

  • Add a peer_id field to each [validator], and ensure the remote peer ID matches the peer_id in the config (or else abort the connection)
  • Tag every key in the keyring with a chain_id, in a first-class manner with the tendermint::chain::Id type, and partition the signing keyring by chain ID.
  • When a signing request is received, only use the keyring for that validator's chain_id
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment