Hardware wallet manufacturer Ledger has released a new Ledger Recover service in their latest firmware update. This new feature was met with a mixed response from the crypto community. Some people expressed outrage, arguing that transmitting key fragments to third parties compromises the fundamental purpose of a hardware wallet. To some, it even raised suspicions about a potential backdoor.

Honestly, my initial reaction towards this feature was not negative. Having worked with a previous company that was focused on solving wallet management issues for everyday users, I comprehend the potential of a secure key recovery service. It could present a significant advantage to numerous users and could address one of the key obstacles preventing the widespread adoption of cryptocurrency by average users. The fact that this new feature is opt-in further reassured me that it would not pose a significant threat to other existing users.

However, on a second thought, I started seeing things from a different perspective. While I still believe that the recovery service has the potential to greatly benefit users, I have a few reservations about its current implementation in Ledger. There are a few serious issues that concern me and warrant further discussion and examination.

Before going into my specific concerns, I would like to dispel a common misconception. Many people who reacted with alarm have a misconception about how Ledger uses the Secure Element. They wrongly assume that the code run by the Secure Element is immutable, which is not the case. Ledger runs a custom operating system known as BOLOS, which is executed within the the Secure Element of the SoC. BOLOS, being part of the firmware, can be updated to accommodate new features, such as supporting new cryptography primitives and additional blockchains. The updatable BOLOS invariably has access secret key materials to enable it to derive new keys using different algorithms. Essentially, the entirely of BOLOS forms the trusted computing base (TCB) of the Ledger system. Without the ability to update BOLOS, Ledger would be unable to support new signing algorithms or additional blockchains without rolling out new hardware models.

However, the firmware update of BOLOS is not unregulated. The code that operates within the Secure Element must be signed by the Ledger company. Furthermore, it can reasonably be assumed that a user passcode is necessary to authorize a firmware update. Therefore, even in a hypothetical scenario where Ledger is coerced by a governmental authority to release firmware incorporating a backdoor, this modified firmware couldn't be installed without the user's explicit consent.

This reddit post provides a comprehensive explanation of the interplay between the Secure Element, OS, and apps in a Ledger device.

Information security always involves balancing trade-offs. Methods exist to mitigate risks during firmware updates; one approach is to design hardware to generate key encryption keys based on firmware measurements. Thus, any firmware modification would erase the device. While this enhances security, it complicates the update process for users. Given that most users' threat models don't require protection against state actors, it's understandable that leading hardware wallet manufacturers allow firmware updates without necessitating a full factory reset.

My reservations about the Ledger Recover service center around two key areas: the potential risks inherent in its implementation and the broader human organizational issues. While these problems may not actually arise in Ledger's implementation, the Ledger team's rather poor job at communicating their implementation details to the technical community leaves me with no choice but to assume the worst-case scenario.

The following FAQ contains the most comprehensive description that I could find from Ledger regarding the design of their new service:

In short, only you can access your wallet. When you subscribe to Ledger Recover, a pre-BIP39 version of your private key is encrypted, duplicated and divided into three fragments, with each fragment secured by a separate company—Coincover, Ledger and an independent backup service provider. Each of these encrypted fragments is useless on its own. When you want to get access to your wallet, 2 of the 3 parties will send fragments back to your Ledger device, reassembling them to build your private key.

And on recovery procedure:

The steps are as follows: - Get a new Ledger Nano X. - Open the Ledger Live mobile app and navigate to My Ledger -> Ledger Recover. - Go through reasonable checks to verify your identity. - Follow the onscreen instructions.

In my opinion, the FAQ published by Ledger not only failed to answer many crucial questions, it, in fact, exacerbates my concerns.

The FAQ describes that the private key is encrypted and subsequently divided into three fragments. This, however, leads to several questions: if the key is encrypted prior to its division, whose encryption key is used? Are these fragments encrypted within the Secure Element before distribution to individual operators, thereby averting interception at the software level?

If the key that wraps the users' key materials is under the control of a singular entity and if that entity can access the fragments (perhaps during initial setup), the “layers of protection” in their recovery service become moot.

