Hold Your Own Key: warum der Schlüssel nicht beim Dienst liegen sollte

4 Min Lesezeit Serie: infrastructure #krypto#hyok#hsm#schluesselmanagement

BYOK klingt wie HYOK, ist es aber nicht. Was die Modelle unterscheidet, warum ein HSM allein kein HYOK macht, und wie eine belastbare Schlüsselinfrastruktur jenseits des Produktions-Rechenzentrums aussieht.

Problem

"Unsere Daten sind verschlüsselt gespeichert" lässt eine wichtige Frage offen: Wo liegt der Schlüssel? In der Praxis lautet die Antwort häufig: bei demselben Anbieter, im selben Rechenzentrum, zugänglich für dieselben Operatoren, die auch auf die Daten zugreifen können. Dann ist die Verschlüsselung eine technisch aufwendige Zugangskontrolle gegen Aussenstehende, aber keine strukturelle Trennung gegen den Anbieter 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. Logging 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.

Kurze Antwort

Hold Your Own Key (HYOK) trennt die Schlüsselinfrastruktur räumlich und organisatorisch vom datenverarbeitenden Dienst. Der Dienst fragt bei Bedarf eine Wrap- oder Entsperr-Operation an; der Schlüssel selbst verlässt die Schlüsselinfrastruktur nicht. Entscheidend ist, dass die Schlüsselseite autonom entscheiden kann, eine Anfrage abzulehnen, technisch durch Policy, organisatorisch durch Mehr-Augen-Prinzip, rechtlich durch getrennte Zuständigkeit.

Der Effekt: ein erfolgreicher Angriff auf den datenverarbeitenden Dienst allein führt zu Ciphertext und Metadaten, aber nicht zu Klartext.

Tiefgang

Die drei Modelle im Vergleich

  • Provider-managed Keys. Schlüssel liegen in einem Key-Management-Service 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. Marketing-stark, strukturell nur geringfügig besser: der Anbieter hat den Schlüssel danach im Klartext (oder genauer: im HSM des Anbieters). 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 an die Schlüsselseite, die ihn prüft und ausführt. Kein Klartext-Schlüssel beim Dienst.

Die Variante "External Key Manager" 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 und organisatorische Trennung. Eigener Raum, eigene Stromversorgung, eigene Netzanbindung; Administration durch ein anderes Personal als das der Produktion.
  2. Kein öffentlicher Internet-Endpoint. Erreichbarkeit ausschliesslich über verschlüsselten Tunnel mit mutual TLS, Policy-basierter Zugangskontrolle.
  3. Mehr-Personen-Regel bei sensiblen Operationen. Unseal, Rotation, Export von Key-Material erfordern zwei oder mehr Personen (Shamir-Split, siehe späterer Beitrag dieser Serie).
  4. Manipulationssichere Protokollierung jeder Schlüssel-Anfrage und jeder Policy-Änderung. WORM-Storage oder Merkle-Kette, Retention mindestens so lang wie die Aufbewahrungspflicht der zugrundeliegenden Daten.

Der Schlüsselhierarchie-Gedanke

Eine produktive HYOK-Architektur verwendet mehrere Schlüsselebenen:

  • Root-Key auf einem HSM in der getrennten Infrastruktur, erzeugt und gespeichert ohne jemals den HSM zu verlassen (FIPS 140-3 Level 3 oder 4).
  • Mandantenspezifische KEK (Key Encryption Keys): pro Kunde oder pro Umgebung ein eigener KEK, abgeleitet oder gewrappt 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 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.

Wo HSM wirklich hilft, und wo nicht

Ein HSM (Hardware Security Module) 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 (Hardware sorgt dafür, dass Schlüssel nicht rauskommen).
  • Memory-Dumps 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 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 ausschliesslich 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). Dort muss HYOK greifen.

"Zero-Trust-Architektur ersetzt HYOK." Zero Trust regelt die Zugriffs-Autorisierung; HYOK regelt die Schlüsselverwahrung. Orthogonale Konzepte, die sich ergänzen, aber nicht ersetzen.

Wie Svelnor hier hilft

Svelnor Note nutzt Zero-Knowledge-Verschlüsselung auf Client-Seite (siehe eigener Beitrag dieser Serie); der Schlüssel entsteht im Browser und liegt nie am Server. Svelnor Clean, Svelnor Desk und Svelnor Audit verwenden für Metadaten und nicht-Zero-Knowledge-Daten eine HYOK-Architektur: getrennte Schlüsselinfrastruktur mit HSM, Shamir-Unseal durch separates Personal, kein öffentlicher Endpoint. Ein erfolgreicher Angriff auf den Verarbeitungs-Dienst allein fuehrt damit nicht zu Klartext. Die Schlüsselhierarchie (Root auf HSM, Mandanten-KEKs, objektweise DEKs) folgt dem im Beitrag skizzierten Muster.

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 in die getrennte Infrastruktur. Für Hochdurchsatz-Workloads (Video-Encryption, Bulk-Indexing) ist DEK-Caching im Arbeitsspeicher nötig, mit expliziter Lebensdauer und sicherer Verwerfung.

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).