Schlüsselverwaltung & Betriebssicherheit für Krypto-Zahlungen

Die meisten schwerwiegenden Vorfälle der Jahre 2025–2026 lassen sich letztlich auf Schlüssel oder Signaturen zurückführen — ein kompromittiertes Signing-Tool, ein geleakter Admin-Schlüssel oder ein durch Phishing manipulierter Operator. (Diese Fälle analysieren wir gesondert in unserem Überblick über aktuelle Krypto-Zahlungs-Hacks.) Der gemeinsame Nenner liegt meist darin, wie Schlüssel autorisiert, gespeichert oder zum Signieren verwendet werden.

Das Problem ist, dass Multisig, MPC, Hot/Cold-Wallets und HSM diskutiert werden, als wären sie gleichwertige Optionen auf derselben Ebene — dieses Verwechseln macht die Auswahl zum Chaos. Es handelt sich tatsächlich um drei unabhängige Dimensionen, und ein echtes Schlüsselverwaltungs-Setup ist eine Kombination aus allen dreien. Dieser Artikel arbeitet jede einzeln durch und behandelt dann die hybride Architektur, die Signing-Infrastruktur und operativen Standards, die das Ganze zusammenhalten, sowie die breitere operative Angriffsfläche — API- und Infrastruktur-Isolation, Personen und Anbieter, Domains und Identität sowie das neueste und am wenigsten verstandene Risiko: KI-Agenten mit Zugriff auf Ihre Gelder.

Private Schlüssel, Seed-Phrasen und warum „Es liegt auf meinem Gerät" keine Sicherheit bedeutet

Im Kern von allem steht der private Schlüssel: eine Zeichenkette kryptografischer Zufallszahlen. Wer ihn besitzt, kann Transaktionen signieren und die Gelder an der entsprechenden Adresse bewegen. Er ist die ultimative Kontrolle über die Gelder einer Adresse — und das ultimative einzelne Risikopunkt.

Eine Seed-Phrase (üblicherweise 12 oder 24 Wörter, der BIP-39-Standard) ist eine menschenlesbare Kodierung dieses privaten Schlüssels. Die „Hierarchisch Deterministische" (HD) Regel leitet Tausende von privaten Schlüsseln und Adressen aus einer einzigen Seed-Phrase ab. Das macht eine Seed-Phrase mindestens genauso sensibel wie einen einzelnen privaten Schlüssel, wenn nicht sogar sensibler: Verliert man einen privaten Schlüssel, verliert man eine Adresse; verliert man die Seed-Phrase, verliert man die gesamte Wallet.

Hier ist ein weit verbreitetes Missverständnis, das direkt angesprochen werden sollte: Manche nehmen an, dass nichts schiefgehen kann, solange sich das Signing-Gerät und die Wallet in den eigenen Händen befinden und der Schlüssel offline ist. Das Problem ist, dass private Schlüssel und Seed-Phrasen in gewöhnlichen Software- und Hardware-Wallets exportiert werden können. Jeder mit internem Zugriff auf das Gerät oder eine Sicherungskopie kann den privaten Schlüssel exportieren und kopieren und dann die Gelder von überall aus kontrollieren — ohne das „eigene" Gerät jemals zu berühren.

„Der Schlüssel liegt auf meinem eigenen Gerät" bedeutet also nicht „Niemand sonst kann ihn entnehmen." Was tatsächlich zählt, ist, ob der private Schlüssel exportiert werden kann. Wie Sie unten sehen werden, ist HSM die einzige Option, die den Export auf Hardware-Ebene blockiert.

Drei unabhängige Dimensionen, kein einziges Spektrum

Bevor Sie ein Setup auswählen können, hilft es, die drei Fragen zu trennen, die Sie tatsächlich beantworten.

Autorisierungsmodell: Single-Sig, Multisig oder MPC/TSS

Single-Sig bedeutet, dass ein einziger privater Schlüssel alles kontrolliert — das einfachste Setup und der größte einzelne Ausfallpunkt.

Multisig erfordert M von N unabhängigen privaten Schlüsseln zum gemeinsamen Signieren (z. B. 3-von-5), wobei jeder Unterzeichner einen vollständigen, unabhängigen privaten Schlüssel hält. Auf Chains, die Smart Contracts unterstützen, implementiert Contract-Multisig (Safe ist der De-facto-Standard) diese Logik in einem Contract, wobei Signaturen und Schwellenwertregeln öffentlich on-chain überprüfbar sind — auf Kosten höherer Gas-Gebühren pro Transaktion und einer Contract-Konfigurationsbearbeitung bei jeder Änderung der Unterzeichner. Es gibt hier auch eine leicht übersehene Schwäche: Die Signing-Infrastruktur für Contract-Multisig ist noch nicht ausgereift. Ein Safe-execTransaction-Aufruf erscheint auf einem Hardware-Wallet oft als langer Calldata-String, sodass Unterzeichner Schwierigkeiten haben zu sehen, was sie tatsächlich genehmigen, und die Ökosystem-Unterstützung für Clear Signing und Transaktions-Parsing ist noch begrenzt. Dies ist genau die beim Bybit-Vorfall ausgenutzte Angriffsfläche, weshalb Unternehmen, die Contract-Multisig einsetzen, häufig Drittanbieter für Transaktions-Parsing und Kreuzverifizierung hinzuziehen müssen, um die Lücke zu schließen. Chains wie Bitcoin hingegen unterstützen Multisig nativ auf der Script-Ebene, ohne Contract-Abhängigkeit.

