Part 4: Genesis of Ledger Recover – Controlling Access to the Backup: Identity Verification

Part 5 of our Genesis of Ledger Recover blog series is available here.

Welcome back to the fourth part of our blog series on Ledger Recover 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), then sent to trusted Backup Providers, and finally stored safely while always maintaining the highest level of security.

In more details, Genesis of Ledger Recover Part 1 – “Self-custody without compromise,” delves into how we carefully considered all potential challenges when building Ledger Recover, provided by Coincover, to make this feature a great and secure solution to back up your Secret Recovery Phrase.

Genesis of Ledger Recover Part 2 – “Securely distributing the shares,” introduces several cryptographic tools and mathematical concepts that Ledger Recover leverages to securely distribute your seed shares to backup providers.

Genesis of Ledger Recover Part 3 – “Avoiding collusions and leaks,” tackles how we ensure that the shares are stored safely, and how we prevent backup providers from colluding to reconstruct your Secret Recovery Phrase.

The next question you may have now is: how can Ledger Recover protect the entropy of a Secret Recovery Phrase without just introducing yet another additional mechanism secret-based such as a password, a two-factor authentication or similar? Especially in a situation where you might have lost access to all means of digital authentication (like your email, various hardware wallets and authenticators, etc…).

The key to granting Ledger Recover users complete control over unlocking their secrets lies in leveraging their identity, which is the core essence of ownership.

In this section, we will delve into Identity Verification mechanisms which provide access to your backup by yourself and only you. Let’s start with some definitions. 

A primer on Identity Verification 

Identity Verification is the process of confirming the accuracy and legitimacy of an individual’s claimed identity. It involves verifying personal information from trusted sources, namely official documents. The goal is to prevent fraudulent activities or unauthorized access to sensitive information by validating the accuracy of an individual’s claimed identity.

Note that from now on, we will use the IDV acronym for Identity Verification.

Wait ! What If someone stole my identity documents ? Would this person be able to pass the Identity Verification process ?

Ledger Recover is resilient to such scenarios as it does compare several sources of information over the process including: 

• Identity certified information: the data extracted from the official document using OCR¹ technologies
• Biometrics data²: live data extracted from a human and matched against the official documents records, in Ledger Recover case, your face
• Liveness check: checks to make sure a real human is behind the biometrics data and not spoofed
• Live interviews from different IDV service providers.

Going through the IDV process will require you to film a small video and follow instructions in order to allow the system to capture sufficient information to confirm that you are effectively the holder of the identity documents provided.

Master your Secret : Ledger Recover empowers you as Ultimate Key

At Ledger, we promote self-custody and individual autonomy, which is why Identity Verification (IDV) is a crucial component of Ledger Recover.

By utilizing IDV, Ledger Recover, provided by Coincover, ensures that you, as the account owner, have complete control over the recovery process, as opposed to relying on social recovery methods that require the involvement of others or multiple parties.

One of the key advantages of IDV is that it leverages your government-issued identification document, which is typically securely within your possession and readily accessible. This means that you can confidently authenticate your identity without having to rely on external entities or complicated procedures. It is also one of the only forms of authentication that can be restored after catastrophic events like losing everything (papers, digital accesses, etc…).

By integrating IDV into Ledger Recover self-custody framework, it empowers you to maintain full control over your assets and personal information. Its streamlined and secure verification process prioritizes your convenience, allowing you to confidently recover your account while adhering to the principles of self-custody and individual autonomy.

How does Ledger Recover use IDV service providers?

During the backup process, Ledger Recover captures your ID data through the IDV service provider identification process, has the user confirm it on his device and associates it to the shares of the entropy of your Secret Recovery Phrase. Then the only way to restore your private keys is to unlock your shares by proving your identity to two of the three backup providers through two independent IDV service providers.

Ledger Recover prioritizes the security and accuracy of IDV, which is why it employs independent IDV service providers, namely Coincover and Tessi, that are leveraging the Digital IDV technology from Onfido and Veridas respectively. 

Ledger Recover IDV service providers are renowned for their expertise and cutting-edge solutions in the IDV industry, making them ideal choices for a rigorous verification process. Onfido and Veridas both rely on technologies that passed Presentation Attack³ Detection (PAD) level 2 test conducted by iBeta Quality Assurance.  

By utilizing multiple IDV service providers, Ledger Recover ensures a robust and thorough verification process model, as each provider brings a unique perspective and set of algorithms to the table.

Multiple IDVs is the core mechanism with which Ledger Recover ensures a Restore request is coming from a legitimate user. But implementing this correctly introduces many questions and additional security considerations:

But what if the two IDV service providers do not reach a consensus ?
Is this process time resilient ? 
What if I change appearance between Backup and Restore ? 
How do I make sure I’m performing an IDV for the right device and seed?

Concretely how does all of this work within Ledger Recover ? Let’s look at some of the implementation details answering those questions.

Intrication of Identity Verification within Ledger Recover

As introduced in part 1 to 3 of this blog post series, Ledger Recover has strong cryptographic mechanisms to split, distribute, store, collect and re-assemble the shares of a seed on your device. Using IDV to authorize restoring a seed introduces two broad categories of challenges:

