Google hat die ersten stabilen Versionen der Komponenten bekannt gegeben, die das Sigstore-Projekt bilden, das in der Erstellung von produktiven Implementierungen als geeignet erachtet wird. Sigstore entwickelt Werkzeuge und Dienste zur Verifizierung von Software mittels digitaler Signaturen und zur F\u00fchrung eines \u00f6ffentlichen Logs, das die Authentizit\u00e4t von \u00c4nderungen belegt (Transparency-Log). Das Projekt wird unter dem Dach der gemeinn\u00fctzigen Organisation Linux Foundation von Unternehmen wie Google, Red Hat, Cisco, VMware, GitHub und HP Enterprise sowie mit Beteiligung der OpenSSF (Open Source Security Foundation) und der Purdue University vorangetrieben. <\/p>\n
Sigstore kann als das Pendant zu Let's Encrypt f\u00fcr Code betrachtet werden und bietet Zertifikate zur Best\u00e4tigung von Code durch digitale Signaturen sowie Werkzeug zur Automatisierung der \u00dcberpr\u00fcfung. Mit Sigstore k\u00f6nnen Entwickler digitale Signaturen f\u00fcr Anwendungsartefakte erstellen, wie zum Beispiel Release-Dateien, Container-Images, Manifeste und ausf\u00fchrbare Dateien. Das genutzte Material zur Signierung wird in einem unver\u00e4nderbaren \u00f6ffentlichen Log festgehalten, das f\u00fcr \u00dcberpr\u00fcfungen und Audits verwendet werden kann. <\/p>\n
Anstelle von permanenten Schl\u00fcsseln verwendet Sigstore kurzlebige, ephemeral Schl\u00fcssel, die auf der Grundlage von Berechtigungen generiert werden, die von OpenID Connect-Anbietern best\u00e4tigt werden (zum Zeitpunkt der Schl\u00fcsselerzeugung, die zur Erstellung einer digitalen Signatur erforderlich ist, identifiziert sich der Entwickler \u00fcber den OpenID-Anbieter mit einer E-Mail-Adresse). Die Authentizit\u00e4t der Schl\u00fcssel wird durch ein \u00f6ffentliches zentrales Protokoll \u00fcberpr\u00fcft, das sicherstellt, dass der Unterzeichner tats\u00e4chlich die Person ist, f\u00fcr die er sich ausgibt, und dass die Signatur von demselben Teilnehmer erstellt wurde, der auch f\u00fcr fr\u00fchere Releases verantwortlich war. <\/p>\n
Die Marktreife von Sigstore wird durch die Ver\u00f6ffentlichung von zwei zentralen Komponenten \u2014 Rekor 1.0 und Fulcio 1.0 \u2014 unterst\u00fctzt, deren Programmierschnittstellen als stabil erkl\u00e4rt wurden und zuk\u00fcnftig abw\u00e4rtskompatibel bleiben. Die Komponenten des Dienstes sind in der Programmiersprache Go geschrieben und stehen unter der Lizenz Apache 2.0. <\/p>\n
Die Rekor-Komponente enth\u00e4lt eine Protokollimplementierung zur Speicherung von mit digitalen Signaturen beglaubigten Metadaten, die Informationen \u00fcber Projekte widerspiegeln. Zur Gew\u00e4hrleistung der Integrit\u00e4t und zum Schutz vor nachtr\u00e4glicher Datenverf\u00e4lschung wird eine Baumstruktur, das sogenannte \"Merkle-Baum\", verwendet, in der jeder Ast alle darunter liegenden \u00c4ste und Knoten durch gemeinsames (baumartiges) Hashing verifiziert. Mit einem endg\u00fcltigen Hash kann der Nutzer die Korrektheit der gesamten Transaktionshistorie sowie die Korrektheit vergangener Datenbankzust\u00e4nde \u00fcberpr\u00fcfen (der Root-Hash des neuen Zustands wird unter Ber\u00fccksichtigung des vorherigen Zustands berechnet). Zur Verifizierung und zum Hinzuf\u00fcgen neuer Eintr\u00e4ge steht eine RESTful API sowie eine Kommandozeilenoberfl\u00e4che zur Verf\u00fcgung. <\/p>\n
Die Fulcio-Komponente (SigStore WebPKI) umfasst ein System zur Erstellung von Zertifizierungsstellen (Root CA), die kurzlebige Zertifikate basierend auf E-Mail ausstellen, die \u00fcber OpenID Connect authentifiziert werden. Die Lebensdauer des Zertifikats betr\u00e4gt 20 Minuten, in denen der Entwickler eine digitale Signatur erstellen muss (wenn das Zertifikat sp\u00e4ter in die falschen H\u00e4nde ger\u00e4t, ist es bereits abgelaufen). Zus\u00e4tzlich wird im Rahmen des Projekts das Tool Cosign (Container Signing) entwickelt, das zur Erstellung von Container-Signaturen, zur \u00dcberpr\u00fcfung von Signaturen und zur Ablage von signierten Containern in OCI-kompatiblen Repositories dient. <\/p>\n
Die Implementierung von Sigstore erh\u00f6ht die Sicherheit der Vertriebswege von Software und sch\u00fctzt vor Angriffen, die auf das Ersetzen von Bibliotheken und Abh\u00e4ngigkeiten (Supply Chain) abzielen. Ein zentrales Sicherheitsproblem in der Open-Source-Software ist die Schwierigkeit, die Quelle des Programms zu \u00fcberpr\u00fcfen und den Build-Prozess zu verifizieren. Beispielsweise nutzen die meisten Projekte zur \u00dcberpr\u00fcfung der Integrit\u00e4t eines Releases Hashes, doch oft wird die zur Authentifizierung ben\u00f6tigte Information auf ungesch\u00fctzten Systemen und in \u00f6ffentlichen Koderepositories gespeichert. Dadurch k\u00f6nnen Angreifer die f\u00fcr die Verifizierung notwendigen Dateien austauschen und, ohne Verdacht zu erregen, sch\u00e4dliche \u00c4nderungen einf\u00fcgen. <\/p>\n