Hold Your Own Key: warum der Schlüssel nicht bei Fremden liegen sollte

Problem

"Unsere Daten sind verschlüsselt gespeichert" lässt eine wichtige Frage meistens offen: Wo liegt der Schlüssel? In der Praxis lautet die Antwort dann leider häufig: bei demselben Anbieter, im selben Rechenzentrum, zugänglich für dieselben Operatoren, die auch auf die Daten zugreifen können. Warum? Weil es einfach und kostengünstig ist. Dann ist die Verschlüsselung aber nur eine technisch aufwendige Zugangskontrolle gegen Außenstehende, aber kein Schutz vor möglichen Innentätern eines Anbieters selbst.

Drei Angriffsflächen machen das zum Problem:

1. Behördliche Anordnungen (siehe den Artikel zur deutschen Jurisdiktion) können Daten und Schlüssel gleichzeitig erzwingen.
2. Insider-Zugriff: Ein Mitarbeiter mit Produktions-Zugriff sieht beide Hälften. Revisionssichere Protokollierung schreckt ab, hebelt aber nicht die technische Möglichkeit aus.
3. Einbruch in den Dienst: Ein erfolgreicher Angreifer findet Schlüssel und Daten im selben Netzwerk.

Für wen ist das? Für Verantwortliche, die wissen wollen, wer die Schlüssel zu ihren verschlüsselten Daten hält.

Kurze Antwort

Bei "Hold Your Own Key" liegt der Schlüssel getrennt vom Dienst, der die Daten verarbeitet - so kann ein einzelner Angriff auf den Dienst zwar verschlüsselte Daten, aber keinen Klartext erbeuten.

• HYOK (Hold Your Own Key) trennt die Schlüsselinfrastruktur räumlich und organisatorisch vom datenverarbeitenden Dienst.
• Der Schlüssel bleibt drüben: Der Dienst fragt eine Entsperr-Operation an, der Schlüssel selbst verlässt die Schlüsselseite nie.
• Ablehnen ist möglich: Die Schlüsselseite kann eine Anfrage autonom verweigern - technisch per Policy (Regelwerk), organisatorisch per Mehr-Augen-Prinzip, rechtlich per getrennter Zuständigkeit.
• Abgrenzung: HYOK ist mehr als BYOK (Bring Your Own Key, "eigenen Schlüssel mitbringen"). BYOK sagt nur, wer den Schlüssel erzeugt hat, nicht wo er danach liegt.
• Grenze: HYOK braucht zwingend Hardware (HSM), Regelwerk (Policy) und Organisation (Mehr-Personen-Regel) zusammen - keiner der drei Teile genügt allein.

Tiefgang

Die drei Modelle im Vergleich

• Provider-managed Keys (anbieterverwaltete Schlüssel). Schlüssel liegen in einem Key-Management-Service (KMS, zentraler Schlüsseldienst) des Anbieters, im selben Konto, im selben Rechenzentrum. Convenience hoch, struktureller Schutz gering. AWS KMS default, Azure Key Vault default, GCP KMS default.

• BYOK (Bring Your Own Key). Kunde erzeugt den Schlüssel und importiert ihn in den KMS des Anbieters. Marketingmäßig gerne ausgeschlachtet, strukturell aber nur geringfügig besser: der Anbieter hat den Schlüssel zwar nicht selbst erzeugt, am Ende liegt er dann aber doch dort vor. Eine behördliche Anordnung oder ein Anbieter-Insider kann ihn verwenden.

• HYOK (Hold Your Own Key). Schlüssel verlässt die Kunden- oder drittpartei-kontrollierte Infrastruktur nie. Der datenverarbeitende Dienst sendet einen Wrap- oder Decrypt-Call (eine Anfrage zum Ver- oder Entschlüsseln) an die Schlüsselseite, die ihn prüft und ausführt. Kein Klartext-Schlüssel beim Dienst.

Die Variante "External Key Manager" (externer Schlüsselverwalter) bei AWS und die "Cloud HYOK"-Modelle bei Microsoft oder Google versuchen, die HYOK-Idee auf eine Cloud-API zu übertragen. Im Detail bleibt der Schlüssel dabei auf Kunden-Seite, der Cloud-Dienst ruft per Netzwerk an.