MPC (Threshold Signatures, TSS) bedeutet nicht „einen vollständigen privaten Schlüssel in Stücke schneiden". Echtes MPC verwendet Distributed Key Generation (DKG): Der Schlüssel wird ab dem Moment seiner Erstellung verteilt, jede Partei hält einen unabhängigen Schlüsselanteil, und zu keinem Zeitpunkt existiert jemals ein vollständiger privater Schlüssel. Jede Partei berechnet eine Teil-Signatur aus ihrem Anteil, und diese Teil-Signaturen werden durch ein kryptografisches Protokoll zu einer einzigen Standardsignatur kombiniert — eine Berechnung, keine Verkettung von Byte-Strings — sodass das Ergebnis on-chain von einer gewöhnlichen Einzelsignatur nicht zu unterscheiden ist. Die Gas-Kosten sind normal, die chain-übergreifende Kompatibilität ist gut, und die Änderung von Unterzeichnern oder des Schwellenwerts erfordert keine Berührung eines Contracts.

Es lohnt sich, MPC/TSS von einer älteren, leicht zu verwechselnden Methode zu unterscheiden: Shamir Secret Sharing (SSS). SSS schneidet einen bereits existierenden vollständigen privaten Schlüssel in n Teile; zum Signieren werden genügend Teile zusammengeführt und der vollständige private Schlüssel vor dem Signieren im Speicher rekonstruiert — und dieser Moment der Rekonstruktion ist der einzelne Ausfallpunkt. TSS rekonstruiert nie; der vollständige private Schlüssel erscheint niemals. Das macht es sicherer als SSS.

Sowohl Multisig als auch MPC beseitigen Einzelpunkt-Risiken, nur durch unterschiedliche Mechanismen. Multisig besteht aus mehreren vollständigen Schlüsseln plus on-chain-Verifizierung: transparent, aber kostspielig und umständlich beim Wechsel von Unterzeichnern. MPC besteht aus mehreren Schlüsselanteilen plus off-chain-Kombination von Teil-Signaturen: flexibel und günstig, aber die Koordination hängt von Ihrer Infrastruktur ab.

Hardware-Schutz: Software, Hardware-Wallet, TEE oder HSM

Software-Speicherung hält den privaten Schlüssel auf einem Server oder in Software — die bequemste Option und die zerbrechlichste. Eine Hardware-Wallet (Ledger, Trezor und ähnliche) hält den Schlüssel in einem sicheren Chip, signiert innerhalb des Geräts und lässt den Schlüssel nie das Gerät verlassen.

TEE (Trusted Execution Environment) — denken Sie an Intel SGX, AWS Nitro oder Apple Secure Enclave — schafft einen isolierten, verschlüsselten Speicherbereich auf einer General-Purpose-CPU, wo Schlüssel und Signing-Berechnung selbst für einen Angreifer mit OS-Root unerreichbar bleiben. Es liegt zwischen Software und HSM: starke logische Isolation, gute Performance und in der Lage, beliebigen Code auszuführen (einschließlich MPC-Protokolle), obwohl physische Manipulationssicherheit und Compliance-Zertifizierung hinter HSM zurückbleiben. Dies ist auch die häufigste Art, MPC-Schlüsselanteile zu speichern — durch DKG innerhalb der Enclave generiert und nie daraus entfernt. Fireblocks verteilt beispielsweise MPC-Schlüsselanteile über SGX-Enclaves in mehreren Clouds.

HSM (Hardware Security Module) ist manipulationssichere Hardware auf Enterprise-Niveau, die Zertifizierungen wie FIPS 140-2/3 erfüllt, mit physischer Manipulationssicherheit und automatischem Löschen bei Eindringen. Seine stärkste Garantie: Der private Schlüssel wird innerhalb der Hardware generiert, als nicht exportierbar markiert und kann das Gerät physisch nicht verlassen. Das ist das, was ihn grundlegend von Software- und Hardware-Wallets unterscheidet, und deshalb eignet sich HSM für die Verwahrung hochwertiger vollständiger privater Schlüssel.

Diese Dimension ist orthogonal zum obigen Autorisierungsmodell: Jeder vollständige Schlüssel in einem Multisig kann in einer Hardware-Wallet oder einem HSM liegen, während jeder MPC-Anteil normalerweise in einer TEE-Enclave lebt.

Fonds-Temperatur: Hot, Warm oder Cold

Diese Dimension kümmert sich nicht darum, wie der Schlüssel gespeichert wird — nur darum, wie sehr der private Schlüssel dem Internet ausgesetzt ist, das heißt, wie schnell und wie automatisch das Geld bewegt werden kann.

Hot Wallets sind immer online, werden für sofortige Zahlungen und automatisierte Auszahlungen verwendet — am schnellsten und am risikoreichsten, halten normalerweise nur einen einstelligen Prozentsatz der Gesamtgelder. Warm Wallets sind online, aber mit dem in einer geschützten Umgebung isolierten privaten Schlüssel (einem dedizierten Signing-Service oder HSM), der einen Menschen im Signing-Loop erfordert; diese wickeln den täglichen operativen Settlement ab. Cold Wallets sind vollständig offline und air-gapped, werden für die Langzeitspeicherung großer Reserven verwendet — höchste Sicherheit, langsam in der Nutzung und halten normalerweise den größten Teil der Gelder.

