Die Linux Foundation, BastionZero und Docker haben ein neues Open-Source-Projekt namens OpenPubKey ins Leben gerufen, das ein gleichnamiges kryptografisches Protokoll zur Bestätigung von digitaler Signatur beliebiger Objekte entwickelt. Die Technologie wurde als gemeinsames Projekt der Unternehmen BastionZero und Docker entwickelt, um die Bestätigung von digitalen Signaturen für Docker-Images zu vereinfachen, um deren Manipulation zu verhindern und die Erstellung durch den angegebenen Ersteller zu bestätigen. Das Projekt wird auf einer neutralen Plattform unter dem Schirm der Linux Foundation weiterentwickelt, was eine Abhängigkeit von einzelnen kommerziellen Unternehmen ausschließt und die Zusammenarbeit mit externen Teilnehmern erleichtert. 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 verwendet werden, um die Herkunft beliebiger Ressourcen zu bestätigen, Manipulationen von Abhängigkeiten zu verhindern und die Sicherheit von Verbreitungskanälen für Datensätze zu erhöhen. So kann die Technologie zum Beispiel zur Bestätigung von Software-Builds, einzelnen Nachrichten und Commits eingesetzt werden. Für die Ersteller der Signaturen reicht ein Konto bei einem Dienst, der OpenID unterstützt, während den Verbrauchern die Möglichkeit gegeben wird, angehängte Signaturen zu überprüfen und ihre Verbindung zu der angegebenen OpenID zu bestätigen.
In ihrer Funktionalität ähnelt OpenPubKey dem von Google entwickelten und zuvor an die Linux Foundation übergebenen System Sigstore, unterscheidet sich jedoch erheblich durch die Vereinfachung von Implementierung, Nutzung und Wartung dank der Beseitigung zentralisierter Serverkomponenten, die für die Führung eines öffentlichen Logs zur Bestätigung der Echtheit von Änderungen (transparency log) verantwortlich sind und die Arbeit von Zertifizierungsstellen (Certificate Authority) gewährleisten.
Statt eigene Zertifizierungsstellen zu betreiben, verwendet OpenPubKey die Authentifizierung mit der 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. Die Technologie ist vollständig kompatibel mit bestehenden OpenID-Anbietern wie GitHub, Azure/Microsoft, Okta, OneLogin, Keycloak und Google und erfordert keine Änderungen auf deren Seite (es wird ein standardmäßiger ID-Token des Anbieters verwendet, was die Implementierung von OpenPubKey nur durch Änderungen auf der Client-Seite von OpenID Connect ermöglicht).
Der vom OpenID-Anbieter ausgestellte Token wird in ein Zertifikat umgewandelt, das den Identifikator im OpenID Connect kryptografisch mit dem öffentlichen Schlüssel verknüpft. Anschließend verwendet der Benutzer den generierten Schlüssel, um beliebige Daten zu signieren, und diese Signaturen können später auf die Verbindung zum Identifikator im OpenID Connect überprüft werden. Bei OpenPubKey kommen ephemere Schlüssel zum Einsatz, deren Lebensdauer begrenzt ist – die Schlüssel werden beim Login mittels OpenID generiert und beim Ende der Sitzung mit dem OpenID-Anbieter gelöscht.
Beispielalgorithmus zur Erstellung einer Signatur mit OpenPubKey:
- Anmeldung über einen OpenID-Anbieter (Google, GitHub, Microsoft usw.).
- Anfrage eines Identitätstokens beim OpenID-Anbieter.
- Rückgabe eines Tokens, der mit dem Schlüssel des Anbieters signiert ist und ein Feld 'nonce' mit beliebigen bei der Anfrage übermittelten Daten enthält (der SHA3-Hash des öffentlichen Schlüssels wird übermittelt).
- Verwendung des erhaltenen Tokens auf der Benutzerseite als Zertifikat, das die Schlüsseldaten enthält.
- Anheften des Tokens an die Signatur, ähnlich wie bei einem Zertifikat.
Die Verifizierung besteht darin, zu überprüfen, ob das angehängte Token vom OpenID-Anbieter signiert wurde, und die Gültigkeit der digitalen Signatur des Ressourcen über den öffentlichen Schlüssel zu prüfen, was es ermöglicht festzustellen, dass die Ressource mit einer Identifikation aus dem Zertifikat signiert wurde und dies durch die Signatur des OpenID-Anbieters bestätigt wird. Zum Beispiel kann derjenige, der die Signatur erstellt, ein von Google, dem OpenID-Anbieter, signiertes Token erhalten, das die Information enthält, 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 wurde, kann der Empfänger 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 wurde durch bestimmte Kompromisse erreicht (z.B. Abhängigkeit von externen OpenID-Anbietern und fehlendes Änderungsprotokoll mit hierarchischer Hash-Bildung), die unter bestimmten Umständen zulässig sind, unter anderen jedoch nicht. Um die Abhängigkeit von OpenID-Anbietern, deren Kompromittierung oder Handlungen das System diskreditieren können (z.B. kann ein gehackter Anbieter einen falschen Schlüssel an Dritte weitergeben), zu verringern, wird vorgeschlagen, ein zusätzliches, aber nicht notwendiges, Bindeglied MFA-Cosigner (Multi-Factor Authentication Cosigner) für die Multi-Faktor-Authentifizierung zu verwenden (das Token muss nicht nur vom Hauptanbieter, sondern auch von einem unabhängigen Authentifizierungsdienst signiert werden, der den Benutzer bestätigt).
Zu den Schwächen von OpenPubKey gehört auch, dass Dritte Informationen erhalten können, die zur Verfolgung von Aktivitäten über lange Zeiträume hinweg genutzt werden können, unabhängig von Umbenennungen (erneute Nutzung des identifizierenden Tokens anstelle eines neuen Zertifikats). Die direkte Bindung an die OpenID Connect-Schlüssel bei der Verifizierung schließt die Serverseite aus, erschwert jedoch die Implementierung auf der Clientseite erheblich und lässt mehr Raum für Angriffe (Attack Surface) auf den Client, beispielsweise weil die Aufgabe der Schlüsselrotation auf dem Client lastet. Das Fehlen eines Änderungsprotokolls ermöglicht es dem Client nicht, mögliche Schlüsselverluste zu verfolgen.
Quelle: opennet.ru