Was eine belastbare HYOK-Infrastruktur ausmacht

Vier Eigenschaften sind nicht verhandelbar:

1. Physische Trennung. Eigener Raum, eigene Stromversorgung, eigene Netzanbindung
2. Kein öffentlicher Internet-Endpoint. Erreichbarkeit ausschließlich über verschlüsselten Tunnel mit mutual TLS (beidseitige Authentifizierung, bei der sich auch der anfragende Dienst ausweisen muss), Policy-basierter Zugangskontrolle.
3. Mehr-Personen-Regel bei sensiblen Operationen. Unseal (Entsperren des Schlüsseldienstes), Rotation, Export von Key-Material erfordern zwei oder mehr Personen (Shamir-Split - ein Verfahren, das einen Schlüssel in Teile zerlegt, von denen mehrere zusammenkommen müssen; siehe später geplanten Beitrag aus dieser Serie).
4. Manipulationssichere Protokollierung jeder Schlüssel-Anfrage und jeder Policy-Änderung. WORM-Storage (Write Once Read Many, nur einmal beschreibbar) oder Merkle-Kette (kryptografisch verkettete Protokolleinträge, die nachträgliche Änderungen sichtbar machen), Retention (Aufbewahrungsdauer) mindestens so lang wie die Aufbewahrungspflicht der zugrundeliegenden Daten.

Der Schlüsselhierarchie-Gedanke

Eine produktive HYOK-Architektur verwendet mehrere Schlüsselebenen:

• Root-Key (Wurzelschlüssel) auf einem HSM in der getrennten Infrastruktur, erzeugt und gespeichert ohne jemals den HSM zu verlassen (FIPS 140-3 Level 3 oder 4, eine US-Sicherheitsnorm für Krypto-Hardware).
• Mandantenspezifische KEK (Key Encryption Keys, Schlüssel zum Verschlüsseln anderer Schlüssel): pro Kunde oder pro Umgebung ein eigener KEK, abgeleitet oder gewrappt (verschlüsselt) vom Root-Key.
• Datenverschlüsselungs-Schlüssel (DEK): pro Objekt, Datei, Nachricht ein kurzlebiger symmetrischer Schlüssel, gewrappt mit dem KEK, der mit dem Ciphertext (verschlüsselten Inhalt) gespeichert wird.

Der Dienst, der eine Datei entschlüsseln will, übergibt das gewrappte DEK an die Schlüsselseite und erhält den entwrappten DEK zurück, für die Dauer der Operation, im Arbeitsspeicher, nicht persistiert (also nicht dauerhaft gespeichert).

Wo HSM wirklich hilft, und wo nicht

Ein HSM (Hardware Security Module, ein spezielles Sicherheits-Gerät) ist ein Sonderstück: ein manipulationsgeschütztes Gerät, das private Schlüssel im Klartext nie herausgibt. Operationen wie Signieren, Wrappen, Entwrappen erfolgen innerhalb des HSM.

HSM hilft strukturell gegen:

• Extraktion von Schlüsselmaterial durch einen einzelnen Admin (die (hoffentlich fehlerfreie) Hardware sorgt dafür, dass Schlüssel nicht ausgeleitet werden können).
• Memory-Dumps (Auslesen des Arbeitsspeichers) durch Malware auf dem Host.
• Offline-Clonen des Schlüsselmaterials.

HSM hilft nicht gegen:

• Missbrauch eines im HSM liegenden Schlüssels durch einen legitimierten Anfrager (wer die API-Credentials, also die Zugangsdaten der Schnittstelle, hat, kann die Operation auslösen).
• Behördliche Anordnungen an den HSM-Betreiber, die den Einsatz des Schlüssels verlangen (nicht die Herausgabe).

Ein HSM ist notwendiges Mittel, aber kein hinreichendes. HYOK braucht HSM plus Policy plus Organisation.

Abgelehnte Alternativen und Mythen

