Höre ich gerade, ist wirklich gut !
Wenn ihr eine bessere Vorstellung davon bekommen wollt, was man unter physischem Zugriff verstehen kann, empfehle ich euch den Blog von Mikhail Svarichevsky. Er hat viele schöne Bilder davon 
https://zeptobars.com/en/read/how-to-open-microchip-asic-what-inside
Wenn man ein Chip zerstörungsfrei öffnet ist es auch möglich den Speicher und somit die privaten Schlüssel auszulesen. Das ganze wird schwieriger wenn die Transistoren nur ein paar Nanometer groß sind (komplexe und teure Herstellungsverfahren) und die schützenden Schichten um den Chip herum Schutzmechanismen haben die ein zerstörungsfreies öffnen verhindern sollen. Während normale Mikrocontroller soweit ich weiß keine bis wenige Schutzmaßnahmen haben, sind Secure Chips genau gegen solche Zugriffe gehärtet.
3 „Gefällt mir“
Ja, das kann man.
STMicroelectronics ist da sehr gut dokumentiert.
Hiermit kann man das schließlich testen.
Microchip hat meines Erachtens da auch ein Online-Tool für. Ich kann das die Tage nochmal suchen. Finde es gerade nicht.
1 „Gefällt mir“
Ich habe diesen Thread mit Staunen gelesen. Ich finde es klasse, dass hier so viele Nuancen der Entropie-Generierung kritisch diskutiert werden. Es ist wohl illusorisch, hier mit einem Post alle Fragen zu beantworten, daher versuche ich die Diskussion erst mal einzuordnen und zu betonen, dass man sowieso nie einer einzelnen Komponente vertrauen sollte.
Es ist wichtig, die Gesamtsicherheit eines Systems wie einer Hardware-Wallet zu betrachten. Natürlich ist diese die Summe der Sicherheit der einzelnen Komponenten, aber auch davon abhängig, mit welcher Architektur die einzelnen Bauteile kombiniert werden. Und man darf sich nicht auf einen Einzelaspekt einschiessen, und dann alles andere aussen vor lassen.
Eine Vertrauensminimierung ist nur mit „Open Source“ möglich, was die BitBox02 zu 100% ist. Einzelne Bauteile enthalten eigene Firmware, welche nicht open-source ist. Das gilt für alle bekannten Secure Chips, aber auch für MicroSD-Karten, Mikrocontroller, Kameramodule, Bluetooth-Chips und vieles mehr. Wenn all diese quelloffen sein müssten, gäbe es weltweit keine einzige Open Source-Hardware Wallet. Für die Systemsicherheit ist es wichtig, diese Komponenten innerhalb der Sicherheits-Architektur mit Open-Source-Code so einzubinden, dass diese das Gesamtsystem nicht negativ beeinflussen können. Man vertraut diesen Bauteilen also schlichtweg nicht. Wie wird das in der BitBox02 umgesetzt haben, habe ich hier dokumentiert:
In diesem Thread geht’s ja primär um die Entropie, also wie der Seed mit maximaler Zufälligkeit generiert werden kann. Hier ist auch die Architektur und der Open-Source-Code am wichtigsten:
- Die BitBox02 nutzt fünf unabhängige Entropie-Quellen und kombiniert die im offenen Code für jeden nachprüfbar, so dass jede Quelle die Gesamtentropie nur erhöhen, nicht aber reduzieren kann.
- Die fünf Quellen sind:
- Mikrocontroller
- Secure Chip
- Zufallswert aus der Produktion
- Host-Computer / Smartphone
- Benutzerpasswort
Selbst wenn eine oder mehrere Komponenten komprimittiert sein sollten, ist die Firmware der BitBox02 überprüfbar so entwickelt, dass diese Quelle die Entropie der restlichen Quellen nicht negativ beeinflussen kann. Da nicht mal alle Entropiequellen auf der BitBox02 sind, wird das benötige Vertrauen in uns und die Bauteilhersteller maximal reduziert.
Weiter oben wurde auf einen Standard verwiesen, der einen möglicherweise von der NSA mit einer Backdoor versehenen Algorithmus beinhaltet. Ob das stimmt, oder nicht, kann ich nicht abschliessend beurteilen. Auf jeden Fall wurde dieser „shady“ Algorithmus schon 2015 mit der „Revision 1“ von NIST SP 800-90 entfernt. Der Secure Chip der BitBox02 erfüllt die Vorgaben dieser „Revision 1“ und verwendet diesen Algorithmus nicht.
Können wir aber ausschliessen, dass in irgendeiner Komponente eine Backdoor implementiert ist? Natürlich nicht, das kann kein Hersteller. Da hilft auch keine offizielle Zertifizierung oder irgendwelche Audits, da solche Backdoors extrem subtil sein können.
Daher ist es umso wichtiger, mehrere gute Zufallsquellen so zu kombinieren, dass es keinen „Single Point of Failure“ gibt, und man keiner dieser Komponenten vertraut. Das geht mit „open source“ und „closed source“, aber nur mit 100% Open-Source-Code ist dies öffentlich überprüfbar und macht nicht den Code-Autor zur neuen Instanz, der ich vertrauen muss.
Falls dir konkrete Fragen unter den Nägeln brennen: nur her damit. Ich kann wahrscheinlich nicht alle direkt beantworten, aber ich kann immerhin intern die Experten löchern, welche tatsächlich Kryptografie oder Mathematik studiert haben.
11 „Gefällt mir“
Auf der verlinkten Seite heißt es über die Kombination von MCU und Secure Chip unter anderem:
- Die sichere Speicherung eines eindeutigen Zertifikatsschlüssels („Attestation key“) stellt sicher, dass nur offiziell signierte Firmware verwendet werden kann.
Heißt das, dass wenn jemand versucht, eine manipulierte Firmware zu installieren, dies durch den Attestation Key im Secure Chip abgelehnt wird? Das heißt, der Angreifer bräuchte zwingend die Schlüssel, mit denen ihr eure offiziellen Firmware-Updates signiert?
Es wurde diskuttiert, dass alle Sicherheitskonzepte versagen würden, sobald es einem Angreifer gelänge, seine eigene Firmware auf dem MCU zu installieren oder dem Kunden als Firmware Update unterzuschieben.
3 „Gefällt mir“
Die Revision 1 gibt es nur bei NIST 800-90A.
This Recommendation specifies mechanisms for the generation of random bits using deterministic methods. The methods provided are based on either hash functions or block cipher algorithms.
Übersetzt:
Diese Empfehlung legt Mechanismen für die Erzeugung von zufälligen Bits mit deterministischen Methoden fest. Die bereitgestellten Methoden basieren entweder auf Hash-Funktionen oder Block-Chiffrieralgorithmen.
Demnach würde von der Bitbox gar keine physikalische Entropiequelle verwendet. Wenn die Entropie dann ausschließlich von der Bitbox Open-Source bestimmt wird, ist das Verfahren doch schlechter als ein physikalisches oder ein physikalisches mit kryptografischer Nachbearbeitung.
Der Secure-Chip könnte allerdings NIST 800-90A/B/C. Das würde einer physikalischen Entropie mit kryptografischer Nachbearbeitung entsprechen.
Oder wird die Entropie doch auch physikalisch erstellt?
Auf eurer Homepage ist die Reihenfolge anders.
Es gibt immer/meist eine beste Entropie-Quelle. Ich gehe mal davon aus, dass die der Secure-Chip wie auf der Homepage aufgezählt ist.
Wenn die beste Quelle Wort 1 24x wählt, nützt das doch auch nicht mehr viel. Softwarebasierte Entropiequellen sind doch eh nicht so gut.
Warum habt ihr euch damals für Microchip, einem amerikanischen Hersteller entschieden, wenn ihr doch einen fetteren in der Schweiz vor der Tür habt?
Interessantes Zitat dazu:
- Erst kurz zuvor hatte der Ledger-CEO Pascal Gauthier in einem Podcast bestätigt, dass die Seed Phrasen der “Ledger Recover”-Nutzer theoretisch an die Regierung übergeben werden könnten.
- Das sei möglich, wenn entsprechende Investoren mit “schwerwiegenden Taten” oder Drogen- und Terrorismusverbrechen im Zusammenhang stehen. “Es stimmt nicht, dass der Durchschnittsmensch jeden Tag vorgeladen wird”, beschwichtigt Gauthier.
1 „Gefällt mir“
Wie du ja auch schreibst erfüllt der Secure Chip die SP 800-90A/B/C, wobei sich „A“ auf die „Revision 1“ bezieht. Damit ist der „Dual_EC_DRBG“ Algorithmus raus.
Natürlich verwendet die BitBox02 die vom Secure Chip bereitgestellten True Random Number Generator (TRNG). Dieser setzt sich aus einer Noise-Quelle und einem deterministischen RNG zusammen:
The ATECC608B can generate high-quality random numbers using its internal random number generator. This sophisticated function includes runtime health testing designed to ensure that the values generated from the internal noise source contain sufficient entropy at the time of use. The random number generator is designed to meet the requirements documented in the NIST 800-90A, 800-90B and 800-90C documents.
(siehe Seite 6 im Datasheet)
Im Falle der BitBox02 gibt es zwei „beste“ Entropiequellen, da die MCU auch einen True RNG enthält. Und das heisst ja nicht, dass die anderen Quellen schlecht wären, sonst wäre die gesamte, von uns allen täglich genutzte softwarebasierte Kryptografie nutzlos.
1 „Gefällt mir“
Die Echtheitsprüfung („Attestation“) ist ein kryptografisches Challenge-/Response-Protokoll, welches nur eine echte BitBox02 unter Einbezug eines auf dem Secure Chip gespeicherten Geheimnis korrekt beantworten kann. Dies ist nicht daselbe wie die Prüfung der Firmware-Signatur.
Ich frage aber intern erstmal nach, um die genauen Nuancen noch besser zu verstehen und nichts falsches zu behaupten.
4 „Gefällt mir“
Vielen Dank für dein kritisches Hinterfragen unseres Blog-Artikels, @DeTec. Du bist tatsächlich auf einen Fehler gestossen, der uns bislang nicht aufgefallen ist!
Der Secure Chip und Attestation Check haben nichts mit dem Boot-Prozess und der signierter Firmware zu tun. Der Bootloader prüft die Signaturen, die zusammen mit der Firmware geflashed werden. Secure Chip und Attestation Check kommen erst in der Firmware ins Spiel, nach dem diese installiert und gebootet wurde.
Ich habe diese Aussage im Artikel wie folgt angepasst:
- Die sichere Speicherung eines eindeutigen Zertifikatsschlüssels („Attestation key“) ermöglicht eine kryptografische Echtheitsprüfung der BitBox02 durch die BitBoxApp und andere Software-Wallets.
Wenn ein Angreifer es schafft, gefälschte Firmware auf eine echte BitBox zu laden, dann wäre das sehr schlecht. Die BitBox02 ist durch den komplett schreibgeschützten Bootloader aber so designed, dass dies nicht möglich ist.
Bei einer gefälschten BitBox02 würde der Attestation-Check fehlschlagen und du siehst in der BitBoxApp einen grossen roten Warnhinweis mit der Bitte, umgehend unseren Support zu kontaktieren.
7 „Gefällt mir“
Am besten du würfelst dir deinen Seed selbst
sonst musst du dich immer darauf verlassen, dass Hardware, Software und Lieferweg in Ordnung waren.
12 Seedwörter kannst du komplett mit Würfel und Papier erstellen. Im 12 Wort befinden sich 4 Bit Prüfsumme, die du durch Ausprobieren finden kannst.
Für 24 Seedwörter hast du 8 Bit Prüfsumme. Das musst du dir berechnen lassen z.B. durch Tails.
Das halte ich zumindest im Kontext von Hardware Wallets für relativ gefährlich und nicht zu empfehlen! Warum relativ?
Mit Tails verwendest du trotzdem einen PC, der normalerweise dauerhaft, oder mindestens nachher wieder ans Netz geht.
Anstatt also z.B. einer Software-Wallet und einem sauberen PC zu vertrauen, vertraust du also nur Tails OS (Entwickler und sicherer Download). In meinen Augen tatsächlich ein Sicherheitsgewinn.
Wenn du allerdings die 24 Wörter anschließend auf einer Hardware-Wallet verwenden möchtest, dann musst du die Sicherheit eines Betriebssystems (Tails) auf einem PC mit anschließendem Netz-Zugang mit der Sicherheit einer Hardware-Wallet vergleichen.
Im Kontext von Hardware-Wallets diskutieren wir in den letzten Wochen über physische Angriffe auf MCUs und sogar Secure Elements, über das Angreifen verschlüsselter Passwörter/Seeds, über Schwachstellen von TRNGs und über mögliche Architekturen, bei denen man keinem einzelnen Hersteller mehr vertrauen muss.
Das sind alles Themen, die sich auf einem Sicherheits-Level bewegen, was weit über dem möglichen Sicherheits-Level eines normalen Anwender-PCs mit einem Betriebssystem wie Tails liegt.
Natürlich ist Tails ohne persistenten Speicher im Vergleich zu üblichen Betriebssystemen recht sicher. Aber lange nicht vergleichbar mit einer-Hardware Wallet. Man zieht also durch den vorgeschlagenen Prozess das Sicherheits-Level der Wallet unnötig herunter auf das der PC Lösung mit Tails.
5 „Gefällt mir“
Gefahren:
- Schlüssel nicht zufällig erstellt.
- Schlüssel wird versendet.
Optionen:
- Hardware-Wallet erstellt mir meinen privaten Schlüssel
- Ich würfle mir 12 Seedwörter und probiere beim 12. Wort solange, bis ich ein passendes Wort gefunden habe
- Ich würfle 24 Wörter und nutze Tails für das 24. Wort
- Ich prüfe den Code der Hardware-Wallet z.B. Verifying Dice Roll Math – COLDCARD User Docs und nutze Würfel + HW-Wallet
Eine HW-Wallet lässt sich sicherer bauen als ein normaler PC. Dafür sind die Angriffe auf HW-Wallets spezifischer.
Wo ist die Gefahr bei Tails? Bei der Schlüsselerstellung muss ich Tails nicht vertrauen. Die Entropie stammt aus Würfeln. Tail läuft im Arbeitsspeicher. Das Risiko wäre, dass Tails Informationen heimlich auf einem Dauerhaften Speicher auf dem Rechner ablegt und bei Neustart von einem anderen Betriebssystem aus verschickt. Welche Gefahr sieht ihr denn bei Tails?
Wo ist die Gefahr bei einer HW-Wallet? Die größte Gefahr ist eine Manipulation auf dem Weg zu dir, so dass der Schlüssel nicht zufällig erstellt wird, oder - wie im Fall von Ledger - später verschickt wird. Die Erstellung des privaten Schlüssels innerhalb der HW-Wallet ist für den Leihen eine Black-box.
Beste Option meiner Meinung:
Schritt 1: HW-Wallet firmware aktualisieren
Schritt 2: Prüfen ob HW-Wallet und Software-Wallet auf Basis der gleichen Seed Wörter zu den gleichen Receive-Adressen kommt.
Schritt 3: 12 Seed Wörter würfeln und bei der HW-Wallet das passende 12. Wort druchprobieren
Schritt 4: lange BIP 39 Passphrase nutzen
Bei open sourced HW-Wallets, mit eigener Verifizierung ist das Risiko vermutlich niedriger als bei Tails.
Eine Closed Sourced HW-Wallet zu nutzen, das gibt am Ende nur Ärger. Eines Tages wird auf die Mitarbeiter des Unternehmens Druck ausgeübt und die Kunden werden verraten. Hier würde ich das Risiko bei Tails niedriger einschätzten.
Ich würde Tails für solche Dinge nur mit einem Air gapped PC machen. Einfach bri nem alten Laptop festplatte und Bluetooth/wifi chip ausbauen und nie wieder ans Netz hängen.
Alternativ kannst du auch SeedSigner nutzen. Das ist dann Quasi Tails auf nem Air gapped PC allerdings ein kleiner Rasperry PI zero mit einer speziellen open source HW software die auch nur im ram ausgeführt wird.
1 „Gefällt mir“
Also zuerst einmal bin ich bzgl. Würfeln an sich voll bei dir. Damit schaltet man einige Angriffsvektoren aus und macht sich unabhängig von Zufallsgeneratoren.
Die Gefahren beim Vergleich von Hardware-Wallet (HWW) und PC + Tails sehe ich aber z.B. eher hier:
(„Gefahren“ ist hier im Kontext gemeint. Natürlich ist Tails wesentlich sicherer als ein länger genutztes Windows.)
-
Die Codebasis ist bei der HWW möglichst schlank und einfach. Tails bzw. Linux hingegen ist ein Betriebssystem mit riesiger und komplexer Codebasis.
Bei einem Betriebssystem wird sicher nicht bei jeder Änderung so genau hingesehen. Erstens gibt es ständig zig Änderungen und zweitens gibt es sehr viele spezielle Bereiche, in denen sich auch nicht alle Entwickler gut auskennen. Wie oft gibt es denn Bugs in Betriebssystemen im Vergleich zu Bugs in einer HWW Software?
Ich persönlich kann mit meinen mittleren bis guten Programmierkenntnissen den Code einer HWW einigermaßen nachvollziehen. Beim Betriebssystem habe ich gar keine Chance mich überall auszukennen oder einzuarbeiten. Von enthaltenen Programmen von Drittanbietern oder evtl. proprietären closed-source Anteilen ganz zu schweigen. -
Die Hardware einer HWW ist im Vergleich ebenfalls relativ einfach und sogar gegenüber physischen Angriffen geschützt.
-
Ein PC hat wesentlich mehr Schnittstellen, die angreifbar sind. Relevant sind hier z.B. Ethernet, Wlan und Bluetooth. Falls Tails mal aus Versehen oder absichtlich doch Spuren auf dem PC hinterlässt (siehe die anderen genannten Argumente) , und der PC nachher wieder am Netz ist, ist das tödlich. Weitere Gefahren kommen hinzu, falls man während der Nutzung online ist.
-
Die HWW Hardware ist besser ggü. Supply Chain Attacks geschützt, da die Bauteile überschaubar sind und bestenfalls so verbaut sind, dass man nicht manipulieren können sollte. Ein PC ist praktisch das Gegenteil, inklusive dem genutzten USB-Stick.
Dem Hersteller der HWW muss ich an der Stelle immer noch vertrauen. Aber beim PC kann ich nicht einmal einem einzelnen Hersteller vertrauen, der sich dann um die Sicherheit der Einzelteile kümmert, da sich bei PCs einfach niemand darum kümmert.
Auch eine Multisig Wallet, mit der ich Vertrauen ggü. einzelnen Herstellern weiter reduzieren kann, ist hinfällig, wenn ich den PC mit Tails für alle drei HWWs als Single Point of Failure verwende. -
Nach dem Herunterladen von Tails kann man wie bei der Bitbox überprüfen, ob die Software die richtige ist (Hashes und reproducible Build). Hierzu haben wir für die Bitbox sogar eine Anleitung hier im Forum.
Allerdings kann ich auf dem PC oder USB-Stick jederzeit beliebige Software aufspielen. Es wird nicht nur Software mit einer entsprechenden Signatur zugelassen. Auf dem PC gibt es evtl. auch Software, die während Tails mitläuft, obwohl man die HDD/SSD nicht nutzt (z.B. BIOS, Graphikkarte?).
Das sind nur ein paar übergeordnete, wenig detaillierte und vielleicht teilweise falsche Gedanken, die ich mir als Nicht-Experte dazu mache.
Das ist die Option, die ich falls möglich wählen würde. Auch die Bitbox kann einem nach Eingabe von 23 Wörtern die möglichen Varianten für das letzte Wort anzeigen.
Eigenständiges Durchprobieren ist natürlich bei 24 Wörtern brutal, aber dennoch möglich. Man muss eben aus 2048 Wörtern eines der 8 gültigen finden. So oft wird man das im Leben ja auch nicht machen.
Um die Würfelergebnisse überhaupt in Wörter umzurechnen, würde ich mir die Wortliste mit entsprechender Nummerierung/Zahlencode ausdrucken (je nach Verfahren). Somit kann auch niemand jemals digital nachverfolgen, welche Stellen in der Liste ich mir länger angesehen habe, oder welche Zahlen ich berechnet habe.
2 „Gefällt mir“
Das ist eine gute Funktion der Bitbox, sich die möglichen 24. Worte anzeigen zu lassen.
Ich habe nur Ledger und Coldcard. Bei der Coldcard lassen sich auch Würfel nutzen und der Algorithmus lässt sich stichprobenartig verifizieren. Ich denke dazu werde ich auch noch mal ein Video machen.
1 „Gefällt mir“
An der Stelle kann ich mal wieder mein Tool shillen, wobei das dafür ja eigentlich nicht gedacht ist. Aber wenn man sowieso schon Tails offen hat und bereit ist da seine Mnemonic einzutippen, dann ist das etwas bequemer als nach 8 Wörtern in 2048 manuell zu suchen… 
Was die Diskussion angeht, schließe ich mich dir da aber an und würde das von @CryptoElester beschriebene Vorgehen auch nicht empfehlen.
1 „Gefällt mir“
Die Kritik bezieht sich auf auf die Berechnung des 24. Wortes auf Tails.
Findet Ihr Probleme bei der Erstellung von 12 Seed Wörtern mit Würfel und Papier?
Das ist glaube ich auch die Methode, dich ich wählen werde.
Erlich gesagt finde ich das Würfeln problematisch.
Zumindestens das Würfeln mit W6, da es mir eine zu geringe Zufälligkeit bietet.
Aktuell ist der größte echte Würfel ein W120.
Wenn ich Würfeln würde, würde ich eher einen W20 für die ersten beiden Stellen und einen W100 für die letzten beiden Stellen wählen.
Statistik und Wahrscheinlichkeitsrechnung sind wirklich hochkomplexe Themen, die Wahl der Würfel hat auch einen Einfluß auf das Ergebnis.
Ein guter Würfel fällt zufällig. Um das zu erreichen habe ich Kasino-Würfel verwendet.
Die Anzahl der Seiten des Würfels ist eigentlich egal, solange alle Seiten mit fast gleicher Wahrscheinlichkeit fallen. In diesem Fall ist ein Würfel mit 36 Seiten (1 Wurf) genauso gut wie ein Würfel mit 6 Seiten (2 Würfe).
Ich würde aber schätzen, dass ein W120-Würfel schlechter ist als ein W6 Würfel, weil eine gleichmäßige Produktion hier schwieriger ist und die Seiten daher weniger gleich verteilt fallen.
Aber auch ein etwas schlechter Würfel lässt sich durch mehr Würfe kompensieren.