Um klar zu sein: Temperatur bezieht sich grundlegend auf die Online-Exponierung des privaten Schlüssels und wie leicht Gelder bewegt werden können; Übertragungshäufigkeit und Anteil der Gelder sind Konsequenzen davon, nicht die Definition. Diese Dimension ist ebenfalls orthogonal zu den ersten beiden: Eine Cold Wallet kann Multisig plus HSM verwenden, und eine Hot Wallet kann MPC verwenden.

Zusammengenommen ergibt sich das vollständige Bild: Autorisierungsmodell, Hardware-Schutz und Fonds-Temperatur sind unabhängig, und ein echtes Schlüsselverwaltungs-Setup kombiniert alle drei.

Gängige Schlüsselverwaltungs-Setups

So kombiniert die Branche üblicherweise die drei Dimensionen:

Der Zweck der Auswahl besteht darin, nach Fonds-Temperatur zu staffeln und auf jeder Stufe die beste Kombination zu verwenden. Hot Wallets brauchen Geschwindigkeit, daher bevorzuge MPC. Cold Wallets brauchen Stabilität und Überprüfbarkeit, daher bevorzuge Multisig plus HSM. Governance und Contract-Berechtigungen brauchen Transparenz und Verantwortlichkeit, daher bevorzuge Contract-Multisig plus Timelock.

BlockSecs empfohlene hybride Architektur

BlockSec empfiehlt eine hybride Architektur, die nach Temperatur gestaffelt ist.

Hot/Warm-Wallets: MPC-Signing. Es beseitigt den einzelnen Ausfallpunkt eines privaten Schlüssels, hält die Signing-Latenz niedrig und eignet sich für hochfrequente Zahlungen. Anteile sollten über verschiedene physische Standorte und Sicherheitsdomänen verteilt sein.

Cold Wallets: Mehrparteien-Kontrolle plus on-chain-Überprüfbarkeit, geeignet für große Reserven. Welche Implementierung verwendet werden soll, hängt von den on-chain-Betriebsfähigkeiten Ihres Teams ab — es gibt zwei Wege:

• Für maximale Transparenz mit reifen on-chain-Operationen: Verwenden Sie Contract-Multisig (z. B. Safes 3-von-5), bei dem Schwellenwertregeln und jede Signatur öffentlich on-chain überprüfbar sind. Auf Bitcoin verwenden Sie script-layer natives Multisig, wobei jeder Unterzeichner seinen eigenen Schlüssel in einem HSM oder Hardware-Wallet schützt. Beachten Sie, dass das Signatur-Parsing-Tooling für Contract-Multisig noch nicht ausgereift ist, sodass das Team selbst Kreuzverifizierung hinzufügen muss — die Operationen hier sind nicht leicht.
• Für Teams, die weniger vertraut mit der on-chain-Ausführung sind und weniger operative Komplexität wünschen: Verwenden Sie MPC-Threshold-Signing mit Anteilen in einem TEE und binden Sie dann eine unabhängige dritte Partei als Co-Unterzeichner ein, um vor jeder Signatur eine Transaktionssicherheitsprüfung durchzuführen. Dies vermeidet die Contract-Multisig-Tooling-Lücke und baut unabhängige Drittanbieter-Verifizierung direkt in den Signing-Schwellenwert ein.

Contract-Upgrades und Richtlinienänderungen: Multisig plus Timelock. Jede berechtigungsändernde Operation erfordert Mehrpersonen-Genehmigung und eine Zeitverzögerung.

Unabhängig davon, welchen Weg Sie einschlagen, sind einige Parameter wichtig. Verwenden Sie mindestens 3 Unterzeichner, mit einem Schwellenwert von mindestens 50 %, aber unter der Gesamtanzahl — vermeiden Sie N-von-N, da ein einziger nicht erreichbarer Unterzeichner das Signing blockieren und Gelder sperren würde, und wenn jeder Unterzeichner unentbehrlich ist, wird jeder zum kritischen Ziel für Nötigung oder Entführung. Ein Schwellenwert unterhalb der Gesamtanzahl lässt Redundanz und verringert den Wert, einen einzelnen Unterzeichner anzuvisieren. Jeder Unterzeichner sollte außerdem eine brandneue, dedizierte Adresse in jedem Multisig verwenden, die niemals mit anderen Multisigs oder persönlichen Wallets geteilt wird, und Unterzeichner sollten in Geografie, organisatorischer Rolle und juristischer Person divers sein — wobei die Verteilung mit steigendem Risikoniveau der Wallet zunimmt.

Dieses Risikoniveau sollte aus einer formalen Bewertung stammen: Bewerten Sie jede Wallet nach ihrem finanziellen Einfluss auf das Unternehmen, der Protokollabhängigkeit und dem Reputationsrisiko, und ordnen Sie jeder Bewertungsstufe einen anderen Schwellenwert, Genehmigungsablauf und Monitoring-Dichte zu. Überprüfen Sie die Bewertung alle 6 Monate und unmittelbar nach einer großen TVL-Änderung, einem Contract-Upgrade oder einem Sicherheitsvorfall.

Blind Signing und Signing-Umgebungs-Isolation

Blind Signing bedeutet, dass Ihr Signing-Tool Ihnen einen Calldata-Hash anzeigt — nicht was die Transaktion tatsächlich bewirkt. Es ist kein hypothetisches Risiko: Zum Signing-Zeitpunkt kann der Unterzeichner die eigentliche Bedeutung einer Transaktion über die Benutzeroberfläche nicht verstehen, und diese Lücke war eine direkte Ursache des Bybit-Vorfalls, bei dem das zum Signieren verwendete Front-End oder Back-End kompromittiert wurde und Unterzeichner eine bösartige Transaktion genehmigten, ohne dass in den Contracts selbst ein Fehler vorlag.

