Decentralized threshold crypto custody
In this article we will review existing crypto custody solutions, find common problems and propose a new decentralized approach to crypto custody that addresses common pitfalls of existing systems.
What is crypto custody and why do we need it?
Managing secret keys is hard. They are difficult to remember, easy to lose. They can be stolen, hacked or accidentally revealed to other individuals. Loss of a secret key leads to full loss of access to the user’s account and all funds associated with it. Theft of a secret key allows the perpetrator to steal funds or make other unauthorized operations pretending to come from the account owner.
Those risks and restrictions make it really hard for users, especially new ones, to interact with blockchains and other secret-key crypto systems. It also makes it difficult for existing financial systems, mostly relying on traditional authentication techniques, to integrate with secret-key systems. Finally, independent secret management involves significant risks with regard to loss or theft.
To address these issues, many crypto custody solutions have been proposed. A custodian is a system that offers secure storage of users’ secrets, abstracting away cryptography and technical complexity of underlying secret-key systems, while providing traditional authentication and authorization interfaces, such as email, password or phone.
Centralized custody problems
Most custodians available on the market are centralized. That means there are servers checking users’ identity, databases keeping full user secrets (possibly in several copies as backups), servers using full secrets to generate digital signatures, network interaction between the components, all belonging to a single person or organization.
Centralized architecture has inherent vulnerabilities. A database with secrets can be lost or stolen. A server generating signatures can get hacked and leak secret keys used in the signing process. Spyware can be inserted to watch network traffic.
And the human factor shouldn’t be ruled out, either. It is common for perpetrators to exploit human errors or malevolent intentions for their benefits. In any centralized system, there are people — system administrators, technical staff etc. — with access to important subsystems. And even a single compromised person can render the whole system compromised.
Decentralized custody
The problems described above have the same origin: centralization. A single person, a single server, a single database — if any of them fails, the whole system fails. So, how is it possible to avoid any single point of failure? By making the system decentralized.
First, let’s formulate some requirements for an ‘ideal’ system:
- No single person must be able to compromise the system.
- No storage containing full secrets must exist.
- A full secret key must never appear on any single server or device.
The only way to satisfy the above requirements is to somehow split one key into several parts. Each part must be kept separately, in databases and servers maintained by different people. In order to execute operations, participants have to cooperate in some way, without ever revealing their secret shares to anybody.
A naive approach would be to split the key into n parts and require that all n participants execute an operation. However, that means a single compromised or offline participant compromises the entire system, which breaks requirement 1 and takes us back to the single point of failure issue.
Hence, the number of cooperating participants required to execute an operation on behalf of the user must be fewer than n. Let t denote the number of participants required for executing an operation.
This solution has advantages in both security and availability. Now, at least t participants need to become compromised simultaneously to compromise the entire system. And the system goes offline only if (n-t+1) participants go offline at the same time.
The ideas above are inspired by known approaches to security and cryptography, such as the Shamir Secret Share scheme, multi-factor authentication, multi-signature, threshold cryptography.
Threshold cryptography
In order for a system to function while meeting requirements stated above, there needs to be a way for the participants to create digital signatures on behalf of users without ever revealing their secret shares or recreating a full secret on a single machine.
There is an entire area of cryptography, dedicated to just that: threshold cryptography. Algorithms have been proposed to cover many popular digital signature schemes: RSA, ECDSA, EdDSA etc. Implementing those algorithms can enable a proposed custodian to become cross-blockchain and operate on many systems: Waves, Bitcoin, Ethereum or others.
For now, we will focus on the signature scheme used on the Waves blockchain, based on EdDSA with Curve25519. All scalar values below will be assumed to be in a prime order subgroup.
Decentralized key generation
According to requirements 1 and 3, a full key must never appear on a single machine. That includes the phase of user creation and key generation. So, an algorithm is needed that allows cooperating participants to generate secret key shares and the corresponding public key without revealing their shares or gathering a full key in one place.
Several schemes have been proposed to accomplish this. We base our solution on a scheme proposed by Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk and Tal Rabin in 1999.
Secret shares redistribution
A crypto system like we are proposing should consider security and reliability not only at a fixed point in time, but also over extended periods. To enable that, the network should be not static, but flexible and adaptable to changing circumstances.
Our way to achieve said flexibility is via secret share redistribution. Using existing shares and several rounds of communication, t out of n participants create and distribute new sets of shares to all participants of the updated network, without revealing any shares or full secret. After its completion, all participants included in the redistribution will have new secret shares, incompatible with the old ones, but all users’ public keys will stay the same.
Given that both the number of participants and the threshold value can be changed, this approach is generic enough to cover vital use cases, such as:
Use case: Participant loses data
Solution: Redistribute shares ‘in-place’: same participants, same threshold. A new set of shares for each participant will be created, including the one who lost data.
Use case: Participant reveals data
Solution: Same solution: redistribute ‘in-place’. The participant gets new shares, revealed shares become useless.
Use case: Participant turns malevolent
Solution: ‘Kick’ the participant out of the network: redistribute in a way that does not include the participant in an updated network.
Use case: Participant leaves
Solution: Same solution.
Use case: New participants need to be added
Solution: Redistribute, involving new participants.
Use case: Threshold value changes
Solution: Redistribute, setting a new target threshold in the algorithm.
An algorithm based on a 1997 paper by Yvo Desmedt and Sushil Jajodia is proposed for our system, with additional checks for further security.
User authentication
So far, we focused on the cryptographic aspect — that is on how the network executes operations. However, in order to decide whether to execute them or not, a proof of the user’s identity is required. Moreover, each participant must validate the user’s identity independently and proceed to execute an operation only upon successful authentication.
Traditional authentication with email and password is the most widely used and, therefore, user-friendly way of authentication. Coupled with a reliable identity provider, it offers security on par with traditional banking and financial systems. It also enables 2-factor authentication, phone confirmation and other advanced security measures.
Summary
Today, we are making the first public step in combining scientific advances in the field of threshold cryptography and traditional email authentication. We believe that this will help execute our mission of fostering wide blockchain adoption, and we will continue our work in that direction. And a lot of work still needs to be done. This year, we’ll focus on development and publication of materials, gradually moving towards making the technology not just secure but also publicly available as source code.
Those who are wary of threshold cryptosystems could still use traditional authentication methods, such as seed phrases and various devices, including Ledger.
Shortly, we’ll add an option of exporting secret keys from accounts created with email. But we should warn that this will be a one-way ticket. As a result of this action, the account created with email will be deleted, and the user will be able to access the address created with email, using the secret key.
The use of email authentication will offer several other opportunities, such as:
- changing the password
- resetting the password
- attaching 2FA, such as Google Authenticator
- adding extra features, including stop loss, take profit etc.
As we constantly work on making our services as secure and user-friendly as possible, we’ll keep you posted on latest developments.
And, certainly, we are glad to share that as of today, the email authentication technology becomes available in outside developers’ dApps (swop.fi, levex.fi etc.).
