Zufälligkeit des Seed von Ledger und Bitbox

Fragen
1

Aufgrund der aktuellen Diskussionen habe ich heute Nachmittag mal was zu Zufallsgeneratoren recherchiert. Die Ergebnisse sind noch nicht vollständig, aber ich stelle sie schon mal zusammen und freue ich auf eine spannende Diskussion.

Ledger und Bitbox verwenden unterschiedliche Secure Chips.

In Ledger ist ein ST33J2M0 von STMicroelectronics.

„STMicroelectronics N.V. ist ein europäischer Halbleiterhersteller. Das Unternehmen hat seine Hauptverwaltung in Plan-les-Ouates im Kanton Genf in der Schweiz, weitere wichtige Standorte befinden sich in Frankreich und in Italien.“

In der Bitbox ist ein ATECC608B von Microchip.

„Microchip Technology Inc. ist ein amerikanischer Halbleiterhersteller aus Chandler (Arizona).“

„Zahlreiche Meldungen kritisieren Lücken, Schwächen und Manipulationen bei der Erzeugung von Zufallszahlen für kryptografische Verfahren. Eine Sammlung verschiedener Quellen finden Sie in dieser unvollständigen Sammlung von Pressemeldungen. Daher wird generell für die Generierung von kryptografisch sicheren Zufallszahlen empfohlen, keine Lösung zu verwenden, die auf der Basis von Closed-Source-Hardware aus dem nichteuropäischen Ausland arbeitet oder auf den von der Computer Security Division am NIST der USA für den praktischen Einsatz empfohlenen Zufallserzeugungen beruht.“

Beide Chips sind zertifiziert.

Der Ledger nach AIS31 PTG.2. Die Zufälligkeit wird rein physikalisch erstellt.

Die Bitbox ist nach SP 800-90A/B/C zertifiziert. Die Zufälligkeit wird durch eine Vermischung einer determistischen (gleicher Eingang bei gleichem Ausgang) und einer physikalischen erstellt.

Die Dokumente des National Institute of Standards and Technology (NIST) SP 800-90x beschreiben, wie ein True Random Number Generator (TRNG) und Deterministic Random Bit Generator (DRBG) entworfen und ausgewertet werden sollten. Die Kombination eines TRNG-konformen mit SP 800-90B und einem DRBG-konformen SP 800-90A ist in SP 800-90C beschrieben. Ein DRBG benötigt die Firmware-Nachbearbeitung der TRNG-Ausgabe.
https://microchipdeveloper.com/faq:128

In SP 800-90A ist eine Hintertür der NSA enthalten.

Eine abschließende Meinung habe ich noch nicht. Meine Recherche ist noch nicht beendet. Vielleicht klären sich ja so schon von selber noch ein paar offene Punkte.

8 „Gefällt mir“
2

Das ist vermutlich das Schlimmste, was ich überhaupt zu dem Thema heute noch hätte lesen können. Trotzdem oder gerade deswegen: Gute Arbeit.

Man muss aber auch sagen, dass in deinem verlinkten Wikipedia-Artikel folgendes steht:

„Das NIST entschied nach einer Anhörungsphase, Dual_EC_DRBG aus dem Standard zu entfernen. Am 21. April 2014 veröffentlichte das NIST einen Entwurf für eine überarbeitete Version des Standards SP 800-90A, die Dual_EC_DRBG nicht mehr enthält“

D.h. es dürfte keine Backdoor mehr enthalten sein. Trotzdem ein beunruhigender Vorgang, dass so etwas schon mal eingebaut war in dem Standard.

1 „Gefällt mir“
3

Zuerst einmal finde ich es gut, dass du mal ein paar Fakten als Diskussionsgrundlage zusammenträgst.

Ich habe mich im Detail noch nicht damit beschäftigt. Aber diese Aussage passt denke ich nicht ganz zu dem von dir verlinkten Wikipedia Artikel:

Bei Wikipedia steht:

Das NIST entschied nach einer Anhörungsphase, Dual_EC_DRBG aus dem Standard zu entfernen. Am 21. April 2014 veröffentlichte das NIST einen Entwurf für eine überarbeitete Version des Standards SP 800-90A, die Dual_EC_DRBG nicht mehr enthält.[15]