Die obigen drei Dimensionen abzusichern hilft nur, wenn der Signing-Prozess um sie herum genauso gehärtet ist. Einige Standards gelten unabhängig vom Setup:

• Obligatorische Signing-Hardware. Alle Produktions-Multisig-Operationen sollten eine Hardware-Wallet mit einem Bildschirm verwenden, der groß genug ist, um die vollständige Transaktionszusammenfassung anzuzeigen, und Clear Signing, PIN-Schutz mit Firmware-Integritätsprüfung und eine Lieferkette unterstützt, die auf den Hersteller oder autorisierte Wiederverkäufer beschränkt ist — Echtheit beim Empfang verifizieren.
• Physisch isolierte Signing-Umgebung. Das Signing sollte auf air-gapped Geräten laufen und nicht das alltägliche Büronetzwerk teilen; für hochwertige Operationen sind dedizierte Signing-Geräte angebracht. Stellen Sie den Signing-Service in einer unabhängigen Sicherheitsdomäne bereit, physisch isoliert von Geschäftslogik und Front-End. Signing-Knoten sollten nicht direkt dem öffentlichen Internet ausgesetzt sein — verbinden Sie sich mit ihnen nur über VPN oder eine private Leitung. Signing-Operationslogs sollten separat gespeichert werden und für das Geschäftssystem nicht veränderbar sein.
• Unabhängige Transaktionsverifizierung. Überprüfen Sie den Transaktionsinhalt über einen unabhängigen Kanal vor dem Signieren — ein dediziertes Terminal, ein Hardware-Gerät oder einen Drittanbieter-Transaktionssimulations-/Risikoservice. Diese Prüfung wird am besten von einer unabhängigen dritten Partei durchgeführt, nicht nur von Ihrem eigenen Front-End oder Back-End — allein internen Systemen zu vertrauen ist selbst ein einzelner Ausfallpunkt. Sobald das interne Front-End oder Back-End kompromittiert ist, wie bei Bybit, sind die Informationen, die der Unterzeichner auf dem Bildschirm sieht, manipulierte gefälschte Informationen, und sich selbst gegen sich selbst zu verifizieren ist überhaupt keine Verifizierung. Der Auszahlungsweg braucht diese unabhängige Verteidigungslinie besonders.
• Clear Signing und Kreuzverifizierung. Verwenden Sie Tools, die Transaktionssemantik parsen, sodass der Unterzeichner „Übertrage 1.000 USDC an 0x1234..." sieht statt einen Calldata-String, und verifizieren Sie Schlüsselparameter — Chain-ID, Zieladresse, Calldata, Wert, Nonce und Operationstyp — als identisch über mindestens zwei unabhängige Tools oder Benutzeroberflächen.
• Menschliche plus automatisierte Doppelprüfung. Eine automatisierte Regelmaschine übernimmt die erste Überprüfung, und ein Mensch bestätigt große Transaktionen, bevor sie ausgehen.
• Zero Trust und Backups. Stellen Sie den Signing-Service, die Geschäftslogik und die Front-End-Benutzeroberfläche in verschiedenen Sicherheitsdomänen bereit, und halten Sie Fallbacks für die primäre Signing-UI, RPC und Block-Explorer vor, sodass ein einzelner Anbieter- oder Service-Ausfall das Notfall-Signing nicht blockieren kann.

Operative Multisig-Standards

Schlüssel- und Schwellenwertentscheidungen bringen Sie nur so weit. Einige operative Standards sind genauso wichtig.

Multisig-Register. Führen Sie einen einzigen Datensatz über jeden Multisig, wobei jeder Eintrag mindestens enthält: Adresse, Chain, Signing-Schwellenwert, Risikobewertung, Zweck, Unterzeichneradressen, kontrollierte Contracts, on-chain-Rollen und letztes Überprüfungsdatum. Sicherheitssensible Änderungen sollten das Register innerhalb von 24 Stunden aktualisieren, routinemäßige Änderungen innerhalb von 3 Tagen.

Unterzeichner-Lebenszyklusmanagement. Überprüfen Sie Adressen vor dem Onboarding, indem Sie die vorgesehene Adresse eine bestimmte Nachricht signieren lassen und diese mit einem unabhängigen Tool prüfen. Legen Sie SLAs für die Entfernung der Berechtigungen eines scheidenden oder entfernten Unterzeichners nach Risikobewertung fest — dringend innerhalb von 48–72 Stunden, kritisch innerhalb von 7 Tagen, alles andere innerhalb von 14 Tagen. Führen Sie eine vierteljährliche Zugangsprüfung durch, um zu bestätigen, dass jeder Unterzeichner noch seinen Schlüssel kontrolliert, und aktualisieren Sie das Unterzeichner-Training mindestens jährlich mit den Themen Transaktionsverifizierung, Notfallverfahren und Social-Engineering-/Phishing-Abwehr, mit einer praktischen Bewertung danach.

Seed-Phrase- und Backup-Schutz. Keinerlei digitale Speicherung — keine Cloud-Laufwerke, Fotoalben oder Dokumente. Speichern Sie Backups verteilt über verschiedene geografische Standorte, wiederherstellbar gegen Naturkatastrophen, Diebstahl und einen vermissten Operator. Kein einzelner Punkt sollte die vollständigen Wiederherstellungsinformationen halten.