Further, there's another aspect that needs clarification: are the encryption public keys embedded in the firmware, or are they obtained from software? If it's the latter, there exists a potential threat where an attacker could substitute the encryption key with a different one, enabling the interception of the key in transit, and consequently, access to the private key material.

Even without these potential vulnerabilities, the Ledger Recover service still breaks a crucial assurance many users rely on: that there is no possible way to extract or clone a secret key from a hardware wallet. Many wallet management procedures employed by large enterprises hinge on this assumption and the physical security of the hardware itself. An attacker who knows the passcode could use a fake identity to sign up for the recovery service and clone the private key to a new Ledger device. The new recovery service, at the very least, weakens - if not entirely disrupts - this assumption.

The Ledger Recover service relies on government-issued ID for verification. This implies that at least part of the recovery process involves human judgment. Whenever humans are involved, the organizational design always becomes a crucial point of discussion.

Firstly, how do Coincover and Ledger verify your identity? Is the verification process performed independently by both? Or does one party conduct the verification and the other merely a rubber stamp?

From their FAQ, a third party who retains one of the three shares of the key is termed an "independent backup service provider". This title suggests that this provider only offers a "backup service”. It is reasonable to expect that this provider would not be involved in the verification process. If this is the case, who has the authority to instruct the backup service to return a fragment?

These questions essentially revolve around the degree of independence of the three supposedly separate parties. If at least one of them is not practically independent, the entire 2-of-3 threshold secret sharing scheme may offer no protection to the majority party.

Furthermore, where are Coincover and the "independent backup service provider" based? If they are both situated in the same country, or in friendly nations, a single court order could potentially force two of the parties to surrender their key fragment. This could potentially lead to the seizure of assets, which represents a serious threat to some users’ security.

In conclusion, while Ledger's new recovery service has the potential to significantly benefit users, there are pressing concerns regarding its implementation and organizational structure. The increased attack surface, questionable independence of parties involved in key recovery, and the potential impact of governmental intervention raise legitimate doubts about the security of the system. Ledger needs to address these issues transparently and communicate their solutions effectively to the technical community to ensure user confidence and maintain the high security standards users have come to expect from hardware wallets.

Hardware wallet manufacturer Ledger has released a new Ledger Recover service in their latest firmware update. This new feature was met with a mixed response from the crypto community. Some people expressed outrage, arguing that transmitting key fragments to third parties compromises the fundamental purpose of a hardware wallet. To some, it even raised suspicions about a potential backdoor.

Honestly, my initial reaction towards this feature was not negative. Having worked with a previous company that was focused on solving wallet management issues for everyday users, I comprehend the potential of a secure key recovery service. It could present a significant advantage to numerous users and could address one of the key obstacles preventing the widespread adoption of cryptocurrency by average users. The fact that this new feature is opt-in further reassured me that it would not pose a significant threat to other existing users.

However, on a second thought, I started seeing things from a different perspective. While I still believe that the recovery service has the potential to greatly benefit users, I have a few reservations about its current implementation in Ledger. There are a few serious issues that concern me and warrant further discussion and examination.

Before going into my specific concerns, I would like to dispel a common misconception. Many people who reacted with alarm have a misconception about how Ledger uses the Secure Element. They wrongly assume that the code run by the Secure Element is immutable, which is not the case. Ledger runs a custom operating system known as BOLOS, which is executed within the the Secure Element of the SoC. BOLOS, being part of the firmware, can be updated to accommodate new features, such as supporting new cryptography primitives and additional blockchains. The updatable BOLOS invariably has access secret key materials to enable it to derive new keys using different algorithms. Essentially, the entirely of BOLOS forms the trusted computing base (TCB) of the Ledger system. Without the ability to update BOLOS, Ledger would be unable to support new signing algorithms or additional blockchains without rolling out new hardware models.

However, the firmware update of BOLOS is not unregulated. The code that operates within the Secure Element must be signed by the Ledger company. Furthermore, it can reasonably be assumed that a user passcode is necessary to authorize a firmware update. Therefore, even in a hypothetical scenario where Ledger is coerced by a governmental authority to release firmware incorporating a backdoor, this modified firmware couldn't be installed without the user's explicit consent.

