Web3 expandiert rasant: Täglich entstehen neue Anwendungen, Protokolle und Funktionen. Für viele Nutzer liegt die eigentliche Eintrittsbarriere jedoch nicht in mangelnder On-Chain-Funktionalität, sondern in der Herausforderung, Wallet-Schlüssel sicher aufzubewahren und wiederherzustellen.
Der aktuelle Industriestandard ist nach wie vor die Seed-Phrase (Mnemonic). Dieser Ansatz bringt jedoch reale Probleme mit sich: Nutzer erstellen oft Screenshots ihrer Phrasen und synchronisieren sie versehentlich mit Cloud-Alben; andere schreiben sie auf Papier, nur um diese zu verlieren oder zu beschädigen, was zum dauerhaften Verlust von Vermögenswerten führt. Solche Geschichten sind allzu häufig. Oft entstehen diese Risiken nicht durch technische Ausfälle, sondern durch Nachlässigkeiten in den täglichen Gewohnheiten.
In den letzten Jahren ist eine wachsende Zahl von Wallet-Lösungen im „Web2-Stil" entstanden, die es Nutzern ermöglichen, Wallets mit vertrauten Anmeldemethoden zu erstellen, zu sichern und wiederherzustellen. Obwohl ihr Ziel die Senkung der Eintrittsbarriere ist, gibt es erhebliche Unterschiede in der Implementierung – insbesondere, ob sie wirklich dezentralisiert und selbstverwahrt (self-custodial) bleiben.
Das Risiko der zentralisierten Aufteilung (Sharding): Einige Lösungen teilen den privaten Schlüssel in mehrere „Anteile" oder „Shards" auf. Die Aufteilung selbst ist nicht das Problem. Das kritische Risiko entsteht, wenn eine einzelne teilnehmende Entität (wie das Backend des Dienstanbieters) genügend Anteile hält, um den Wiederherstellungsschwellenwert zu erreichen. In diesem Fall besitzen sie technisch die Fähigkeit, den vollständigen Schlüssel zu rekonstruieren, wodurch „Self-Custody" zu einer bloßen formellen Zusage wird.
Das Risiko von HSM-Abhängigkeiten: Andere Lösungen speichern private Schlüssel in Hardware Security Modules (HSMs) und behaupten, sie würden Transaktionen nur nach strengen Regeln signieren. Obwohl dies solide klingt, kann die Regelsetzung oder die Ausführung der Richtlinie außerhalb der vertrauenswürdigen Grenze (d.h. außerhalb des HSM) in extremen Szenarien umgangen oder manipuliert werden, was zu Signaturen führt, die nicht der Absicht des Nutzers entsprechen.
Wie sich das Keyless Wallet von OneKey unterscheidet
Das Keyless Wallet von OneKey verwendet einen Ansatz „Google/Apple Login + PIN", der Benutzerfreundlichkeit mit echter Self-Custody in einem einzigen Design vereint.
Sie führen Login und Wiederherstellung über vertraute Kontosysteme durch, aber die zugrunde liegende Architektur verwendet einen verteilten Schlüsselverwaltungs- und Signierungsmechanismus. Dies stellt sicher, dass keine einzelne Partei – einschließlich OneKey – Ihren vollständigen Schlüssel rekonstruieren oder einseitig Überweisungen initiieren kann.
Mit anderen Worten: Selbst wenn unsere Server, eine bestimmte Komponente oder eine einzelne teilnehmende Entität kompromittiert würden, könnte ein Angreifer nicht einfach in OneKey einbrechen, um „Ihre Wallet zu stehlen".
Die Lösung von OneKey
Das Keyless Wallet von OneKey basiert auf einem verteilten Schlüsselverwaltungsmechanismus. Sein Ziel ist es, Sie von der hochriskanten Last des Aufschreibens, Speicherns und Transportierens von Seed-Phrasen zu befreien. Stattdessen können Sie Ihr Wallet mit einer Methode erstellen und wiederherstellen, die Sie bereits kennen: Google / Apple Login + PIN.
Reduzierte Belastung, kompromisslose Self-Custody
Traditionelle Wallets basieren auf Seed-Phrasen (typischerweise 12 oder 24 Wörter), die erfordern, dass Nutzer sie sicher speichern und bei Bedarf manuell wiederherstellen. Das Keyless Wallet ermöglicht Ihnen die Verwaltung Ihrer Vermögenswerte durch einfaches Erinnern an eine PIN. Die Fähigkeit zur Wiederherstellung Ihres Wallets basiert auf einer verteilten Architektur, die sicherstellt, dass die vollständige Kontrolle niemals an einen einzigen Dienstanbieter übergeben wird.
Zwei-Faktor-Authentifizierung: Konto + PIN
Das Keyless Wallet verwendet zwei Authentifizierungsfaktoren:
Ihr Google / Apple-Konto
Ihre PIN
Das bedeutet, dass selbst wenn Ihr Google- oder Apple-Konto kompromittiert wird, kritische Operationen nicht ohne die PIN durchgeführt werden können. Umgekehrt reicht das alleinige Vorhandensein der PIN nicht aus, um auf das Wallet zuzugreifen oder es wiederherzustellen, ohne sich in das zugehörige Konto einzuloggen. Beide Faktoren sind unverzichtbar und reduzieren das Risiko eines Single Point of Failure erheblich.
Die Seed-Phrase erscheint erst nach Verifizierung
Beim Design des Keyless Wallets wird die vollständige Seed-Phrase oder der private Schlüssel über längere Zeiträume nicht an einem einzigen Ort im Klartext gespeichert. Erst wenn Sie sowohl Ihr Konto als auch Ihre PIN auf Ihrem Gerät erfolgreich verifiziert haben, schließt das Wallet die notwendigen Wiederherstellungs- und Aktivierungsprozesse lokal ab.
So funktionieren Backup und Wiederherstellung:
Verschlüsselte Speicherung: Daten, die sich auf die Seed-Phrase beziehen, werden verschlüsselt auf dem Server gespeichert, um die Verfügbarkeit zu gewährleisten (z. B. für die Wiederherstellung auf mehreren Geräten).
Sharding-Mechanismus: Die kritischen Materialien, die zur Entschlüsselung erforderlich sind, werden auf mehrere Parteien oder Knoten aufgeteilt und verteilt.
Daher kann keine einzelne Partei (einschließlich OneKey) den Schlüssel einseitig in einen verwendbaren Klartextschlüssel rekonstruieren, es sei denn, Sie führen die Verifizierung durch und lösen die Wiederherstellung auf Ihrem Gerät aus.
Technische Tiefenanalyse
Dieser Abschnitt erklärt, was auf der Client-Seite (Ihrem Gerät) und auf der Server-Seite geschieht, wenn Sie ein neues Keyless Wallet mithilfe von Google oder Apple erstellen. Er verdeutlicht auch, warum die Prozesse „Backup" und „Wiederherstellung" benutzerfreundlich sind und gleichzeitig sicherstellen, dass keine einzelne Partei jemals Zugriff auf Ihren vollständigen privaten Schlüssel hat.
Sichern eines Keyless Wallets
Während des Onboarding-Prozesses zur Erstellung eines Keyless Wallets können Sie:
Auf dem Startbildschirm „Mit Google fortfahren" auswählen.
Oder auf die Schaltfläche „•••" tippen → Keyless Wallet → Google oder Apple auswählen.
Wichtiger Hinweis: Das Keyless Wallet und traditionelle Seed-Phrase-Wallets sind zwei getrennte, unabhängige Systeme. Derzeit wird die Migration eines „bestehenden Seed-Phrase-Wallets" zu einem Keyless Wallet nicht unterstützt; sie existieren parallel.
Gehen wir den technischen Prozess durch, der abläuft, wenn ein Nutzer ein Wallet mithilfe seines Google- oder Apple-Kontos erstellt.
Schritt 1 — Generierung, Verschlüsselung und Speicherung des Seed-Chiffretextes auf dem Gerät
Lokale Generierung: Das Gerät generiert lokal eine neue Seed-Phrase (die als zufällige Quelle für das Schlüsselmaterial des Wallets dient).
Erstellung des symmetrischen Schlüssels: Gleichzeitig generiert das Gerät einen symmetrischen Schlüssel.
Verschlüsselung: Das Gerät verwendet diesen symmetrischen Schlüssel, um die Seed-Phrase zu verschlüsseln und so den Seed-Chiffretext zu erzeugen.
Sichere Speicherung: Nur der Seed-Chiffretext wird zur sicheren Speicherung an das OneKey-Backend gesendet (zur Gewährleistung der Verfügbarkeit für die geräteübergreifende Wiederherstellung).
Wichtige Punkte:
Nur lokale Verarbeitung: Sowohl die Seed-Phrase im Klartext als auch der symmetrische Schlüssel werden ausschließlich auf dem Gerät generiert und verarbeitet. Sie werden niemals direkt vom Gerät übertragen.
Nicht verwendbarer Chiffretext: Der Chiffretext selbst kann nicht zum Signieren verwendet werden. Ohne den symmetrischen Schlüssel ist es unmöglich, den Chiffretext zurück in eine verwendbare Seed-Phrase oder Schlüsselmaterial zu entschlüsseln.
Schritt 2 — Aufteilung des symmetrischen Schlüssels in zwei „2-von-2"-Anteile
Zurück auf dem Gerät wird der symmetrische Schlüssel mithilfe von Shamir's Secret Sharing (SSS) mit einem Schwellenwert von 2-von-2 in zwei Anteile aufgeteilt:
Backend-Anteil: Wird vom OneKey-Backend gehalten.
Juicebox-Anteil: Wird im dezentralen Speicherprotokoll Juicebox gespeichert.
Wichtige Punkte:
Bei einem 2-von-2-Schwellenwert ist kein einzelner Anteil ausreichend, um den symmetrischen Schlüssel zu rekonstruieren. Selbst wenn OneKey sowohl den „Seed-Chiffretext" als auch den „Backend-Anteil" besitzt, kann es den Wallet nicht einseitig wiederherstellen oder eine Transaktionssignatur initiieren.
Schritt 3 — Schreiben des Netzwerkanteils in das verteilte Netzwerk, geschützt durch die PIN
Der Juicebox-Anteil wird in das Juicebox-Netzwerk geschrieben.
Der Nutzer legt eine PIN fest, die den Zugriff zum Abrufen dieses Anteils von Juicebox schützt.
Technische Implementierung: Der Anteil wird weiter in mehrere Unteranteile (Sub-shares) aufgeteilt und zur Speicherung auf verschiedene Knoten verteilt. Um den Anteil abzurufen, muss die korrekte PIN eingegeben werden, um die Schwellenwert-Verifizierung des Netzwerks zu bestehen.
Wiederherstellung eines Keyless Wallets
Schritt 1 — Authentifizierung und Abruf des Seed-Chiffretextes + Backend-Anteils
Das Gerät führt die Authentifizierung mithilfe Ihres Google / Apple-Kontos durch.
Nach erfolgreicher Verifizierung ruft das Gerät zwei Datenelemente vom OneKey-Backend ab:
Seed-Chiffretext
Backend-Anteil
Schritt 2 — Eingabe der PIN zum Abrufen des Juicebox-Anteils
Sie geben Ihre PIN auf dem Gerät ein.
Das Gerät verwendet die PIN, um den Juicebox-Anteil aus dem dezentralen Speicherprotokoll Juicebox abzurufen.
Schritt 3 — Rekonstruktion des symmetrischen Schlüssels und Entschlüsselung
Das Gerät kombiniert den Backend-Anteil + Juicebox-Anteil, um den ursprünglichen symmetrischen Schlüssel zu rekonstruieren.
Es verwendet diesen symmetrischen Schlüssel, um den Seed-Chiffretext zu entschlüsseln und die ursprüngliche Seed-Phrase lokal auf dem Gerät wiederherzustellen.
Sobald die Wiederherstellung abgeschlossen ist, funktioniert das Wallet normal innerhalb der OneKey App, genau wie ein Standard-Wallet.
Umfassende Analyse
Endzustand (Datenverteilung)
Nutzer: Hat Zugriff auf sein Google / Apple-Konto und erinnert sich an die PIN.
OneKey Client (Gerät): Besitzt die verwendbare, entschlüsselte Seed-Phrase (vorübergehend zur Nutzung).
OneKey Server: Speichert den Chiffretext und den Backend-Anteil.
Juicebox-Bereiche: Speichern einzeln die Juicebox-Unteranteile (erforderlich zur Rekonstruktion des Juicebox-Anteils).
Sicherheitseigenschaften
Kompromittierung der OneKey-Serverdatenbank: Selbst wenn ein Angreifer Zugriff auf sowohl den Chiffretext als auch den Backend-Anteil erhält, kann er den symmetrischen Schlüssel nicht einseitig rekonstruieren. Daher ist es ihm unmöglich, die Seed-Phrase zu entschlüsseln.
Kompromittierung der Juicebox-Bereiche/Knoten: Solange ein Angreifer keine ausreichende Anzahl von Juicebox-Unteranteilen erhält (wodurch der Wiederherstellungsschwellenwert nicht erreicht wird), kann er den Juicebox-Anteil nicht wiederherstellen und somit nicht bei der Rekonstruktion des symmetrischen Schlüssels helfen.
Kompromittierung des Kontos: Der alleinige Zugriff auf das Google- oder Apple-Konto reicht nicht aus, um die Juicebox-Unteranteile von der Juicebox-Seite abzurufen. Der Abrufprozess wird streng durch die PIN geschützt; ohne die PIN kann die Wiederherstellungskette nicht abgeschlossen werden.
Sicherheit
Das Designziel des OneKey Keyless Wallets ist es, die Eintrittsbarriere zu minimieren, ohne die „Kontrolle" in die Hände einer einzelnen Partei zu zentralisieren. Da die Wallet-Wiederherstellung einer der sensibelsten Vorgänge ist, stellen wir die Sicherheitsprotokolle und Bedrohungsmodelle in den Mittelpunkt unseres Designs. Dadurch wird gewährleistet, dass verbesserte Benutzerfreundlichkeit nicht auf Kosten der Sicherheit geht.
Sicherheitsziele
Unsere Architektur ist darauf ausgelegt, die folgenden zwei kritischen Ziele zu erfüllen:
Kein einseitiger Zugriff: Kein Dritter (einschließlich OneKey) sollte in der Lage sein, den privaten Schlüssel oder die Seed-Phrase des Nutzers einseitig zu rekonstruieren oder zu verwenden.
Strikte Wiederherstellungsbedingungen: Der einzige Weg für einen Nutzer, sein Wallet wiederherzustellen, besteht darin, gleichzeitig zwei Verifizierungsanforderungen zu erfüllen:
Erfolgreiche Authentifizierung über sein Google / Apple-Konto;
Und Nachweis des Besitzes der PIN.
Warum OneKey Ihren Schlüssel (einseitig) nicht rekonstruieren kann
Um eine verwendbare Seed-Phrase oder Schlüsselmaterial auf Ihrem Gerät wiederherzustellen, müssen alle folgenden Elemente gleichzeitig vorhanden sein:
Der Seed-Chiffretext
Beide Anteile des symmetrischen Schlüssels (Backend-Anteil + Juicebox-Anteil)
Diese Architektur führt zu mehreren direkten Schlussfolgerungen:
Bösartige Akteure innerhalb von Juicebox: Wenn weniger als die Schwellenwertanzahl der Juicebox-Bereiche/Knoten bösartig handeln, kann der Angreifer keinen gültigen Juicebox-Anteil rekonstruieren und somit den symmetrischen Schlüssel nicht rekonstruieren.
Vollständige Kompromittierung des verteilten Netzwerks: Selbst im hypothetischen Szenario, dass das gesamte verteilte Sharding-Netzwerk kompromittiert wird, würde dem Angreifer immer noch der vom OneKey-Backend gehaltene Backend-Anteil oder der Chiffretext fehlen, was eine unabhängige Wiederherstellung unmöglich macht.
Kompromittierung des OneKey-Backends: Selbst wenn das OneKey-Backend angegriffen würde, würde dem Angreifer immer noch der auf der Juicebox-Seite gespeicherte Anteil fehlen. Ohne den Juicebox-Anteil reichen die Backend-Daten allein nicht aus, um den symmetrischen Schlüssel zu rekonstruieren oder den Seed-Chiffretext zu entschlüsseln.
Warum „Konto + PIN" beide unverzichtbar sind
Hinsichtlich Identität und Zugriffskontrolle trennt das Keyless Wallet „Wer Sie sind" (Kontoidentität) von „Was Sie wissen" (PIN):
Die Kontoseite: OneKey verwendet etablierte OAuth 2.0 Login-/Autorisierungsflüsse, um sich mit Google und Apple zur Identitätsprüfung und Autorisierung zu verbinden.
Die PIN-Seite: Die PIN schützt den Prozess des Abrufens des kritischen Anteils aus dem dezentralen Speicherprotokoll (Juicebox). Selbst wenn ein Angreifer Ihr Konto kompromittiert, kann er den entsprechenden Anteil nicht abrufen oder die Wiederherstellung abschließen, ohne die PIN zu kennen.
Verschlüsselung und Schlüsselverwaltung
Auf der Ebene der Verschlüsselung und Schlüsselaufteilung hält sich das Keyless Wallet an das Prinzip, dass „Chiffretext gespeichert werden kann, aber Schlüssel niemals zentralisiert werden dürfen":
Verschlüsselung der Seed-Phrase: Die Seed-Phrase/das Schlüsselmaterial wird mithilfe von authentifizierten Verschlüsselungsalgorithmen (AES-256) verschlüsselt, um den Chiffretext zu erzeugen und die Integritätsprüfung während der Wiederherstellung zu gewährleisten.
Schlüsselaufteilung und -rekonstruktion: Shamir's Secret Sharing (SSS) wird verwendet, um den symmetrischen Schlüssel gemäß den Schwellenwertregeln aufzuteilen und zu rekonstruieren.
Backend-Verschlüsselung im Ruhezustand: Auf dem Backend gespeicherte Anteile werden vor der Speicherung zunächst mithilfe von Cloud KMS und Verschlüsselungsalgorithmen verschlüsselt. Dies stellt sicher, dass während des gesamten Prozesses niemals Klartext sichtbar ist, was die Sicherheit der Schlüsseldaten garantiert.
Zuverlässigkeit
Ein kritischer Punkt beim Verständnis des OneKey Keyless Wallets ist, dass die Wiederherstellung von der gleichzeitigen Erfüllung von zwei Bedingungen abhängt: Sie müssen sich bei dem entsprechenden Google- oder Apple-Konto anmelden können UND Sie müssen sich an Ihre PIN erinnern.
Im Gegensatz zu traditionellen Web2 „Passwort vergessen"-Abläufen kann OneKey Ihre PIN nicht für Sie abrufen, noch kann es Ihren privaten Schlüssel oder Ihre Seed-Phrase in Ihrem Namen rekonstruieren. Dies ist kein Produktfehler, sondern ein bewusster Teil der Sicherheitsschranke: Wenn ein Dienstanbieter in der Lage wäre, auf eines dieser Elemente zuzugreifen, wäre das Kernmerkmal der „Self-Custody" grundlegend kompromittiert.
Daher erfordert eine echte „Zero Trust"-Lösung zwangsläufig, dass der Nutzer einen Teil der Verantwortung trägt: Zugriff auf Ihr Konto beibehalten und sich an Ihre PIN erinnern.
Was ist, wenn ich meine PIN vergesse?
Es gibt jedoch ein Sicherheitsnetz: Die Seed-Phrase für ein Keyless Wallet existiert in einer verwendbaren Form auf Geräten, auf denen Sie bereits angemeldet sind.
Wenn Sie Ihre PIN vergessen, aber noch Zugriff auf ein Gerät haben, auf dem das Wallet angemeldet und funktionstüchtig ist, können Sie die PIN normalerweise auf diesem Gerät zurücksetzen. Dieser Vorgang erstellt eine neue Backup-Konfiguration und stellt sicher, dass Sie die Fähigkeit zur geräteübergreifenden Wiederherstellung in Zukunft behalten.
Regelmäßige Erinnerungen zur PIN-Verifizierung
Um das Risiko zu verringern, dass Sie Ihre PIN im Laufe der Zeit vergessen, wird OneKey Sie in angemessenen Abständen auffordern, Ihre PIN zu verifizieren.
Wenn Sie bei einer dieser Überprüfungen feststellen, dass Sie sich nicht an Ihre PIN erinnern können, sollten Sie die Gelegenheit nutzen, Ihre PIN sofort zurückzusetzen, während Sie noch Zugriff auf das Gerät haben, und dann Ihre Backup-Konfiguration neu zu generieren/aktualisieren.
Die ultimative Grenze der Verfügbarkeit
Zusammenfassend lässt sich sagen, dass Sie im Allgemeinen den Zugriff auf Ihr Keyless Wallet behalten, solange Sie mindestens eine der folgenden Bedingungen erfüllen:
Sie besitzen noch ein funktionsfähiges, angemeldetes Gerät; ODER
Sie können sich bei Ihrem Google / Apple-Konto anmelden UND Sie erinnern sich an Ihre PIN (was Ihnen die Wiederherstellung auf einem neuen Gerät ermöglicht).
Unsere Empfehlung: Führen Sie eine „Geräteübergreifende Wiederherstellungsübung" durch
Da der Wiederherstellungsprozess im Wesentlichen nur „In Konto anmelden + PIN eingeben" ist, empfehlen wir dringend, dass Sie unmittelbar nach der Erstellung Ihres Keyless Wallets eine Wiederherstellungsübung auf einem zweiten Gerät durchführen.
Dadurch sichern Sie:
Einen Zugangspunkt auf Gerät A.
Einen Zugangspunkt auf Gerät B.
Bestätigte Zuversicht in Ihren Backup-Pfad (Konto + PIN) für die zukünftige Wiederherstellung auf neuen Geräten.
Fazit
Für viele neue Nutzer ist die Verwendung von Seed-Phrasen, obwohl sie der Industriestandard sind, oft alles andere als intuitiv. Die Eingabe einer Seed-Phrase auf einem neuen Gerät ist mit erheblichen Reibungsverlusten verbunden, und das Wissen, wie oder wo diese sicher zu speichern ist, führt häufig zu Verwirrung.
Das OneKey Keyless Wallet zielt darauf ab, eine andere Balance zu finden:
Es senkt die Eintrittsbarriere durch die Verwendung einer vertrauten Methode (Google / Apple + PIN). Gleichzeitig stellt es durch eine verteilte Schlüsselverwaltungsarchitektur sicher, dass keine einzelne Partei (einschließlich OneKey) Ihren vollständigen Schlüssel einseitig rekonstruieren kann. Dies erreicht einen Kompromiss zwischen „Benutzerfreundlichkeit" und den „Grenzen der selbstverwahrten Sicherheit", der für die breite Öffentlichkeit sehr gut geeignet ist.