Sichere Kommunikation. Koordinieren Sie unter Unterzeichnern über primäre und Backup-Kanäle auf verschiedenen Plattformen, wobei jede MFA, Ende-zu-Ende-Verschlüsselung und nur-auf-Einladung-Mitgliedschaft erzwingt. Vor dem Signieren überprüfen Sie die Identität eines Unterzeichners über einen unabhängigen Kanal — einen Videoanruf, eine Passphrase und einen authentifizierten zweiten Kanal — um zu verhindern, dass ein gekapertes IM-Konto einen Unterzeichner imitiert.

Notfallreaktions-SLA. Legen Sie Unterzeichner-Reaktionszeiten nach Vorfallschwere fest, zum Beispiel dringend unter 2 Stunden, zeitkritisch 2–12 Stunden, routinemäßig 24–48 Stunden. Testen Sie die Erreichbarkeit von Unterzeichnern vierteljährlich, nicht nur auf dem Papier, und führen Sie mindestens eine vollständige End-to-End-Notfallübung pro Jahr durch, die Szenarien wie einen geleakten Schlüssel, einen nicht erreichbaren Unterzeichner, einen kompromittierten Kommunikationskanal und Notfallprotokoll-Operationen abdeckt.

Multisig-On-Chain-Monitoring. Überwachen Sie Unterzeichner-/Schwellenwertänderungen, Übertragungs-Schwellenwertüberschreitungen, Nonce-Lücken, Interaktionen mit unbekannten Adressen, fehlgeschlagene Transaktionen, Modul-/Guard-Änderungen und abnormale Proposer-Wallet-Salden. Die Monitoring-Infrastruktur selbst muss manipulationssicher sein.

API-Sicherheit

API-Sicherheit ist die erste Verteidigungslinie für Ihr Zahlungs-Backend. Das bedeutet Authentifizierung durch einen API-Schlüssel plus HMAC-Signatur oder FIDO2/WebAuthn, Rate-Limiting zur Verhinderung von Brute-Force und Missbrauch, DDoS-Schutz über einen CDN-/WAF-Service, strikte Validierung jedes Eingabeparameters zur Verhinderung von Injection und Log-Audit, sodass jeder API-Aufruf einen vollständigen Audit-Trail erzeugt.

Signing-Umgebungen müssen von all dem isoliert sein, nicht nur dadurch geschützt — weshalb der Signing-Service in seiner eigenen Sicherheitsdomäne gehört, wie oben erläutert.

Betriebssicherheit: Personen, Anbieter und unabhängige Audits

Mehrere schwerwiegende Vorfälle in 2026 involvieren Social Engineering — darunter gefälschte Rekrutierung, IT-Support-Imitation und KI-Gesichtsaustausch. Die Abwehr erfordert drei gemeinsam arbeitende Ebenen.

Training und Bewertung steht an erster Stelle: Jeder mit Zugang zu Signing-Systemen, Produktions-Anmeldedaten oder sensiblen Operationen absolviert beim Onboarding Sicherheitstraining, aktualisiert es jährlich und aktualisiert den Inhalt innerhalb von 30 Tagen nach jeder Prozessänderung.

Aufgabentrennung ist genauso wichtig: Initiierung, Genehmigung und Ausführung können nicht von derselben Person durchgeführt werden, und Admin-Konten können nicht direkt auszahlen. Hochsensible Operationen wie das Signieren sollten dedizierte Geräte verwenden — vollverschlüsselt, automatisch sperrend — mit Hardware-Wallets in einem Safe, wenn nicht in Verwendung, und der gesamte Fernzugriff über ein VPN geroutet.

Dritte brauchen dieselbe Disziplin. Führen Sie Due Diligence vor der Auswahl eines Anbieters durch, überprüfen Sie den Compliance- und Sicherheitsstatus wichtiger Anbieter jährlich erneut, und gewähren Sie Drittanbieter-Zugang mit einem klaren Geltungsbereich, Zweck und Ablaufdatum — sofort widerrufen, sobald dieses abläuft oder das Projekt endet. Verifizieren Sie die Identität von Drittanbieter-Personal unabhängig, bevor Sie Zugang gewähren.

Nichts davon sollte allein auf internen Selbstprüfungen beruhen. Führen Sie regelmäßig unabhängige Drittanbieter-Sicherheitsbewertungen durch, die mindestens Penetrationstests, Red-Team-Übungen sowie Code- und Smart-Contract-Audits abdecken. Beheben Sie Befunde einzeln und verifizieren Sie die Schließung in der nächsten Bewertungsrunde.

Entwicklungs- und Infrastruktursicherheit

Mehrere schwerwiegende Zahlungs- und Krypto-Vorfälle der letzten Jahre lassen sich auf einen kompromittierten Entwicklungsprozess zurückführen — wobei die Contracts und die Signing-Logik selbst einwandfrei waren. Das bedeutet, dass die Entwicklungs- und Infrastrukturschicht dieselbe Aufmerksamkeit verdient wie die Signing-Schicht, in vier Bereichen.

Entwicklungsumgebungs-Isolation hält Entwicklungskonten von privilegierten Konten (Signing, Cloud-Management) getrennt, hält Produktions-Anmeldedaten außerhalb der Reichweite der Entwicklungsumgebung und setzt Entwicklungstools und Erweiterungen auf eine Genehmigungsliste.

Ihre Code-Repos und Lieferkette brauchen Branch-Schutz, signierte Commits und Mehrpersonen-Review auf dem Hauptbranch. Beziehen Sie Abhängigkeiten nur aus offiziellen Repos mit gepinnten Versionen und Typosquatting-Prüfungen, und führen Sie automatisches Secret-Scanning durch, das jeden exponierten Schlüssel sofort widerruft und rotiert.