"Wir haben BYOK, also HYOK." Nein. BYOK beschreibt nur, wer den Schlüssel erzeugt hat. HYOK beschreibt, wo er nach Erzeugung lebt.

"E2E-Verschlüsselung macht HYOK überflüssig." Nur dann, wenn der Klartext wirklich ausschließlich auf dem Endgerät des Nutzers existiert. In den meisten "E2E"-Produkten bleibt ein serverseitiger Entschlüsselungspunkt (für Suche, für Benachrichtigungen, für Backup-Wiederherstellung oder eben für das Arbeiten auf den Daten auf den Servern des Anbieters). Dort muss HYOK greifen.

"Zero-Trust-Architektur ersetzt HYOK." Zero Trust (ein Modell, bei dem keine Komponente automatisch vertraut wird) regelt die Zugriffs-Autorisierung; HYOK regelt die Schlüsselverwahrung. Orthogonale Konzepte, die sich ergänzen, aber nicht ersetzen.

Was Sie jetzt tun sollten

1. Stellen Sie Ihrem Anbieter die eine entscheidende Frage: Wo liegt der Schlüssel, und kann der Dienst ihn allein - ohne eine getrennte Schlüsselseite - verwenden? Die Antwort zeigt, ob es sich um provider-managed Keys, BYOK oder echtes HYOK handelt.
2. Lassen Sie sich nicht von "BYOK" beruhigen. Fragen Sie ausdrücklich nach, ob der importierte Schlüssel danach im Klartext beim Anbieter verfügbar ist. Wenn ja, schützt BYOK strukturell kaum mehr als anbieterverwaltete Schlüssel.
3. Prüfen Sie die vier Mindesteigenschaften. Bei einem HYOK-Versprechen: physische Trennung, kein öffentlicher Endpunkt, Mehr-Personen-Regel bei sensiblen Operationen und manipulationssichere Protokollierung. Fehlt eine, ist es kein belastbares HYOK.
4. Klären Sie den Notfall mit. Lassen Sie sich erklären, wie der Disaster-Recovery-Fall (Wiederanlauf nach Ausfall) aussieht - getrennte Schlüssel nützen nichts, wenn ihr Verlust Ihre Daten dauerhaft unzugänglich macht.
5. Dokumentieren Sie die Trennung für Audits. Wenn Sie reguliert sind, halten Sie die HYOK-Architektur in Ihren technischen und organisatorischen Maßnahmen (TOM nach Art. 32 DSGVO) fest - das verlangen Prüfer regelmäßig.

Wie Dernium hier hilft

Dernium Note nutzt vollständige Zero-Knowledge-Verschlüsselung auf Client-Seite (siehe eigener Beitrag dieser Serie); der Schlüssel entsteht im Browser und wird nie zu uns übertragen. Dernium Clean, Dernium Desk und Dernium Office verwenden für Metadaten und nicht-Zero-Knowledge-Daten eine HYOK-ähnliche Architektur, ohne dass dabei Mehraufwand auf der Anwenderseite entsteht: eine organisatorisch und räumlich getrennte Schlüsselinfrastruktur (verschlüsselter Keystore auf eigener Hardware, nicht öffentlich erreichbar). Selbst der Worst-Case eines Diebstahls der Server, auf denen die Daten liegen, führt damit nicht zu einer Entschlüsselung Ihrer Daten. Die im Beitrag skizzierte vollständige Schlüsselhierarchie (Root-Key, Mandanten-KEKs, objektweise DEKs) ist dabei unser Zielbild; nicht jeder Dienst setzt heute schon jede Stufe um.

Verifikation

• HSM-Standards: FIPS 140-3.
• BSI TR-02102-1 (Kryptografische Verfahren), Abschnitt zu Schlüsselmanagement.
• Referenz-Implementationen für HYOK-Broker-Patterns: HashiCorp Vault mit externer HSM-Anbindung, Open Quantum Safe liboqs, Tink.
• External Key Manager: AWS XKS API, Google Cloud External Key Manager, Azure Managed HSM External Key.

Offene Punkte

