Key Shards

Disclaimer: This is a summary of patterns we have observed during our research and should not be considered any form of technical or investment advice. Also, the given “known examples” do not imply they are the best implementations of the said pattern or any superior to any other implementation of the pattern not listed.

Summary

Split a key into several different pieces and restored using enough pieces.

Context

In self-sovereign identity, a party may use a key for multiple purposes such as signing key for transaction authorisation and public/private key pair for encryption/decryption.

Problem

A user may lose or forget his/her secret keys, e.g., the device containing the keys is lost, stolen, or broken. A lost key denotes that the owner could lose control over its blockchain account, related identity, and assets.

Forces:

  • Lost key – Private keys are usually long and hard to remember. Also, many blockchain platforms do not provide a sound mechanism to recover a lost or compromised key. Thus, it results in permanent loss of control over the related identifier and its assets.
  • Centralisation – A blockchain user’s keys are usually stored in a wallet application, e.g., installed on a mobile device or a hardware wallet. Such centralised management of keys may cause lead to a single point of failure. Once the device is lost or hacked, the user may lose control of all keys.

Solution

To protect the security of a key, one can spilt the key into several pieces/shards and store each piece in a different place. For example, store key pieces on a decentralised file system ensuring that all pieces are not collocated like in IPFS or different regions of a cloud provider. Also, key parts could be stored on different devices like USB flash drives, hardware wallets, or writen on a piece of paper and stored in a safe box. When a transaction is to be signed, collect relevant key pieces to reconstruct the key.

Key Shards

Key Shards

In the simplest form, a key could be split into n pieces. Then combine all n pieces to reconstruct the key before signing a transaction. However, we could adopt more advanced cryptographic techniques known as secret splitting schemes. For example, when a key is split into n pieces using a technique like Shamir’s secret scheme, only m pieces (m ≤ n) are needed to reconstruct the key. In such a technique, even if a key piece is lost, the user can still control his/her identity or assets as far as enough key pieces can be collected to reconstruct the key.

Benefits

  • Tolerance to partial key loss – Even if some key pieces are lost, the key can be recovered as far as enough pieces/shards can be collected.
  • Decentralisation – The key pieces are stored in a decentralised way, which reduces the risk of losing all key pieces in an attack.
  • Flexibility – An entity does not have to input all but just enough key pieces when recombining a lost key.

Drawbacks

  • Cost – Maintaining key pieces needs extra vigour. If a key piece is lost, there is no way to restore it.
  • Security – Having multiple key pieces provides multiple targets to attack.

Related patterns

  • The master and sub-key generation pattern can use key shards is to split and recombine both master and sub-keys.
  • The key splitting and recombining functionalities could be integrated into both hot and cold wallets.
  • Alternative to key sharding delegate list pattern aims to replace a compromised key with a new one.

Known uses

  • For each private key of an account, Parity distributes 12-word phrase acting as an additional backup. If a user loses the private key, this phrase can helpfully recover it.
  • Crypto++ is an open-source C++ library of cryptographic algorithms and schemes, which implements the Shamir’s Secret Sharing scheme: splitting up a secret into a defined number of pieces, and restoring the original secret when given enough secret pieces.