Welcome back to the third part of our blog series on Ledger Recover’s genesis! Our goal is to explore the many technical hurdles encountered when building a seed recovery service, and how Ledger Recover, provided by Coincover solves them with a secure design and infrastructure.

In the previous parts, we explained how the entropy of a Secret Recovery Phrase can be split in multiple shares (or fragments), and sent to trusted backup providers, while always maintaining the highest level of security. Thanks to modern cryptography tools and secure hardware, we are able to perform a full backup of a seed, with the guarantee that no attacker can get hold of any of the shares during transit.

We will now move on to the next logical step, physically backing up the shares. Providing secure storage is key and raises crucial questions that we need to address: How do we ensure the shares are stored safely and can’t be stolen? How can we prevent collusion between backup providers to reconstruct your seed?

To ensure the safety of share storage, one possible approach is to have each provider store their individual share in a secure location, such as a safe. Alternatively, you might opt to store it in a – different – bank safe yourself. This arrangement allows providers to focus solely on safeguarding their respective keys, making it easier to control access and reducing the risk of leaks from family and friends.

Protecting ourselves against potential collusion poses more challenges. You might consider creating multiple shares distributed among different categories of friends or storage providers. You may also bind them with contracts. While these solutions are viable, they still require a certain level of trust.

An alternative solution is to encrypt the shares before they are sent to your friends. That way, even if they collude, they won’t be able to use the shares to rebuild your seed. But here is the catch-22 of the physical space: To encrypt the shares, you need a new personal secret key. You’re essentially backing up a secret, your seed, by introducing another secret that you must protect and remember.

We could argue that this new secret is less critical than the original one since it is only used to protect you from collusion between your friends. An attacker getting access to this new key would not be able to directly steal your funds, but if you were to lose it you would also lose access to your seed.

In Ledger Recover, provided by Coincover, we use the properties of the secure hardware at our disposal to answer those questions in the most user-friendly way possible. We rely on the Secure Element (SE) contained in your Ledger hardware wallet, as well as Hardware Security Modules (HSM) used by each of the backup providers.

A Secure Element is a specialized chip commonly used in passports, credit cards, and payment systems to securely store and process sensitive data. SEs are specifically engineered to withstand a wide range of attacks such as physical tampering, side-channel, fault-injection, software exploitation or malwares. These chips are certified by third-party security labs through intensive testing regarding those attacks.

Your Ledger Nano relies on this proven and trusted technology to store and protect your seed. The Ledger OS running on this SE will always prompt for your physical consent before using the seed.

Hardware Security Module (HSM) is a security enclave typically available as a plug-in card or external device directly attached to a computer or network server. It leverages cryptographic processors, secure memories, and various anti-tampering countermeasures to securely store and process secrets. These modules safeguard critical infrastructures and are employed by highly security-conscious organizations, including the banking industry, to secure their secret keys and infrastructure.

Ledger utilizes multiple HSMs for various use cases, including verifying the authenticity of Ledger Nano and Ledger Stax devices, and enabling secure OS updates over an encrypted and authenticated channel.

Both SEs and HSMs play critical roles in enhancing data security in diverse applications. They help organizations meet regulatory requirements for data privacy and security and secure manipulation of critical data.

The first layer of protection comes from the Secure Element (SE) itself. Prior to splitting the entropy into three shares, the SE encrypts it using an AES 256 symmetric key stored in its Operating System (referred to as the ‘Entropy Encryption Key’). After encryption, the entropy is divided into three shares that are then distributed to backup providers. Of course, you have control over this process, and the SE will always request your explicit consent before initiating it, just like for any other application requesting access to the seed.

Even in the event of collusion among backup providers attempting to reconstruct the seed (a scenario made nearly impossible by other robust protections we’ll discuss later), their efforts would only result in obtaining the encrypted seed. Without the encryption key stored in the Secure Element (SE), they would be unable to utilize the seed.

A key point to understand: this Entropy Encryption Key is common to all Ledger Devices, so that you can restore your seed on any legitimate Ledger Device. It is injected into the Operating System during an OS update, itself a very secure operation.

By incorporating the Entropy Encryption Key directly into the device, we eliminate the need for users to remember or store an additional encryption key to safeguard against collusion risks (the catch 22 mentioned above). This approach ensures enhanced security without requiring additional trust in Ledger, as it aligns with the existing level of security provided through OS updates.

Given its level of criticality, the Entropy Encryption Key is exclusively utilized by the device’s Operating System during authentic Ledger Recover restore and backup processes. This process involves the establishment of authenticated secure channels with multiple HSMs from different companies (each backup provider). Additionally, various other infrastructure components, such as suspicious activity detection (e.g., restoring multiple seeds on the same device) and identity verification, are managed by separate teams, which drastically increases the number of people that are required to perform a successful collusion attack. We will dig deeper into the governance and monitoring we have put in place in the 5th part of this series!

