BIP39 Samenphrasen Was diese 12 Wörter tatsächlich sind und wie die HD-Wallet-Ableitung funktioniert

Ein BIP39-Mnemotechnik besteht aus 128 oder 256 Bit zufälligen Daten, die als menschenlesbare Wörter mit einem festen 2048-Wörter-Liste codiert werden. Das ist der ganze Trick. Das „Magische“ liegt darin, dass Wörter leichter auf Papier geschrieben werden können als Hex-Zeichen – kryptografisch gibt es nichts Besonderes an den Wörtern selbst.

Interessant wird es bei der vierstufigen Stack, die auf dieser Codierung aufgebaut ist: BIP39 (Wörterliste und Codierung), BIP32 (hierarchische deterministische Schlüsselabgleichung), BIP43 (Konventionen für Zweckfelder) und BIP44 (Koins/Konto/Adressenstruktur). Die meisten Erklärungen vermischen alle vier. Dieser Text trennt sie.

Die Wörterliste: 11 Bit pro Wort, inklusive Prüfsumme

Der BIP39-Englische Wörterliste hat genau 2048 Wörter. 2¹¹ = 2048, also codiert jedes Wort 11 Bit Information. Eine 12-Wort-Phrase enthält insgesamt 132 Bit; eine 24-Wort-Phrase enthält 264 Bit.

Nicht alle dieser Bits sind Entropie. Die letzten Bits des letzten Worts sind eine Prüfsumme – die ersten ENT/32 Bit von SHA256(Entropie_bytes), wobei ENT die Entropielänge in Bit ist:

Länge der Phrase	Entropie-Bits (ENT)	Prüfsummen-Bits (CS = ENT/32)	Gesamt-Bits
12 Wörter	128	4	132
15 Wörter	160	5	165
18 Wörter	192	6	198
21 Wörter	224	7	231
24 Wörter	256	8	264

Die Prüfsumme erklärt, warum „fast gültige“ Mnemotechniken fehlschlagen. Wenn ein Bit der Entropie umgekehrt wird, ändert sich das Prüfsummen-Byte, wodurch die Phrase ungültig wird. Dies erkennt Transkriptionsfehler – insbesondere die, die in den Prüfsummen-Bits landen. Wallets, die vor der Schlüsselabgleichung validiert werden, lehnen die Phrase vollständig ab. Einige überprüfen nicht; sie leiten einfach ein Wallet aus schlechten Entropie ab.

Die Entropie-zu-Wörter-Kodierung in Python:

import hashlib, os

# Generate 128 bits of entropy
entropy = os.urandom(16)  # 16 bytes = 128 bits

# Compute checksum: first 4 bits of SHA256(entropy)
h = hashlib.sha256(entropy).digest()
checksum_bits = format(h[0], '08b')[:4]  # first 4 bits of SHA256 output

# Combine entropy bits + checksum bits
all_bits = format(int.from_bytes(entropy, 'big'), '0128b') + checksum_bits
# all_bits is now 132 bits

# Split into 11-bit groups -> 12 word indices (0-2047)
word_indices = [int(all_bits[i:i+11], 2) for i in range(0, 132, 11)]
# Look up each index in the BIP39 word list to get the mnemonic

Die Mnemotechnik ist nicht der Schlüssel: der PBKDF2-Schritt

Hier gehen die meisten Erklärungen falsch. Die 12 Wörter sind nicht dein privater Schlüssel und werden nicht direkt zum Signieren verwendet. Sie sind ein Zwischenschritt. Bevor jegliche Schlüsselmaterial abgeleitet wird, wird die Mnemotechnik durch PBKDF2-HMAC-SHA512 verlängert:

import hashlib

mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about"
passphrase = ""  # optional; empty string = no passphrase

seed = hashlib.pbkdf2_hmac(
    'sha512',
    mnemonic.encode('utf-8'),                    # password: the mnemonic words
    ('mnemonic' + passphrase).encode('utf-8'),   # salt: always "mnemonic" + passphrase
    2048,                                         # iterations
    dklen=64                                      # 512 bits output
)
# seed is 64 bytes (512 bits) -- this is what actually seeds key derivation

