HAQQ Social Login

Introduction

In my previous article, a vast number of Web3 users face challenges related to the loss of their private keys/mnemonic phrases. For the widespread adoption of Web 3, a secure and user-friendly solution is essential. However, when it comes to security secrets, any lasting solution must be one that strictly avoids custodial practices.

”Not Your Keys, Not Your Coins”

In the quest for a secure solution for storing secrets, such as private keys/mnemonic phrases, at HAQQ, we explored various options and settled on developing a solution based on Shamir’s Secret Sharing (SSS). In essence, the solution works by breaking down the secret into M parts in a way that it can only be reconstructed by having N or more parts. In continuation, let’s discuss how and where to store the parts of the secret such that only the user can reconstruct the secret.

General Description

For HAQQ Social Login, we chose a Shamir’s Secret Sharing (SSS) scheme with the user’s secret divided into 3 parts. To recover the key, it is compulsory to collect any 2 parts. The user always controls 2 parts of the key and instantly restores it, while the 3rd part is stored on the blockchain in an encrypted form for the convenient recovery in case of phone loss. At this point, it is important to note that having any single part of the secret in hand does not allow for the recovery of the original secret.

As I mentioned earlier, by the term “secret,” we refer to the primary mnemonic phrase of the user in the HAQQ Wallet, represented in code. The primary mnemonic is the initial one added — it could have been imported from another wallet like Metamask or TrustWallet or generated when creating a new wallet. All subsequent accounts are added as “Imported” and are not saved in HAQQ Social Login.

The secret splitting into parts occurs within the HAQQ Wallet mobile application, and the secret in its original form never leaves the mobile application. HAQQ never copies, saves, or transmits users’ secrets (mnemonic phrases, codes, private keys). Secrets never leave the user’s device at any time.

HAQQ Wallet splits the secret into 3 parts as follows:

• Share A — Social Share — Stored in the HAQQ Blockchain, but not in its original form. It is encrypted and divided into sub-parts, which will be discussed in more detail below.
• Share B — Local Device Share — Saved locally on the user’s device, in a special Key Storage.
• Share C — User Cloud Share — Saved in the user’s personal cloud storage. As of the time of writing this article, HAQQ Wallet supports Apple iCloud or Google Drive.

As I mentioned earlier, to recover the secret, the user needs to have access to any 2 shares out of the 3. For example, access to the social login share and the cloud share, or access to the local share and the cloud share. With this chosen division, the user always controls 2 parts of the secret necessary for recovery, while externally storing 1 social share in a split form. This share is saved on the blockchain in an encrypted format.

In this storage setup, the only scenario for losing access to the wallet is to simultaneously lose both the phone and access to either the social login or the cloud storage. Losing the phone and access to both the cloud storage and social identifier simultaneously is an extremely unlikely scenario. However, since it cannot be completely ruled out, we recommend saving mnemonics as a backup storage mechanism, not as the primary one.

Share A — Social Share

Login

Let’s delve into a key aspect of HAQQ Social Login, namely Share A — the Social Share. The general algorithm looks as follows: a user logs into a social login provider, which could be Apple, Google, Twitter, or any other provider, and receives an identifier. The HAQQ wallet then splits the social share, which is already a share of the secret, using the Shamir’s Secret Sharing (SSS) algorithm into 5 parts, requiring 3 out of 5 parts for recovery. Each share is stored on the blockchain in an encrypted form with the identifier represented as a hash of the previously obtained social identifier.

At the time of writing, only 2 Apple and Google providers are supported — let’s discuss which other providers should be added?

When a user restores access to the wallet, they log in again to the social login provider and, using the obtained identifier, retrieve the parts of the social share from the blockchain. They then reconstruct and recover these parts, subsequently restoring the private key.

Secret saving process

The mobile wallet receives the social login and takes its hash, which will subsequently serve as the identifier. With this hash, it goes to the Smart Contract Relayer List and retrieves a list of 5 randomly selected active relayers. This list is then saved, and in subsequent interactions, the same relayers will be returned unless the user requests new ones.

After obtaining the list of relayers, the mobile wallet, using the Shamir’s Secret Sharing (SSS) algorithm, splits Share A into 5 parts (requiring 3 parts for recovery) and transmits each sub-part to a separate relayer along with the identifier.

The relayer, upon receiving the sub-share, encrypts it with its unique key and stores it in a special smart contract on the blockchain. This means that the sub-share is stored in the most secure location — on the blockchain in an encrypted form. Each Relayer has its own independent smart contracts, ensuring their autonomy.

In subsequent interactions, the user can approach a relayer and retrieve their sub-share in decrypted form using the identifier. This process allows the user to reconstruct Share A when needed.

Secret recovery process

1. The user logs into the social login provider and obtains an identifier by taking its hash.
2. The wallet gains access to Share C in the cloud storage.
3. The wallet queries the Smart Contract Relayer List using the social identifier, receiving a list of relayers where parts of the social share are stored.
4. By making requests to all relayers, the wallet gathers 5 sub-shares and reconstructs Share A. For recovery, it is sufficient for 3 out of 5 relayers to be operational.
5. With Share A and Share C in hand, the wallet restores the secret and overwrites the shares, preserving Share B in the local Key Storage of the phone. After overwriting, the old Share B remains on the old phone, but it is now better suited to the new overwritten Share A and Share C.

This process ensures a secure and distributed recovery of the secret, requiring a combination of access to the social login, cloud storage, and relayers to reconstruct the shares.

Blockchain level - Smart Contract

Relayer List

The primary function of a smart contract is to retrieve a list of Relayers that a mobile application can communicate with to interact with the network. Upon the initial request, if the hash derived from SocialID and Verifier has not been previously registered in the smart contract, the smart contract will create a new record. This involves generating an internal identifier, selecting any 5 nodes from the available node list (initially chosen randomly), and then returning to the mobile application a hash representing the internal identifier. Additionally, an array of node addresses with corresponding ball numbers (indexes) will be provided, indicating where the mobile app should store the associated data.

Verifier List

The core function of a smart contract is to store all possible combinations of JWT fields (jwt, is, and, subject, array [verifier_key, verifier_value]) for verification when received in a KeyNode. When adding a Verifier, the smart contract ensures uniqueness by checking for duplicate “aud” records. The implementation of the ability to add and remove Verifiers from users, thereby transferring control to external entities (Relayers), will be addressed in a subsequent stage.

Key Value Storage

This contract, which can be updated either directly or through a proxy contract, serves the primary purpose of individually storing a bundle of IDs from JWT and an encrypted Share from Shore A for each KeyNode. Each Relayer is associated with its own Key Value Storage Smart Contract. Within this contract, the hash derived from the internal ID acts as the unique identifier, and the encrypted portion from the social part of the private key serves as the corresponding value. Importantly, each Relayer utilizes its unique encryption key for added security.

Security

This solution has been developed by HAQQ Network and has undergone an independent external security audit conducted by Halborn. You can review the audits at https://github.com/haqq-network/audits.

Written by VorobevSA. The original article is published here.

‍