Implementation of "Recover" by Ledger and the Underestimated Need for Understanding

Ledger, a leading company providing security solutions for cryptocurrencies, is soon launching "Recover," an optional (but irrevocable) private key backup service.

Despite some initial misunderstandings, the quality of the offering remains undeniable. This article analyzes the communication surrounding this launch, addresses the technical concerns raised by users, and suggests a reflection on the intention and objective of this service.

Ledger recently introduced "Recover," an optional private key backup service. Through a detailed Know Your Customer (KYC) process, users can request a backup of their key from affiliated partners. This document does not contain explanatory diagrams, but suggestions for such diagrams are welcome and will be duly credited.

Current users, whether prospective users of the option or not, have not understood the following:

• Why does an export feature (perceived as such initially) exist on hardware designed to prevent it?

The sending of restoration elements occurs in a secure intermediate environment, and the seed does not leave directly or entirely to the same recipient. However, there is a contradiction between the offering and this feature; their communication failed in this regard.

• Why offer a direct link between key export and a KYC process involving new third parties?

One can assume that this prepares for future compliance and legal needs of Ledger and/or its custody clients more than a customer-oriented approach.

• The ambiguity has led to all kinds of exploitations in a rather paranoid environment.

Analysis of the Initial Communication

It is essential to clarify that the risks associated with using Ledger remain the same, with or without the "Recover" option. Users have raised concerns mainly about the technical aspects of cryptography and the implications of sharing sensitive data with third parties in the KYC process.

Competitors have seized this opportunity to launch promotions and amplify user questioning, with some, like Foundation reporting their best sales day.

Clarification of Cryptographic Functionality

The primary cryptographic functionality involved in the "Recover" service is Shamir's Secret Sharing (SSS), a method for securely accessing secret information in a distributed manner. The secret is divided into multiple fragments, called "shards," which are used to reconstruct the original secret. This process is similar to hashing a password, which accesses the secret in multiple key fragments. To unlock access to the secret via Shamir's secret sharing of secret keys, a minimum number of fragments must be combined.

At the heart of a Ledger device is the Secure Element (SE). It stores the BIP-32 seed and user access code and performs all cryptographic operations. It runs firmware called BOLOS, consisting of a kernel with access to the seed and an application loader that executes each application in a sandbox. Critical executions are signed by a Ledger master key shared among all keys and physically confirmed by the user. Otherwise, nothing comes out.

https://developers.ledger.com/docs/embedded-app/bolos-hardware-architecture/

To use an SE, companies must sign NDAs and not share certain aspects of the chip, including not sharing the code they execute on the chip. This principle of trust in one or more providers is implied by the use of (almost) all hardware wallets.

Details of the Backup Process

The ambiguity has largely dissipated with the subsequent technical explanations:

• https://twitter.com/P3b7_/status/1658580819030441990
• https://twitter.com/P3b7_/status/1658809445965606913
• ou pas (mais c'est le revers de l'open source) :?https://twitter.com/BTChip/status/1658796108263374848

On request and following a detailed KYC process, after physical validation on the user's device, they can request a backup of their key from partners.

On the secure element of the key, the fragments are duplicated and encrypted by Ledger's master key, shared among all devices. These encrypted fragments are then transmitted to partners through a secure channel. The partners, in turn, each encrypt a part of the secret. During restoration, under a KYC procedure, the partners send back the fragments. Two out of three fragments are sufficient for Ledger's master key to decrypt and generate the key in the secure element of the new device.

Technical Risks and Considerations on Sensitive Data

Other research centers have refused to use SSS due to potential vulnerabilities, partially resolved in Ledger's case. Here are the points that could still raise concerns:

Lack of Authentication

A notable issue with SSS is the lack of a robust authentication system. Ledger has attempted to address this problem by using a heavy authentication process that involves exposing users' sensitive data on the cloud of partners and their KYC providers. However, this raises important questions about privacy protection and data security. A Ledger device is designed to minimize exposure of metadata and third-party attestation of identity using public-key cryptography. Therefore, the authentication process used by Ledger may contradict basic principles of data security.