Zwei Dinge zu beachten:

• Der Salz ist immer die Literal-String "mnemonic" verkettet mit dem Passwort. Ein leeres Passwort bedeutet, dass das Salz einfach "mnemonic" — es gibt kein separates „kein Passwort“-Modus.
• Das Passwort verändert komplett das resultierende Seed. Die gleichen 12 Wörter mit Passwort "A" vs "a" erzeugen völlig andere Wallets mit völlig anderen Adressen. Dies ist das „25. Wort“-Feature: Ein Passwort ermöglicht es dir, plausiblen Verweigerung (zwei Wallets aus einer Phrase) zu bewahren, aber das Verlieren des Passworts ist dauerhaft, selbst wenn die 12 Wörter in der Hand sind.

Von Seed zu Master-Schlüssel: BIP32

Die 512-Bit-Seed wird in HMAC-SHA512 mit dem festen Schlüsselstring "Bitcoin seed". Die 64-Byte-Ausgabe teilt sich in zwei 256-Bit-Hälften:

import hmac, hashlib

master = hmac.new(b'Bitcoin seed', seed, hashlib.sha512).digest()
master_private_key = master[:32]   # left 256 bits: the actual EC private key
master_chain_code  = master[32:]   # right 256 bits: used for all child derivation

Der Chain-Code ist der Grund, warum HD-Wallets funktionieren: Er verhindert, dass abgeleitete Schlüssel durch Brute-Force-Angriffe angegriffen werden, selbst wenn der Elternschlüssel bekannt ist. Ohne diesen Code würde die Kenntnis eines Elternpublic-Schlüssels und eines beliebigen Kind-Schlüssels alle Geschwister-Schlüssel enthüllen. Mit dem Chain-Code erfordert die Ableitung eines Kindschlüssels sowohl den Elternschlüssel als auch den Chain-Code als Eingaben – und für die gehärtete Ableitung direkt den Elternprivatschlüssel.

Zusammen master_private_key + master_chain_code bilden die Master-erweiterte privaten Schlüssel, codiert als ein xprv... Base58Check-String. Der entsprechende erweiterte öffentliche Schlüssel ist xpub... – nützlich für Watch-Only-Wallets, die Adressen ableiten müssen, ohne den privaten Schlüsselmaterial zu offenbaren.

BIP44-Ableitungswege: m/44’/60’/0’/0/0 entschlüsselt

BIP44 definiert eine fünfstufige Ableitungsarchitektur. Hier ist m/44’/60’/0’/0/0 – die Standard-Adresse für Ethereum – komponentenweise aufgebrochen:

Ebene	Wert	Hex-Index	Bedeutung
m	—	—	Master-Schlüssel-Root
44'	Zweck	0x8000002C	BIP44-Zweck. Gehärtet (Apostrophe = 0x80000000 + Index).
60'	Koins-Typ	0x8000003C	Ethereum, nach SLIP-0044. Bitcoin = 0′, Solana = 501′, usw.
0'	Konto	0x80000000	Erstes Konto. Erhöhen Sie für isolierte Konten.
0	Änderung	0	Außenseite-Kette (0 = Empfangsadressen, 1 = Änderungsadressen). Wallets nutzen die Änderungskette selten für EVM-Ketten.
0	Index	0	Adressindex. Erhöhen Sie für die 2. Adresse, 3. usw.

Die Apostrophe bezeichnen gehärtete Ableitung. Gehärtete Kindschlüssel können nur aus dem Elternprivatschlüssel abgeleitet werden, nicht aus dem Elternpublic-Schlüssel. Dies ist wichtig, weil bei normaler (nicht gehärteter) Ableitung ein kompromittierter Kindprivatschlüssel plus dem Elternpublic-Schlüssel den Elternprivatschlüssel und alle Geschwister-Schlüssel enthüllen würde. Bei Zweck, Koins-Typ und Konto-Ebenen ist gehärtete Ableitung die Spezifikation.

Warum die gleiche Phrase unterschiedliche Adressen in verschiedenen Wallets erzeugt