Die bekannte Lücke sollte also Geschichte sein, wenn ich das richtig verstehe.

Natürlich weiß man dann immer noch nicht, wo evtl. erneut eine gewollte oder ungewollte Backdoor enthalten ist. Aber die Mischung verschiedener Verfahren mildert dieses Risiko denke ich ausreichend ab.

In deiner Recherche tauchen auch die Shiftcrypto Aussagen zur Bitbox kaum auf; Ledger dagegen zitierst du ständig mit ihren Werbeaussagen.

Shiftcrypto schreibt:

Wallet seed generation

To add redundancy and failsafes, the BitBox02 uses five sources of randomness (aka entropy) to generate the wallet seed instead of a single source. Each source is cryptographically combined such that the overall entropy is at least as strong as the strongest of all, not the weakest of all. This mitigates against attacks even when four of the sources are compromised. The entropy sources are:

  • A true random number generator on the secure chip
  • A true random number generator on the microcontroller
  • A static random number set during factory installation and unique to each BitBox02
  • Host entropy provided by the app running on your computer, e.g. from /dev/urandom
  • A cryptographic hash of the device password

The latter two are completely independent of the BitBox02.

Nachvollziehen müsste man das, ausgehend von der Code-Stelle, die @mcwinston schon verlinkt hat:

keystore_error_t keystore_create_and_store_seed(
    const char* password,
    const uint8_t* host_entropy,
    size_t host_entropy_size)
{
    if (host_entropy_size != 16 && host_entropy_size != 32) {
        return KEYSTORE_ERR_SEED_SIZE;
    }
    if (KEYSTORE_MAX_SEED_LENGTH != RANDOM_NUM_SIZE) {
        Abort("keystore create: size mismatch");
    }
    uint8_t seed[KEYSTORE_MAX_SEED_LENGTH];
    UTIL_CLEANUP_32(seed);
    random_32_bytes(seed);

    // Mix in Host entropy.
    for (size_t i = 0; i < host_entropy_size; i++) {
        seed[i] ^= host_entropy[i];
    }

    // Mix in entropy derived from the user password.
    uint8_t password_salted_hashed[KEYSTORE_MAX_SEED_LENGTH] = {0};
    UTIL_CLEANUP_32(password_salted_hashed);
    if (!salt_hash_data(
            (const uint8_t*)password,
            strlen(password),
            "keystore_seed_generation",
            password_salted_hashed)) {
        return KEYSTORE_ERR_SALT;
    }

    for (size_t i = 0; i < host_entropy_size; i++) {
        seed[i] ^= password_salted_hashed[i];
    }
    return keystore_encrypt_and_store_seed(seed, host_entropy_size, password);
}

Hier sieht man zumindest mal die von @sutterseba erwähnten bitweisen XORs (^=) vom Seed mit Host Entropy und Hash des Passworts. Weiter könnte man sich mal die Funktionen UTIL_CLEANUP_32() und random_32_bytes() anschauen. Und man müsste (und kann) das wie gesagt alles von Anfang bis Ende nachvollziehen. Fehlt mir aber gerade die Muße.

4 „Gefällt mir“
4

Kann schon sein. Der Secure Chip ist aber aus dem NSA-Land, gleichzeitig dem Land mit der Weltleitwährung.

Hier ist noch ein interessanter Artikel dazu.
https://www.degruyter.com/document/doi/10.1515/dmvm-2014-0012/pdf

Weil hier fast jeder meinen Ledger schlecht macht und das mit der ganzen Werbung hier ist für mich total unglaubwürdig. Ich jage übrigens schon länger hier der Antwort nach, wer jetzt die besseren 24 Wörter erstellt. Die Lösung hätte ich gerne von einer dritten Quelle belegt.

Das ist genau der Punkt, an dem ich vorhin nicht abschließend weitergekommen bin. Hier auf Folie 6 steht zu AIS31 PTG.3:
„Strongest class: strong physical noise source with cryptographic postprocessing.“
Übersetzt:
„Stärkste Klasse: starke physische Geräuschquelle mit kryptographischer Nachbearbeitung.“

