Wallet-Infrastruktur und Sicherheitsmodell
Branchenhintergrund
Wallet-Systeme stützen sich typischerweise auf eine oder mehrere grundlegende kryptografische Verfahren, um private Schlüssel zu schützen. Diese Ansätze zu verstehen, liefert den Kontext für das in diesem Dokument beschriebene Sicherheitsmodell.
Shamir's Secret Sharing (SSS)
SSS teilt einen privaten Schlüssel in mehrere Anteile auf; zur Rekonstruktion des Originals ist ein Mindest-Schwellenwert nötig. Es bietet perfekte Geheimhaltung — jede Anzahl von Anteilen unterhalb der Schwelle verrät nichts über den Schlüssel. SSS ist ausgereift, gut mit Werkzeugen unterstützt und schnell (20–40 ms Signierung). Der Kompromiss: Der private Schlüssel muss zum Signieren vollständig wieder zusammengesetzt werden, was im Moment der Rekonstruktion einen einzelnen Ausfallpunkt schafft.
Threshold Signature Schemes (TSS)
TSS (allgemein als MPC bekannt) erlaubt es mehreren Parteien, gemeinsam eine Signatur zu erzeugen, ohne den privaten Schlüssel jemals wieder zusammenzusetzen. Damit entfällt das Rekonstruktionsrisiko von SSS. Der Kompromiss ist Unreife — das erste effiziente Zwei-Parteien-ECDSA-Protokoll erschien erst 2017 — und Leistung: Jede Signatur umfasst Netzwerk-Roundtrips und verursacht Latenz, die mehrere Sekunden erreichen kann.
Trusted Execution Environments (TEE)
TEEs führen kryptografische Operationen in Hardware-Enclaves aus, sodass Schlüsselmaterial nie exponiert wird und nur autorisierter Code läuft. Clients können Operationen über Attestierungen verifizieren. TEEs skalieren gut und vermeiden die Roundtrip-Latenz von TSS, ihre Sicherheit hängt aber von der Integrität der Enclave ab, die historisch anfällig für Seitenkanalangriffe war.
WebAuthn PRF Extension
Die WebAuthn-PRF-(Pseudo-Random-Function)-Extension leitet ein deterministisches Secret aus der Passkey-Hardware des Nutzers ab — Secure Enclave auf Apple-Geräten, TPM unter Windows, Titan chip unter Android. Dieses Secret ist an das Gerät und die Biometrie oder den PIN des Nutzers gebunden, wird on-device während der Authentifizierung berechnet und niemals übertragen. Sie ermöglicht eine Klasse von Wallet-Designs, in der Schlüsselmaterial mit einem Secret verschlüsselt werden kann, das kein Server je gesehen hat.
Dreiparteien-Schlüsselschutz
Überblick
Private Schlüssel in diesem System werden nirgends vollständig gespeichert — weder auf Nutzergeräten, noch auf unseren Servern, nirgendwo. Stattdessen wird das Schlüsselmaterial kryptografisch auf drei unabhängige Parteien mit einem 3-of-3 Secret-Sharing-Schema verteilt. Alle drei Parteien müssen zusammenarbeiten, um einen Schlüssel zu rekonstruieren. Weniger als drei verraten mathematisch null Information über den privaten Schlüssel.
Dies ist ein Hybridmodell: Es verbindet passkey-basierte Client-seitige Verschlüsselung (PRF-as-KEK), Secret Sharing und eine isolierte serverseitige Enclave in einer Architektur. Die entstehende Konstruktion erreicht dieselbe informationstheoretische Sicherheitsgarantie wie Shamir's Secret Sharing — keine Teilmenge von Parteien unterhalb der Schwelle gewinnt Information über den Schlüssel — und bindet einen Anteil an die physische Authenticator-Hardware des Nutzers, sodass allein ein serverseitiger Kompromiss den Schlüssel nicht rekonstruieren kann.
Das ist das Standard-Sicherheitsmodell für alle modernen Geräte (alle gängigen Browser unter iOS, macOS, Android und Windows).
Die drei Parteien
Partei 1 — Der Authenticator des Nutzers
Die Passkey-Hardware des Nutzers berechnet ein deterministisches Secret, gebunden an dieses Gerät und die Biometrie oder den PIN des Nutzers. Diese Ausgabe — PRF output genannt — entsteht on-device während der Authentifizierung und wird nirgendwohin übertragen. Sie wird nicht gespeichert. Sie wird nicht protokolliert. Sie existiert nur im RAM für die Dauer der Signieroperation.
Dieses Secret ist der Beitrag des Nutzers zur Schlüsselrekonstruktion. Ohne ihn haben die beiden anderen Parteien nichts, woraus ein brauchbarer privater Schlüssel entstehen könnte.
Partei 2 — Die API
Die API speichert eine verschlüsselte Kopie des Schlüsselmaterials des Nutzers. Es ist mit dem PRF-abgeleiteten Secret des Nutzers verschlüsselt, das die API nie gesehen hat. Die API steuert den Zugriff — sie gibt diese verschlüsselte Nutzlast nur an eine Anfrage frei, die eine gültige WebAuthn-Assertion mit dem registrierten Passkey des Nutzers vorlegt. Sie kann die Nutzlast jedoch selbst nicht entschlüsseln.
Die API fungiert als authentisierter Liefermechanismus, nicht als Schlüsselverwahrer.
Partei 3 — Die Crypto Enclave
Ein separates, isoliertes System — unabhängig von der API mit eigenen Verschlüsselungsschlüsseln und eigener Infrastruktur — hält den serverseitigen Schlüsselanteil. Dieser Anteil ist at rest mit einem nur der Enclave bekannten Secret verschlüsselt. Die Enclave gibt den entschlüsselten Anteil erst frei, nachdem die Anfrage die Assertion-Validierung bestanden hat, und nur zur Kombination mit dem Anteil des Nutzers im letzten Signierschritt.
Die Enclave sieht weder den PRF output des Nutzers, noch den Schlüsselanteil des Nutzers, noch den zusammengesetzten privaten Schlüssel.
Sicherheitseigenschaften
Kein einzelner Ausfallpunkt
| Szenario | Folge |
|---|---|
| Nutzergerät gestohlen | Angreifer kann Biometrie/PIN nicht reproduzieren; PRF output ist nicht erreichbar |
| API vollständig kompromittiert | Angreifer erhält nur Ciphertext, verschlüsselt mit einem Secret, das er nie gesehen hat |
| Enclave vollständig kompromittiert | Angreifer erhält einen Anteil des Schlüssels; der andere Anteil liegt auf keinem der kompromittierten Systeme |
| API und Enclave beide kompromittiert | Angreifer erhält die verschlüsselte Nutzer-Nutzlast und den Server-Anteil — kann die Nutzer-Nutzlast aber weiterhin nicht ohne den PRF output vom physischen Authenticator entschlüsseln |
Das letzte Szenario ist das entscheidende. Selbst eine vollständige Kompromittierung der gesamten serverseitigen Infrastruktur reicht nicht aus, einen privaten Schlüssel zu rekonstruieren. Der Authenticator des Nutzers ist das kryptografische Tor, das kein serverseitiger Einbruch umgehen kann.
Informationstheoretische Sicherheit
Das Hybridmodell erbt dieselbe Klasse von Sicherheitsgarantie wie Shamir's Secret Sharing: Die Schlüsselaufteilung ist nicht nur rechnerisch sicher — sie ist informationstheoretisch sicher. Ein Angreifer mit unbegrenzter Rechenleistung, der das Material von zwei der drei Parteien hält, gewinnt keine Information über den privaten Schlüssel. Es gibt keinen Algorithmus, der bei beliebig viel Zeit oder Hardware den Schlüssel allein aus den Daten zweier Parteien ableiten kann. Das ist dieselbe Garantie wie bei einem One-Time Pad.
Keine Verwahrung durch Konstruktion
Wir betreiben sowohl die API als auch die Enclave. Trotzdem können wir nicht einseitig auf Nutzergelder zugreifen. Der PRF output des Nutzers ist das fehlende Stück — er wird in der Hardware des Nutzers erzeugt und nie übertragen. Unsere Unfähigkeit, auf Gelder zuzugreifen, ist keine Policy oder Zusage in den Nutzungsbedingungen. Es ist eine mathematische Zwangsbedingung, die unabhängig von internen Zugriffskontrollen, regulatorischem Druck oder Infrastruktur-Kompromiss gilt.
Wie eine Transaktion signiert wird
Die gesamte Signierung erfolgt auf dem Gerät des Nutzers. Der private Schlüssel wird auf keinem Server zusammengesetzt.
- Der Nutzer genehmigt eine Transaktion in der Anwendung. Das Gerät authentifiziert den Nutzer per Biometrie oder PIN.
- Das Gerät berechnet sein hardwaregebundenes PRF-Secret lokal. Dieses Secret verlässt das Gerät nie.
- Die Anwendung holt die verschlüsselte Nutzer-Nutzlast von der API und den Server-Anteil von der Enclave. Keines dieser Stücke ist für sich allein nutzbar.
- Auf dem Gerät des Nutzers, im RAM: Das Hardware-Secret entschlüsselt die Nutzer-Nutzlast und liefert den Schlüsselanteil des Nutzers. Die beiden Anteile werden zum vollen privaten Schlüssel kombiniert.
- Der private Schlüssel signiert die Transaktion — vollständig on-device.
- Der private Schlüssel wird sofort aus dem RAM gelöscht. Er wird nicht gecacht, nicht persistiert, nicht protokolliert.
Der vollständige private Schlüssel existiert nur Millisekunden lang, nur auf dem Gerät des Nutzers und nur während der Signieroperation. Kein Server sieht ihn jemals.
Export des privaten Schlüssels
Wenn ein Nutzer seinen privaten Schlüssel exportiert — etwa um zu einem anderen Wallet zu wechseln — gilt dasselbe Prinzip. Der Schlüssel wird rekonstruiert und vollständig auf dem Gerät des Nutzers bereitgestellt. Der Server liefert die verschlüsselten Anteile, Entschlüsselung und Zusammenbau erfolgen lokal. Zu keinem Zeitpunkt beim Export passiert der private Schlüssel durch einen Server oder wird für einen Server sichtbar.
Passkey-Sync und geräteübergreifender Zugriff
Moderne Plattformen — iCloud Keychain bei Apple, Google Password Manager unter Android — synchronisieren Passkeys über die Geräte eines Nutzers. Das hardwaregebundene Secret für die Schlüsselrekonstruktion gehört zum synchronisierten Passkey-Material, sodass derselbe PRF output auf jedem Gerät in der Sync-Gruppe des Nutzers reproduzierbar ist. Damit bleibt das Dreiparteien-Sicherheitsmodell über Geräte hinweg erhalten: Jedes synchronisierte Gerät kann an der Signierung teilnehmen, ohne Änderung der serverseitigen Architektur.
Nutzer werden darüber informiert, ob ihr Passkey mit ihrem Cloud-Konto synchronisiert wurde, damit sie jederzeit Einblick in die Wiederherstellbarkeit ihres Wallets haben.
PRF-Unterstützung gibt es unter iOS 18+, macOS Sequoia 15.4+, Android 14+ und YubiKey der 5er-Serie. Auf Plattformen ohne PRF-Unterstützung wird ein serverseitiger Signing-Fallback verwendet.
Vergleich mit herkömmlicher Wallet-Sicherheit
| Modell | Ort des privaten Schlüssels | Wer kann auf Gelder zugreifen |
|---|---|---|
| Standard-Self-Custody (Seed Phrase) | Vom Nutzer gespeichert | Jeder mit der Seed Phrase |
| Exchange / Hot-Wallet-Verwahrung | Vom Betreiber gespeichert | Betreiber (und wer den Betreiber kompromittiert) |
| Hardware-Wallet | Auf dem Gerät gespeichert | Jeder mit physischem Gerät + PIN |
| Dieses System | Nirgends vollständig gespeichert | Erfordert gleichzeitig den Authenticator des Nutzers live und die Server-Infrastruktur |
Zusammenfassung
Dieses Hybridmodell — PRF-basierte Client-seitige Verschlüsselung, Secret Sharing und eine isolierte Enclave — verteilt Vertrauen auf drei wirklich unabhängige Parteien, sodass keine Zweier-Teilmenge einen privaten Schlüssel rekonstruieren kann, mit derselben informationstheoretischen Sicherheitsgarantie wie Shamir's Secret Sharing. Das biometriegebundene Hardware-Secret des Nutzers ist der kryptografische Anker des gesamten Systems. Serverseitige Infrastruktur kann, egal wie gründlich sie kompromittiert ist, keine gültige Signatur ohne physische Beteiligung des Nutzers erzeugen.