In CI/CD benötigen Änderungen der Pipeline-Konfiguration Mehrparteien-Genehmigung und Versionskontrolle, mit reproduzierbaren Builds. Secrets gehen über einen dedizierten Manager wie Vault oder ein Cloud-KMS — Produktions-Secrets sollten für Menschen niemals direkt zugänglich sein — und SAST plus Dependency-Scanning sind Voraussetzungen für die Bereitstellung, keine optionalen Extras.

Für Infrastruktur und Cloud gewähren Sie privilegierten Zugang über Just-in-Time-Provisionierung, Mehrparteien-Genehmigung und Zeitlimits. Halten Sie Break-Glass-Konten für Notfälle vor, aber alarmieren Sie bei jeder Nutzung. Führen Sie vollständige Audit-Logs, Echtzeit-Alarme bei Admin-Operationen und regelmäßig geübte Backup- und Disaster-Recovery-Verfahren.

Domain, DNS und Identität: Die unterschätzte Angriffsfläche

Domain und DNS sind eine stark unterschätzte Angriffsfläche in Krypto — viele Phishing-Vorfälle und Diebstähle lassen sich auf ein kompromittiertes Registrar-Konto oder gekapertes DNS zurückführen. Die Domains zu schützen, auf denen Nutzer Fondoperationen initiieren, ist genauso wichtig wie den Schutz der Signing-Umgebung selbst.

Verwalten Sie Ihr Registrar-Konto als hochprivilegiertes Konto: Erzwingen Sie Hardware-Schlüssel-MFA und verlangen Sie eine Out-of-Band-Bestätigung für kritische Änderungen wie Transfers, Löschungen oder Nameserver-Änderungen. Auf DNS- und E-Mail-Seite aktivieren Sie DNSSEC auf kritischen Domains, verwenden Sie CAA, um zu beschränken, welche CAs Zertifikate ausstellen können, und konfigurieren Sie SPF/DKIM/DMARC (p=reject) auf allen sendenden Domains — setzen Sie auch nicht sendende Domains explizit auf Mail-Ablehnung, um Spoofing zu verhindern.

Überwachen Sie kontinuierlich DNS-Datensatzänderungen, Nameserver-Delegation und anomale Certificate-Transparency-Log-Ausstellungen unter Verwendung von Monitoring-Infrastruktur, die nicht von der Domain abhängt, die sie überwacht. Dokumentieren Sie Ihren Umgang mit Domain-Hijacking und nicht autorisiertem Transfer, üben Sie ihn jährlich und setzen Sie gestaffelte Ablaufwarnungen plus automatische Erneuerung, damit eine abgelaufene Domain kein Einfallstor wird.

Identität und Konten sind der Einstiegspunkt für fast alle lateralen Bewegungen. Eine vollständige Inventur der organisatorischen Konten plus ein strikter MFA-Standard ist wichtiger als jede Einzelpunkt-Verteidigung.

Beginnen Sie mit einer Konto-Inventur: Registrieren Sie jedes organisatorische Konto — Social Media, E-Mail, SSO/IdP, Registrar, Verwahrungsplattformen, Code-Repos, Cloud-Root, wichtige SaaS — mit einem klaren Eigentümer und überprüfen Sie sie regelmäßig. Erzwingen Sie phishing-resistentes MFA mit FIDO2/WebAuthn-Hardware-Schlüsseln auf hochprivilegierten Konten und verlassen Sie sich niemals auf SMS oder Sprache als primären Faktor — SIM-Swap, SS7 und Voice-Phishing umgehen sie alle. Dies ist die wirksamste einzelne Verteidigung gegen Kontoübernahme.

Erzwingen Sie einen Passwortmanager mit eindeutigen starken Passwörtern, untersagen Sie gemeinsame Logins und beschränken Sie die Wiederherstellungs-E-Mail und -Telefon auf die Organisationsdomäne — halten Sie Wiederherstellungscodes in sicherem Speicher, nicht in persönlicher E-Mail oder der Cloud. Wenn jemand das Unternehmen verlässt, widerrufen Sie ihren gesamten Zugang innerhalb von 24 Stunden und rotieren Sie alle gemeinsamen Anmeldedaten, die sie berührt haben, und führen Sie die ganze Zeit über Verhaltens- und Anmeldedaten-Leck-Monitoring auf hochprivilegierten aktiven Konten durch.

Warum die Architektur eines KI-Agenten von Natur aus unsicher ist

Zahlungsunternehmen setzen zunehmend KI-Tools und -Agenten ein, um Entwicklungs- und Betriebseffizienz zu steigern — das eröffnet jedoch eine neue Angriffsfläche, die bei nachlässigem Umgang direkt Gelder bedroht.

Hier ist der Teil, der leicht übersehen wird: Ein KI-Agent ist nicht nur ein Modell, das Fragen beantwortet. Er ist eine Maschine, die externe Inhalte lesen, Tools aufrufen, Anmeldedaten halten und Aktionen ausführen kann. Die Wurzel des Risikos liegt darin, dass er Text aus nicht vertrauenswürdigen Inhalten als auszuführende Anweisungen behandelt.

