TPM signiert TLS-Handshakes: Schlüssel verlässt die Maschine nie
Signing TLS handshakes inside a TPM
In einem Beitrag über Remote Attestation in vertraulichen VMs zeigt der Autor, wie ein TPM die Identität einer Maschine für gegenseitiges TLS sichert. Statt des privaten Schlüssels auf der Festplatte zu speichern, signiert das TPM die Handshake-Digests, ohne den Schlüssel preiszugeben. Die Go-Bibliothek go-tpm-tls findet den passenden Schlüssel anhand des Zertifikats und integriert sich nahtlos in den Standard-TLS-Stack. Der Autor vergleicht mit Dateirechten, kurzlebigen Zertifikaten und KMS und erklärt, warum das TPM die einzige Option ist, die alle vier Anforderungen erfüllt.
Ein Schlüssel in einer Datei ist keine echte Maschinenidentität – es ist eine Inhaberberechtigung, die zufällig auf einer Maschine gespeichert ist, und wer sie liest, wird zu dieser Maschine, überall, bis jemand es bemerkt und das Zertifikat widerruft.
- bob1029
Ich nehme an, der Wert davon hängt von deinem Bedrohungsmodell ab.
Der TPM gibt dir eine stärkere Zusicherung, dass eine Maschine einen Schlüssel besitzt, aber es ist wahrscheinlich, dass ein dedizierter HSM viel schwerer zu extrahieren ist.
Dass der TPM in der Maschine ist, ist ein zweischneidiges Schwert. Einerseits macht es Attestierung machbar, aber andererseits hast du jetzt die Sicherheits-Blackbox in derselben physischen Domäne wie die Maschine, die sie nutzt. Das Risiko von Seitenkanal-Extraktion steigt dramatisch, wenn diese Systeme koexistieren. Es ist viel schwieriger, einen HSM über das Netzwerk zu instrumentieren.
- KaiserPro
Für ein Unternehmen, für das ich arbeite, musste ich eine Maschine über unbekannte Kanäle versenden und ein gewisses Vertrauen haben, dass sie nicht manipuliert wurde.
Mein Bedrohungsmodell war ein einigermaßen technischer Ingenieur, der aus irgendeinem Grund Laufwerke austauscht, oder jemand, der behauptet, dass die Maschine "anders" ist. (kein Staatsterrorismus-Scheiß)
Nachdem die Maschine imagiert wurde, würde sie sich mit unserem zentralen Konfigurationsserver verbinden, ihren Hostnamen erhalten und Schlüssel austauschen, die im TPM eingebettet wären.
Sobald die Maschine versendet und gebootet ist, checkt sie ein und signiert eine Challenge. Jede Art von Aktion auf der zentralen API könnte eine Challenge haben. Jede Maschine wird mindestens einmal pro Stunde attestiert.
Ich bin mir nicht sicher, wie "sicher" das alles ist, aber es scheint zu funktionieren.
- duk3luk3
Klingt interessant; schade, dass wir nur Text von einer LLM bekommen und nicht die Einsichten des Autors.
- ted_dunning
Die Verbindung zwischen Attestierung und Schlüssel wird mit TAS schön hergestellt. TAS gibt dir ein Zertifikat und Spiffe verlangt dann ein solches Zertifikat, um ein SVID zu geben, das du als Zertifikat für mTLS verwendest.
Das bedeutet, dass die Vertrauenswurzel durch Software (TAS) verläuft, die überprüft, dass deine Attestierungsnachweise mit der Live-Policy übereinstimmen. Das funktioniert ohne Änderungen an Spiffe.
Das erfüllt nicht wirklich deine Anforderungen, den Schlüssel aus dem Speicher herauszuhalten, da das resultierende SVID mehrere Minuten im Speicher bleibt, aber es erfüllt die Bedürfnisse der meisten Menschen.
- yusufmotiwala
Ist das nicht ein bereits gut diskutiertes Problem und nicht spezifisch für TPM?
Wir hatten ein ähnliches Problem (wir verwenden OpenSSL). OpenSSL hat OPENSSL_secure_malloc(), das verhindert, dass sensible Speicherinhalte ausgegeben werden. Das Problem ist jedoch, dass nicht alle Pfade den sicheren Allokator verwenden. Zum Beispiel dieses Issue: https://github.com/openssl/openssl/issues/27603
Ich bin nicht sicher, ob sich das in OpenSSL 4.x geändert hat, aber es ist sicherlich etwas Wünschenswertes.