Der Ledger hat ja wie bereits angedeutet eine reine physikalische Zufälligkeit nach PTG.2.

Die Zufälligkeit der Bitbox wird durch eine Vermischung einer deterministischen (gleicher Eingang bei gleichem Ausgang) und einer physikalischen erstellt.

„Deterministische Zufallszahlengeneratoren erzeugen Pseudozufallszahlen.“

Entspricht das dem Verfahren nach AIS31 PTG.3?

Die weiteren Vermischungen bei der Bitbox dürften irrelevant sein, da die stärkste Quelle interessant ist.

6

Fair enough. Ich finde die Bewerbung des nach Blocktrainer Ansicht besten Produkts zwar nicht unglaubwürdig. Aber dadurch wird manchmal der Eindruck erzeugt, das wäre das einzige empfehlenswerte Gerät.

Solange alles mit rechten Dingen zugeht, ist die stärkste Methode führend. Da beide Wallets TRNGs verwenden, sollten sie also ungefähr gleichauf sein. Die genauen Klassifizierungen kenne ich nicht.

Aber wir diskutieren doch aktuell über die Sicherheit. Und da schneidet an dieser Stelle die Bitbox m.E. besser ab.
Beim Ledger musst du der Firma Ledger und dem Secure Element Hersteller vertrauen, dass mit der einen Zufallsquelle alles ok ist (closed-source).
Bei der Bitbox würden einzelne Betrüger über das Mischen der Verfahren abgefangen. Ein schlechter RNG reicht immer noch, um einen Betrug beim physikalischen Verfahren zu entschärfen.

Die Frage ist ja durchaus interessant. Aber dabei geht es nicht um Sicherheit vor Herstellerbetrug oder Angriffe durch Dritte, so wie in der aktuellen Ledger Recover Diskussion.

Es geht nur darum, wie hoch die Wahrscheinlichkeit ist, dass zwei Nutzer dieselben 24 Wörter erzeugt bekommen. Wie gesagt, das ist wirklich sehr interessant, aber ein anderes Thema.

Wobei ich prinzipiell US-Teile auch vermeiden würde, wo es geht.

2 „Gefällt mir“
7

Also ich nicht. Mir geht eigentlich nur um die bessere Zufälligkeit.

Oder die 24 Wörter werden per Brute-Force erraten.

1 „Gefällt mir“
8

Ok, da hast du in diesem Thread wohl recht! :sweat_smile:

Bei den gefühlt 10 Threads zum Thema Ledger Recover bin ich da durcheinander gekommen. Genug für mich für heute…

1 „Gefällt mir“
9

Sehr interessante Zusammenstellung. Ich vermute aber, dass die wenigsten das notwendige Know-How haben werden, um daraus die für sie sinnvollen Schlüsse ziehen zu können.
Wenn man den RNGs der Hersteller nicht vertraut, hat man immer noch die Möglichkeit, sich offline einen eigenen Seed zu generieren, z.B. durch Würfel oder Münzwürfe.
Ich hab das selbst bei der Inbetriebnahme der Bitbox02 vor ein paar Monaten mit einer Münze einmal durchgezogen und kann damit sehr gut schlafen.

1 „Gefällt mir“
10

Dann mal weiter im Kontext.

Roughly speaking, PTG.2 conformant RNGs generate high-entropy random
numbers. These random numbers may not be practically indistinguishable from independent
uniformly distributed random numbers (output from an ideal RNG). The entropy shall in
particular prevent successful guessing attacks. In particular, class PTG.2 includes the
applications for class PTG.1. …

Übersetzt:
Gestärkterweise erzeugen PTG.2-konforme RNGs hohe Partiten. Diese Zufallszahlen sind möglicherweise nicht praktisch nicht von unabhängig einheitlich verteilte Zufallszahlen (Ausgang aus einem idealen RNG). Die Entropie soll besonders verhindern erfolgreiche Ratenangriffe. Insbesondere die Klasse PTG.2 enthält die Anwendungen für Klasse PTG.1.

