Closed sbond14 closed 10 months ago
The "secret connection" protocol uses an identity key, regardless of whether or not it's authenticated by the remote peer. Think of it the same way you would the node identity key for any CometBFT/Tendermint node.
You can validate the remote validator's identity key by including an address hash as seen here: https://github.com/iqlusioninc/tmkms/blob/5c8575860f448c4849d1c74f4434a455ab718098/tmkms.toml.example#L34
Unfortunately this hasn't ended up being particularly useful in practice because CometBFT/Tendermint does not persist this key but randomly generates it on node startup, which has been a longstanding unaddressed issue.
Thanks for the info!
Say I want to fail over to another yubikey to start doing the signing for my validator. Does that secret_key value need to be the same on the new yubikey?
This key in particular has nothing to do with validator/consensus signing. It only identifies TMKMS as a network peer when it connects to your validator.
It's the equivalent of node_key.json
, whereas the keys on the YubiHSM are the equivalent of priv_validator.json
Understood, thank you!
I am curious if this line in tmkms.toml is still required? If so, what is it used for? I don't understand how it helps authenticate the KMS to the validator if the secret is never placed anywhere on the validator machine.