Early on, I created a system that we had awarded as one of our earliest patents.
After Mt Gox, it was clear that there is a need for a “Secure Split Key” technique — to build upon the Deterministic Key Generation technique that I have documented before. In order to address the issue of key management (including with exchanges), I created a number of systems that allow users and businesses to securely store a private key (such as for a digital wallet) in such a way that it cannot be obtained by an unauthorised party, but can also be reproduced when necessary. Titled “Secure Multiparty loss resistant Storage and Transfer of Cryptographic Keys for blockchain based systems in conjunction with a wallet management system,” the full description can be found in PCT application number PCT/IB2017/050829.
In summary, a commercial wallet based on a “Secure Split Key” or threshold system can secure a digital wallet, or another type of resource for that matter, by:
- splitting a cryptographic key (or a mnemonic seed for a cryptographic key) into a plurality of shares such that it can be restored or regenerated from two or more of the shares: such could be performed using a known cryptographic algorithm called “Shamir’s Secret Sharing Scheme” (4S), which involves splitting the key up into unique parts or shares that are then distributed to different parties. The shares can be used to reconstruct the key when needed. Each individual share is of no value or use on its own, until it is combined with one or more other shares. The number of shares required to reconstruct the key can vary according to the needs of the situation. In some cases, all shares may be required, while in other cases, merely a sufficient number is required;
- determining a common secret at two or more nodes on a network i.e. parties, and then using the common secret to generate an encryption key which can be used to encrypt one or more of the shares, or a message relating to the share;
- using the common secret to transmit at least one share of the key between the two or more nodes: the two steps can be performed using the foregoing technique and the invention described above (PCT application number: PCT/IB2017/050856). The transmission of shares between the parties must be performed in a secure manner because any unauthorised interception of multiple shares could enable the interceptor to reconstruct the key.
Therefore, different shares of the key or its mnemonic can be transmitted securely between different parties and then stored in separate locations. The key does not exist anywhere in its complete form until required, at which time it can be regenerated from a specified number of shares, e.g. using the 4S algorithm that was used to split it. No single party has the ability to generate the private key unilaterally, not even the user. Even if the user dies, becomes incapacitated, or loses the key, the other two shares could be used to access the funds by another legitimate party — e.g. an attorney, next of kin, etc. Alternatively, if the wallet provider is hacked, the key and thus the funds remain secure.
So, for example, a digital wallet provider could use the technique as follows in a ‘2-of-3’ scheme — i.e., there is a threshold of 2 shares required for regeneration:
- A user registers with a wallet provider to create a new wallet to store his/her funds (for example, bitcoins).
- A public-private key pair is generated and associated with the user’s wallet.
- The private key is split into shares using 4S.
- One share of the private key is sent by a secure transmission to the user using the technique described above.
- Another share of the private key is retained by the wallet provider and stored on a server.
- Another share is sent by a secure transmission to a remote location for safe storage.
- The wallet provider can destroy any or all copies of the complete private key, because it is no longer needed. When the private key is needed for subsequent authorisation of the user (e.g. because the user now wishes to make a transaction), the key can be reconstructed from the user’s share, which (s)he provides to the wallet provider when needed, and the wallet provider’s share.
- In the event that one share is lost, the key can still be reconstructed using the remaining two shares.
Therefore, we have created a solution for securing a digital wallet (or, indeed, any other type of controlled resource) which avoids the risks associated with either storing a private key yourself or trusting a third party (such as the wallet provider) to do so. With such a technique (in combination with the Deterministic Key Generation in the first invention described above), no Mt. Gox-type hack would succeed in stealing bitcoins; a hacker would not be able to access users’ complete private keys, and could not steal their bitcoins.
Introduction — Threshold-Schema Basics
Differences between different transaction-signature schemas:
There are many participants, and each one holds merely a share of the private key. Combining all shares, the transaction (tx) is signed. The result is the same as a single signature. The public key (for verification) is the same for all of them.
More importantly, the division of keys can be extended in script. Alice can have a 2-of-3 scheme where Bob has one key for the first key in a 2-of-2 script, and Bob may use a 2-of-3 scheme where Alice has one key for the second key. Together, they can both securely self-backup the other or even create a more complex system that enables the level of control they require.
Most critically, it is a system that allows for the generation of keys that are sent to the parties in the system sequentially merely once. The shares are used, and then a new key is created.
If you think it through, it also allows shares to be used by devices. Such can be the user’s device or such may be systems (such as an oracle or IoT controller) that act to sign based on a vote.
A user could have a shared-key system where one key is a simple pin-based derived key; another key root is stored on the device, and is stored securely; the third is a recovery root key, which can be locked in a safe or an escrow service.
When used on a web-based wallet, the online system would not need to have the user’s entire key, and yet could act to recover lost bitcoin and tokens.