Although no concrete attack is known to date to stay on the safe side it might be favourable to use a class PTG.3 RNG as a measure of precaution. …

Übersetzt:
Obwohl bisher kein konkreter Angriff bekannt ist, um auf der sicheren Seite zu bleiben, könnte es günstig sein, eine Klasse PTG.3 RNG als Vorsichtsmaßnahme zu verwenden.

The PTG.2 class specification does not require a post-processing algorithm if the raw random
numbers are already good enough. However, even then it might be reasonable to apply a post-
processing algorithm with memory. The post-processing algorithm might smooth a bias or
short-term dependencies. Even if it is not data-compressing the entropy of its internal state
might compensate entropy defects of the raw random numbers provided that in the course of the
time more random raw bits are fed into the post-processing algorithm than outputted by the
PTRNG. …

Übersetzt:
Die PTG.2-Klassifizierung erfordert keinen Nachbearbeitungsalgorithmus, wenn die rohen Zufallszahlen bereits gut genug sind. Aber auch dann könnte es sinnvoll sein, eine Post-Bearbeitungsalgorithmus mit Speicher. Der Algorithmus nach der Verarbeitung könnte eine Bias glätten oder kurzfristige Abhängigkeiten. Auch wenn es die Entropie seines inneren Zustands nicht datakomprimiert
könnten Entropiedefekte der rohen Zufallszahlen kompensieren, vorausgesetzt, dass im Laufe der
Zeit mehr zufällige Rohstücke werden in den Post-Cprocessing-Algorithmus eingespeist als von der
PTRNG.

(PTG.3) + (DRG.4): Hybrid RNGs combine security properties of both PTRNGs and DRNGs.
One may hope that the combination of both an analogue part and algorithmic post-processing
might also help to harden RNG implementations against side-channel attacks and fault attacks.

Übersetzt:
(PTG.3) + (DRG.4): Hybrid-RNGs kombinieren Sicherheitseigenschaften von PTRNGs und DRNGs. Man kann hoffen, dass die Kombination von analogem Teil und algorithmischer Nachbearbeitung
könnte auch dazu beitragen, die RNG-Implementierungen gegen Seitenkanalangriffe und Fehlerangriffe zu verschärfen.

For a PTG.2 RNG the post-processing algorithm (if it exists) may not be cryptographic. If the
post-processing algorithm belongs to class DRG.2, resp. even to DRG.3, (viewed as a free-
running DRNG) this extends the reaction time upon a total failure of the entropy source
(PTG.2.2), resp. the PTRNG may even belong to class PTG.3 (cf. PTG.3.6).

Übersetzt:
Für ein PTG.2 RNG ist der Post-processing-Algorithmus (falls vorhanden) möglicherweise nicht kryptographisch. Wenn der Post-Bearbeitungsalgorithmus zur Klasse DRG.2 bzw. zu DRG.3 gehört (als frei-DRNG laufen lassen) dies verlängert die Reaktionszeit bei einem Totalausfall der Entropiequelle
(PTG.2.2), bzw. das PTRNG kann sogar zur Klasse PTG.3 (vgl. PTG.3.6)

Class DRG.4 defines requirements for hybrid deterministic RNGs that primarily rely on the
security imposed by computational-complexity, which is ‘enhanced’ by additional entropy from
a physical true RNG. RNGs of class DRG.4 clearly may be used for the same cryptographic
applications as DRG.3-conformant DRNGs, and additionally for applications that require
enhanced forward secrecy.

Class DRG.4 is based on class DRG.3 but may not use an external source of randomness for the
seeding process. RNGs of class DRG.4 contain an internal source of randomness for seeding
and reseeding, resp. seed-update (to ensure forward secrecy).

Übersetzt:
Klasse DRG.4 definiert Anforderungen an hybride deterministische RNGs, die sich in erster Linie auf die Sicherheit der Rechenkomplexität beruhen, die durch zusätzliche Entropie aus ein physischer RNG. RNGs der Klasse DRG.4 können eindeutig für die gleiche Kryptografie verwendet werden Anwendungen als DRG.3-konforme DRNGs und zusätzlich für Anwendungen, die es erfordern
verbesserte Verschwiegenheit.