• Verify with certainty that you are the legitimate owner of the secret when the recovery comes
• Establishing a strong binding between your identity and your shares, throughout the lifecycle of the shares

Binding Identity, Shares and Devices

The main purpose of binding Identity and Shares is to ensure that shares are only released when a real human has proven his identity, ownership of the share, and has confirmed his consent on a trusted device. The goal is also to avoid an attacker (external or insiders) being able to intercept or modify any steps of the backup or restore processes, and re-route to their own devices.

To ensure this binding, Ledger Recover introduces a few mechanisms binding closely the identity being verified, to the shares and the device in use. 

Confirmation Data at the very beginning of Backup and Recovery Process

Let us take a moment to explain why your identity data is stored and how it is leveraged to ensure you are always in control of what’s happening over the process.

During the backup process, after having explicitly allowed the usage of the Ledger Recover service on your hardware device and passed the IDV steps, you are asked to confirm within your trusted display that the correct information has been effectively extracted from your official document thanks to OCR.  

If those are correct to you, you can confirm the backup process/restore and allow the backup/restore of your Seed encrypted shares. 

This confirmation on device allows some key security features for Ledger Recover:

• It captures your explicit consent on backing / restoring a share 
• It allows you to validate on a trusted hardware device the correct linking of your shares with your identity.
• It allows the system to bind your device with the current backup / restore sessions, so that no other device can be used instead. 

After this step each share is sent through a secure channel to each Backup Provider, and bound strongly with the identity data that has been confirmed. 

This is a direct application of common Ledger principles of clear signing all interactions and enabling “Don’t trust, Verify”.

Binding shares and IDV

As mentioned in part 3, each share is encrypted at rest by the Backup Provider using the identity, directly inside the HSM. This is done during the backup phase of the SRP.

To secure the restore phase and trust the identity used for releasing the share, all communications with IDV service providers are secured (encrypted and authenticated) and all messages received from IDV service providers are signed. This signature is controlled directly inside the HSM of each Backup Provider, before decrypting internally the share.

One Time Security Code

The last part to protect is the IDV process itself. An attacker with control over your display and that somehow steals your credentials could try and make you pass an IDV to restore your seed on their device.

Ledger Recover Restore process has therefore been made to be robust against Man-in-the-Middle attack scenarios, by creating a strong binding between the hardware device that initiates the recovery and the IDV process itself, using a One Time Security Code. 

More precisely, the One Time Security Code is a code derived from a shared secret between the Ledger Backup Provider HSM and your hardware device. The One Time Security Code is generated both on both the HSM side and on your hardware device, therefore this code can’t be intercepted as it never transits. This code is unique, it can only be used one time, it is tied to your session and your device, and it will change for every recovery attempt. 

Once this code is generated it will be shown only once on your device: write it down cautiously; it will be needed early in the identification process but never shown again. This code will be asked during a liveness check and verified. Any failure here will abort the recovery attempt.

Identity Verification

Ledger Recover relies on multiple independent sources to obtain a comprehensive and reliable evaluation of your identity and reliable evaluation of your identity and ensures an extremely high level of certainty on the user’s identity interacting with the system. Let’s look at the details of the IDV itself.

Backup Process

The IDV process during backup is made to be straightforward. The goal here is to ensure the real identity is associated with the right shares. The condition to open a backup session is to provide consistent data through the process: Selfie is consistent with your Identity document photo, and Your Identity Document is readable enough to extract information such as place of birth, date of birth, first name, last name and selfie photo.

Once your Identity has been proven to be consistent and processable, this data is then encrypted and stored securely for later comparison (during the recovery process basically) and the backup for your Secret Recovery Phrase is effectively created.

Recovery Process

The recovery process is much more complex as it does not only check the consistency of your identity but whether or not you are the legitimate owner of the shares.

First, as a central concept and mentioned in part 3 of this series our protocol relies on isolation of share release decisions. This implies that each Backup Provider has its dedicated IDV service to accept or deny a release request based on its own IDV process result. 

To recover your backup you’ll have to pass several tests including two IDVs. Each IDV is bound to a share of your entropy, which is independently released if identification is successful.

Identity Verification process with Coincover Backup provider

One share of your Secret Recovery Phrase’s entropy is trusted to Coincover as a Backup Provider. Coincover also provides part of the Identification Service in collaboration with Onfido. During this step you will have to provide a photo of your ID document and record a video with various instructions. 

Then the process goes through 3 distinct validations : 

• Biometric test : Comparison of selfie provided during the backup and video. This check is automatically validated.
• ID Information Consistency Check : Comparison of extracted information from the ID Document with the one provided during backup.
• ID Document and Video Consistency Check : Check the authenticity of the video and consistency with the ID document photo and selfie extracted from the video.

Those three steps go through automatic validation and if necessary, in case the processing output is below a satisfying threshold, it goes through manual verification. 

If and only if all these verifications are conclusive, the secured share is finally released for this Backup Provider. 

Identity Verification process with Ledger as Backup provider

Ledger as a Backup Provider relies on Tessi services to validate your identity when you request a restore of your entropy. On that second backup provider the IDV differs on some key aspects that need to be mentioned : 

• Each identification involves two manual verifications run by trained agents. Those trained agents will make sure your request is authentic and legitimate. 
• It introduces a strong mechanism to bind your device with your session, the One Time Security Code described in the previous section. Therefore it ensures that you are effectively running an IDV process specifically created for your device only. 

Manual Identification Verification

As mentioned, a notable aspect of this process is that it involves human-made verification of the provided data. Similar to the tests mentioned earlier for the Coincover backup provider, this verification is carried out separately by two distinct and unconnected agents.

If -and only if- all these verifications are conclusive, the secured share is finally released for this Backup Provider.

Consolidation of Decisions

Once you’ve run the two proposed IDVs, the system consolidates the outputs of the verification processes. Several scenarios are possible here :

1. You successfully passed the two verification processes: the recovery is accepted and the two shares are sent through a secure channel to your device.
2. You got a mixed or full rejection from the two IDVs and you decided to not ask for a manual investigation: your recovery is aborted.
3. You got a mixed or full rejection from the two IDVs and you decided to fill a claim to continue the recovery process: a Manual Investigation process starts (details below).

Manual Investigation Process

Manual Investigation process takes place whenever you are not able to successfully pass the IDV tests and you request a deeper assessment  of your request. At this stage there is a reinforced verification workflow that will allow you to securely access your secret. 

The manual investigation process is performed by Coincover. Its main objective is to precisely identify the reason why the IDV process has failed and collect any additional relevant and legitimate element that can rectify the initial issue.

This is achieved by performing a third IDV using another independent service provider IDNow which is followed by a video chat with an identification specialist trained to determine if the IDV is performed under any constraint.

During this video chat, you may be explicitly asked to confirm the reasons behind the ongoing identification process. Additionally, you may be asked to perform a series of randomized actions aimed at detecting any manipulation or presentation attacks, such as:  

• Holding your ID document to be captured by the camera while placing a finger on a security-relevant parts of the ID; this location is variable and randomly determined; 
• Answering randomly generated questions;
• Performing unusual movements.

What if the third IDV still fails for a legitimate reason?

Once the cause behind the unsuccessful IDVs is identified, a Coincover investigator will contact you to collect all the necessary documents to support your claim. If relevant, this investigation process might involve a legal officer to: 

• Physically meet you to corroborate your identity and claim; and/or
• Certify the official documents provided to support your claim.

IDV Data & Privacy regulations

Your IDV data is collected and processed through Ledger Recover in compliance with privacy regulations, in particular the European General Data Protection Regulation. 

Ledger only collects what is strictly necessary to verify your identity, i.e. data extracted from your identity document (name, last name, date and place of birth), a selfie (extracted from the video capture) and, upon recovery request, a photo of your identity document. 

In accordance with our data retention policy, your IDV data is securely retained until you unsubscribe from the service and then archived in a database with strict limited access for litigation purposes only. 

Security plays a crucial role in safeguarding your privacy, and we are fully committed to handling your data with extra care. To that end, we have implemented all the necessary technical and organizational measures to safeguard and secure the IDV information we hold about you. Therefore, your identity data is never stored in plain text within our system. During transit, it is processed in a secure and isolated infrastructure zone with access control and constant monitoring. 

To learn more about how Ledger manages your data and your rights, check out our Privacy Policy. For more information on Coincover’s data protection practices, please refer to Coincover’s privacy policy.

Not Quite The End: The Almost Conclusion 

Here we are at the end of the implementation part of our Blog Series. In this part, we’ve seen how Ledger Recover leverages your identity as the ultimate key to unlock your backup. We’ve seen how IDV is used in Ledger Recover, fine-tuned compared to existing providers and we’ve also touched some countermeasures used to secure the IDV itself, making sure no attackers, external or insiders, can implement man in the middle attacks on the verification.

Thank you and congratulations for reading all the way up to this lengthy part! You should now have a detailed picture of the security and implementation details of Ledger Recover, understanding how self-custody was made to go along with convenience and security. We believe we’ve designed a solution that will help Ledger Recover users better manage their Secret Recovery Phrases without compromising on security or self-custody.

But this is not the end (the hint is in the title). A security product is nothing if you do not operate it securely… How does Ledger Recover operate to ensure the impregnability of the system’s security measures? That’s what we will set out to answer in the Part 5 of Genesis of the Ledger Recover blog series: Operational Security.

1. OCR stands for Optical Character Recognition. This technology decipher and transform printed or handwritten text into machine-understandable data and make them processable by machine. We use OCR in Recover to extract your personal identity data from official documents to associate them to your backup or verify they keep unchanged when you request a recovery. ↩︎
2. Comparing Biometric data has been well-established as a robust method for accurately verifying individuals identity. Biometric data is measurable, capturing unique physical or behavioral characteristics used for verification. ↩︎
3. A presentation attack occurs when a bad actor, or fraud perpetrator, uses someone else’s physical characteristics or biometric data, commonly known as “spoofs,” to impersonate someone else. ↩︎