Lack of Revocation System

Another problem is the absence of a revocation system or the existence of a shared revocation system that requires excessive trust in third parties. This could increase the risk of security attacks or data leaks.

Lack of Implementation Standards

In the absence of implementation standards for SSS, users must rely entirely on Ledger for the security of their data. This could potentially increase the risk of security vulnerabilities or implementation errors. This is the accepted trade-off when purchasing a Ledger.

Auditability

Auditability is another important issue. The authentication process, access to transmitted shards, and usage of Ledger's master key are not verifiable, making it difficult for users to ensure their data is being handled securely and that Ledger's master key is being used correctly. This is also the accepted trade-off when purchasing a Ledger.

Sharing of Integrity

Sharing data integrity by distributing shards can also have disadvantages. For example, it could make data integrity dependent on a minimum threshold of reliability from actors. This could, in turn, favor technically reliable cloud service providers at the expense of social preferences and trust in favor of clouds (GAMAM).

Secure Element (SE)

Regarding the Secure Element (SE), it is important to note that no existing SE chip can natively and securely execute secp256k1 (the curve used by Bitcoin & Ethereum), which is an inherent limitation of current semiconductor technology. Therefore, to execute secp256k1 or SSS, an SE must pass a key to a code execution process within the SE or to an MPU. This could potentially pave the way for unexpected uses of this key within the sandbox, which are generally not expected from a personal hardware wallet.

While other hardware wallets explicitly state this risk and the SE's output, Ledger has focused its communication on the impossibility of such an occurrence thanks to its proprietary technology. The reality proves to be different, causing some dismay among users.

The following sources provide additional information on these subjects:

• https://blog.keys.casa/shamirs-secret-sharing-security-shortcomings/
• https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Dangers.md
• https://github.com/BlockchainCommons/SmartCustody/blob/master/Docs/SSKR-Sharing.md

New technologies, especially those related to data security and cryptography, often come with unforeseen risks and challenges. While Ledger has introduced a series of measures to mitigate some of the associated risks, significant questions remain. Therefore, it is crucial for users to be fully aware of these risks and challenges before adopting such systems. Additionally, open dialogue and transparent communication from technology providers are crucial to maintain user trust and ensuring the robustness and security of cryptographic systems.

Interrogations on technical motivations persist

Questions remain regarding the use of the master key.

• Is it used to slow down the exploitation of leaked fragments due to its acquisition cost and the necessary decryption time? Is it a marketing ploy for security? Or does it aim to restrict the key restoration capability to only Ledger devices?
• Furthermore, what would prevent partners, upon request from an authority or in collusion among themselves, from gathering the keys and decrypting them on a device (since all devices have the same master key)? Why involve partners instead of using multiple Ledger channels to avoid interceptions?
• Why are partners added to the process instead of multiple Ledger channels if the concern is to prevent interceptions, knowing that they all have access to the master key via the Ledgers?

Unclear commercial and legal motivations

Beyond these technical questions, the motivations and intentions behind the "Recover" service remain unclear.

