Welcome back to the sixth part of our blog series on Ledger Recover’s genesis! 

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 all the potential challenges when building Ledger Recover, provided by Coincover, and introduces us to the core security feature of Ledger Recover, splitting your Secret Recovery Phrase into shares.

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.

Genesis of Ledger Recover Part 4 – “Controlling access to the backup: identity verification,” discusses how the service ensures that the person initiating the request for sharing or recovering their Secret Recovery Phrase is indeed its rightful owner.

Genesis of Ledger Recover Part 5 – ‘Operational Security,’ takes a closer look at how we ensure maximum security at the operational level, including security infrastructure, separation of duties, governance, monitoring, and finally the Incident Response strategy.

For this part, let the authors introduce you to Ledger Donjon, Ledger’s internal security evaluation lab. The Ledger Donjon is made up of a world-class expert team with extensive backgrounds in the security and smartcard industries. Its key functions are internal and external security assessment. They work closely with Ledger’s Firmware development and hardware teams to analyze and improve the security of Ledger products.

The team is continuously looking for vulnerabilities on Ledger products as well as Ledger’s providers’ products.

This last article explores the security challenges identified by the Ledger Donjon when building a seed recovery service, and how regular internal and external security audits are conducted in order to guarantee the maximum of security to users.

The aim of a hardware wallet is to protect your keys, either the embedded application’s private keys or the master seed itself. The user’s keys should not be accessed if the user did not grant access to them. Each time a user decides to interact with the keys, for example, by signing a transaction, a pin request is made and the action can only be performed if the user enters his pin code after validating the transaction on the trusted screen of the device.

This mechanism is guaranteed by our custom OS, dubbed BOLOS, running on top of the Secure Element. The Secure Element prevents unwanted access to your wallet by protecting it against most of the attack scenarios, still allowing for legitimate access to your seed or private keys. The combined work of the Secure Element and the custom OS  allows guaranteeing user consent when a user tries to access his secrets.

User consent mechanism did not change for Ledger Recover and the creation of the three Secret Recovery Phrase shares: the OS requires user consent because it needs to interact with the seed. From a device point of view, the Ledger Recover opt-in is like interacting with smart contracts or signing transactions. And if you do not grant access to the seed, the share creation is impossible. Moreover, Ledger Recover only allows exporting shares, not the seed itself, and only on fully encrypted secure channels, as described in the previous blog posts.  

The duo custom OS and Secure Element also allows you to have custom applications on your Ledger devices without compromising security. As reminded by the Donjon when talking about the threat model for confidentiality of the Seed and Private Keys.

The applications on the device, therefore, never have access to your seed. They can only interact with private keys dedicated to each application, which are generated from the seed by BOLOS, without the possibility to extract them. Ledger Recover was designed as a feature integrated directly into BOLOS and not as an external app to maintain the validity of the threat model:

Another critical point for Ledger device security is to interact with the seed or the private keys without leaking any information about them.

Like for other cryptographic operations on the seed, shares are generated inside the Secure Element, providing us with security mechanisms that prevent external attackers from obtaining any information about the seed. Moreover, as seen in the first part, the chosen cryptographic protocol allows the creation of shares which alone provides no information about the original seed.

The shares also need to be protected during the communication between the Secure Element on the device and the HSM (Hardware Security Module). 

The communication channels ensure all the properties of a secure channel: confidentiality, integrity, and authenticity. This is done using a Secure Channel already integrated into Ledger devices and HSMs through the mechanism of Attestation: 

The shares will also transit to the backup providers’ databases, and the same requirements must be fulfilled. To ensure the encryption of the shares, we take advantage of the encryption mechanism brought by the HSM. This way, only a genuine Ledger Recover HSM can decrypt the shares. It also means that even if someone succeeds in stealing the shares databases it will have no information about the shares.

These first requirements allow us to ensure that the shares will only be transported through a genuine Ledger device to a genuine Ledger Recover HSM, with no one in between these two elements being able to retrieve the share. 

The other critical asset of Ledger Recover is the user identity information. We also need to protect users from data breaches. This is why we have verified during reviews that: 

All the security reviews have been done by considering external attackers and internal rogue employees. The security requirements must consider the case of an insider trying to steal shares to ultimately steal user funds. This is why all the security behavior is put inside secure components, like HSMs and Nano devices.   

