Social Key Recovery Hackathon

If you are using cryptocurrencies or care about securing passphrases, you probably thought about data recovery at some point, such as mnemonic phrases or hard drive backups. However, there is another method for backing up important keys or passphrases that provides several upsides for the user and can even be initiated with minimal user interaction. In the following, we will introduce this method called Social Key Recovery.

by Simon Schmoll

What is Social Key Recovery?

Social Key Recovery is not only useful for those adept with cryptocurrencies. It also provides a way for backing up passphrases, secrets and even documents. So what exactly is Social Key Recovery and how does it work?

Definition:

Social key recovery describes the process of backing up keys (or data) in the context of one’s social cycle which usually consists of family and friends. Therefore, a key or passphrasecan be split up with the Shamir Secret Sharing Schema (SSSS) (see next section). The key pieces (also called shards) which are the result from the SSSS can then be distributed to the close circle of family/friends. In case the user loses his key, he can now restore it with the previously distributed shards.

It is always better to illustrate such a definition with a fictional example and don’t worry about some terminologies, those will be explained in the subsequent sections:

Let’s assume Alice has a secret which secures something of value (cryptocurrencies would be a good use case here). She worries about losing this secret and as a consequence, losing access to her assets. Now she might be inclined to back up her secret with people she trusts. Hence, she uses an app for Social Key Recovery which splits her secret into five parts and distributes those to people she is close to. Furthermore, she specifies that three of the five parts are necessary to recompute her secret. One day Alice loses her phone and with it her secret. At this point, she can contact three of the five people who earlier received a part of her secret. With the help of these people, she can restore her secret. Thus Alice regains access to her assets and everyone is happy 🙂

Of course, this is a simplified version of the underlying functionalities and now you might say: “Hold on you want to tell me that my password can be restored by my friends, so they could collude to steal all my cryptocurrencies or sensitive passwords?” Glad you asked because this non-negligible possibility is a real threat and therefore it is necessary to discuss several security-related issues and attack vectors in a subsequent section.

Shamir Secret Sharing Scheme

I mentioned the SSSS algorithm in the previous section and now it’s time to explain the functionality on a high level. For further explanations such as the difference between using finite field and integer arithmetic click here.

The algorithm takes a key k and splits it into several shards. However, the amount of shards is flexible. E.g., we could split the key into two or more shards. Next, we need to define a threshold value for recovering the initial key. This threshold value needs to be smaller than the total amount of pieces.

To illustrate the functionality, we can again use a fictitious example: A company that digitally signs documents with a single master key. However, due to security concerns, the key is only on a single computer. Thus, the SSSS makes it convenient for the company to back up the key without introducing a single point of failure. As such, the key is split and each executive receives one piece of the key. The company has 10 executives and its policy requires 7 executives to successfully restore the key. Conclusively, the key is split into 10 pieces and the threshold value is 7. In case of a hardware failure of the computer with the master key, 7 out of 10 executives could restore the key. Furthermore, the order of the keys does not matter as every combination of 7 out of 10 keys would suffice to restore the master key.

SSSS provides a flexible algorithm for choosing the total number of shards and the threshold value, as such it can provide unique security properties for situations with different security demands.

Security considerations

As mentioned before, the SSSS introduces a powerful mechanism to restore keys without introducing a single point of failure. During our hackathon, we discussed the security properties of the scheme under different threat models. The security properties can be adapted to the risk model of each user, as some scenarios demand a higher security assumption than other scenarios.

For this, I want to recall our initial example of Alice. But now we get more specific: Alice holds one Bitcoin and wants to use the social recovery app to back up her private key. In this context, it is enough to understand that the private key is like a password that enables anyone to spend this one Bitcoin. Her friends Bob, Carol and Dan are already using the app. After installing the app, she splits the key and selects her friends to share the pieces of her key. As a result, she splits the key into three pieces and sets the threshold value to two. Meaning that any two of her friends can recover her private key. Now let’s examine the security properties of this setup. We assume that Alice’s friends are technically knowledgeable and capable of extracting the shard from their internal phone storage, as the shards should not be directly accessible in the app. Then it would suffice for two friends to collude and thus steal the Bitcoin of Alice because they are capable of reconstructing the private key from the shards. This security setup might not be sufficient to hold large monetary value as the communication necessary to reconstruct the key is minimal. Meaning, e.g., Bob and Carol can secretly collude without the knowledge of Alice. However, we can improve the security properties, if we increase the number of pieces and the threshold value. As such we might distribute a total of 5 pieces to 5 members of Alice’s family/friends and require 3 of them to reconstruct the private key. Many potential scenarios could be adapted to different security requirements. If I only hold little value in my cryptocurrency wallet (an application that manages cryptocurrencies and hides the technical complexities of spending and receiving them), I might be comfortable with the initial setup and if I lose my wallet I can easily restore my private key with only two friends. However, maybe I demand higher security standards and as such, I can distribute pieces to more people with a higher threshold value.

Another important consideration might be that the initial private key can be encrypted before splitting it up. In this case, an adversary would not only need to collect enough pieces, but it is also necessary to gain knowledge about the password that decrypts the private key. Contrary to the initial consideration this setup could introduce a single point of failure, as the password requires a backup through the user. If she forgets to create or loses the password, she will be unable to recover her key. Nonetheless, if a complex password or a long private key needs to be backed up, then remembering or writing down a short password to encrypt it might be a more comfortable solution in comparison to remembering the initial secret.

Prototype

During the two-day hackathon, we explored the possibilities of a cross-platform mobile app prototype that provides basic functionalities necessary for distributing key shares with other devices. The main objective was to get familiar with the frameworks (NativeScript, Angular and Typescript) and to implement an initial prototype that can distribute arbitrary data from one device to another.

Before explaining the prototype we need to define some terminology:

• Buddy: Someone with whom I want to share a shard. This can be anyone with a phone number. E.g., family or friends
• Secret: The secret is a broader terminology for a key, as a secret could be a private key for a cryptocurrency wallet, a passphrase for other applications, etc

The following features were implemented during the two-day hackathon:

• Add buddies: With phone number, name and internal code (which is used to establish a WebSocket connection between two devices)
• Add secrets: Which can be sent to buddies
• Share secret: The user can select a buddy with whom to share the secret through a WebSocket connection (the socket is identified through the shared code). The whole secret is shared, as SSSS is currently not implemented.
• Notifications: Each user (key owner and buddy) is notified when the share is successfully transferred through the WebSocket.

The workflow can be illustrated through the following gif:

The demo shows two iPhones, the left iPhone wants to share its secret with the right iPhone. The following workflow is necessary to achieve this:

1. Add Secret (left iPhone) – Has already been done before the demo!
2. Add Buddy on both iPhones to establish a WebSocket connection.
3. The “code” field is used to connect both devices.
4. Left iPhone shares secret with right iPhone.

(A notification is displayed on both iPhones)

The hackathon provided an initial exploration into the possibilities of Social Key Recovery. Further, we gained insight into the technologies that might support a Social Key Recovery app. However, for a working MVP, several features need to be discussed and implemented. Such as secure communication, usage of a SSSS library, recovery functionality and many more. We are excited to explore this field of secret sharing and are convinced that this project benefits the end-user through enhancing security and privacy.

Sources:

Shamir, A. (1979). How to share a secret. Communications of the ACM, 22(11), 612-61 https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing