Zufälligkeit des Seed von Ledger und Bitbox

Fragen
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“