Security Analyses are done continuously for Ledger components. The analyses are performed in two distinct ways: Internal Security Reviews and External Pentests. The following sections will detail what they are and why two different types of analysis are required.

As security is not an option at Ledger, a dedicated in-house team has been created: the Ledger Donjon (The Ledger Donjon, Enter the Donjon). (https://donjon.ledger.com/threat-model/). Its primary mission is to improve the security of Ledger’s products. To accomplish this, the Donjon has technical skills allowing them to perform: 

To give concrete examples of what the team does:

However, as transparency is one of our core values, we at Ledger also want to be challenged by our community. That’s where pentests, also called security evaluations, come into play.

These pentests allow us to demonstrate to customers – both individuals and companies – the level of security of products or services, such as our Ledger Nano line or Ledger Recover. By undergoing these evaluations, we are subjecting such products, services, software and knowledge to testing by an independent third-party security laboratory with highly advanced equipment and expertise. As a result of the evaluations, Ledger has been awarded CSPN certificates for the Nano S and Nano X by ANSSI.

The pentests are not performed by any random laboratory. We decided to go with the ones licensed by ANSSI, France’s Cybersecurity Agency, known for its meticulous work in the field of cybersecurity.

Our decision led us to onboard Synacktiv for this crucial journey. Hailing from Paris, Synacktiv is an offensive security laboratory recognized for the quality of their work and their findings. Given our utmost desire to uncover any potential flaws, vulnerabilities, or bugs in Ledger Recover, we spared no effort in ensuring they were positioned for success by providing them with all the resources and support they needed:

The outcome was more than positive for Ledger. Despite all the hard work and time we put into developing and reviewing Ledger Recover, bugs and vulnerabilities were still found by Synacktiv, which led to refactoring and architecture changes in the code, adding additional security layers and toughening what was already in place. And, of course, the Ledger Donjon performed an Internal Security Review.

As firm believers that “the devil is in the details”, we are committed to forging ahead on that path, conducting regular pentests on Ledger Recover.

For example we will detail some outcomes from the different audits and the mitigation planned.

Ledger Recover was designed to take advantage of the security built into our devices and HSMs. But even with such security, we need to ensure users cannot be fooled or manipulated into performing actions that would compromise their seed and therefore assure them maximum security.

During one of the reviews, we noticed that the restore process was vulnerable to social engineering attacks. It relied on a prerequisite: having installed beforehand a rogue Ledger Live on the user’s computer. The idea was the following:

This attack could be carried out through social engineering, for example, by manipulating the user into performing an Identity Verification. To fix this issue, we decided to have two lines of actions: first, like for all other products we decided to provide user documentation to give users the right process to follow and not be fooled during some actions. The second action we put in place is a technical measure: preventing a single account from starting two restores from the same seed.

Other outcomes of the security reviews were about the potential internal threats. This security point of view was already present in the original architecture with the idea of having three companies to store the different parts of seed and prevent a bad actor from stealing elements. But at first the mitigation was designed at a high level by the separation of knowledge. The security reviews showed some weakness which led to additional mitigations.

For example, we developed the diversification of backup_id. Originally the backup_id was the same in the three databases, so the Ledger Recover service could retrieve easily which part of the share on the first backup provider was linked to the one on the second backup provider. Then we decided to diversify the backup_id in a way that if people from two companies decide to collude it will be difficult to know which share is paired with another share.

Another case was the database where the user identity information is stored. At first it was encrypted with a simple encryption. To prevent an internal attacker from being able to retrieve the key we decided to use HSM encryption in that way no one could retrieve the key. Even if we add several infrastructure hardening (see Part 5 <TODO: link when published>). 

This last chapter shows you that our products are built by prioritizing the safety of our users. This is why several actions are already planned for the future of Ledger Recover: the security will be analyzed regularly either by our internal team or by external security actors.

Our devices are also repeatedly audited and assessed to assure the pair custom OS and Secure Element guarantee the security of the user secrets. This process is never ending and will continue throughout the life of Ledger Recover as a service.

Last but not least, Ledger Recover is part of our Bounty program and the source code containing the implementation of Ledger Recover is also public and can be reviewed by anyone.

Thank you again for having stayed with us through this journey of unveiling what’s behind the scene of Ledger Recover. And hoping to see you on the day of the official launch!

Similar to Notcoin - Blum - Airdrops In 2024

origin »

108 +