Direktabwicklungs-Architektur: Wie HD-Wallets und die xPub-Ableitung funktionieren

Das größte Sicherheitsrisiko in jedem Krypto-Zahlungssystem ist die Preisgabe privater Schlüssel. Wenn der Server, der eingehende Zahlungen überwacht, dieselben Mittel auch ausgeben kann, bedeutet ein einziger Einbruch den Totalverlust. Eine Direktabwicklungs-Architektur kann dieses Verwahrungsrisiko reduzieren – und der Mechanismus dahinter, die Schlüsselableitung in HD-Wallets, ist nützlich genug, um ihn zu verstehen.

Das Problem mit Hot Wallets auf Servern

Ein „Hot Wallet“ ist eine Wallet, deren privater Schlüssel auf einem mit dem Internet verbundenen Rechner liegt. Die meisten naiven Krypto-Zahlungslösungen funktionieren genau so: Wallet erzeugen, privaten Schlüssel in eine Konfigurationsdatei oder die Datenbank legen und damit Einzahlungsadressen erstellen sowie Auszahlungstransaktionen signieren.

Im Nachhinein ist das Problem offensichtlich: Wer den Server kompromittiert – über eine ungepatchte Schwachstelle, einen Supply-Chain-Angriff, geleakte Zugangsdaten oder eine falsch konfigurierte Firewall –, erhält den privaten Schlüssel und kann damit jede daran hängende Wallet leerräumen. Die Geschichte der Börsen-Hacks ist zu weiten Teilen eine Geschichte kompromittierter Hot Wallets.

Die Lösung besteht darin, das Beobachten von Zahlungen vom Ausgeben der Mittel zu trennen.

HD-Wallets und der Extended Public Key

BIP-32 (Hierarchical Deterministic Wallets) beschreibt, wie sich aus einem einzigen Master-Seed ein unendlicher Baum von Schlüsselpaaren ableiten lässt. Die entscheidende Eigenschaft ist die Ableitung öffentlicher Schlüssel: Aus dem Extended Public Key (xPub) eines Elternknotens lassen sich sämtliche Kind-Public-Keys – und damit alle zugehörigen Bitcoin-Adressen – ableiten, ohne den privaten Schlüssel jemals zu sehen.

Mathematisch möglich wird das durch die Arithmetik auf elliptischen Kurven: Öffentliche Schlüssel sind Punkte auf einer Kurve, und durch Addition eines deterministischen Tweaks lassen sich Kind-Public-Keys allein aus dem öffentlichen Schlüssel des Elternknotens berechnen.

In der Praxis bedeutet das:

1. Sie erzeugen den Master-Seed offline – auf einem air-gapped Rechner, einer Hardware-Wallet oder einem Signiergerät.
2. Sie exportieren den xPub (nur den öffentlichen Schlüssel, kein privates Material) und geben ihn an Ihren Zahlungsserver.
3. Der Server leitet Adresse 1 für Rechnung 1 ab, Adresse 2 für Rechnung 2 und so weiter – jede eindeutig und in einem genehmigten Direktabwicklungs-Setup mit öffentlichem Schlüsselmaterial des Händlers verbunden – ohne den privaten Schlüssel je zu kennen.

Wie die Adressableitung konkret abläuft

Für einen BIP-32-xPub am Ableitungspfad m/44'/0'/0' (Bitcoin-Standard nach BIP-44) leitet der Server Adressen unter m/44'/0'/0'/0/N ab, wobei N der Rechnungsindex ist. Jedes N ergibt eine eindeutige Adresse. Die Adressen sind deterministisch – derselbe xPub und dasselbe N liefern immer dieselbe Adresse –, sodass sich jede Adresse zur Überprüfung erneut ableiten lässt.

Für UTXO-Chains (Bitcoin, Litecoin, Dogecoin, Bitcoin Cash) ist das der Standardweg. Andere Chains nutzen andere, aber gleichwertige Mechanismen:

• TON und Tron: Für jede Rechnung wird ein frisches Schlüsselpaar erzeugt; auf dem Server liegt nur der öffentliche Schlüssel und damit die Adresse. Der private Schlüssel wird entweder verworfen (Watch-only-Betrieb) oder in einem Offline-Pool verwahrt.
• Solana: Ein Offline-Pool vorab erzeugter öffentlicher Schlüssel (abgeleitet aus einem Offline-Seed) wird pro Rechnung um einen Eintrag verbraucht.
• EVM-Chains (ETH, BSC, Polygon usw.): xPub-Ableitung über BIP-44, genau wie bei Bitcoin.
• XRP und XLM: Modell mit gemeinsamer Adresse und eindeutigem Destination Tag bzw. Memo je Rechnung.

Der vollständige Non-Custodial-Zahlungsablauf

1. Rechnung wird erstellt: Ihre Website ruft die Gateway-API auf. Das Gateway leitet allein aus öffentlichem Material eine frische Einzahlungsadresse ab (oder vergibt einen eindeutigen Tag).
2. Kunde zahlt: Die Mittel gehen an diese Adresse. Das Gateway erkennt die Transaktion über die API eines Blockchain-Explorers.
3. Bestätigung: Nach der erforderlichen Anzahl an Confirmations aktualisiert das Gateway den Rechnungsstatus und schickt einen signierten Webhook an Ihren Server.
4. Die Mittel kommen an: direkt in Ihren eigenen Wallets. Das Gateway hat sie nie verwahrt, kann sie nicht bewegen und besitzt dafür auch keinen privaten Schlüssel.
5. Auszahlung: Wenn Sie Guthaben zusammenführen oder eine Auszahlung vornehmen wollen, signieren Sie die Transaktion offline – auf einem air-gapped Rechner, einer Hardware-Wallet oder einem beliebigen Signiergerät – und senden die signierte Transaktion ins Netz. Der Server protokolliert den Transaktions-Hash, kann die Ausgabe aber nicht selbst anstoßen.

Was das für die Sicherheit bedeutet

Eine vollständige Kompromittierung des Zahlungsservers ist in diesem Modell schlimmstenfalls ein Datenleck: Angreifer sehen die Bestellhistorie und laufende Rechnungen, können aber keinen einzigen Satoshi bewegen. Die Mittel liegen in Wallets, deren Schlüssel den Server nie berührt haben.

Deshalb verlangen Non-Custodial-Gateways, dass Sie vor der ersten Zahlung einen xPub exportieren (oder ein Offline-Tool zur Schlüsselerzeugung nutzen). Der etwas höhere Einrichtungsaufwand erkauft ein grundlegend anderes Risikoprofil: kompromittierter Server ≠ verlorene Mittel.

Für jeden Betreiber mit nennenswertem Volumen ist diese Architektur ein nützliches Modell. Standardmäßig schreibt Payora Zahlungen dem Payora-Guthaben gut; geprüfte Händler können Direktabwicklung mit öffentlichem Schlüsselmaterial des Händlers beantragen, wo sie verfügbar ist. Erfahren Sie, wie Payoras Abwicklungsmodi funktionieren.