• Ledger highlights a diversity of legislations for shards, but the marketing argument is weak; given that the imposed regulations are from France, England, and the USA. The customers' reaction on the networks was immediate: "We've seen better geographical distribution to avoid regulatory capture".
• The proposed service primarily targets a broad audience, typically individuals with a relatively modest sum to secure. An additional monthly cost of €10, added to the initial device cost, can represent a significant amount compared to these modest amounts. This audience is also the least knowledgeable about the device's operation and the associated risks. It is logical that these users seek to understand the benefits of a Know Your Customer (KYC) procedure, which allows a company to verify the identity of its customers and better understand their current level of security. In the end, even without a clearly defined alternative at this stage, some have questioned their initial trust in Ledger, which they had previously underestimated. This is especially the case considering the difficulty in understanding the choices regarding code ownership, the presumed use of the Ledger's master key, and the use of keys between the operating system (SE) and the code that utilizes it. However, these practices are logical and generally common in hardware wallet solutions.
• Why expose our keys to the risk of partner collusion and abuse of authorities' access to our keys without the user being able to verify or even know about it?
• Why offer the option of a KYC process to send key fragments to third-party clouds?
• Why would Ledger seek to prove that a "social backup" (a popular trend among altcoin investors) is more secure than a Ledger?
• Is this a new offering from Ledger to third parties to provide partial custody? Is it a legal constraint? Or is it the prelude to a more comprehensive compliance process?
• Are the master key(s) present in the SE used for encryption, decryption, and signing?

Conclusion

Although some parties have defended Ledger for various reasons, significant technical questions remain. The incident may seem close to some, but it is uncertain whether all stakeholders share this perspective.

The question of how necessary a secure element (like a Ledger) and KYC on third-party clouds are for implementing Shamir's secret sharing for recovery purposes remains open. Ultimately, each user will need to evaluate the risks and conditions associated with backing up their keys based on their specific situation.

A big thank you to the team at https://entonnoirdubitcoin.space for their exchanges and expertise on the subject!

__

For further exploration and to complement your own research and contrasting opinions:

The security of your encryption keys and recovery phrases is crucial to protect your cryptocurrencies. Here are some recommendations to maximize security:

• Seed: The seed should be generated randomly and contain sufficient entropy (i.e., random data) to be secure. Generally, a seed of 128 to 256 bits is considered sufficiently secure. This corresponds to a mnemonic phrase of 12 to 24 words in standard practice (with the same level of security for 12 and 24 words).
• Passphrase: A passphrase should be long and complex to be secure. It should contain a combination of uppercase and lowercase letters, numbers, and special characters. The recommended length varies, but a passphrase of 12 characters or more is generally considered secure.
• Private Key: Like the seed, the private key should be randomly generated and contain sufficient entropy. It should be kept secret and never shared.
• Derivation Path: The derivation path should be kept secret, just like the seed and private key. If someone knows your seed and derivation path, they can generate all your private keys.
• Mnemonic Phrase: The mnemonic phrase should be kept secret and never shared. It should be noted and stored securely. It is recommended to write it on paper rather than storing it digitally to avoid the risk of hacking.

It is important to note that these recommendations are general and may not be suitable for all situations. It is always best to consult a security expert for advice tailored to your specific situation.

When to Use a Hardware Wallet and When Not to for Cryptocurrency Usage?

A hardware wallet is a highly secure way to store cryptocurrencies. It can be used when you want to maximize the security of your funds. Here are some situations where using a hardware wallet may be appropriate:

• If you hold a significant amount of cryptocurrencies: If you have a substantial amount of cryptocurrencies, it is recommended to use a hardware wallet. The additional security provided by these devices is worth the investment.
• If you plan to hold your cryptocurrencies long-term: If you intend to hold your cryptocurrencies for an extended period (often referred to as "HODLing"), a hardware wallet can be a good option. It allows you to secure your assets offline and protect them from online attacks.
• However, there are also situations where using a hardware wallet may not be the best option:
• If you frequently trade cryptocurrencies: If you engage in frequent trading, using a hardware wallet may be impractical. Each transaction requires the wallet to be connected to a computer, which can be cumbersome if you trade frequently.
• If you hold a small number of cryptocurrencies: If you only have a small number of cryptocurrencies, investing in a hardware wallet may not be cost-effective. In this case, a software wallet may be sufficient.
• If you need quick and easy access to your cryptocurrencies: Software wallets or online wallets offer faster and easier access to your cryptocurrencies, provided you have an internet connection.

