Ledger Recover White Paper jetzt verfügbar
- Dieses Thema hat 25 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 8 Monaten, 3 Wochen von
.
-
Beiträge
-
-
**Als Teil unserer Verpflichtung, unsere Open-Source-Roadmap zu beschleunigen, veröffentlichen wir heute das Ledger Recover White Paper, ein wichtiger Schritt, der es jedem ermöglicht, die kryptographischen Protokolle zu überprüfen, bevor wir den optionalen Opt-in-Service einführen.**
Dies baut auf den über 150 Anwendungen und anderen Open-Source-Funktionen auf, die Ledger bereits implementiert hat.
Der wichtigste Aspekt des Whitepapers ist, dass Sie erfahren können, wie Ledger Recover, das von Coincover bereitgestellt wird, technisch funktioniert, und den Dienst selbst im Detail prüfen können. Wir tun dies, um die Transparenz in Zukunft zu erhöhen. Dieses White Paper ändert nichts an der Sicherheit Ihres Ledger-Geräts.
[https://github.com/LedgerHQ/recover-whitepaper](https://github.com/LedgerHQ/recover-whitepaper)
Wir empfehlen Entwicklern, Forschern und Krypto-Enthusiasten gleichermaßen, sich mit diesem Weißbuch zu befassen und die sicheren Mechanismen von Ledger Recover vollständig zu verstehen.
**Ihr Feedback ist immer willkommen**
Wenn Sie Verbesserungsvorschläge zu Sicherheitsthemen haben, können Sie uns gerne über das Donjon Bounty kontaktieren: [https://donjon.ledger.com/bounty/](https://donjon.ledger.com/bounty/)
**Was werden Sie in diesem Weißbuch finden?**
Eine gründliche Untersuchung des Systemdesigns von Ledger Recover, das Design des kryptographischen Protokolls, Sicherheitsmerkmale und Details zu den folgenden Arbeitsabläufen:
* Sichern Ihrer Secret Recovery Phrase
* Wiederherstellung auf einem neuen Ledger-Gerät
* Sichere Löschung Ihrer BackupsWährend dieser Abläufe ist der Rahmen zwischen dem Ledger-Gerät und den HSMs der Sicherungsanbieter durchgängig gesichert.
Die geheime Wiederherstellungsphrase wird mit einem festen Ledger-Schlüssel verschlüsselt, bevor sie geteilt wird, und die Fragmente werden den Sicherungsanbietern über einen sicheren Kanal (basierend auf einem elliptischen Diffie-Hellman-Schlüsselaustausch) zur Verfügung gestellt, was bedeutet, dass kein Vermittler das Fragment der geheimen Wiederherstellungsphrase entschlüsseln kann (vorausgesetzt, ein Angreifer gibt sich nicht aktiv als der Empfänger aus, wofür wir vorbeugende Maßnahmen haben).
Der Algorithmus, mit dem die Fragmente berechnet werden, verwendet eine Variante eines Algorithmus zur Wahrung der Privatsphäre namens Shamir Secret Sharing, der verhindert, dass ein Zwischensystem (d. h. Ledger Live, Dritte, Angreifer) die Informationen abfangen kann.
Zusammenfassend lässt sich sagen, dass unser zukünftiger Dienst Ledger Recover, der von Coincover bereitgestellt wird, kritische Sicherheitsmerkmale enthält, darunter eine Ende-zu-Ende-Verschlüsselung, Nichtabstreitbarkeitseigenschaften, Tools zur Wahrung der Privatsphäre und ein minimalistisches Design, wodurch dieser Dienst vollständig für die sichere Sicherung und Wiederherstellung der geheimen Wiederherstellungsphrase eines Ledger-Geräts geeignet ist.
Wir sind stolz darauf, einen neuen Schritt in der Beschleunigung des Open-Sourcing unserer Roadmap für die Verifizierung zu erreichen. Kompromisslose Sicherheit und Selbstverwahrung werden immer im Mittelpunkt dessen stehen, was wir bei Ledger entwickeln. Sie können unsere Open-Sourcing-Roadmap hier einsehen, und unser nächster Schritt wird die Freigabe des Quellcodes in diesem Sommer sein – halten Sie dann Ausschau danach!
[Updated Open Source Roadmap](https://preview.redd.it/3hc11lkg2d7b1.png?width=1400&format=png&auto=webp&s=0078b616d8fac5dbaa9b4f07045841d3753dd2a2)
**Wir möchten von Ihnen hören. Bitte teilen Sie uns Ihre Fragen und Ihr Feedback zu dem nachstehenden Weißbuch mit.**
-
-
-
Just allow us to select the firmware we want. I would like to use a firmware without the backdoor. Unfortunately, as long as the Recover option is on the device, a smarter hacker will come along and exploit the backdoor – whether it be the US government giving Ledger instructions or some random hacker.
You should make 2 firmwares available. One with, one without Recover. People should be able to choose, not have the backdoor forced on them. It was never part of the deal when we gave you our money.
I still haven’t moved out of Ledger, but I definitely will if this is going to be forced on me. If you want to force a backdoor onto me, I’m out. If I want to “recover”, I’ll use Binance. That’s way more safer than Ledger, and my funds are insured with them. I’m sure Ledger doesn’t have the capability to cover people’s losses.
Listen to your customers. The feedback was clear from the first day you decided to release the backdoor.
-
Ledger needs to respect the millions of rugpulled customers who bought their device with no NSA/CIA/FBI/IRS confiscation backdoor.
Console makers for decades have blown efuses to close firmware exploits and hardware wallets all have high watermark firmware versions.
Keystone ships with multicoin firmware, with a separate Bitcoin only firmware that once flashed prevents reflashing back to multicoin firmware.
Bitbox02 sell a Bitcoin only model that cannot be converted to multicoin/UTF TOTP edition.
Ledger should release a separate high watermark efuse blowing no-recover-firmware fork that can Never be flashed back to a recover-service-firmware fork.
-
-
-
-
-
-
-
This is still really bad, the reality is that every time from now on that someone posts a standard “My Ledger got Hacked and I lost everything” thread, if they are a ‘Ledger Recover’ user, there will be no way to know for sure that the the leak didn’t happen on Ledger’s side… (And no real way that Ledger could identify if there was some internal issue and leaks were happening on their end either)
There really needs to be a different firmware that has a totally different onboarding workflow and a totally different backup model in terms of who holds what… (Or at the very least, a model that doesn’t have this feature at all)
-
-
-
-
So you’re going for the recovery thing is confirmed, from who will you ask for these fees when there is nobody left? It isn’t rocket science to understand how much damage this whole thing has done to ledger, seriously there’s something going on; else why would a company dig it’s own grave, you guy have some very deep reason to let go of entire community but still roll out recovery. It’s interesting and scary at the same time.
-
-
-
-
-
-
Looks to be a 34-page technical white paper. The entire security of all assets is relying on Identity Verification not being vulnerable. There’s 2 pages on it, with the helpful and informative title “A Note on Identity Verification”. Even if the other 32 pages can be proven to be cryptographically secure – and let’s assume they are – this entire effort still misses the point. Explain the expected failure rates of the Identity Verification, and how those failures will be dealt with by Ledger and/or the providers. $50K insurance isn’t nearly enough – unless the market for this is expected to be people who simultaneously will throw hundreds of dollars a year away on nothing, while also having less than $50K in crypto to protect. That seems like a Venn diagram with two circles on the opposite side of the room.
-
-
Serious thoughts and questions…
If there’s successful attack on this new feature, it probably won’t be a flaw in the crypto systems and protocols, which the document focuses very heavily on.
More likely, it will be a flaw in the implementation, a weak link between the various components, or an attack at the fringes, or subversion of the user’s host, Ledger Live and/or the orchestration component. Or an attack on one of cloud hosted components.
Where does the “Orchestrator” live, is this part of Ledger Live, running on a customers PC or iOS device, or a cloud hosted service?
Where does “Stargate” live? It is a service in AWS, correct? How is that hosted and secured?
How do backups traverse from the orchestrator to the backup providers and then to the HSM?
What if a recipient is being impersonated by an attacker that has stolen the static private key?
What happens if the static private keys are extracted? We know it is very hard to extract a users seed phrase from the hardware device, and an attacker’s reward for doing so is the crypto secured by a single device. But in the case of a static private key common to all devices and/or HSM’s, it seems like the potential impact is huge. Would that be ‘game over’ for Ledger/Recover?
How do we reconcile Ledger’s apparent stance that this system is virtually impervious to attack with the fact that insurance is limited to loses of only $50K. Why not $500K or $5M?
Who has less than $50K at stake, isn’t able to self-custody and yet is willing to pay $10/mo? It seems like such a small target audience.
Are there any other larger motivations for providing this service beyond users who struggle to self-custody?
Thank you in advance for any responses.
-
This confirms what was thought to be the case: The seed is encrypted with a fixed key on the ledger device, which exists on every ledger. That’s also how restoration to any ledger device works.
Which means this encryption is meaningless. It adds zero to security. If someone gets 2 of 3 shards, then that someone can recover the seed, as long as they have a ledger device. Whether those shards are part of an encrypted seed or not just adds a little bit of inconvenience to the attacker: They need a ledger to recombine, can’t do it outside a ledger.
You’re relying 100% on the secure storage of the shards by the providers. “The seed gets encrypted before sharding it” is so much marketing speak that adds nothing to that secure storage.
Terrible, truly terrible idea. And the reason that the community dubbed “Ledger Recover” as “Ledger Trust Me Bro” instead.
-
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