Klasse DRG.4 basiert auf der Klasse DRG.3, darf aber keine externe Zufälligkeitsquelle für die
Aussaat. RNGs der Klasse DRG.4 enthalten eine interne Zufälligkeitsquelle für die Aussaat
und Nachbesen, bzw. Samen-Aktualisierung (um Vorwärtsgeheimnis zu gewährleisten).

„Der ATECC608B kann mit seinem internen Zufallszahlengenerator qualitativ hochwertige Zufallszahlen erzeugen. Diese ausgeklügelte Funktion umfasst Runtime-Health-Tests, um sicherzustellen, dass die Werte, welche intern aus einer Rauschquelle generiert werden zum Zeitpunkt der Nutzung ausreichend Entropie enthalten. Der Zufallszahlengenerator ist darauf ausgelegt, die Anforderungen, die in den Dokumenten NIST 800-90A, 800-90B und 800-90C dokumentiert sind, zu erüllen. Die Zufallszahlen können für jeden Zweck verwendet werden, einschließlich als Teil der kryptografischen Protokolle des Geräts. Denn jede Zufallszahl ist im Wesentlichen einzigartig unter allen Zahlen, die jemals auf diesem oder einem anderen Gerät generiert wurden. Deren Einbeziehung in die Protokollberechnung sorgt dafür, dass Replay-Angriffe (d.h. das erneute Übertragen einer zuvor erfolgreiche Transaktion) fehlschlagen werden.“
https://cool-web.de/esp8266-esp32/m5stack-atom-lite-id-unit-krypto-modul-mit-microchip-atecc608b.htm

1 „Gefällt mir“
11

Ich fasse zusammen, wie weit ich gekommen bin.

Der Ledger Security Chip liefert reine physikalische Ergebnisse.

Der Bitbox Security Chip vermischt scheinbar physikalische Ergebnisse mit deterministischen mit der internen Firmware, was ein noch besseres Ergebnis liefern kann. Bedenklich ist, dass das Produkt amerikanisch ist und Hintertüren der NSA in der Firmware sein könnten. Diese Ergebnisse werden später mit vier weiteren schlechteren Quellen vermischt, was das Ergebnis eher verschlechtert. Stellen wir uns mal vor, dass Hintertüren eingebaut sind, die die eliptische Kurve nicht voll ausnutzen, bringt mir das nachträglich Vermischen nichts mehr.

Das war eine Recherche eines Nicht-Informatikers und Nicht-Kryptographen. Korrigiert mich gerne!

12

Eigentlich sollte es doch möglich sein die Zufälligkeit des Zufallsgenerators zu testen? Es gibt doch diverse Verfahren um wiederkehrende Muster in Daten zu identifizieren.

Ich möchte mal ein bekanntes Beispiel dafür geben wie schnell ein Zufallsgenerator absichtlich und unabsichtlich korrumpiert werden kann: OpenSSL ist eine Programmpaket womit auf Linux Betriebssystemen die Schlüssel für verschlüsselte Verbindungen erzeugt werden können. 2008 wurde entdeckt dass der Zufallsgenerator in OpenSSL, welches in Debian basierenden Linux Distributionen verwendet wurde, vorhersagbare Schlüssel erzeugt. Verursacht durch einen bereits zwei Jahre zurückliegenden Patch.
Offenbar war es keine Absicht, weil der verantwortlich Entwickler die Veränderung in der Community kommuniziert hatte, aber niemandem war der fatale Fehler aufgefallen.

So wurden auf Debian und darauf basierenden Linux-Betriebssystemen wie Ubuntu unsichere Schlüssel mit OpenSSL erzeugt. Und das zwei Jahre lang.

https://www.golem.de/0805/59657.html
https://lists.debian.org/debian-security-announce/2008/msg00152.html

Das war leider auch kein Einzelfall. Mit Zufallsgeneratoren gab es immer wieder mal Probleme:

