Threshold based key backup service

This post is supposed to outline the different steps and components needed in order to implement threshold-based key backup service as discussed at the weekly design meeting #25

Initially, it will only focus on an Android implementation, and we will later have to consider how to make a port for iOS.

The system will consist of two phases. The first one constructing a workable solution that does not support refresh of key shares. The second phase will add the refresh option on top. It is here important to note that the second phase can be added after deployment and will allow us to refresh the secret shared keys already in the system.

The system itself will use threshold cryptography in a 2-out-of-3 setting. It will be based on Java, building on top of PESTO Paper and Showcase Implementation for threshold authentication and a Shamir Secret Sharing library for threshold sharing.

For 2FA either email code or a standard OTP (or Google Authenticator) will be used, depending on the user's choice.

  • For email code, each SSS parties sends an email with a code and the user submits code to corrisponding parties;
  • For OTP, the OTP is sent to Alphawallet which will then inform the servers of whether or not they should accept a threshold password authentication request from the given user.

Phase 1

The system will consist of the following components:

AlphaWallet OTP gateway

This will be a single-serve implementing a standard 2FA approach. Note that based on the discussion at Weekly meeting #25 the OTP will be checked before the password. Hence this server can also function as a filter for requests. The server checks the OTP and checks with a filter if the supposed user is allowed to try to log in. If so, it informs the REST servers of this. This is done through a special REST call to each of these server through a mutual authenticated TLS connection based on mutually pinned certificates

Mobile app in Java

This will be based on the client code from PESTO that will get integrated into the Alphawallet app. We make a library jar (or make available through Maven) that can be called from the app, which contain the relevant code from PESTO.

However this also contains some additional features. Concretely features to actually share and retrieve the user’s private Ethereum key. This is done through HTTPS messages sent to the servers after authentication using the the users private (PESTO) key. We assume the 2FA authentication with Alphawallet takes place outside the library.

REST server app

This will be based on PESTO and thus written in Java. Concretely it will require several modifications and additional components.

  • A database module storing a simple map of userID to data. The plan is to use a simple lite database that will be stored locally on each server instance.

  • Load balancer. The PESTO implementation is minimal and does not contain any kind of filtering of requests (which is strictly needed to filter online password brute force attempts). The 2FA server will do most of per user filtering and ELB will be able to do the rest of the filtering (i.e. based on IP).

  • PESTO unfortunately does not currently support the threshold setting, but only the setting where all parties must be involved. The code must be changed to support the threshold setting. Concretely this means that the blinding values used in requests and the servers key shares must be removed (as they are shared multiplicatively, which we cannot do in the threshold setting, which will cost adaptive security). Furthermore other sharings must now be Sharmir based instead of additive. We will update the implementation to support this and hardcode it to the 2-out-of-3 setting (to make the change much simpler).

  • An interface for a mutually authenticated connection to Alphawallet must be made to make the internal filtering of requests.

  • Code must also be made to accept the Sharmir secret shares. Basically this is done by sending signed shares of the Shamir secrets over TLS after authentication (we assume TLS is secure enough for sending the shares without extra encryption). We will handle this by making an extra REST method that accepts such shares signed under the user’s private key (the private key that is part of the threshold password authentication).

  • Dead code should be removed. This involves non-core code, pABC, identity proving, refreshing (since we can’t use the refreshing scheme in the threshold setting).

  • Since PESTO is still being implemented we need to be able to receive updates from the master implementation so this project will be a specific branch on the PESTO repo s.t. it can easily be rebased with the master later to receive relevant updates.

Of these tasks Tore will do everything related to PESTO/REST server implementation and creation of client jar. Another developer should then take care of the 2FA server, Android app integration and final deployment.

Phase 2

We must augment the implementation with support for refreshing the Shamir Secret key shares along with the servers own private key shares. We will do so using an interactive protocol where every server will construct a 2-out-of-3 secret sharing of 0 and ask all other servers to add this to their shares. This will have to be done for every shared key (i.e. we cannot reuse randomness).

Furhtermore, in order to protect against a corrupt server using this to destroy the shares (by sending an incorrect value) we must do a ZK proof that the shares are correct and share 0.

It seems the easiest way to do so is to commit to all shares towards all parties using Pedersen commitments. The parties can then verify their own commitments and it is possible to prove that the sum of the commitments commit to the 0 value. This should sufficiently convince people.

However, we need to be a bit careful with this and should probably use a concrete proactive secret sharing scheme. I will look into this furhter once it becomes relevant.

My feedback:


Regarding email code, αWallet need a way to tell the parties that αWallet knows if the user owns a certain email address. This can be done by email address attestation that is needed in multiple other occasions, for example, allowing users to send ether by email without knowing the beneficiary's Ethereum address.

We might choose to implement OTP-only at first, and when that email attestation is made available, make it reusable for this case. This project will take a few months to implement so it's possible to build email address attestation capability in the meanwhile, and the mobile key management code can simply take advantage of that availability.

Having email address attestation is not mandatory - since αWallet can simply inform the parties that we know the email address is correct, through TLS, but we like the idea of giving the users a reusable email address attestation for other scenarios, and we love to keep αWallet OTP gateway slim and easy-to-secure, letting some other code to deal with email attestation.


  • Sangalli and I would need to test ELB's capacity as a security measurement. Since it is made for load balancing, it might not have the finesse needed for a security policy editor.