Open-Source-Firmware + Sicherheitselement-Chiplösung
- Dieses Thema hat 2 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 10 Monaten, 1 Woche von
.
-
Beiträge
-
-
Wie wir bereits wissen, gibt es kein Sicherheitselement mit Open-Source-Firmware. Ich frage mich jedoch, warum Ledger das Problem nicht auf bitbox02-Art gelöst hat? In wenigen Worten: Sie haben ein quellennahes Sicherheitselement, aber sie speichern darin keine Seeds/Schlüssel. Das Sicherheitselement speichert stattdessen den Schlüssel, der für die Entschlüsselung der Seeds benötigt wird. Die Entschlüsselung des Saatguts erfolgt in einer Open-Source-Software. Wenn also jemand physischen Zugang zu Ihrem Gerät hat, kann er Ihr Seed nicht bekommen, weil er den Schlüssel für die Entschlüsselung des Seeds nicht vom Sicherheitselement bekommen kann. Das Sicherheitselement hat keinen Zugang zum Seed. Und alle Operationen mit dem Seed können aufgrund der offenen Quelle überprüft werden. Ausführliche Beschreibung hier: [https://shiftcrypto.ch/blog/best-of-both-worlds-using-a-secure-chip-with-open-source-firmware/](https://shiftcrypto.ch/blog/best-of-both-worlds-using-a-secure-chip-with-open-source-firmware/)
Kennt jemand irgendwelche Nachteile dieser Lösung? Und eine wichtige Frage für mich ist, warum Ledger damals nicht diesen Weg gewählt hat?
-
As with Ledger, firmware can always access your private keys.
> [The firmware on your hardware wallet has full access to your private keys and could do all sorts of malicious things.](https://shiftcrypto.support/help/en-us/30-security/130-can-a-hardware-wallet-be-hacked)
This is true for all hardware wallets.
As for why they didn’t skin the cat this way instead of that way – they chose to go closed source and once that decision was made there was no need to have the private key not live on the secure element.
That is a novel method of keeping things fairly open source though so credit where due.
-
What does this change in terms of security threat model? Either a secure element chip has a backdoor allowing “non-secure” Apps/OS to interact with it to extract its secret, or it has no such backdoors.
There is no difference in the kind of a secret it stores, whether it is the seed (master key), derived private keys, or encryption key to decrypt (private keys) – there is no practical difference in risk model.
-
- Du musst angemeldet sein, um auf dieses Thema antworten zu können.