Das zeigt wie kritisch Zufallsgeneratoren sein können. Es können mit oder ohne Absicht schwerwiegende Sicherheitslücken entstehen. Und das kommt auch in Open Source Projekten vor und es kann Jahre dauern bis der Fehler jemandem auffällt.
Das heißt aber nicht dass das Open Source Prinzip nicht funktioniert. Vielmehr zeigt es wie wichtig die Transparenz ist. In einem freien Projekt fallen Sicherheitslücken manchmal nach Jahren auf, häufig auch durch die Arbeit von Leuten die nicht zu den Entwicklern des Projektes gehören. Da OpenSSL in der gesamten Wirtschaft benutzt wird, haben viele Instanzen ein Interesse an der Sicherheit solcher Lösungen. Bei einem closed source System ist nur der Hersteller dafür verantwortlich. Wenn der Hersteller sich nicht ausreichend darum kümmert (ob sie das tun lässt sich von außen kaum beurteilen) können solche Sicherheitslücken nicht nur 2 Jahre sondern bis zum Lebensende der Produktreihe bestehen bleiben.

1 „Gefällt mir“
13

Also ich finde hier im Forum wurde nun wirklich gute Recherchearbeit geleistet, die zu einigen, doch unglaublich wichtigen Fragen geführt hat, deren Beantwortung doch stark davon abhängt, wie mein künftiges Vertrauen in den Bitcoin-Space aussieht. Zumindest was die Verwahrung des Bitcoin mittels Hardware-Wallet angeht.

Als Eigentümer mehrerer BitBox’s, die ich aufgrund meines Vertrauens in Roman und das Blocktrainer-Team gekauft habe, wäre es wirklich toll, wenn sich bspw. ein Vertreter von Shiftcrypto (Stadicus war das glaube ich, der zumindest früher hier geschrieben hat) zu den Bedenken äußern könnte.

Warum nutzt die BitBox bspw. für die Seed-Generierung einen Chip eines US-Unternehmens mit einem Verschlüsselungsverfahren, in das ein US-Geheimdienst schon früher versucht hat eine Backdoor einzubauen ?
Wie sicher kann eine solche Backdoor heute ausgeschlossen werden ? Und durch welches Verfahren ?
Dass der Seed bspw. durch ein Firmware-Update von dem Gerät weg übertragen werden kann, dürfte mittlerweile ohnehin außer Frage stehen.
Mir ist aktuell die Sicherheit des generierten Seed an sich schon das Wichtigste, von dem Gedanken, dass der Seed das Gerät nicht verlassen kann, habe ich mich schon verabschiedet.

14

So wie ich das verstehe wird in der BitBox nicht nur der Secure Chip zur Erzeugung des Seed benutzt.

https://shiftcrypto.support/help/de-de/4-fortgeschritten/104-kann-ich-eine-wallet-mit-meiner-eigenen-entropie-erstellen

Die BitBox02 nutzt fünf verschiedene Entropie-Quellen um höchstmögliche Zufälligkeit als Basis für Deine privaten Schlüssel zu erlangen: aus der Produktion, dem Gerätepasswort, dem Host-Computer, dem Mikrocontroller und dem „secure chip“.

3 „Gefällt mir“
15

Finde ich wirklich gut die Zusammenstellung! Aber ich komme nicht zum gleichen Ergebnis, was an den schon angesprochenen Gründen liegt. Dein Vergleich wird bisher pro Ledger durch geführt; manche Fakten wurden von dir nicht richtig berücksichtigt:

  1. Ignorieren der Tatsache, dass Bitbox zwei TRNGs verwendet

  2. Sicherheit der Bitbox durch Vermischung und dadurch Unabhängigkeit von einzelnen Herstellern; bzw. Unsicherheit des Ledgers durch Abhängigkeit von einzelnem RNG auf Closed-Source Element

zu 1)
Du schreibst, dass die Bitbox nur einen TRNG auf dem Secure Element verwendet. Dieses sei als US-Produkt unsicher.
Allerdings schreibt Shiftcrypto, dass sie sowohl den TRNG auf der MCU (Microchip Technology ATSAMD51J20A), als auch den TRNG auf dem Secure Element (Microchip Technology ATECC608B) verwenden. Siehe auch mein Beitrag weiter oben.