It is important to note that regardless of the storage method you choose, you should always take measures to protect your cryptocurrencies. This includes using strong passwords, regularly backing up your wallet, and keeping your software up to date to ensure it is always secure.

What are the Alternatives for Seed Backup?

Is it possible to implement a secure environment on an operating system to achieve the equivalent of hardware security on a standard USB key (at a reduced hardware cost)?

The Secure Element (SE), a dedicated security chip, is frequently used to enhance security in hardware wallets. However, as mentioned, existing SE chips struggle to natively and securely execute secp256k1 due to inherent limitations in current semiconductor technology. Therefore, in practice, the security is roughly equivalent to that of secure environments outside the SE.

SE chips themselves also vary in their capabilities. Some, like those used in Ledger devices, are better protected against heat, electrical currents, and reverse engineering by manufacturers, with features like metal plates, Faraday cages, noise, secrecy (intellectual property), or simply complexity. On the other hand, not all hardware wallets necessarily have Secure Elements, such as Trezor, SigSigner, and Blockstream Jade, Specter, to allow for greater openness; some, like SigSigner or Blockstream Jade, require a QR code to retrieve the seed without risking storing it on the device in case of device theft. Others, like ColdCard, monitor access attempts and can permanently block access after a certain number of errors, employing tactics like false PIN prompts or slow screens.

One potential solution to this problem could be the implementation of a secure execution environment (TEE - Trusted Execution Environment) at the operating system (OS) level. Tails OS, for example, allows for effective segmentation of spaces and access. A TEE is a secure area within a main processor that ensures the confidentiality and integrity of data and code. A TEE can execute code, process data, protect resources, and manage rights, thereby providing enhanced protection compared to a rich execution environment (REE).

However, while this may theoretically provide security similar to that of a SE, there are several challenges to overcome. First, implementing a TEE is complex and requires security expertise. Second, while SEs are dedicated hardware components designed specifically for security, a TEE is still susceptible to compromise due to vulnerabilities at the OS level.

Furthermore, it is crucial to note that even with a TEE, the transfer of keys between the TEE and the MPU (Micro Processing Unit) must be carefully managed to avoid unintended use of the key, similar to the case with the SE. Mishandling these keys could open the door to potential attacks, compromising the security of cryptocurrencies.

In such cases, a multi-signature approach with additional signature methods and an incorruptible physical backup (such as a metal plate) can reasonably complement the device and provide more options in managing access to funds. Some wallets, like Liana, are moving towards such solutions.

Therefore, while theoretically possible, implementing a secure environment at the OS level to emulate hardware security presents several challenges and potential risks. These risks need to be carefully weighed by individuals based on their level of security expertise, their ability to execute and maintain the long-term key storage with the chosen device, and the value of the funds and the associated economic or usage risks of these cryptographic keys. Sometimes, a mobile terminal or a disconnected computer can also serve this purpose.

Continuous research and development in this field are essential to overcome these challenges and strengthen the security of cryptocurrencies. This research is funded and intensive.

As technology continues to evolve, it is crucial for users to stay informed and educated about the latest advancements, risks, and best practices in securing their cryptocurrencies. Taking proactive measures, seeking expert advice, and staying vigilant can help users navigate the complexities of securing their digital assets.

In conclusion, the implementation of Ledger's "Recover" service has raised important technical and security questions. While Ledger has taken steps to address some concerns, significant uncertainties and risks remain. Users must carefully evaluate the risks and trade-offs associated with the backup of their keys based on their specific circumstances.

It is essential for companies like Ledger to maintain an open dialogue, transparent communication, and robust security practices to uphold user trust and ensure the integrity and security of cryptographic systems. By addressing these concerns and actively engaging with the community, companies can continue to innovate and provide secure solutions in the evolving landscape of cryptocurrencies.

Thank you for reading and exploring this analysis. We encourage you to further research and engage in discussions with diverse perspectives to deepen your understanding of this complex topic.