Das bedeutet, dass ein Angreifer keine Schwachstelle und kein gestohlenes Konto braucht. Ein einziger Satz, versteckt in einem Dokument, einer Webseite, einem Code-Kommentar oder einer PR-Beschreibung, kann das Verhalten des Agenten dazu entführen, Daten zu leaken oder nicht autorisierte Aktionen durchzuführen. Dies wird Prompt Injection genannt, und bis 2026 wurde nachgewiesen, dass es sich direkt zu Remote Code Execution ausweitet — Microsoft demonstrierte, dass ein einzelner Prompt ein Programm auf dem Rechner startet, auf dem ein Agent läuft, und GitHub Copilot, Cursor und MCP-Infrastruktur haben jeweils RCE-Schwachstellen mit CVSS 9,6 oder höher offengelegt.

Es wird schlimmer für alles Privilegierte. Ein Entwicklungs- oder Betriebsagent erbt standardmäßig den Dateizugriff, Shell-Berechtigungen und Datenbankschlüssel seines Operators. Eine Studie aus 2026, die gängige Coding-Agenten abdeckte, stellte fest, dass alle durch Prompt Injection gebrochen werden konnten, mit einer adaptiven Angriffserfolgrate von über 85 %. Jeder Agent, der nicht vertrauenswürdige Eingaben verarbeitet, sollte als potenzieller Insider behandelt werden, der Ihre Anmeldedaten hält — und die Lieferkette ist ebenfalls ein Hochrisikolink: Im März 2026 lag eine vergiftete KI-Gateway-Abhängigkeit 3 Stunden lang in einem öffentlichen Repo und wurde fast 47.000 Mal heruntergeladen.

Wie man KI-Agenten-Effizienz gewinnt, ohne die Kontrolle über Gelder zu verlieren

Der Ansatz besteht darin, den Agenten denselben Einschränkungen zu unterwerfen, die Sie auf nicht vertrauenswürdigen Code anwenden würden, über fünf Kontrollen:

• Isolierte Ausführung — führen Sie die Tool-Ausführung des Agenten in einer Sandbox aus, sodass Prompt Injection nicht die echte Shell, Produktionsschlüssel oder die Signing-Umgebung erreichen kann.
• Least Privilege — gewähren Sie den Tools, Datenbankschlüsseln und MCP-Services des Agenten nur das Minimum, das für eine einzelne Operation benötigt wird, niemals eine „Vollzugriffs"-Anmeldeinformation.
• Ein menschliches Gate bei Fondoperationen — für alles, was Transfers, Signing oder Berechtigungsänderungen betrifft, kann der Agent nur vorschlagen, niemals automatisch ausführen. Unabhängige menschliche Genehmigung gilt hier ebenfalls, dasselbe Prinzip hinter der oben behandelten Signing-Verifizierung.
• Vertrauenswürdige Anweisungen von nicht vertrauenswürdigen Daten trennen — tun Sie dies auf Architekturebene und erwarten Sie nicht, dass das Modell „sie von selbst unterscheidet".
• Lieferketten-Sperrung — wenden Sie dasselbe Versions-Pinning und dieselben Herkunftsprüfungen auf KI-bezogene Abhängigkeiten an, die Sie auf Ihre regulären Code-Repos anwenden.

Diese Einschränkungen müssen nicht theoretisch bleiben. BlockSecs Open-Source-Web3 Companion ist eine Referenzimplementierung einer sicheren agentischen Wallet (MIT-Lizenz, Forschungsvorschau). Er ermöglicht es einem KI-Agenten, einem Nutzer bei der Vorbereitung von on-chain-Transaktionen zu helfen, während private Schlüssel und endgültige Autorisierung vollständig außerhalb der Reichweite des Agenten bleiben. Sein Bedrohungsmodell behandelt den Agenten selbst als nicht vertrauenswürdig — das gesamte System muss garantieren, dass selbst ein vollständig kompromittierter Agent die Gelder des Nutzers nicht bewegen kann.

Die Architektur basiert auf drei Punkten. Schlüssel-Isolation bedeutet, dass nur ein einziges unabhängiges Signing-Modul (ein separater Go-Prozess) jemals den privaten Schlüssel berühren kann — der Agent erhält eine Transaktions-Intent-ID, kann eine Signatur anfragen, sieht aber nie einen Schlüssel. Schlüssel werden mit Envelope-Encryption (AWS KMS oder lokal AES-256) gespeichert, und Klartext existiert nur für den Moment des Signings im Speicher, danach wird er auf null gesetzt.

Vor der Übertragung durchläuft eine Transaktion vier sequenzielle Ebenen, von denen jede davon ausgeht, dass die vorherige versagt hat: Transaktionssimulation (Calldata dekodieren, Reverts vorhersagen), Gegenpartei-Risikobewertung, reine Go-Hard-Policy-Limits (pro-Transaktions-Cap, Tagesbudget, Whitelist — keine davon kann der Agent ändern) und schließlich Passkey-Menschenbestätigung, ein WebAuthn-Fingerabdruck oder Gesichtsscan, den ein rein software-basierter Angriff nicht fälschen kann. Schlüssel, Richtlinie und Passkey bilden drei unabhängige Vertrauensgrenzen, sodass das Durchbrechen einer die anderen beiden intakt lässt.

Ein KI-Agent kann die Effizienz wirklich steigern, darf aber keine alleinige Kontrolle über Gelder und Signing haben. Stecken Sie ihn in eine Least-Privilege-Sandbox als Assistent und lassen Sie Menschen die endgültige Entscheidung über Gelder und Signing treffen.

Alles zusammenführen