zu 2)
Wie man sieht kommen sowohl MCU als auch Secure Element von Microchip Technology aus den USA. Im Falle, dass in beiden TRNGs also eine NSA Backdoor enthalten wäre, könnte die NSA die Zufallszahlen kennen bzw. vorhersagen.
Das Problem multipliziert sich hierbei allerdings, da die NSA (wahrscheinlich) alle vorhersagbaren Zahlen des einen RNG, mit den vorhersagbaren Zahlen des anderen RNG kombinieren müsste.
Du gehst auch immer noch nicht auf den Punkt ein, dass in diesem NSA Betrugsfall noch die anderen RNGs existieren. Die NSA kann nicht einfach auf die Schnelle noch die Pseudozufallszahlen vorhersagen oder ein ausreichend komplexes Passwort bruteforcen. Schließlich wird u.a. das Passwort als Basis für die Zahlen verwendet.

Ohne Betrug durch irgendjemanden verwendet also der Ledger einen einzelnen TRNG; die Bitbox verwendet zwei TRNGs.
Im Betrugsfall müssten wir eine NSA Backdoor bei der Bitbox, mit einem Betrug im Closed-source Element von Ledger vergleichen. Diesen Fall fängt die Bitbox mit den anderen Zufallsquellen ab; der Ledger gar nicht. Außerdem könnte Ledger durch closed-source Code bei den Zufallszahlen viel einfacher betrügen, siehe anderer Thread.

@BTC-Punk, falls du in diesem Thread ausschließlich die Qualität der Zufallszahlen im Nicht-Betrugs-Fall vergleichen willst, dann sind die Zertifizierungen der TRNGs ein Anhaltspunkt, sie sagen aber auch nicht alles (z.B. mögliche Design-Fehler auf dem RNG oder in der weiteren Verarbeitung).
Nach Belieben springst du aber selbst immer wieder zum möglichen Betrug durch die NSA. In diesem Fall sollten wir aber die Sicherheitsaspekte generell mit einbeziehen, also auch die oben angesprochenen Punkte auf beiden Seiten.

Generell zu RNGs)
Wie @DeTec schon schreibt, sind RNGs alleine ein sehr komplexes Thema. Das Problem ist nicht, dass sich die erzeugten Zahlen bei statistischen Tests nicht wie Zufallszahlen verhalten.
Stattdessen sind m.E. die Hauptschwierigkeiten, dass man erstens dem Hersteller vertrauen muss, da ihm die Zahlen vorab bekannt sein könnten.
Und zweitens, dass ein Fehler im Design dafür sorgt, dass die generierten Zahlen einer vorhersagbaren Systematik folgen. Das würde dazu führen, dass die „Zufallszahlen“ nicht den kompletten möglichen Wertebereich ausnutzen, oder sie sich immer wieder in ähnlichen Abfolgen ändern, sie also nicht wirklich zufällig sind. Mehrere RNGs würden also mit höherer Wahrscheinlichkeit als notwendig ähnliche Zahlen produzieren. Angreifer könnten außerdem versuchen, Zahlen vorherzusagen.
Ich schätze mal, dass selbst TRNGs hierbei nicht perfekt sein können; wenn auch ausreichend für unsere Zwecke. Auch ohne dass ich hier vom Fach bin, würden mir auf Anhieb einige Dinge einfallen, die beim Auslesen und Verarbeiten physikalischer Größen falsch laufen könnten. Die Entwickler machen sich da sicher viele Gedanken; aber man macht auch Fehler oder übersieht etwas.
Ich persönlich würde deshalb bei absoluter Paranoia einfach (richtig!) würfeln. Der Zufall dabei ist zwar (vernachlässigbar) schlechter als z.B. bei echtem Rauschen oder radioaktivem Zerfall. Aber man kann beim Würfeln sehr einfach alle relevanten Fehler ausschießen, während das bei einem TRNG aufgrund der Komplexität nicht so einfach ist.

Das würde mich tatsächlich auch interessieren. Und wenn man schon zwei Elemente nutzt, dann sollte vielleicht nur eines aus den USA kommen.

