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\u00e4tigen. Das Projekt wird auf einer neutralen Plattform unter dem Dach der Linux Foundation weiterentwickelt, wodurch die Abh\u00e4ngigkeit 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. <\/p>\n
Die M\u00f6glichkeiten von OpenPubKey beschr\u00e4nken sich nicht nur auf Container-Images; die Technologie kann auch zur Best\u00e4tigung der Herkunft beliebiger Ressourcen eingesetzt werden, um Abh\u00e4ngigkeiten vor Manipulation zu sch\u00fctzen und die Sicherheit von Datenverteilungswegen zu erh\u00f6hen. So kann die Technologie beispielsweise f\u00fcr die Beglaubigung von Software-Builds, einzelnen Nachrichten und Commits verwendet werden. Signierer ben\u00f6tigen lediglich ein Konto bei einem Dienst, der OpenID unterst\u00fctzt, w\u00e4hrend den Nutzern die M\u00f6glichkeit einger\u00e4umt wird, angeh\u00e4ngte Signaturen zu \u00fcberpr\u00fcfen und deren Zusammenhang mit der angegebenen OpenID zu best\u00e4tigen. <\/p>\n
In ihrer Funktion \u00e4hnelt OpenPubKey dem von Google entwickelten und zuvor an die Linux Foundation \u00fcbergebenen System Sigstore, unterscheidet sich jedoch durch eine wesentliche Vereinfachung bei der Implementierung, Nutzung und Wartung, da sie auf zentralisierte Serverkomponenten verzichtet, die f\u00fcr die F\u00fchrung eines \u00f6ffentlichen Logs zur Best\u00e4tigung der \u00c4nderungen (Transparency Log) und die Bereitstellung von Zertifizierungsstellen (Certificate Authority) verantwortlich sind. <\/p>\n
Anstelle der Einrichtung eigener Zertifizierungsstellen nutzt OpenPubKey die Authentifizierung \u00fcber die OpenID-Technologie und verkn\u00fcpft die erstellten Signaturen mit bestehenden OpenID Connect-Anbietern. Mit anderen Worten, OpenPubKey erm\u00f6glicht es, kryptografische Schl\u00fcssel spezifischen Benutzern zuzuordnen, indem OpenID Connect-Anbieter (IdP) anstelle von Zertifizierungsstellen verwendet werden. Diese Technologie ist vollst\u00e4ndig kompatibel mit bestehenden OpenID-Anbietern wie GitHub, Azure\/Microsoft, Okta, OneLogin, Keycloak und Google, ohne dass \u00c4nderungen auf deren Seite erforderlich sind (es wird das vom Anbieter bereitgestellte Standard-ID-Token verwendet, was die Implementierung von OpenPubKey nur durch \u00c4nderungen auf der Client-Seite von OpenID Connect erm\u00f6glicht). <\/p>\n
Das von dem Anbieter ausgestellte OpenID-Token wird in ein Zertifikat umgewandelt, das die Identifikation in OpenID Connect kryptografisch an den \u00f6ffentlichen Schl\u00fcssel bindet. Der Benutzer nutzt anschlie\u00dfend den generierten Schl\u00fcssel, um Daten zu signieren. Diese Signaturen k\u00f6nnen sp\u00e4ter auf ihre Verbindung zur Identifikation in OpenID Connect \u00fcberpr\u00fcft werden. In OpenPubKey kommen tempor\u00e4re Schl\u00fcssel zum Einsatz, deren Lebensdauer begrenzt ist \u2013 die Schl\u00fcssel werden beim Login mithilfe von OpenID generiert und beim Beenden der Sitzung mit dem OpenID-Anbieter gel\u00f6scht. <\/p>\n
Beispielhafter Algorithmus zur Erstellung einer Signatur mit OpenPubKey: <\/p>\n
Die Verifizierung besteht darin, zu \u00fcberpr\u00fcfen, ob das angeh\u00e4ngte Token vom OpenID-Anbieter signiert wurde, und die Richtigkeit der digitalen Signatur des Ressourcen mit dem \u00f6ffentlichen Schl\u00fcssel zu \u00fcberpr\u00fcfen. Dadurch kann sichergestellt werden, dass die Ressource mit der ID aus dem Zertifikat signiert wurde und dies durch die Signatur des OpenID-Anbieters best\u00e4tigt ist. Beispielsweise kann der Ersteller der Signatur ein vom OpenID-Anbieter Google signiertes Token erhalten, das Informationen enth\u00e4lt, dass es als bob@gmail.com verifiziert wurde und den \u00f6ffentlichen Schl\u00fcssel 0x54A5\u2026FF verwendet. Weiterhin kann der Empf\u00e4nger einer Nachricht, die mit demselben Schl\u00fcssel signiert wurde, das signierte Token des Anbieters verwenden, um zu verifizieren, dass der Schl\u00fcssel bob@gmail.com \u2014 0x54A5\u2026FF ist und die Nachricht tats\u00e4chlich von bob@gmail.com signiert wurde. <\/p>\n
Die Vereinfachung der Architektur wurde durch bestimmte Kompromisse erreicht (zum Beispiel die Abh\u00e4ngigkeit von externen OpenID-Anbietern und das Fehlen eines \u00c4nderungsprotokolls mit hierarchischer Hashung), die in einigen Situationen akzeptabel sind, in anderen jedoch nicht. Um die Abh\u00e4ngigkeit von OpenID-Anbietern zu verringern, deren Kompromittierung oder Handlungen des Personals das System diskreditieren k\u00f6nnten (zum Beispiel kann ein gehackter Anbieter einen gef\u00e4lschten Schl\u00fcssel an Dritte herausgeben), wird die Verwendung eines zus\u00e4tzlichen, jedoch nicht obligatorischen, Elements MFA-Cosigner (Multi-Factor Authentication Cosigner) f\u00fcr die Mehrfaktorauthentifizierung vorgeschlagen (das Token muss nicht nur vom Hauptanbieter, sondern auch von einem unabh\u00e4ngigen Authentifizierungsdienst signiert werden, der den Benutzer best\u00e4tigt). <\/p>\n