Schlüsselverwaltung ist keine einzelne Entscheidung — es sind drei, unabhängig getroffen und dann kombiniert: Wer signieren muss, wo der Schlüssel oder Anteil physisch liegt und wie sehr er dem Internet ausgesetzt ist. Die richtige Kombination für jede Fondsstufe zu finden, sie mit gehärteter Signing-Infrastruktur zu untermauern und mit den oben genannten operativen Standards zusammenzuhalten, ist der Ansatz von BlockSec, die Lücken zu schließen, die hinter den meisten schlüssel- und signaturbezogenen Vorfällen der Jahre 2025–2026 stecken. Und weil sich die Angriffsfläche nun über Schlüssel hinaus erstreckt — auf APIs, Personen, Anbieter, Code-Pipelines, Domains, Identität und KI-Agenten — braucht jeder davon dieselbe Behandlung: Nehmen Sie an, dass die darunter liegende Ebene versagt hat, und halten Sie einen Menschen im Loop, wo immer Gelder bewegt werden können.

Für das vollständige Bild, wo Schlüsselverwaltung und operative Sicherheit neben dem Rest des Compliance-Programms eines Zahlungssystems stehen, laden Sie unser Krypto-Zahlungssicherheits- und Compliance-Playbook (PDF) herunter.

FAQ

Was ist der eigentliche Unterschied zwischen MPC und Multisig? Multisig besteht aus mehreren vollständigen privaten Schlüsseln, die jeweils separat on-chain verifiziert werden — transparent, aber kostspielig und umständlich beim Wechsel von Unterzeichnern. MPC (Threshold Signatures) besteht aus mehreren Schlüsselanteilen, die so generiert werden, dass niemals ein vollständiger privater Schlüssel existiert; Teil-Signaturen werden off-chain zu einer einzigen Signatur kombiniert — flexibel und günstig, aber abhängig von Ihrer Koordinationsinfrastruktur.

Ist Shamir Secret Sharing (SSS) dasselbe wie MPC? Nein. SSS teilt einen bereits existierenden vollständigen privaten Schlüssel in Teile auf und rekonstruiert den vollständigen Schlüssel im Speicher zum Signieren, was den Rekonstruktionsmoment zu einem einzelnen Ausfallpunkt macht. Echtes MPC (TSS) rekonstruiert niemals einen vollständigen privaten Schlüssel — jede Partei berechnet nur eine Teil-Signatur aus ihrem eigenen Anteil.

Was ist der Unterschied zwischen einem TEE und einem HSM? Ein TEE (wie Intel SGX, AWS Nitro oder Apple Secure Enclave) ist ein isolierter, verschlüsselter Bereich auf einer General-Purpose-CPU, der beliebigen Code ausführen kann, einschließlich MPC-Protokolle — starke logische Isolation, aber schwächere physische Manipulationssicherheit und Zertifizierung als ein HSM. Ein HSM ist dedizierte manipulationssichere Hardware, bei der der private Schlüssel intern generiert, als nicht exportierbar markiert wird und das Gerät physisch nicht verlassen kann.

Was ist eine Warm Wallet und wie unterscheidet sie sich von Hot oder Cold? Eine Warm Wallet ist online, hält aber den privaten Schlüssel in einer geschützten Umgebung isoliert (einem dedizierten Signing-Service oder HSM) und erfordert einen Menschen im Signing-Loop, wird für den täglichen Settlement verwendet — liegt zwischen einer immer-online, automatisierten Hot Wallet und einer vollständig offline, air-gapped Cold Wallet.

Was empfiehlt BlockSec speziell für Cold Storage? Es hängt von den on-chain-Betriebsfähigkeiten des Teams ab: Teams mit reifen on-chain-Operationen können Contract-Multisig (z. B. Safes 3-von-5) verwenden, wobei der Schlüssel jedes Unterzeichners in einem HSM oder Hardware-Wallet liegt; Teams, die weniger operative Komplexität wünschen, können MPC-Threshold-Signing mit Anteilen in einem TEE plus einem unabhängigen Drittanbieter-Co-Unterzeichner für Transaktionssicherheitsprüfungen verwenden.

Was ist Blind Signing und warum ist es gefährlich? Blind Signing ist, wenn eine Signing-Benutzeroberfläche nur einen Calldata-Hash anzeigt anstatt was die Transaktion tatsächlich bewirkt. Der Unterzeichner kann die eigentliche Bedeutung dessen, was er genehmigt, nicht verifizieren, was eine direkte Ursache des Bybit-Vorfalls war.

Können KI-Agenten mit Krypto-Zahlungsoperationen vertraut werden? Nicht mit alleiniger Kontrolle. Ein KI-Agent sollte nur Fondoperationen vorschlagen dürfen, niemals automatisch ausführen — Transfers, Signing und Berechtigungsänderungen brauchen alle unabhängige menschliche Genehmigung, wobei der Agent in einer Least-Privilege-Sandbox läuft.

Was ist Prompt Injection und wie ernst ist es? Prompt Injection versteckt Anweisungen in nicht vertrauenswürdigen Inhalten — einem Dokument, einer Webseite, einem Code-Kommentar oder einer PR-Beschreibung — die das Verhalten eines KI-Agenten entführen. Bis 2026 ist es in offengelegten Schwachstellen, die gängige Coding-Tools betreffen, zu Remote Code Execution eskaliert, bewertet mit CVSS 9,6 oder höher.

Was ist die wirksamste einzelne Verteidigung gegen Kontoübernahme? Phishing-resistentes MFA — Erzwingen von FIDO2/WebAuthn-Hardware-Schlüsseln auf hochprivilegierten Konten und niemals auf SMS oder Sprache als primären Faktor verlassen, da SIM-Swap, SS7 und Voice-Phishing alle diese Kanäle umgehen können.