Da ja gerade viel über die Hardware Wallets diskutiert wird, hier mal eine neue Nachricht. Allerdings brauchten die Hacker in dem Fall physischen Zugriff auf die HW.
In den letzten Jahren gab es mehrere erfolgreiche Hacks verschiedener Trezor-Modelle; allerdings immer mit notwendigem physischen Zugriff auf das Gerät. Deshalb ja auch die regelmäßige Empfehlung, eine Hardware Wallet mit Secure Element zu verwenden.
Soweit ich weiß wird auf dem Trezor der Seed verschlüsselt auf dem Microcontroller (MCU) gespeichert, wie auch bei der Bitbox.
Der entscheidende Unterschied ist allerdings, dass die Seed-Verschlüsselung ausschließlich anhand des Gerätepassworts (PIN) durchgeführt wird und der Trezor kein Secure Element hat. Alle weiteren Schlüssel würden wenig Sinn machen, wenn diese ebenfalls auf der angreifbaren MCU gespeichert wären.
Bei den Hacks wurde also zuerst mit speziellen Techniken der Flash-Speicher der Trezor MCU ausgelesen, was sicher nicht trivial ist. Anschließend konnte man den PIN relativ einfach brute-forcen, da die meisten Nutzer keine langen PINs verwenden.
Ein sicherer Schutz dagegen ist also entweder eine sehr lange PIN, da man nur Ziffern verwenden kann. Oder eine optionale Passphrase (BIP39).
Lustigerweise empfiehlt Trezor selbst für die PIN nur eine geringe Mindestlänge von 6 Ziffern, was in dieser Hinsicht nutzlos ist. Ohne Passphrase würde ich bei der PIN mindestens 30 Ziffern verwenden.
Bei der Bitbox sieht das ganze anders aus, wie auf der Shiftcryto Website oder hier von Stadicus beschrieben (ich wiederhole mich 
).
Der Seed ist ebenfalls verschlüsselt im Flash-Speicher der MCU gesichert, der potentiell ausgelesen werden kann. Um den Seed zu entschlüsseln, sind aber drei verschiedene Schlüssel notwendig.
- Gerätepasswort → könnte gebrute-forced werden, falls zu kurz
- Salt auf der MCU → könnte mit ähnlichen Techniken extrahiert werden wie beim Trezor
- Zufälliger Schlüssel → ist auf dem Secure Element gespeicht
Da bei jedem Seed-Entschlüsselungs-Versuch auch der Schlüssel des Secure Elements benötigt wird, kann man das Gerätepasswort also nicht einfach brute-forcen.
Erstens werden die Entsperrversuche verlangsamt. Zweitens blockiert sich die Bitbox spätestens nach ca. 730.000 Versuchen automatisch, wobei sich dieser Zähler ebenfalls auf dem Secure Element befindet.
Das Secure Element ist außerdem besser als eine MCU gegen physischen Zugriff gesichert. Das ist ja gerade der Sinn der Sache. Man kann den Schlüssel also sehr wahrscheinlich nicht mit den gleichen Techniken auslesen.
Beim Ledger wiederum ist der Seed gleich selbst auf dem Secure Element gespeichert.
In beiden Fällen also, bei Ledger und Bitbox, muss ich ein gewisses Vertrauen in die physische Sicherheit des Secure Elements haben. Sollte man das bei direktem Zugriff irgendwann doch knacken können, hätte man den Seed entweder direkt, oder man müsste „nur“ noch das Gerätepasswort brute-forcen.
Ein langes Gerätepasswort oder eine (nicht gespeicherte) optionale Passphrase würden allerdings auch bei Ledger und Bitbox dagegen schützen.
7 „Gefällt mir“
Auch beim Trezor One schon passiert:
1 „Gefällt mir“
Nicht mit den gleichen Techniken aber vielleicht mit anderen. Jedenfalls wird aktiv daran geforscht solche Chips zu knacken.
Analyse des Secure Chips ATECC508A, dem Vorgänge von ATECC608A, der in der Bitbox verwendet wird wurde:
Analyse von ATECC608A:
Im Jahr 2020 haben wir den Microchip ATECC508A Secure Memory Schaltkreis evaluiert. Wir fanden eine Schwachstelle, die es einem Angreifer ermöglichte, einen geheimen Datenslot mittels Single Laser Fault Injection auszulesen. Dies wurde auf der Black Hat USA vorgestellt. In der Folge wurde der Produktlebenszyklus dieses Chips veraltet, und der Schaltkreis wurde durch den ATECC608A ersetzt, der angeblich sicherer ist. Wir stellen einen neuen Angriff vor, der es ermöglicht, denselben geheimen Datenslot für diesen neuen Chip abzurufen. Diesmal verwenden wir eine doppelte Laser-Fehlerinjektion, um zwei Sicherheitstests während einer einzigen Befehlsausführung zu umgehen. Die Methode unterscheidet sich von unserer früheren Arbeit und der Angriffspfad ist komplexer.
1 „Gefällt mir“
Kleine Ergänzung: die BitBox02 verwendet schon länger den ATECC608B-Chip, der gegen potentielle Attacken wie im zweiten Video gezeigt geschützt ist.
7 „Gefällt mir“
Klar, das muss denke ich auch so sein, um bösartigen Angreifern zuvor zu kommen und die Teile verbessern zu können. Auf jeden Fall sehr interessante Videos!
Ehrlich gesagt wundert es mich, dass man tatsächlich selbst bei aktuellen Secure Elements noch solche Side Channel Attacks über Analyse von Power Traces und Fault Injection durchführen kann.
Selbst mir als Laie fallen direkt einige Möglichkeiten ein, wie man das verhindern könnte, und tatsächlich stehen diese auch im Wikipedia Artikel zu Side-Channel-Attacks. Zusätzliche zufällige und unnötige Operationen, Glättungs-Filter und Rauschgeneratoren sollten doch eigentlich ein einfaches Auswerten der Stromaufnahme verhindern können.
Mit der Coldcard kenne ich mich nicht wirklich aus. Aber offenbar wird der Seed nicht auf Basis des Gerätepassworts verschlüsselt? Ebenso bei Ledger. Ich verstehe nicht, warum das nicht Standard ist, da man bei gutem Passwort solche Attacken komplett nutzlos macht. Im besten Fall könnte man korrektes Kauderwelsch auslesen, was man nicht brute-forcen kann.
Mir persönlich ist durch die aktuellen Diskussionen auf jeden Fall nochmal erstens die wirklich sehr durchdachte Architektur der Bitbox. sowie zweitens die Bedeutung eines guten Gerätepassworts oder einer Passphrase klar worden (falls man kein Multisig macht).
Alternativ eine Wallet, die den Seed nicht speichert, wobei ich auch nicht auf die ganzen anderen Vorteile des Bitbox Designs verzichten wollte. Mit dem Seedsigner kann ich mich noch nicht zu 100% anfreunden, auch wenn es ein tolles Projekt ist.
3 „Gefällt mir“
Falls sich einer der Mitlesenden wundert, was es denn mit diesem brute-forcen auf sich hat:
Hier könnt ihr mal testen, ab welcher Länge und mit welcher Konstellation aus Buchstaben, Ziffern und Sonderzeichen ein Passwort sicher wird:
(ich würde dort nicht mein tatsächliches Passwort testen!)
Check dein Passwort
Allgemein wird ein Passwort bestehend aus Groß- und Kleinbuchstaben, Ziffern und Sonderzeichen mit einer Länge von 10 Zeichen empfohlen!
2 „Gefällt mir“
Danke für diese wertvolle Info. Ich habe meinen Beitrag angepasst. Das ganze unterstreicht im Grunde nur das Sicherheit keine Konstante ist. Was heute als ausreichend sicher gilt kann morgen wieder anders sein.
Was den ATECC608B angeht möchte ich daher nur auf folgenden Screenshot aus dem zweiten Video hinweisen 
2 „Gefällt mir“
Bevor aber jemand etwas möglicherweise missversteht: Selbst wenn im ATECC608B Chip eine Schwachstelle gefunden wird, wäre das kein Weltuntergang und die HW bleibt sicher. Bevor man selbst von so einer Problematik betroffen sein könnte, muss man sein HW an einen Dieb mit viel Expertise und Geld verlieren. Was bei den meisten wohl keine akute Gefahr darstellen dürfte. Und die Hersteller reagieren darauf und aktualisieren die Chips/Geräte. Wer nicht damit leben will kann sich dann ein aktualisiertes Neugerät kaufen.
2 „Gefällt mir“
Widerspricht sich das letzte Zitat nicht?
Beim Ledger ist der Seed auf dem Secure Element gespeichert und somit gegen physische Angriffe besser geschützt.
Bei der Bitbox und bem Trezor liegen laut dem ersten Zitat der Seed auf dem Mikrocontroller, bei der Bitbox verschlüsselt.
Oder liegt der Seed bei der Bitbox auf dem Scecure-Element und dem Mikrocontroller?
Liegt der Seed beim Ledger auch verschlüsselt im Secure Element? Mit diesem neuen Feaure soll er ja auch verschlüsselt aufgeteilt werden.
Soweit ich weiß (und da können @Joko_BitBox oder @Stadicus ) mich gerne korrigieren, liegt der Seed bei der Bitbox02 eigentlich nirgendwo, sondern wird jedesmal anhand der bekannten Quellen neu abgeleitet.
2 „Gefällt mir“
Im Blog steht dass der Seed („wallet seed“) verschlüsselt im Mikrocontroller gespeichert und anhand verschiedener Schlüssel entschlüsselt werden kann:
Das der Seed erst bei der Entsperrung des Gerätes abgeleitet wird habe ich auch gehört. Wird die Entschlüsselung des Seed als Ableitung des Seed interpretiert? Weil im Blog Artikel steht das die privaten Schlüssel vom wallet seed abgeleitet werden und nicht der seed selbst.
1 „Gefällt mir“
Ich glaube das Wording ist hier ein bisschen missverständlich. 
Die Entropie, oder äquivalent die Seedphrase, liegt verschlüsselt auf der MCU. Nach dem Entschlüsseln und nach optionaler Eingabe einer Passphrase, wird der Seed abgeleitet.
Da wie gesagt verschlüsselt gespeichert wird, kann man auch sagen, der Seed bzw. Entropie sind „gar nicht“ gespeichert.
„Seed“, „Seedphrase“ und „Entropie“ muss man bei dieser Diskussion nicht unbedingt unterscheiden.
4 „Gefällt mir“
Beides ist richtig, da nicht eindeutig zwischen Mnemonic und dem BIP-39 Seed unterschieden wird.
Die Mnemonic bzw. die Entropie muss natürlich persistent (aber verschlüsselt) gespeichert werden, ansonsten müsste man die BitBox02 bei jedem Verbinden neu einrichten. Theoretisch könnte man die BitBox02 sogar Stateless nutzen (also als reines Signiergerät ähnlich wie einen Seedsigner), auch wenn sie dafür natürlich eigentlich nicht konzipiert ist.
Der eigentliche Seed (BIP-39) wird jedes Mal erst beim Entsperren komplett neu abgeleitet, das ist alleine wegen der optionalen Passphrase, die schließlich nach dem Ausstecken nichts mehr auf dem Gerät verloren hat, sowieso notwendig.
Deswegen kann man halt sagen, dass der Seed „nirgendwo“ auf der BitBox02 gespeichert wird. Das ergibt aber als Argument nur Sinn, wenn man auch wirklich eine optionale Passphrase nutzt, ansonsten ist die Ableitung ja eindeutig.
Edit: @skyrmion war schneller…
4 „Gefällt mir“
Also wird quasi der Zustand der Entropie bei der Schlüsselerstellung eingefroren.
Was ist, wenn ich einen Seed von einer anderen Wallet verwende?
Es wird halt deine Mnemonic verschlüsselt gespeichert. Das ist das Ergebnis aus dem „Einrichten der Wallet“, da ist also u.a. Zufall aus den verschiedenen Quellen drin.
Was du jetzt mit „Zustand“ oder „einfrieren“ meinst ist mir nicht ganz klar.
Was soll dann sein? Dann wird halt diese andere Mnemonic gespeichert.
Vielleicht fürs Verständnis: Die Mnemonic (also die 24 Wörter) entspricht sozusagen direkt der Entropie, es ist nur eine andere Codierung.
1 „Gefällt mir“
Die Entropie entsteht ja unter Anderem aus einem physikalischen Zustand, aus dem dann Seed oder Mnemonic abgeleitet werden. Dieser Zustand ist doch immer anders, weshalb ich ja auch immer neue 24 Wörter bekomme. Deswegen müsste doch dieser Zustand gespeichert werden.
Die Entropie ist die Mnemonic. Und die wird gespeichert.
2 „Gefällt mir“