Key-management features for validators

[joepetrowski]

A lot of validators have different policies around how they store keys and sign messages. We could move some functionality out of the client.

Stash / Controller Key Management

We should have an HTML file or docker container with Polkadot JS that is "blessed" by Parity or W3F. This could be, for example, a tweet with the hash of this container. This would allow key generation and signing on an air-gapped or live-booted machine.

Session Key Management

Validators have different risk profiles. For example, some worry about availability and always want to be online. Others are more risk-averse and would rather be reported offline occasionally than equivocate. The validator's business logic should be able to handle this outside the client.

When a client needs to sign something, it should be able to make a call to another machine with the payload to sign. Then, that machine can implement whatever signing logic and key management it wants.

For example, the following setup should be possible. The validators would only send payloads that need to be signed. The signing machine could implement whatever logic or setup the validator prefers. It could be a dumb HSM that just acts as a signing oracle or MPC key storage and could also implement more complex logic (like not signing two blocks of the same height).

cc: @folsen

[burdges]

I agree about air gaped stash and controller key management. We support Ed25519 keys for these to simplify adding support to Trezor, etc.

Validators have different risk profiles. For example, some worry about availability and always want to be online.

I disagree. I think all cosmos slashings thus far come from their "session" private keys existing in more than one place.

The validator's business logic should be able to handle [keys] outside the client.

I disagree. As much as possible, we should prevent validators' session private keys from ever existing outside the keystore. #3324 (comment)

In particular, we eventually want SGX builds in which the enclave cannot import or export session private keys and the enclave signs any session public key for the session private keys in generates, so that any equivocations indicate an exploit of either substrate or SGX.

We sadly cannot absolutely prevent session secret keys existing elsewhere because networks launch in various states, but any features for importing or exporting secret key should be marked as dangerous.

When a client needs to sign something, it should be able to make a call to another machine with the payload to sign.

Yes, except any machine that acts as a dumb signing oracle might be better off running critical portions of substrate, like babe, grandpa, etc. We can prevent many equivocations with slightly smarter signing oracles, but not all grandpa ones, so you're asking partially about running substrate piecemeal. I'd allocate more resources to smarter sentry nodes that help with availability or whatever, but yes this also makes sense.

[joepetrowski]

I think all cosmos slashings thus far come from their "session" private keys existing in more than one place.

Well, in this proposed setup, the private keys do only exist in one place.

[burdges]

Right, we need an RPC call for import of keys, but their documentation should communicate our wish that keys only exist in one place with some warning that you'll get yourself slashed otherwise.

As I said in #3324 (comment) the default workflow should be

1. an operator first sends an RPC request to generate a session key, or maybe a one part of a session key,
2. substrate creates the new key, stores the session key pair into the keystore, and return only the public keys to the operator, and
3. the operator signs the full session public key with their controller key and returns this session certificate via the RPC.

Any external signer programs should work roughly similarly

[joepetrowski]

Closing in favor of #4689