Similarly, at Ledger, no single person possesses the authority to deliver new OS upgrades for the device. The process is cryptographically enforced to always require the digital signature from a quorum of several individuals from different teams, each with different interests within the company.

This practice, known as separation of duty, is another crucial cybersecurity measure that we will delve into more deeply in the operational security section.

Now on the side of the backup providers, we have a somewhat equivalent setup.

Each backup provider uses a Hardware Security Module to manipulate their share of the seed. When their HSM receives the share from the device securely (doubly encrypted by the Entropy Encryption Key and the secure channel ephemeral key described in the previous blog post), Secure Channel encryption is lifted  and share consistency is verified directly within the HSM.

Due to limited memory capacity, HSMs cannot store a large number of shares. Therefore, for storage purposes, each share is re-encrypted using an AES 256 symmetric encryption key, known as the ‘Provider Storage Key’. This additional layer of encryption allows the shares to be securely stored outside the bounds of the HSM in an RDMS. In other words, the shares never appear outside of a secure enclave without a double encryption scheme.
The Provider Storage Key is generated inside the HSM by each provider, and never leaves it unwrapped. It is never accessible by anyone, including employees of the backup providers themselves. This is standard cybersecurity practice from companies that handle high secret, highly sensitive data.

The shares also never leave the confines of the HSM in clear, and are always encrypted either in transit or at rest.

Once again, a robust separation of duties is enforced for individuals who have the ability to manipulate and access the HSMs. Different responsibilities, such as updating the code, physical access to the HSM, accessing the database, and installing software on the HSM’s physical host, are assigned to distinct individuals with limited access rights. Furthermore, any software running on the HSM must undergo digital signing by a quorum of multiple individuals from different teams and with diverse interests within the company.

All of this makes it extremely hard – almost impossible – for a single person in any of the involved companies to have access to the shares.

Okay, we’re getting closer to a complete solution to securely store our shares!

But what if several insiders within backup providers collectively desired to retrieve an individual’s entropy, orchestrating an effective large collusion among teams and quorum members from each company?

Is it possible to introduce technical measures that make it extremely challenging, if not infeasible, to achieve? Can we implement safeguards that provide enough time for any insider within any of the companies to raise the alarm to all users before anything happens?

One solution is to use what is known as “Database diversification”. Once again, we harness the capabilities of our HSMs to implement it.

If you have been following this blog post from the beginning, you now understand that the processing of shares is exclusively managed within the secure confines of HSMs, but that the actual storage of those encrypted shares takes place in a separate backend database outside the HSM.

Here’s what we will do: let the HSM generate unique database IDs for each share, serving as their specific identifiers within the backend database. These IDs will be generated in a ‘diversified’ manner, derived from a secret created by the HSM itself, securely stored within its own secure memory, and never exposed unwrapped. The backend therefore only serves as an external storage, unable to read its database content or decide on the identifiers of its own database entries.

What does this mean? The share identifiers will be distinct across different backup providers, including Ledger, Coincover, and EscrowTech. Additionally, as user data also remains encrypted and diversified, even if collusion were to occur between two providers it would not provide any clues regarding which database entry corresponds to which user or to which entry in the other provider’s database.

The only possible approach would be to brute force all possible combinations of shares across all databases from all involved backup providers. This process is highly time-consuming, requiring a full recovery flow that involves utilizing the full infrastructure of HSMs and a legitimate Ledger device for decrypting each combination with manual approval by PIN code. As intended, this approach demands substantial time and effort.

The non-diversified user identifier is of course present within the component responsible for orchestrating the recovery flow (only present on Ledger side). This is precisely why, as mentioned earlier, a strict separation of duties is enforced between the teams and individuals who manage the Orchestration component and those who oversee the Backup Provider HSMs and databases.

After splitting and securely sharing Secret Recovery Phrases, we have now devised a solution that ensures the secure storage of the different shares. It relies on hardware devices, cryptographic constructs, and operational separations that are all essential to build a secure product. We are now protected from risks at the source and destination endpoints, but also during transit and storage. We have also reduced collusion risks from individuals within each company, or within companies themselves, as close to zero as possible.

At this point, you may be wondering about the last missing part: Releasing the shares encrypted by each backup provider. This process must be heavily protected, so how do we make sure that the actual owner of the seed is the one initiating the request for share release?

It is now time to introduce the Identity Verification (or IDV) process, which is the final piece of the puzzle. When a backup provider is asked to release its share of a seed, it expects to receive an authorisation from an IDV provider which is proof that the request has been initiated by the real owner of the seed.

By having a different IDV provider for each Backup provider, we add an extra layer of protection against collusion.

Implementing IDVs for multiple backup providers can be quite complex, which is why we will dedicate our next blog post to explaining it in detail. Tag along if you want to know more!

Pierre AOUN / Yacine BADISS

Similar to Notcoin - Blum - Airdrops In 2024

origin »

97 +