We identified and subsequently fixed a security issue in the implementation of the Shutter Network DKG protocol that caused unintentional publication of secret keys during the DKG ceremony.
Key generation in the Shutter Network DKG protocol happens in four phases (“Dealing”, “Accusing”, “Apologizing”, “Finalized”). During the first DKG phase (the so-called “Dealing” phase), each Keyper (i) will send an encrypted polynomial evaluation corresponding to another Keyper’s (j) secret key share at index (i). If Keyper (i) fails to send a valid encrypted evaluation, Keyper (j) must issue an accusation against Keyper (i) in the “Accusation” phase. In response, Keyper (i) must respond with an apology, which contains the same polynomial evaluation in plaintext (unencrypted), allowing all Keypers to verify its correctness publicly. The reason for this design is resistance against collusion / malicious behaviour by forcing misbehaving Keypers to make their key shares public.
If enough Keypers send public apologies, the secret shares of Keypers can be reconstructed.
Until the fixed release (v1.3.15), Keypers were failing to send the polynomial evaluations, resulting in enough public “apologies” being sent to render the key shares of some Keypers public even though the DKG was deemed successful.
Since the communication during the DKG phases happens on a tendermint based blockchain, that is by design public, those unencrypted “apology” messages could theoretically be accessed by anyone.
We took the following steps to mitigate this issue:
- Issued new releases that correct this behaviour and asked Keypers to upgrade
- Asked all Keypers operating in Keyper Sets that produce long lived keys to delete the tendermint blockchain database containing key material
- Performed transitions on the affected Keyper Sets to ensure new DKG keys were generated
Since most Shutter use cases produce short lived keys that are made public within a short time frame anyway the impact there was limited. The exception to this is the Shutter API, which does produce long lived keys.
Having completed the above mitigation steps described above, we ensured continued availability and uninterrupted secured decryption operations. We currently have no reason to believe that this vulnerability was being known of or exploited by third parties before we discovered it internally.
This incident also prompted us to evaluate potential improvements to the DKG protocol. We will continue strengthening it and will share a detailed update as the work progresses, including how these findings relate and build upon the work presented in our research paper.
The issue has now been fully resolved and mitigated across all Keyper sets. Keyper nodes remain online and actively participate in decryption key generation.
We give our thanks to all Keypers for maintaining availability throughout the resolution process and for their continued reliability. Their consistent uptime and stable operations were essential in ensuring a smooth and coordinated recovery.