Blog · Aus der Entwicklung ·
Versiegelte Schlüssel: Wo die privaten TLS-Schlüssel bei obhut liegen
Wer ein Zertifikat für Ihre Domain ausliefert, braucht dessen privaten Schlüssel. Bei obhut entsteht er im Zertifikatsdienst, wird dort sofort versiegelt und erst auf dem Edge-Knoten wieder geöffnet, der Ihre Verbindungen annimmt. Datenbank, API und Hintergrunddienste sehen ihn nie im Klartext. Hier steht, wie das funktioniert, welche Lecks es abfängt und wogegen es nicht schützt.
Warum der private Schlüssel zählt
Mit dem privaten Schlüssel eines Zertifikats kann sich jeder als Ihre Domain ausgeben, solange das Zertifikat gilt. Vergangene Verbindungen entschlüsselt er nicht, denn jede Verbindung handelt einen eigenen Sitzungsschlüssel aus; für einen überzeugenden Angriff auf Ihre Nutzer reicht er trotzdem.
Eine Plattform, die TLS für viele Kunden terminiert, hält solche Schlüssel für jede Domain. Lägen sie im Klartext in ihrer Datenbank, genügte ein einziges Leck: ein Datenbankabzug, eine falsch abgelegte Sicherung, eine Zeile im Debug-Log. Deshalb trennen wir, wer einen Schlüssel erzeugt, wer ihn speichert und verteilt, und wer ihn benutzt.
Drei Stellen, drei Aufgaben
Der Zertifikatsdienst erzeugt und versiegelt
Der Zertifikatsdienst bestellt Zertifikate über ACME bei Let's Encrypt. Für jede Bestellung, auch für jede Erneuerung, erzeugt er einen neuen Schlüssel auf der Kurve P-256; einen alten verwendet er nie wieder. Bevor der Schlüssel den Dienst verlässt, verschlüsselt er ihn mit AES-256-GCM unter einem 32 Byte langen Schlüsselverschlüsselungsschlüssel, dem KEK, mit einer frischen Zufallszahl für jede Versiegelung. Die Kennung des KEK ist in die Echtheitsprüfung der Verschlüsselung eingebunden: Ein verändertes Paket oder eines mit falscher Kennung lässt sich nicht öffnen. Zurück gibt der Dienst nur die öffentliche Zertifikatskette und das versiegelte Paket. Eine Schnittstelle, die einen Schlüssel im Klartext herausgibt oder ein Paket öffnet, hat er nicht.
Die Steuerungsebene speichert und verteilt
Die Steuerungsebene, also API, Hintergrunddienste und Datenbank, speichert die Kette und das versiegelte Paket und verteilt beides unverändert an die Edge-Knoten der Zone. Den KEK besitzt sie nicht; wo sie ihn anfordern könnte, steht unten bei den Grenzen. Auch auf dem Knoten liegt das Paket bis zur Verwendung versiegelt in seinem lokalen Speicher.
Der Edge-Knoten öffnet und benutzt
Erst der Edge-Knoten hält den KEK. Kommt ein neues Zertifikat an, öffnet er dessen Paket einmal, prüft, ob der Schlüssel zum Zertifikat passt, und hält ihn danach im Arbeitsspeicher, nicht auf der Festplatte. Scheitert das Öffnen, meldet der Knoten das Zertifikat mit Grund als nicht verwendbar. Das bisherige Zertifikat bleibt dann im Einsatz, bis jeder aktive Knoten des Pools das neue verwenden kann oder das alte abläuft.
Wie ein Knoten an den KEK kommt
Ein neuer Edge-Knoten erzeugt bei seiner Anmeldung ein frisches X25519-Schlüsselpaar; der private Teil bleibt im Speicher des Anmeldeprozesses. Den öffentlichen Teil schickt er zusammen mit einem Einmal-Token, das ein Betreiber ausstellt und das standardmäßig nach einer Stunde verfällt; gespeichert wird nur sein Hash.
Die Steuerungsebene prüft das Token und bittet den Zertifikatsdienst, den KEK für genau diesen öffentlichen Schlüssel zu verpacken, mit HPKE nach RFC 9180 (X25519, HKDF-SHA256 und AES-256-GCM). Die Steuerungsebene reicht das Paket nur weiter; öffnen kann es allein der Knoten, der den passenden privaten Schlüssel hält. Dort liegt der KEK danach in der Identitätsdatei des Knotens, lesbar nur für dessen Synchronisationsdienst; der Edge-Dienst und der Tunnel-Dienst erhalten beim Start eine private Kopie.
Was die Versiegelung abfängt
Ein Abzug der Datenbank, ein Blick in die Protokolle von API und Hintergrunddiensten oder ein Mitschnitt der Verteilung an die Knoten zeigt nur versiegelte Pakete. Wer eines verändert, erhält kein anderes Ergebnis, sondern einen Fehler, und der Knoten meldet das Zertifikat als nicht verwendbar, statt einen fremden Schlüssel zu benutzen.
Automatische Tests halten das fest: Ein verändertes Paket und eines mit falscher KEK-Kennung gehen nicht auf, ein verpackter KEK öffnet sich für keinen anderen Knoten, und ein Ende-zu-Ende-Test bestellt ein Zertifikat bei einer ACME-Test-CA, verteilt es versiegelt und liefert es über einen echten Edge-Knoten aus.
Wogegen sie nicht schützt
Versiegelung schützt Daten, die in falsche Hände geraten. Sie ist kein Schutz gegen jemanden, der die Plattform selbst steuert. Die Grenzen im Einzelnen:
- Der Edge-Knoten muss Ihre Verbindungen annehmen und hält die Schlüssel seines Pools deshalb offen im Arbeitsspeicher, den KEK in einer Datei. Die Festplatten der Knoten sind nicht verschlüsselt. Wer einen Knoten oder seine Festplatte in die Hände bekommt, kann beides benutzen.
- Es gibt einen KEK je Umgebung, den sich alle Knoten teilen. Ein gesperrter Knoten verliert den Zugang zur Steuerungsebene, nicht aber den KEK, den er schon hat. Ein gestohlener Knoten ist deshalb ein Anlass, einen neuen KEK zu erzeugen, alle Knoten neu anzumelden, alle Zertifikate neu auszustellen und die alten zu widerrufen. Ein Verfahren zum Wechsel des KEK ist beschlossen, aber noch nicht gebaut.
- API und Hintergrunddienste besitzen ein Zugangstoken für den Zertifikatsdienst, damit neue Knoten ihren KEK erhalten. Wer dieses Token erbeutet und den Dienst erreicht, kann sich den KEK für einen eigenen Schlüssel verpacken lassen; zusammen mit einem Datenbankabzug öffnet das jedes Paket. Ebenso kann, wer die Steuerungsebene vollständig kontrolliert, Anmelde-Tokens ausstellen und sich einen eigenen Knoten verschaffen. Der Zertifikatsdienst läuft neben der Steuerungsebene auf demselben Server, nur lokal erreichbar; wer dort root ist, kann auch den KEK lesen.
- Die Sicherungen der Steuerungsebene enthalten KEK und versiegelte Pakete zusammen. Sie sind deshalb selbst verschlüsselt.
- Ein Hardware-Sicherheitsmodul setzen wir nicht ein. Die Schlüssel liegen in Software.
Diese Grenzen gelten für jede Plattform, die TLS für ihre Kunden terminiert: Wo die Verbindung endet, muss der Schlüssel benutzbar sein. Entscheidend ist, wie wenige Stellen ihn im Klartext sehen und ob Sie wissen, welche das sind.
Häufige Fragen
Kann obhut meine privaten Schlüssel lesen?
Im Normalbetrieb sehen Datenbank, API und Hintergrunddienste ihn nicht. Der Edge-Knoten, der Ihre Verbindungen annimmt, muss den Schlüssel benutzen. Wer das Zugangstoken der Steuerungsebene oder die Plattform selbst kontrolliert, kann sich den KEK verschaffen; gegen den Betreiber selbst ist die Versiegelung kein Schutz.
Werden Schlüssel wiederverwendet?
Nein. Jede Bestellung, auch jede Erneuerung nach zwei Dritteln der Laufzeit, erzeugt einen neuen ECDSA-Schlüssel auf der Kurve P-256.
Was passiert, wenn ein Knoten ein Paket nicht öffnen kann?
Er meldet das Zertifikat mit Grund als nicht verwendbar. Das bisherige Zertifikat bleibt im Einsatz, bis jeder aktive Knoten des Pools das neue verwenden kann oder das alte abläuft.
Schützt die Versiegelung auch vor Quantenrechnern?
AES-256-GCM gilt auch gegen Quantenrechner als robust. Die Zertifikate selbst sind noch klassisch signiert, und die Übergabe des KEK an einen Knoten nutzt noch klassisches X25519. Der Schlüsselaustausch mit Browsern, die es anbieten, ist dagegen schon hybrid mit einem Post-Quanten-Verfahren abgesichert, wie der Beitrag zum Post-Quanten-TLS beschreibt.
