🛠 PR Checks Summary

AllAutomated Checks passed. ✅

Manual Checks (for Reviewers):

• IGNORE the bot requirements for this PR (force green CI check)

Codecov Report

Attention: Patch coverage is92.81501% with134 lines in your changes missing coverage. Please review.

📢 Thoughts on this report?Let us know!

Today we had a call with@zivkovicmilos to discuss the current implementation of gnokms and the remote signer / private validator interface inherited from the Tendermint codebase, and we concluded the following:

• The current unconventional connection model with the server dialing the client seems irrelevant from a security perspective and is counterintuitive. It also poses implementation issues at several different levels (client initialization, server configuration, etc.). We believe it would be cleaner and healthier to modify this mechanism so that the server is launched and waits for client requests.
• We think that the node should ensure that it never signs the same data twice and that the remote signer should be completely stateless, with as little intelligence as possible, and should only sign what the node requests.
• The current interface that differentiates between vote signing⁠SignVote(chainID string, vote *Vote) and proposal signing⁠SignProposal(chainID string, proposal *Proposal) does not seem relevant to us. We believe that the remote signer should simply sign bytes without adding more complexity.

Before proceeding, I would like to ask for your opinion on the best approach to adopt for the refactor.

Approach A

1. GnoKMS takes the following parameters:
   • The ID of the unique signing key this instance will use to sign data
   • An address to listen on for incoming connections
   • Optionally, the necessary private/public keys for mutual authentication
2. The validator node does not know its validator public key; it only takes the following parameters:
   • The address of the remote signer (GnoKMS) to connect to
   • Optionally, the necessary private/public keys for mutual authentication
3. The node connects to the remote signer, authenticate,gets the validator public key then completes its initialization (the public key is required during node initialization)
4. The node locally verifies if the votes/proposals it wants to sign are consistent (no double signing, no issues with height lower than the previous signature, etc.)
5. The node then sends simple arbitrary data (a slice of bytes) to GnoKMS for it to sign
6. GnoKMS returns the signature of the data in question without performing any checks

Advantages

• The API is very simple
• The attack surface is greatly reduced for the remote signer
• GnoKMS can perform key rotations/changes without needing to coordinate with the node in advance

Approach B

1. GnoKMS takes the following parameters:
   • The path of a keybase containing multiple different keys
   • An address to listen on for incoming connections
   • Optionally, the necessary private/public keys for mutual authentication
2. The validator node already knows its public key; it only takes the following parameters:
   • The address of the remote signer (GnoKMS) to connect to
   • Optionally, the necessary private/public keys for mutual authentication
3. The node initializes with its public key that it already knows, connects to the remote signer, authenticate, thenrequest it to use the corresponding private key.

4, 5, 6. Same as in approach A

Advantages

• A single instance of GnoKMS can sign with multiple different keys
• The initialization of the node can occur independently of the connection to the remote signer

Personally, I prefer the approach A (more simple and secure IMO), but I want to anticipate potential alternatives before tackling the refactor.

Other questions

• If the node loses connection to the remote signer, should it fail immediately, or should it simply continue running, attempting to reconnect to the remote signer every X seconds and fail to sign blocks in the meantime?
• Should GnoKMS accept that multiple different nodes connect in parallel? Or do we want to enforce a 1:1 connection?