DPoP, HMAC, Einmal-Nonces, AES-GCM: Anatomie einer Zero-Trust-Zertifikats-API

Unser SDK ermöglicht jedem Browser, ein Signaturzertifikat von AWS Private CA zu beziehen. Das macht den Issuance-Endpoint zur sicherheitskritischsten Fläche, die wir betreiben: Wer ihn überlistet, bekommt eine vertrauenswürdige Identität. Also wird der Endpoint in der Tiefe verteidigt, mit vier unabhängigen Mechanismen pro Anfrage. Dieser Beitrag durchläuft den gesamten Lebenszyklus, von der Challenge bis zum ausgestellten Zertifikat, und erklärt, was jede Schicht tatsächlich verhindert.

Das Bedrohungsmodell in einem Absatz

Ein API-Schlüssel allein authentifiziert ein Konto, keine Anfrage. Schlüssel in clientseitigem Code sind per Definition kompromittierbar. Was wir vor der Zertifikatsausstellung tatsächlich beweisen müssen: Der Aufrufer besitzt den privaten Schlüssel passend zum CSR, die Anfrage ist frisch und unverändert, und die Nutzlast ist unterwegs vertraulich. Jede Schicht unten existiert, weil eine dieser Aussagen sonst falsch wäre.

Schicht eins: erst die Challenge, Einmal-Nonces

Der Ablauf beginnt an einem Challenge-Endpoint, der eine Nonce ausstellt und in DynamoDB ablegt. Die Nonce wird Teil der nachfolgenden Zertifikatsanfrage, und der Server konsumiert sie genau einmal, gelöscht erst, nachdem jede andere Verifikation bestanden ist. Die Reihenfolge zählt: Zu früh konsumieren verbrennt legitime Wiederholungen bei fehlgeschlagener Prüfung; zu spät lässt Replays durch. Die Antwort des Challenge-Endpoints ist selbst verschlüsselt, was uns gleich zu Schicht vier bringt.

Schicht zwei: DPoP bindet die Anfrage an den Schlüssel

DPoP (Demonstrating Proof-of-Possession, spezifiziert in RFC 9449) lässt den Client pro Anfrage ein JWT signieren, gebunden an HTTP-Methode und URL in seinen Claims. Der Server importiert den JWK aus dem Proof-Header und verifiziert Signatur und Claims. Eine gestohlene Anfrage ist ohne den Schlüssel nutzlos, und ein für einen Endpoint erstellter Proof scheitert an einem anderen.

Schicht drei: Der DPoP-Schlüssel muss der CSR-Schlüssel sein

Das ist die Prüfung, die die meisten Designs auslassen. Der Besitz irgendeines Schlüssels reicht nicht; es muss der sein, der zertifiziert wird. Der Server vergleicht den öffentlichen DPoP-Schlüssel mit dem öffentlichen Schlüssel im CSR. Ohne diesen Schritt könnte ein Angreifer den CSR eines Opfers mit dem eigenen Proof präsentieren oder umgekehrt. Ein Vergleich schließt eine ganze Substitutionsklasse.

Schicht vier: kanonisches HMAC und verschlüsselte Nutzlasten

Eine kanonische HMAC-SHA256-Signatur deckt Methode, URI, ausgewählte Header und den Hash der Nutzlast ab, abgeleitet aus dem gemeinsamen API-Secret. Zusätzlich werden Anfrage- und Antwort-Bodies mit einem PBKDF2-abgeleiteten Schlüssel per AES-GCM verschlüsselt. Das sind anwendungsschichtige Kontrollen als Ergänzung zu TLS, kein Argument, dass TLS unzureichend sei; sie sorgen dafür, dass die Nutzlast nur für Parteien mit dem Secret lesbar ist.

Ein Detail, das ich im Rückblick schätze: Eine Middleware-Factory auf der Client-Seite fixiert die Reihenfolge, sodass ein Nutzer nicht versehentlich vor dem Verschlüsseln signieren oder doppelt verschlüsseln kann. Sicherheits-Middleware, die falsch zusammengebaut werden kann, wird falsch zusammengebaut.

Dann, und nur dann: die Ausstellung

Wenn alle vier Prüfungen grün sind, bittet die Lambda ACM Private CA um die Ausstellung, mit Nutzungsmessung an derselben Anfrage. Wiederkehrende Clients erhalten nach Möglichkeit ihr bestehendes Zertifikat statt Duplikaten. Der private Schlüssel überquert zu keinem Zeitpunkt die Leitung; nur der CSR tut das (wie in unserem Beitrag zum Signer-Interface und Client-Schlüssel-Lifecycle beschrieben).

Häufige Fragen

Ist das OAuth? Nein. DPoP beweist hier den Besitz des Signaturschlüssels pro Anfrage, keine delegierte Nutzer-Autorisierung. Der API-Schlüssel identifiziert weiterhin den Kunden.

Warum DPoP und HMAC? Sie binden Unterschiedliches. DPoP bindet die Anfrage an den privaten Schlüssel des Clients; HMAC bindet sie an das gemeinsame Secret und deckt die exakte kanonische Anfrage ab. Jede Seite fängt Manipulation ab, die die andere nicht kann.

Was passiert bei Uhrenversatz oder Wiederholungen? Die Nonce wird einmal konsumiert, nach allen Verifikationen, sodass ein gescheiterter Versuch innerhalb des Gültigkeitsfensters mit derselben Nonce wiederholt werden kann.

Keiner dieser Mechanismen ist exotisch. Der Wert liegt in der Komposition: Jede Schicht unterstellt, dass die anderen versagen könnten. Das ist, was Zero Trust bedeutet, wenn man es auf die eigene API anwendet.