Ich bin generell kein Freund von US-Teilen. Mit ihrer unglaublichen Arroganz schreiben die USA einem auch gerne vor, welche Geräte, die „US Technology“ enthalten, man wohin exportieren darf. Dabei gibt es zwar gewisse Anteilsgrenzen, aber ich würde damit gar nicht erst anfangen.

6 „Gefällt mir“
16

Wie schätzt Ihr denn die Sicherheit von Trezor ein ?

Da gibt es nur open source und überhaupt keinen closed source Secure Chip, wäre dann die Schwachstelle eines möglicherweise korrumpierten Secure Chip dadurch nicht gelöst ?

17

Ein Secure Chip hat gegenüber ein normalen Chip Vor- und Nachteile. Wenn du auf ein Secure Chip verzichtest, verzichtest du folglich auch auf die Vorteile.

Secure Chips haben einige Vorteile, aber ich denke, die wichtigsten sind die Zertifizierung nach hohen Sicherheitsstandards, die besonderen Schutzmaßnahmen gegen physischen Zugriff und fertige kryptographische Funktionen, die man nicht selbst potenziell fehlerhaft implementieren muss.

Shiftcrypto kombiniert die verschiedenen Lösungsansätze und streut damit das Risiko.

18

Das ist sicher richtig. Die Frage nach der Alternative Trezor war aber ja unter der Prämisse gestellt, dass ein möglicherweise mit einer Backdoor ausgestatteter Secure Chip als Sicherheitsrisiko dort nicht möglich wäre. Nur unter Annahme dieses Risikos macht ein Verzicht auf den Secure Chip natürlich Sinn.

19

Durch den Verzicht auf ein Secure Chip entstehen neue potenzielle Schwachstellen. Die Kompromittierung eines Mikrocontrollers kann einfacher sein als die eines Secure Chips. Auch das auslesen der Schlüssel kann durch physischen Zugriff auf die Halbleiter des Chips bei einem Mikrocontroller einfacher sein.

Es sieht so aus als ob jedes Sicherheitselement und Konzept seine speziellen Risiken mit sich bringt. Bei der Wahl der Architektur und Chips entscheidet man sich als Hersteller und Kunde eigentlich dafür welche Anzahl und Art von Risiken man eingehen möchte. Eine technisch perfekt sichere Lösung dürfte prinzipiell unmöglich sein.

1 „Gefällt mir“
20

Nur mit Software nur mit Mikrocontroller kann man keine guten Zufallswerte erzeugen. Man braucht immer eine externe physikalische Quelle. Am PC kann man das mit Benutzerinteraktionen wie Mausbewegung, Tastendrücke oder durch mechanische Toleranzen der Trägheit der Festplatte erreichen. Bei Servern ohne Benutzerschnittstelle und mit SSD ist es dann besonders schwierig besonders nach einem Neustart, der immer gleich abläuft. Ein guter Zufallsgenerator benutzt mehrere Zufallsquellen, dazu gehört ein Secure-Chip, der Widerstands- und/oder Halbleiterrauschen nutzt. Also eine Hardwarewallet ohne Secure-Chip würde ich nicht benutzen wollen.

21

Die letzte Folge von @renna im Blocktrainer Bitcoin Podcast behandelt genau solche Fragen und ist sehr hörenswert.

Der Microcontroller, der bei der Bitbox eingesetzt wird, hat auch einen TRNG an Bord. Nur dafür benötigt man also nicht unbedingt ein Secure Element.

Aber wie @DeTec schon schreibt, ist ein Secure Element besser ggü. software-seitigen, aber vor allem besser ggü. physikalischen Angriffen geschützt. Deshalb wird es auch laut @Stadicus bei der Bitbox eingesetzt.

Ich würde ungerne auf ein Secure Element verzichten wollen. Ansonsten kann es bei Diebstahl der HW-Wallet gefährlich werden. Der Brute Force Schutz ist beim Microcontroller wohl leichter zu umgehen (siehe Podcast). Bei der Bitbox sind die Entsperrversuche durch das Secure Element auf ca. 730.000 begrenzt.

3 „Gefällt mir“