search

oasisprotocol / oasis-core

Performant and Confidentiality-Preserving Smart Contracts + Blockchains
https://oasisprotocol.org
Apache License 2.0
332 stars 109 forks source link

Consensus keys should be ephemeral if possible #2368

Open kostko opened 4 years ago

kostko commented 4 years ago

Consensus keys should be ephemeral if possible (enforced by the consensus layer?). This would enable honest validator nodes to perform key erasure to mitigate attacking previous validator sets.

Yawning commented 4 years ago

I support this in theory, I'm not sure how easy this would be to do in practice.

bennetyee commented 4 years ago

We should plan on moving in this direction. As the number of past consensus committees grow with time, the number of old keys that can change history grows (esp when servers are retired, etc) and becomes security debt, and key erasure (whether new key generation or via forwad secure signatures) is the only known way to mitigate this risk.

kostko commented 4 years ago

Agreed, we should look into how to implement this. The major question is whether just switching the consensus key is something that is supported by Tendermint Core.

bennetyee commented 4 years ago

Can we do something like the following (rather than changing to a different signature scheme or switching consensus key):

Make it a key management problem. We require that nodes generate a new key periodically. Nodes can have long term keys, but the long term key is used to register the node's ephemeral key. Registration is on-chain, so there is a record. Good implementations would generate the key on demand, when registration is done. Registration is only good for a limited time, e.g., two (or four or ...) epochs. So in order for a node to participate in the consensus committee, it has to generate new keys, and switch over to the new key at epoch boundaries. Expiration time is known, since an ephemeral key starts becoming valid at the time of registration, and if a node does not have a valid key it cannot serve on committees. Good implementations will erase old keys, but that's all we can ask for, since even forward-secure signature schemes require correct implementation of advancing the private key epoch rachet.

kostko commented 4 years ago

What you are proposing is essentially what this issue is all about, it requires switching the consensus key that Tendermint Core uses (e.g., after a certain block height). I'll look into what would need to be done to support this.