Die Linux Foundation, BastionZero und Docker haben ein neues Open-Source-Projekt namens OpenPubKey ins Leben gerufen, das ein gleichnamiges kryptografisches Protokoll zur Beglaubigung digitaler Signaturen beliebiger Objekte entwickelt. Die Technologie wurde als Gemeinschaftsprojekt von BastionZero und Docker entwickelt, um die Beglaubigung digitaler Signaturen von Docker-Images zu erleichtern, um ihre Manipulation zu verhindern und die Erstellung durch den angegebenen Ersteller zu bestätigen. Das Projekt wird auf einer neutralen Plattform unter dem Dach der Linux Foundation weiterentwickelt, wodurch die Abhängigkeit von einzelnen kommerziellen Unternehmen beseitigt und die Zusammenarbeit mit externen Akteuren erleichtert wird. Die Referenzimplementierung von OpenPubKey ist in Go geschrieben und wird unter der Lizenz Apache 2.0 verbreitet.
Die Möglichkeiten von OpenPubKey beschränken sich nicht nur auf Container-Images; die Technologie kann auch zur Bestätigung der Herkunft beliebiger Ressourcen eingesetzt werden, um Abhängigkeiten vor Manipulation zu schützen und die Sicherheit von Datenverteilungswegen zu erhöhen. So kann die Technologie beispielsweise für die Beglaubigung von Software-Builds, einzelnen Nachrichten und Commits verwendet werden. Signierer benötigen lediglich ein Konto bei einem Dienst, der OpenID unterstützt, während den Nutzern die Möglichkeit eingeräumt wird, angehängte Signaturen zu überprüfen und deren Zusammenhang mit der angegebenen OpenID zu bestätigen.
In ihrer Funktion ähnelt OpenPubKey dem von Google entwickelten und zuvor an die Linux Foundation übergebenen System Sigstore, unterscheidet sich jedoch durch eine wesentliche Vereinfachung bei der Implementierung, Nutzung und Wartung, da sie auf zentralisierte Serverkomponenten verzichtet, die für die Führung eines öffentlichen Logs zur Bestätigung der Änderungen (Transparency Log) und die Bereitstellung von Zertifizierungsstellen (Certificate Authority) verantwortlich sind.
Anstelle der Einrichtung eigener Zertifizierungsstellen nutzt OpenPubKey die Authentifizierung über die OpenID-Technologie und verknüpft die erstellten Signaturen mit bestehenden OpenID Connect-Anbietern. Mit anderen Worten, OpenPubKey ermöglicht es, kryptografische Schlüssel spezifischen Benutzern zuzuordnen, indem OpenID Connect-Anbieter (IdP) anstelle von Zertifizierungsstellen verwendet werden. Diese Technologie ist vollständig kompatibel mit bestehenden OpenID-Anbietern wie GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak und Google, ohne dass Änderungen auf deren Seite erforderlich sind (es wird das vom Anbieter bereitgestellte Standard-ID-Token verwendet, was die Implementierung von OpenPubKey nur durch Änderungen auf der Client-Seite von OpenID Connect ermöglicht).
Das vom Anbieter ausgegebene OpenID-Token wird in ein Zertifikat umgewandelt, das den Identifikator im OpenID Connect kryptografisch an den öffentlichen Schlüssel bindet. Anschließend nutzt der Benutzer den generierten Schlüssel, um beliebige Daten zu signieren, und diese Signaturen können später auf ihre Verbindung zum Identifikator im OpenID Connect überprüft werden. In OpenPubKey werden flüchtige Schlüssel verwendet, deren Lebensdauer begrenzt ist – die Schlüssel werden bei der Anmeldung mit OpenID generiert und am Ende der Sitzung mit dem OpenID-Anbieter gelöscht.
Beispielhafter Algorithmus zur Erstellung einer Signatur mit OpenPubKey:
- Anmeldung über einen OpenID-Anbieter (Google, GitHub, Microsoft usw.).
- Anfrage eines Identifikationstokens beim OpenID-Anbieter.
- Rückgabe des Tokens, das mit dem Schlüssel des Anbieters signiert ist und ein Feld "nonce" mit zufälligen Daten enthält, die bei der Anfrage übermittelt wurden (es wird der SHA3-Hash des öffentlichen Schlüssels übermittelt).
- Nutzung des erhaltenen Tokens auf der Benutzerseite als Zertifikat, das Informationen über den Schlüssel enthält.
- Anfügung des Tokens an die Signatur, analog zu einem Zertifikat.
Die Verifizierung besteht darin, zu überprüfen, ob das angehängte Token vom OpenID-Anbieter signiert wurde und ob die digitale Signatur für die Ressource mit dem öffentlichen Schlüssel korrekt ist. Dies bestätigt, dass die Ressource mit einer Identität aus dem Zertifikat signiert wurde und dies durch die Signatur des OpenID-Anbieters bestätigt wird. Ein Beispiel: Der Ersteller der Signatur kann ein von Google signiertes OpenID-Token erhalten, das angibt, dass er als bob@gmail.com verifiziert wurde und den öffentlichen Schlüssel 0x54A5…FF verwendet. Bei Erhalt einer Nachricht, die mit demselben Schlüssel signiert ist, kann er das vom Anbieter signierte Token zur Verifizierung nutzen, dass der Schlüssel bob@gmail.com — 0x54A5…FF ist und die Nachricht tatsächlich von bob@gmail.com signiert wurde.
Die Vereinfachung der Architektur erfolgt durch bestimmte Kompromisse (zum Beispiel die Abhängigkeit von externen OpenID-Anbietern und das Fehlen eines Änderungsprotokolls mit hierarchischer Hash-Speicherung), die in einigen Situationen akzeptabel, in anderen jedoch nicht sind. Um die Abhängigkeit von OpenID-Anbietern, deren Kompromittierung oder Handlungen von Mitarbeitern das System diskreditieren könnten (beispielsweise kann ein gehackter Anbieter einem Dritten einen gefälschten Schlüssel geben), zu verringern, wird vorgeschlagen, ein zusätzliches, jedoch nicht verpflichtendes, Element namens MFA-Cosigner (Multi-Factor Authentication Cosigner) für die Multi-Faktor-Authentifizierung zu verwenden (das Token muss nicht nur vom Hauptanbieter signiert werden, sondern auch von einem unabhängigen Authentifizierungsdienst, der den Nutzer bestätigt).
Zu den Schwächen von OpenPubKey gehört auch, dass es Informationen von Dritten gibt, die zur langfristigen Verfolgung von Aktivitäten genutzt werden können, unabhängig von Umbenennungen (Wiederverwendung eines identifizierenden Tokens anstelle eines neuen Zertifikats). Die direkte Bindung an OpenID Connect-Schlüssel bei der Verifizierung schließt den serverseitigen Teil aus, erschwert jedoch erheblich die Implementierung auf der Client-Seite und bietet mehr Angriffsflächen für potenzielle Angriffe (attack surface) auf den Client, da der Client für die Schlüsselrotation verantwortlich ist. Das Fehlen eines Änderungsprotokolls lässt den Client mögliche Schlüsselverletzungen nicht verfolgen.
Quelle: opennet.ru