Latenz. Jede Schlüsselanfrage kostet einen Netzwerk-Roundtrip (Hin- und Rückweg über das Netz) in die getrennte Infrastruktur. Für Hochdurchsatz-Workloads (Video-Encryption, Bulk-Indexing) ist DEK-Caching (Zwischenspeichern der Schlüssel) im Arbeitsspeicher nötig, mit expliziter Lebensdauer und sicherer Verwerfung. Auch der Swap (auf die Festplatte ausgelagerter Arbeitsspeicher) muss vollverschlüsselt sein.

Disaster Recovery. Die Schlüsselseite darf nicht gleichzeitig mit dem Dienst ausfallen, sonst sind Daten dauerhaft unzugänglich. Geographisch getrennte Replikation der KEKs, offline gelagerte Shamir-Shares als Last-Resort.

Regulatorische Vorgaben. Wer mit EU-Behörden oder regulierten Branchen arbeitet, sollte die HYOK-Trennung dokumentieren (TOM nach Art. 32 DSGVO, IT-Grundschutz-Baustein CON.1 Krypto-Konzept).

Häufige Fragen

Worin unterscheiden sich BYOK und HYOK genau?

BYOK (Bring Your Own Key) sagt nur aus, dass Sie den Schlüssel selbst erzeugt und in den Schlüsseldienst des Anbieters importiert haben. Danach liegt er aber meist im Klartext beim Anbieter und kann von ihm verwendet werden. HYOK (Hold Your Own Key) bedeutet, dass der Schlüssel die getrennte, von Ihnen oder einem Dritten kontrollierte Infrastruktur nie verlässt - der Dienst kann ihn nur durch eine prüfbare und ablehnbare Anfrage nutzen. Kurz: BYOK regelt die Herkunft, HYOK den dauerhaften Aufenthaltsort.

Reicht ein HSM allein für echten Schutz aus?

Nein. Ein HSM verhindert, dass Schlüsselmaterial ausgelesen oder kopiert wird, aber es verhindert nicht den Missbrauch eines Schlüssels durch jemanden, der berechtigte Zugangsdaten besitzt. Auch eine behördliche Anordnung kann den Einsatz des Schlüssels verlangen, ohne ihn herauszugeben. Belastbarer Schutz entsteht erst aus HSM plus Regelwerk (Policy) plus organisatorischen Maßnahmen wie dem Mehr-Personen-Prinzip.

Macht Ende-zu-Ende-Verschlüsselung HYOK überflüssig?

Nur dann, wenn der Klartext ausschließlich auf den Endgeräten der Nutzer existiert und nie auf einem Server entschlüsselt wird. In der Praxis brauchen viele als "E2E" beworbene Produkte serverseitige Entschlüsselungspunkte - etwa für Suche, Benachrichtigungen, Backup-Wiederherstellung oder serverseitiges Arbeiten auf den Daten. Genau dort, wo der Server den Klartext doch sehen muss, sorgt HYOK dafür, dass der Schlüssel nicht ebenfalls beim Dienst liegt.

Was passiert mit meinen Daten, wenn die Schlüsselseite ausfällt?

Das ist die Kehrseite der Trennung: Fällt die Schlüsselinfrastruktur dauerhaft aus und gibt es keine Wiederherstellung, sind die Daten unwiderruflich unlesbar. Deshalb gehört zu jeder ernsthaften HYOK-Architektur ein Disaster-Recovery-Konzept - etwa geografisch getrennte, replizierte Schlüssel und offline gelagerte Schlüsselanteile (Shamir-Shares) als letzte Rückfallebene. Fragen Sie einen Anbieter immer nach diesem Notfallpfad.

Bringt HYOK für mich als Anwender mehr Aufwand mit sich?

Nicht zwangsläufig. Gut umgesetzt läuft die Schlüsselanfrage zwischen Dienst und Schlüsselseite vollständig im Hintergrund - Sie bemerken davon nichts. Der spürbare Effekt ist allenfalls eine minimale zusätzliche Latenz pro Operation, die durch Zwischenspeichern der Schlüssel meist ausgeglichen wird. Der zusätzliche Aufwand liegt beim Anbieter im Betrieb der getrennten Infrastruktur, nicht bei Ihnen.