---
title: "Cold Wallets: Offline-Signatur, Wiederherstellung und Betriebskontrollen"
description: "Lernen Sie, wie man Cold-Wallet-Verwahrung über Schlüsselerstellung, Wallet-Identität, Backups, Transaktionsprüfung, Offline-Signaturen, Multisig, Wiederherstellung und Vorfallreaktion entwirft und überprüft."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Cold Wallets: Offline-Signatur, Wiederherstellung und Betriebskontrollen
> Nur zu Bildungszwecken; keine Anlageberatung. Investieren kann zu Verlusten führen.
## Direkte Antwort
Eine Cold Wallet ist ein Verwahrungssystem, das geheimes Signiermaterial und den entscheidenden Freigabeschritt außerhalb der normalen Angriffsfläche internetverbundener Software hält. Die Assets bleiben auf der Blockchain; das System kontrolliert Schlüssel oder andere Befugnisse, die Zustandsänderungen autorisieren können. „Cold Wallet“ ist eine betriebliche Bezeichnung, keine vom Protokoll definierte Geräteklasse. Der Cold-Storage-Status hängt vom gesamten Ablauf ab, nicht von Marke oder Verbindungstyp.
Ein Hardware-Signer kann Cold Storage auch bei einer USB-Verbindung unterstützen, wenn der private Schlüssel isoliert bleibt. Der Ablauf ist dennoch unsicher, wenn der Nutzer ein ungeprüftes Ziel oder einen undurchsichtigen Contract-Aufruf signiert. Umgekehrt ist ein Air-Gap-Computer nicht allein wegen der fehlenden Netzwerkschnittstelle sicher: Kompromittierte Entropie, Installationsmedien, Transaktionsparser, Wechseldatenträger, Backups oder Displays können die Grenze durchbrechen. Cold Storage senkt das Risiko einer entfernten Schlüsselentnahme, beweist aber weder Transaktionsabsicht noch Softwarekorrektheit, Wiederherstellbarkeit, Privatsphäre oder Finalität.
Die Wiederherstellungskopie ist nicht „nur ein Backup“. Ein Mnemonic, roher Seed, erweiterter privater Schlüssel oder ein gleichwertiger Wiederherstellungsanteil kann die Ausgabeberechtigung wiederherstellen und muss daher vergleichbar mit einem Signierer geschützt werden. Eine Passphrase, ein Ableitungspfad, Netzwerk, Skripttyp, Wallet-Deskriptor, Schlüsselreihenfolge und Schwellenwertrichtlinie können ebenfalls notwendig sein, um die erwarteten Adressen wiederherzustellen. Eine öffentliche Watch-Only-Wallet kann normalerweise nicht signieren, aber ein `xpub` oder Deskriptor kann Adressbeziehungen und Transaktionsverläufe offenlegen, und BIP-32 liefert erweiterte öffentliche Schlüssel mit stärkeren Sicherheitsimplikationen als gewöhnliche öffentliche Schlüssel.
## Wie man Kaltlager gestaltet und überprüft
### 1. Berechtigungen und Bedrohungsmodell festlegen
Erfassen Sie das genaue Netzwerk, die Vermögenswerte, das Konto oder die Ausgabepolitik, Eigentümer, Begünstigte, Wiederherstellungsbehörde, erwartete Transaktionshäufigkeit und maximale operative Belastung. Identifizieren Sie Remote-Malware, bösartige Anwendungen, Lieferkettenkompromittierungen, Insider-Zusammenarbeit, physischen Diebstahl, Nötigung, Feuer, Flut, Verlust, Arbeitsunfähigkeit und Erbschaften als separate Bedrohungen. Entscheiden Sie, was kalt bleiben muss: ein einzelner privater Schlüssel, alle Schlüssel in einem Schwellenwert, ein Quorum von Unterzeichnern, ein EIP-712-Autorisierungsschlüssel oder ein Administrator, der in der Lage ist, Wallet-Code zu ändern.
### 2. Vertrauenswürdige Entropie und Software initialisieren
Beschaffen Sie Geräte und Software über authentifizierte Kanäle, prüfen Sie den Initialisierungszustand, verifizieren Sie unterstützte Releases und lehnen Sie jede in der Verpackung oder von Dritten vorgefertigte Mnemonic beziehungsweise jedes Geheimnis ab. Erzeugen Sie Entropie kontrolliert und dokumentieren Sie Standard und Implementierung. BIP-39 kodiert `128` bis `256` Bit Entropie als Mnemonic und leitet einen `512-bit` Seed aus Mnemonic plus optionaler Passphrase ab; es ist kein Standard, der einen selbst erdachten Merksatz in eine sichere Wallet verwandelt.
### 3. Reproduzierbare Wallet-Identität festschreiben
Dokumentieren Sie vor einer größeren Einzahlung Netzwerk, Master-Fingerprint, Ableitungsstandard und vollständigen Pfad, Kontoindex, Adress- oder Skripttyp sowie erste verifizierte Empfangsadressen. Bewahren Sie für Bitcoin-Richtlinien Output-Deskriptor, Prüfsumme, Schlüsselherkünfte, Schwelle, Signer-Anzahl, Schlüsselreihenfolge und Wechselgeldzweige auf. Jeder Signer bestätigt seinen Schlüssel und die angezeigte Richtlinie unabhängig. Behandeln Sie ein `xpub` als sensible Metadaten: Es kann nicht gehärtete öffentliche Nachkommen ableiten, die Privatsphäre beeinträchtigen und zusammen mit einem passenden nicht gehärteten privaten Kindschlüssel den übergeordneten erweiterten privaten Schlüssel nach BIP-32 offenlegen.
### 4. Sicherung und Wiederherstellung testen
Schützen Sie jede erforderliche Wiederherstellungseingabe, einschließlich des Mnemonics oder der Anteile, der optionalen Passphrase, des Deskriptors oder der Smart-Account-Konfiguration, des Ableitungspfads und der Wiederherstellungsanweisungen. Erfinden Sie kein Schema, indem Sie Mnemonic-Wörter in ad-hoc-Fragmente aufteilen; verwenden Sie eine spezifizierte Schwelle oder ein Multisig-Design, wenn keine einzelne Kopie ausreichen sollte. Platzieren Sie Kopien in wirklich unabhängigen Ausfallbereichen und verfolgen Sie den Zugriff, ohne deren Inhalte preiszugeben. Üben Sie auf einem vertrauenswürdigen Ersatzgerät oder einem neu initialisierten Signierer die Wiederherstellung und vergleichen Sie den erwarteten Fingerabdruck, die Richtlinie und die Empfangsadresse, bevor Sie die Testumgebung löschen.
### 5. Vollständige Signaturabsicht erstellen und prüfen
Ein Online-Koordinator kann den Chain-Zustand abrufen und eine unsignierte Anfrage erstellen, ist aber nicht vertrauenswürdig. Prüfen Sie bei einer Bitcoin-`PSBT` Netzwerk, jeden Input und UTXO-Betrag, Empfänger-Output, Betrag, Gebühr, Gebührensatz, Locktime, Sighash-Richtlinie und ob jeder weitere Output authentifiziertes Wechselgeld ist. Prüfen Sie bei einer EVM-Transaktion `chainId`, `nonce`, `to`, `value`, Gaslimit, Gebührenobergrenzen und dekodierte `data`; bei EIP-712 Domain, `chainId`, `verifyingContract`, Nachrichtenfelder, Nonce und gegebenenfalls Frist. EIP-712 strukturiert Daten und trennt Domains, bietet allein aber ausdrücklich keinen Replay-Schutz.
### 6. Über eine kontrollierte Übertragungsgrenze signieren
Bewegen Sie nur die erforderliche nicht signierte oder teilweise signierte Nutzlast durch den genehmigten QR, Karte, Kabel oder einen anderen Kanal. Luftspalten und QR-Codes machen Parser oder Medien nicht vertrauenswürdig: Der Unterzeichner muss die Nutzlast analysieren, Richtlinien und Änderungen authentifizieren, materielle Konsequenzen anzeigen und nicht unterstützte Felder ablehnen. Bei Multisignaturen halten Sie Unterzeichner, Betreiber, Standorte, Anbieter und Wiederherstellungspfade unabhängig genug, um dem Bedrohungsmodell zu entsprechen; behandeln Sie den Koordinator als austauschbar und unfähig, die Richtlinie unbemerkt zu ändern. Vergleichen Sie die signierte Transaktion oder Operation vor der Übertragung mit der genehmigten Absicht.
### 7. Abgleichen, pflegen und Migration vorbereiten
Nach der Übertragung vergleichen Sie die Transaktionskennung, die enthaltene Transaktion, Ausgänge oder Protokolle, die tatsächliche Gebühr, das Wechselgeld, die Kontonummer, Berechtigungen und die resultierenden Salden mit der unterzeichneten Absicht, und warten Sie dann auf die für die Kette und den Anwendungsfall geeignete Endgültigkeit. Halten Sie kompatible Software, verifizierte Firmware-Pfade, lesbare Sicherungskopien, dokumentierte Deskriptoren und regelmäßige Wiederherstellungsübungen aufrecht, ohne Produktionsgeheimnisse auf einem Online-Gerät einzugeben. Wenn irgendein Signatur- oder Wiederherstellungsgeheimnis exponiert werden könnte, kann ein einfaches Einzel-Schlüssel-Konto diesen Schlüssel nicht widerrufen: Stellen Sie neue Autorität her, migrieren Sie Vermögenswerte und Rollen, widerrufen Sie verbleibende Berechtigungen, wo das Protokoll dies zulässt, und bewahren Sie einen Vorfallbericht auf.
## Beispielaufgaben
### Gestufte Zuweisung und Finanzierung
Ein Verwahrungsplan begrenzt die Online-Interaktions-Wallet auf `5%` von `100,000 units` des Vermögenswertwerts: `100,000 × 5% = 5,000 units` heiß und `95,000 units` kalt. Das kalte Ziel erhält zuerst einen `100-unit`-Test, und die verbleibende Übertragung ist `95,000 - 100 = 94,900 units`. Nach beiden Übertragungen beträgt das Ziel des kalten Guthabens `100 + 94,900 = 95,000 units`; der kleine Test begrenzt einen Einrichtungsfehler, validiert jedoch keine zukünftigen Signaturen oder die Wiederherstellung aus dem Backup.
### Bitcoin PSBT Gebühr und Änderung
Ein `PSBT` verwendet Eingaben von `0.80 BTC` und `0.35 BTC`, insgesamt `1.15 BTC`. Es zahlt `1.00 BTC` an den Empfänger und schätzt `250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC`. Das authentifizierte Wechselgeld muss daher `1.15 - 1.00 - 0.000020 = 0.149980 BTC` betragen. Wenn der Unterzeichner diesen Wechselgeldausgang anhand seiner aufgezeichneten Richtlinie nicht identifizieren kann, sollte er nicht unterschreiben, auch wenn die gesamte Arithmetik ausgeglichen ist.
### EVM maximales Budget versus tatsächliche Gebühr
AnEVMKonto beginnt mit`5 ETH`und genehmigt eine Übertragung von`1.2 ETH`. A`30,000 gas`Grenze und`50 gwei`maximale Gebühr bedeutet ein Gebührenbudget von`30,000 × 50 gwei = 0.001500 ETH`. Wenn die Transaktion verwendet`21,000 gas`zu einem effektiven Preis von`25 gwei`, die tatsächliche Gebühr beträgt`21,000 × 25 gwei = 0.000525 ETH`, verlassen`5 - 1.2 - 0.000525 = 3.799475 ETH`. Der Unterzeichner muss die Gebührenobergrenzen überprüfen und`data`, nicht davon ausgehen, dass das maximale Budget belastet wird oder dass eine leer wirkende Oberfläche eine gewöhnliche Übertragung beweist.
### Zwei-von-drei-Signer-Resilienz
Eine `2-of-3`-Policy mit den Unterzeichnern `A`, `B` und `C` hat `3` gültige Signierpaare: `AB`, `AC` und `BC`. Wenn ein Unterzeichner nicht verfügbar ist, bleibt genau ein `1`-Paar; wenn ein Unterzeichner kompromittiert ist, kontrolliert dieser Unterzeichner allein `0` gültige Paare; wenn zwei Unterzeichner kompromittiert sind, kontrollieren sie `1` gültiges Paar und können ausgeben. Das Design toleriert daher einen Verlust oder eine isolierte Kompromittierung, nicht zwei, und die Wiederherstellung erfordert immer noch den korrekten Descriptor, die Ableitungsdaten und die Schlüsselreihenfolge.
## Risiken und Prüfungsfehler
- **Falsches Netzwerk oder falsche Richtlinie:** Wird ein gültiger Schlüssel mit der falschen Chain, Adressart, dem falschen Skript, Konto oder Smart-Account-Regelwerk wiederhergestellt, entstehen andere oder unbrauchbare Adressen.
- **Unzureichende Entropie:** Vorhersagbarer Zufall, ein Brainwallet oder ein kompromittierter Generator kann auch einen Offline-Schlüssel erratbar machen.
- **Von Dritten geliefertes Geheimnis:** Eine vorgedruckte, importierte, fotografierte oder von Helfern bereitgestellte Mnemonic kann bereits unter Kontrolle eines Angreifers stehen.
- **Offengelegtes Backup:** Papier, Metall, Cloud-Kopien, Drucker, Kameras, Versandwege oder Nachlassunterlagen können die vollständige Ausgabebefugnis preisgeben.
- **Passphrasenfehler:** Eine verlorene oder falsch eingegebene BIP-39-Passphrase kann ohne Fehlermeldung eine andere Wallet ableiten.
- **Abweichende Ableitungsparameter:** Fehlende Pfade, Coin-Typen, Kontoindizes oder Wallet-Konventionen können wiederherstellbare Assets verbergen.
- **Verlust der Konfiguration:** Multisig-Schlüssel ohne Deskriptor, Schwelle, Skripttyp, Schlüsselherkunft und Reihenfolge stellen die finanzierte Wallet womöglich nicht wieder her.
- **Offengelegte öffentliche Metadaten:** Ein `xpub`, Deskriptor, Adressbestand oder eine Koordinator-Datenbank kann Salden, Zusammenhänge und künftige Adressen offenlegen.
- **Kompromittierte Lieferkette:** Manipulierte Hardware, Firmware, Software, Verpackung oder Update-Kanäle können Entropie, Adressen oder Signaturen austauschen.
- **Ersetzung durch den Host:** Der Online-Koordinator kann Empfänger, Betrag, Gebühr, Wechselgeld, Calldata, typisierte Nachricht oder unsignierte Nutzlast ersetzen.
- **Unzureichende Anzeige:** Kürzung, Blind Signing, nicht unterstützte Skripte oder unvollständige Dekodierung können wesentliche Berechtigungen verbergen.
- **Angriff auf die Wechselgeldadresse:** Prüft der Signer das Wechselgeld nicht gegen die Richtlinie, kann eine Bitcoin-Transaktion es an einen Angreifer senden.
- **Gebühren- oder Nonce-Fehler:** Überhöhte Gebühren, alte EVM-Nonces, falsche Locktimes oder unerwartete Sighash-Modi können die Ausführung verzögern, ersetzen oder verändern.
- **Fortbestehende Vertragsberechtigung:** Token-Freigaben, Permits, Module, Delegationen und Administratoraufrufe können länger als die sichtbare Transaktion gelten.
- **Angriff auf den Übertragungskanal:** QR, USB, Speicherkarten, Kabel und Parser-Formate können schädliche Nutzlasten oder Metadatenabfluss transportieren.
- **Korrelierte Schwelle:** Signer am selben Ort, gemeinsame Seeds oder ein einziger Anbieter, Betreiber oder Wiederherstellungsort schwächen die Unabhängigkeit der Schwelle.
- **Physischer Angriff:** Diebstahl, Nötigung, Überwachung, Manipulation und Entdeckung von Geheimnissen bleiben ohne Netzwerkzugang möglich.
- **Umweltschaden:** Feuer, Hochwasser, Korrosion, Medienalterung, unzugängliche Tresore, Tod oder Handlungsunfähigkeit können korrekte Geheimnisse unerreichbar machen.
- **Nachlassende Kompatibilität:** Alte Firmware, nicht unterstützte Ableitungen oder Skripte und undokumentierte Migrationen können spätere Wiederherstellung oder Signatur verhindern.
- **Unvollständige Incident Response:** Wer nur den Saldo prüft, ohne Schlüssel, Rollen, Freigaben und Wiederherstellungsrechte zu migrieren, lässt die ursprüngliche Kompromittierung möglicherweise aktiv.
## Häufige Missverständnisse
### Muss eine Cold Wallet dauerhaft physisch getrennt bleiben?
Nein. Die Sicherheits-Eigenschaft besteht darin, dass geheime Befugnisse isoliert bleiben und das Signieren durch eine kontrollierte, überprüfbare Grenze erfolgt. Ein kabelgebundener Hardware-Signer kann diese Eigenschaft bewahren; ein luftisolierter Computer mit kompromittierter Einrichtung oder Überprüfung des Payloads möglicherweise nicht.
### Werden Münzen im Hardware-Gerät aufbewahrt?
Nein. Der Blockchain-Zustand erfasst die Vermögenswerte. Das Gerät schützt oder nutzt eine Berechtigung, die Transaktionen signieren kann, und kompatibles Wiederherstellungsmaterial kann diese Berechtigung auf einer anderen Implementierung reproduzieren.
### Ist ein mnemonisches Backup weniger sensibel als das Signiergerät?
Nein. Ein vollständiges Mnemonik und das erforderliche Passwort können die Wallet wiederherstellen. Ein Backup ist normalerweise inaktiv, aber seine Kompromittierung kann genauso entscheidend sein wie die Extraktion des aktiven Signierschlüssels.
### Entfernt Multisig die Notwendigkeit für Backups und Konfigurationsaufzeichnungen?
Nein. Schwellenwerte verringern ausgewählte einzelne Ausfallpunkte, aber jeder Schlüssel benötigt einen Wiederherstellungsplan und die Wallet-Richtlinie oder der Descriptor muss reproduzierbar sein. Zu wenige überlebende Schlüssel oder eine verlorene Konfiguration können immer noch Guthaben sperren.
### Beweist ein erfolgreicher Testtransfer, dass das Kaltlagerungssystem sicher ist?
Nein. Es bestätigt zu einem Zeitpunkt einen begrenzten Pfad. Es beweist nicht die Qualität der Entropie, die Geheimhaltung der Sicherung, die Wiederherstellung, die Dekodierung zukünftiger Transaktionen, die Unabhängigkeit des Quorums, Software-Updates, die Sicherheit von Verträgen oder die Vorfallwiederherstellung.
## Verwandte Themen
- [Hardware-Wallet](/de/crypto/hardware-wallet/)
- [Seed-Phrase](/de/crypto/seed-phrase/)
- [Öffentliche und private Schlüssel](/de/crypto/public-private-key/)
- [Multisig-Brieftasche](/de/crypto/multisig-wallet/)
- [Transaktionssimulation](/de/crypto/transaction-simulation/)
## Quellen
- [Übersicht über die Blockchain-Technologie](https://doi.org/10.6028/NIST.IR.8202) - NIST (zugegriffen: 2026-08-19)
- [BIP 32: Hierarchische deterministische Geldbörsen](https://bips.dev/32/) - Bitcoin Verbesserungsvorschläge (zugegriffen: 2026-08-19)
- [BIP 39: Merksatzcode zur Erzeugung deterministischer Schlüssel](https://bips.dev/39/) - Bitcoin Verbesserungsvorschläge (zugegriffen: 2026-08-19)
- [BIP 44: Multi-Konto-Hierarchie für deterministische Wallets](https://bips.dev/44/) - Bitcoin Verbesserungsvorschläge (zugegriffen: 2026-08-19)
- [BIP 174: Teilweise signiertes Bitcoin Transaktionsformat](https://bips.dev/174/) - Bitcoin Verbesserungsvorschläge (zugegriffen: 2026-08-19)
- [BIP 380: Allgemeine Funktionsweise von Output-Skript-Deskriptoren](https://bips.dev/380/) - Bitcoin Verbesserungsvorschläge (zugegriffen: 2026-08-19)
- [BIP 129: Bitcoin Sichere Multisig-Einrichtung](https://bips.dev/129/) - Bitcoin Verbesserungsvorschläge (zugegriffen: 2026-08-19)
- [EIP-712: Typisierte strukturierte Daten-Hashing und -Signierung](https://eips.ethereum.org/EIPS/eip-712) - Ethereum Verbesserungsvorschläge (zugegriffen: 2026-08-19)
Source: https://wiki.fcontext.com/de/crypto/cold-wallet/index.mdx