Die Phrase und der Standardweg des Wallets sind unabhängige Variablen. Wallets haben historisch unterschiedliche Wege, und einige Unterschiede sind noch nicht gelöst.

Für Ethereum ist der Hauptunterschied:

• MetaMask, Ledger Live, die meisten modernen Wallets: m/44'/60'/0'/0/N – Standard-BIP44.
• MyEtherWallet (legacy default): m/44'/60'/0'/N – eine Ebene kürzer. Ein Wallet, das aus der gleichen Phrase in MEW mit dem alten Weg wiederhergestellt wird, erzeugt eine völlig andere Adresse-Menge als MetaMask.
• Trezor Suite: Folgt jetzt Standard-BIP44 für ETH, hatte aber historisch eigene Besonderheiten bei einigen Altcoins.

Für Bitcoin ist die Divergenz strukturell: BIP44 (m/44'/0'/0', Legacy P2PKH, Adressen beginnen mit 1), BIP49 (m/49'/0'/0', P2SH-P2WPKH, Adressen beginnen mit 3), und BIP84 (m/84'/0'/0', native segwit P2WPKH, Adressen beginnen mit bc1q) erzeugen aus derselben Seed unterschiedliche Adressen. Die Adresseformat sagt dir, welchen Weg verwendet wurde, weshalb die Adresseformat bei der Wiederherstellung wichtig ist.

Wenn du eine Phrase importierst und „die Gelder sind nicht da“, überprüfe den Ableitungsverlauf, bevor du annimmst, dass die Phrase falsch ist. Die meisten Wallets lassen dich während des fortgeschrittenen Imports den Weg manuell angeben.

Sicherheitsfehlerarten

Die Kryptografie hier ist nicht der schwache Punkt. Jeder Angriff, der gegen BIP39-Wallets funktioniert, zielt auf die menschliche Seite des Prozesses ab.

Phishing: „Geben Sie Ihre Wiederherstellungspassage ein, um fortzufahren“

Der höchste-Volume-Angriff in erheblichem Maße. Falsche Wallet-UIs, Browsererweiterungen, die von böswilligen Skripten eingefügt wurden, oder Kundenbetreuungsschönheiten in Discord – alle bitten die Benutzer, ihre 12 Wörter irgendwo einzugeben. Das richtige mentale Modell: Legitime Wallet-Software fragt nach deiner Seed-Phrase nach der ersten Einrichtung nie. Eine Anfrage nach der Phrase ist ein Angriff, unabhängig davon, wie legitimiert die UI aussieht.

Zwischenablageüberwachung

Malware, die die Zwischenablage abfragt, eine Folge von 12 oder 24 bekannten BIP39-Wörtern erkennt und ausliefert. Das Auslieferszenario dauert Millisekunden. Das Kopieren einer Seed-Phrase irgendwo – selbst kurz in einen Texteditor – schafft eine Exposition. Zwischenablagehistorienmanager (Windows Clipboard History, macOS Clipboard Manager, IDE Paste History) sind besonders hochriskant.

Screenshots und Cloud-Photo-Sync

Das Aufnehmen eines Screenshots einer Seed-Phrase auf einem Smartphone lädt sie in Sekunden in iCloud Photos oder Google Photos hoch, bevor die meisten Menschen sie gelesen haben. Diese Backups sind nicht client-seitig verschlüsselt. „Ich habe einen Screenshot gemacht, um sie sicher zu halten“ ist ein direkter Exfiltrationsweg. Ein Papierbackup in einem physisch sicheren Ort ist keine lächerliche Empfehlung.

Server-seitige Mnemotechnikgenerierung

Jede Website, die eine BIP39-Phrase serverseitig generiert, hat eine Kopie der Entropie. Der einzige sichere Ort zur Generierung ist ein Gerät, das du kontrollierst, und das offline bei der Generierung ist. Ein Hardware-Wallet, ein air-gapped Gerät oder ein auditiertes client-seitiges Tool. Eine Website ist keines davon – selbst wenn das JavaScript korrekt aussieht, kannst du nicht sicherstellen, dass der Server die Ausgabe nicht protokolliert.

Wenn du eine Phrase struktur- oder validierst – Entropie überprüfen, das abgeleitete Seed sehen, einen Weg validieren – läuft BIP39 Mnemonik-Konverter komplett im Browser. Die Phrase verlässt dein Gerät nie, was die einzige Architektur für diesen Anwendungsfall ist.

Der Entwickleransatz: Du solltest fast sicher nicht die Seed-Phrase in deiner App behandeln

Wenn du eine kryptografisch benachbarte Anwendung entwickelst, ist die Neigung, die Seed-Phrase in deinem Backend zu „verwenden“, fast immer falsch. Die Angriffsoberfläche:

• Protokollierung. Jede Webframework protokolliert Anfragen irgendwo. Eine Debug-Zeile, eine falsch konfigurierte Protokollierungseinstellung, und jede Phrase, die dein API verlässt, ist auf der Festplatte – unendlich, über mehrere Protokollierungsziele, die du nicht auditiert hast.
• Transit. HTTPS schützt die Verbindung. Es schützt nicht die Load-Balancer, den Backend-Prozess, die Datenbank oder den Log-Aggregator. Jeder ist ein separater Angriffspunkt.
• Speicher. Prozessdump, Crashberichte, Core-Dateien und Heap-Snaps capture in-Memory-Strings. Eine Seed-Phrase in einem Python-Objekt oder JavaScript-Objekt ist nicht zero-copy; sie erscheint wahrscheinlich in mehreren Allocationen, bevor sie „gelöscht“ wird.
• Verantwortlichkeit. Wenn dein Backend Benutzer-Seed-Phrasen verarbeitet und du gebrochen wirst, ist der Schaden dauerhaft. Im Gegensatz zu Passwörtern gibt es kein Zurücksetzen. Betroffene Benutzer verlieren Geld und haben keine Rechtsmittel.

Die funktionierende Architektur: Leite das, was du brauchst, auf der Client-Seite ab und übertrage nur das Ergebnis – einen öffentlichen Schlüssel, einen nur-Lese-xpub, eine signierte Transaktion. Das Backend sieht die Phrase nie. Bibliotheken, die dies korrekt tun: @scure/bip39 (auditiert, minimal abhängig), ethers.jsund bitcoinjs-lib. Für Hardware-Wallet-Integrationen liefern die Trezor- und Ledger-SDKs eine signierte Transaktion – der Schlüssel verlässt das Gerät nie.

Die vollständige Ableitungs-Kette im Überblick

Schritt	Eingang	Betrieb	Ausgabe
1. Entropie	128–256 zufällige Bit	SHA256-Prüfsumme → 11-Bit-Gruppen	12–24 Wort-Mnemotechnik
2. Seed	Mnemotechnik-Wörter + „mnemonic“ + Passwort	PBKDF2-HMAC-SHA516, 2048 Runden	512-Bit-Seed (64 Byte)
3. Master-Schlüssel	Seed-Byte	HMAC-SHA512(„Bitcoin seed“, Seed)	Master-privater Schlüssel (256 Bit) + Chain-Code (256 Bit)
4. Konto-Schlüssel	Master-Schlüssel + Pfad m/44’/60’/0’	BIP32 gehärtete Kindableitung × 3	Konto-erweiterte privater Schlüssel
5. Adresse-Schlüssel	Konto-Schlüssel + Pfad /0/N	BIP32 normale Kindableitung × 2	Kind-privater Schlüssel → secp256k1 öffentlicher Schlüssel → keccak256 → Adresse

BIP39 hat genau das getan, was es entworfen hat: Entropie schreibbar und wiederherstellbar zu machen. Die Angriffsoberfläche ist nicht in der Kryptografie – PBKDF2 mit 2048 Runden, HMAC-SHA512, secp256k1 – alles ist sicher. Die Angriffe sind rein operativ: die Phrase irgendwo einzugeben, sie digital zu speichern, ein Tool zu vertrauen, das sie serverseitig generiert. Die Mathematik ist in Ordnung. Die Menschen sind die schwache Stelle, weshalb der Entwickler-Tipp lautet: „Architektiere dein System so, dass die Phrase niemals deine Infrastruktur berührt.“

Das könnte Ihnen auch gefallen