Custody at Conio — part 2

This is the 2nd out of 3 articles describing the cryptocurrency custody solutions developed at Conio

In the previous article, we have seen how Conio adopts a “2-of-3” multi-signature approach. That is, any 2 out of 3 private keys are needed in order to transfer or recover funds.

Actually, though, the overall Conio custody architecture goes even deeper, and can further safeguard private key #3 (i.e., the key stored in the third-party entity).

As a result, Conio runs a multi-layered solution that incorporates some of the best lessons from prior ideas. We will see later in this article how Conio leverages the advantages provided by what we call the “Stone Age” (storing data in secure offline locations) and by the “Iron Age” (using special physical hardware). All works in concert with an overarching software layer.

Protecting a secret from external — and internal — threats

Let’s for now focus on private key #3: that is, the one stored by the third-party entity.

Securing such private key #3 is quite an important matter for a number of reasons.

Theft

More often than not, attacks to a system come from internal rogue employees rather than external hackers. Without a proper solution, an employee (e.g. DevOps manager) may have access private key #3. In theory, this is not an issue per se: such a person would have access to 1 key out of 3, so s/he would not be able to transfer funds. In practice, however, this would definitely be an overall lapse in security that absolutely must be avoided.

Loss

Losing private key #3 would be quite an inconvenient occurrence. The overall system would still work, since two keys (private key #1 and private key #2) out of 3 would still be available; however, it would not be resilient to any additional key loss.

Therefore, how the private key #3 is stored is quite important. The first thing that comes into mind is to save it in some storage. Though, no hardware has unlimited lifespan, and since here money/assets are involved, this is absolutely not acceptable: people expect no issue at the very least during their own lifetime.

Therefore, any solution must be able to reliably store the private key for 100+ years. This can be achieved through a proper redundant storage solution.

Some initial approaches

In order to prevent someone else from transacting using the private key, or to prevent the loss of the private key itself, a number of approaches have been suggested to safeguard the private key.

For example:

• divide the private key into multiple parts
• make multiple copies of each part of the private key
• store the multiple parts in different secure places.

Such approaches are limited because:

• they are manual
• require a “ceremony” with physical presence of several operators in the same place
• the loss of a part of the private key may still result in the total loss of the private key

Thus, there is a need for new approaches to safeguard the private key.

The Conio approach

The Conio solution is a combination of HSM (Hardware Security Module) devices running specialized software. Conio has chosen the USB armory Mk II from F-Secure as HSM; however, the solution is agnostic to the underlying hardware and any HSM can be used.

One of Conio HSMs

The goal is to safely create, store and use (for recovery purposes) private key #3 within the third-party entity.

The solution consists in few phases:

• Setup
• Reconstruction
• Recovery

Setup Phase (first step) — Private/Public key generation

The first step of the setup phase allows the creation of a private key in a safe way, without anyone actually knowing what the private key actually is.

The third-party entity decides to use a number M of HSM devices. Each one of the HSM generates a digital secret. The HSMs then:

• securely communicate with mutual authentication and encryption
• randomly choose one of the M devices as master device
• a private key is temporarily generated on such master device by taking as inputs the M initial digital secrets
• the public key corresponding to the private key is also generated

Unlike other solutions, this procedure allows operators (and their HSMs) to be in remote areas. There is no need for everyone to be on premise in a special location.

Setup Phase (second step) — Private/Public key storage

The second step of the setup phase stores the private key in a secure and reliable way.

• The master device divides the private key into M parts (“shares”), and sets rules for being able to recover it later
• Each one of the M HSMs receives and stores one of the M shares in which the private key has been divided

Regarding the way shares are created:

• The well-known Shamir’s Secret Sharing (SSS) is the cryptography algorithm chosen for such purpose
• One rule must be chosen. That is, the threshold number K (with K <= M) of the M HSM devices that will be needed to recover the private key through SSS

Reconstruction Phase

This phase allows the reconstruction of the private key. In the previous article, we have seen this corresponds to private key #3, and it is needed to later recover the funds of the user in case of emergency.

Here K HSM devices (with K <= M) must be used.

The K HSM devices:

• securely communicate with mutual authentication and encryption
• randomly choose one of them as the master device for the sake of the reconstruction operation
• send their share of the private key to the master device

The master device at this point:

• using the SSS algorithm, reconstructs the private key

An example where 3 shares (K == 3) out of M are involved

Recovery Phase

This phase finally allows the user funds recovery. Again, this is well explained by reading the previous article: there, we have seen that the overarching system is based on a “2-of-3” signature scheme. If the user loses access to his/her private key #1, then s/he must rely on a transaction signed by private key #2 and private key #3.

In this phase, private key #3 (just now reconstructed) is used to sign the recovery transaction.

Here K HSM devices (with K <= M) must be used.

• as per previous phase, the private key must first be temporarily reconstructed on a random master device
• the master device signs an input message with the private key
• finally, the master device shares the content of the signed message.

Since the corresponding public key is known to the outside world, any external observer can verify that the message has been correctly signed.

Another example where 4 shares (K == 4) out of M are involved

The Operators view

So far we have provided a high-level overview of how the underlying infrastructure set in the third-party entity is eventually able to recover user funds. It’s a platform-view of the procedures, devices and data that work in the process.

Now, we’ll show what the third-party entity operator actually sees on his/her screen, in order to proceed with the recovery process.

Recovery Selection

As mentioned in the previous article, recovery operations are streamlined in batches. In the example shown in the figure above, data has been already signed by Conio (with private keys #2) and provided to the third-party entity.

Now, after authentication, the third-party entity operators can recover funds for users George Washington, Benjamin Franklin and Alexander Hamilton.

HSM use

In order to participate to the recovery authorization process, the third-party entity operator must use his/her HSM.

Authorization

In the example shown in the figure above, we see that the third-party entity has enforced the use of at least 2 SSS shares out of 5. That is, out of a total of 5, any 2 operators (and their associated HSM) must be available at any given time in order for the recovery process to succeed.

Completion

After the required amount of operators has participated in the process, the recovery transaction is finally created. It can now be given to Conio and be broadcast to the network.

Conclusions

In this article and the previous one, we have gone through the multiple layers of the Conio custody solutions. From a logical standpoint, a “2-of-3” solution, with one key offline and further decomposed in multiple cold storage shares.

Multiple parties are involved in this scheme:

• User
• Conio
• Third-party entity and its operators

This allows a safe creation, custody, recovery, and management of a digital asset like a cryptocurrency.

As also said in the previous article, this solution is not geared to cryptocurrency experts, who can (and should) manage cryptocurrencies themselves. This solution is to serve non-technical people who want to have exposure to this new world, with no worries about loss, theft, or (unfortunate) situations such as inheritance.