This reddit post provides a comprehensive explanation of the interplay between the Secure Element, OS, and apps in a Ledger device.

Information security always involves balancing trade-offs. Methods exist to mitigate risks during firmware updates; one approach is to design hardware to generate key encryption keys based on firmware measurements. Thus, any firmware modification would erase the device. While this enhances security, it complicates the update process for users. Given that most users' threat models don't require protection against state actors, it's understandable that leading hardware wallet manufacturers allow firmware updates without necessitating a full factory reset.

My reservations about the Ledger Recover service center around two key areas: the potential risks inherent in its implementation and the broader human organizational issues. While these problems may not actually arise in Ledger's implementation, the Ledger team's rather poor job at communicating their implementation details to the technical community leaves me with no choice but to assume the worst-case scenario.

The following FAQ contains the most comprehensive description that I could find from Ledger regarding the design of their new service:

In short, only you can access your wallet. When you subscribe to Ledger Recover, a pre-BIP39 version of your private key is encrypted, duplicated and divided into three fragments, with each fragment secured by a separate company—Coincover, Ledger and an independent backup service provider. Each of these encrypted fragments is useless on its own. When you want to get access to your wallet, 2 of the 3 parties will send fragments back to your Ledger device, reassembling them to build your private key.

And on recovery procedure:

The steps are as follows: - Get a new Ledger Nano X. - Open the Ledger Live mobile app and navigate to My Ledger -> Ledger Recover. - Go through reasonable checks to verify your identity. - Follow the onscreen instructions.

In my opinion, the FAQ published by Ledger not only failed to answer many crucial questions, it, in fact, exacerbates my concerns.

The FAQ describes that the private key is encrypted and subsequently divided into three fragments. This, however, leads to several questions: if the key is encrypted prior to its division, whose encryption key is used? Are these fragments encrypted within the Secure Element before distribution to individual operators, thereby averting interception at the software level?

If the key that wraps the users' key materials is under the control of a singular entity and if that entity can access the fragments (perhaps during initial setup), the “layers of protection” in their recovery service become moot.

Further, there's another aspect that needs clarification: are the encryption public keys embedded in the firmware, or are they obtained from software? If it's the latter, there exists a potential threat where an attacker could substitute the encryption key with a different one, enabling the interception of the key in transit, and consequently, access to the private key material.

Even without these potential vulnerabilities, the Ledger Recover service still breaks a crucial assurance many users rely on: that there is no possible way to extract or clone a secret key from a hardware wallet. Many wallet management procedures employed by large enterprises hinge on this assumption and the physical security of the hardware itself. An attacker who knows the passcode could use a fake identity to sign up for the recovery service and clone the private key to a new Ledger device. The new recovery service, at the very least, weakens - if not entirely disrupts - this assumption.

The Ledger Recover service relies on government-issued ID for verification. This implies that at least part of the recovery process involves human judgment. Whenever humans are involved, the organizational design always becomes a crucial point of discussion.

Firstly, how do Coincover and Ledger verify your identity? Is the verification process performed independently by both? Or does one party conduct the verification and the other merely a rubber stamp?

From their FAQ, a third party who retains one of the three shares of the key is termed an "independent backup service provider". This title suggests that this provider only offers a "backup service”. It is reasonable to expect that this provider would not be involved in the verification process. If this is the case, who has the authority to instruct the backup service to return a fragment?

These questions essentially revolve around the degree of independence of the three supposedly separate parties. If at least one of them is not practically independent, the entire 2-of-3 threshold secret sharing scheme may offer no protection to the majority party.

Furthermore, where are Coincover and the "independent backup service provider" based? If they are both situated in the same country, or in friendly nations, a single court order could potentially force two of the parties to surrender their key fragment. This could potentially lead to the seizure of assets, which represents a serious threat to some users’ security.

In conclusion, while Ledger's new recovery service has the potential to significantly benefit users, there are pressing concerns regarding its implementation and organizational structure. The increased attack surface, questionable independence of parties involved in key recovery, and the potential impact of governmental intervention raise legitimate doubts about the security of the system. Ledger needs to address these issues transparently and communicate their solutions effectively to the technical community to ensure user confidence and maintain the high security standards users have come to expect from hardware wallets.