Signaturen, Attestierungen und Provenance

Signaturen, Attestierungen und Provenance

0:00 Dieses Modul beantwortet die Frage, die seit Modul eins offen ist: Wie macht man aus einem Vertrauensvorschuss einen Nachweis? Bisher haben wir Risiken verkleinert — enge Rechte, geschützte Zweige, gehärtete Pipeline. Jetzt kommt etwas qualitativ anderes dazu: eine überprüfbare Aussage darüber, wer für ein Artefakt geradesteht und wie es entstanden ist.

0:22 Und gleich eine Klarstellung, die wichtig ist: Eine Signatur beweist nicht, dass etwas gut ist. Sie beweist, wer dafür geradesteht. Die Qualitätsfrage bleibt Ihre.

Signaturen, Attestierungen und Provenance

0:33 Drei Schritte. Zuerst klären wir drei Begriffe, die durcheinandergehen: Prüfsumme, Signatur und Attestierung — sie beantworten drei verschiedene Fragen. Dann schauen wir uns das schlüssellose Signieren an, ein Verfahren, das die unangenehmste Aufgabe der Kryptografie elegant löst: die Verwahrung des privaten Schlüssels.

0:52 Und zum Schluss die Provenance — die Aussage darüber, woraus, womit und auf welcher Plattform ein Artefakt entstanden ist.

Prüfsumme, Signatur und Attestierung

0:59 Fangen wir mit den Begriffen an. Die drei werden oft synonym verwendet, und das führt zu Aussagen wie „das Image ist signiert, also ist es sicher". Wenn wir die drei sauber trennen, wird schnell klar, was jedes Mittel leistet — und vor allem, was es nicht leistet. Drei Mittel, drei Fragen. Eine Prüfsumme sagt, ob ein Artefakt unverändert ist — sie vergleicht nur.

1:22 Eine Signatur sagt zusätzlich, wer sich zu ihm bekennt; sie bindet eine Identität an den Inhalt. Und eine Attestierung ist eine signierte Aussage über ein Artefakt — etwa darüber, unter welchen Umständen es entstanden ist. Erst diese dritte Stufe beantwortet Fragen zur Herkunft. Ein Bild: Die Prüfsumme ist das Siegel auf der Verpackung, die Signatur der Absender auf dem Paket, und die Attestierung der Lieferschein, der sagt, was wo produziert wurde.

1:50 Drei Schichten mit zunehmender Aussagekraft. Ist es noch dasselbe wie eben? Wer bekennt sich dazu? Was wird über die Entstehung ausgesagt? Wenn Sie diese drei Fragen im Kopf behalten, ordnen sich alle Werkzeuge dieses Themenfelds von selbst ein. Und Sie erkennen schnell, wenn eine Zusage zu hoch gehängt wird. „Wir prüfen Hashes" beantwortet nur die erste Frage — bei einem ausgetauschten Artefakt samt ausgetauschter Prüfsumme nützt das nichts, wenn beide vom selben Server kommen.

2:20 Das ist der wichtigste Satz des Moduls, deshalb langsam: Gültig signiert heißt zunächst nur, dass irgendjemand mit einem gültigen Zertifikat unterschrieben hat. Irgendjemand. Erst die erwartete Identität und der erwartete Aussteller machen daraus eine Prüfung — also die Angabe, wessen Unterschrift Sie überhaupt akzeptieren.

2:39 Der dritte Punkt ist ebenso wichtig: Ohne Bindung an den Digest gilt die Aussage womöglich für ein anderes Artefakt. Und der vierte fasst das Ergebnis zusammen, wenn beides fehlt — eine Verifikation ohne festgelegte Erwartung ist ein grüner Haken ohne Inhalt. Die rechte Spalte ist wieder die lehrreiche. Die Prüfsumme wehrt zufällige Veränderung ab — Übertragungsfehler, kaputte Downloads.

3:02 Gegen einen gezielten Austausch samt neu berechneter Summe hilft sie nicht. Die Signatur wehrt fremde Urheberschaft ab, aber nicht die Fehler des echten Urhebers; ein signiertes Artefakt kann eine Schwachstelle enthalten. Und die Attestierung wehrt erfundene Herkunft ab, aber nicht die falsche Aussage der Plattform. Deshalb die Fußzeile: Es hängt alles daran, wer die Attestierung erzeugt — nicht daran, dass es eine gibt. Genau das messen die SLSA-Stufen.

3:30 Der erste Punkt ist verbreitet und wirkungslos: Die Prüfsumme liegt neben dem Artefakt auf demselben Server. Wer das Artefakt austauschen kann, tauscht die Summe gleich mit. Der zweite ist der eben besprochene grüne Haken ohne Erwartung. Der dritte ist ein Fehler mit Langzeitwirkung — signiert wird ein Tag statt eines Digests, und der Tag wandert später auf ein anderes Image; die Signatur bleibt gültig und meint etwas anderes.

3:55 Und der vierte ist der häufigste organisatorische Fehler: Die Attestierung wird erzeugt, aber vor dem Deployment nie gelesen.

Keyless Signing mit Cosign

4:03 Kommen wir zum interessantesten technischen Verfahren dieses Seminars. Es löst ein Problem, an dem klassische Signaturverfahren in der Praxis regelmäßig scheitern: die Verwahrung des privaten Schlüssels. Und es löst es auf eine Weise, die zunächst paradox klingt — indem es den Schlüssel nach wenigen Minuten wegwirft. Der Ablauf ist bemerkenswert. Cosign erzeugt ein flüchtiges Schlüsselpaar im Arbeitsspeicher.

4:27 Eine Zertifizierungsstelle namens Fulcio prüft das Identitätstoken — also den Nachweis, wer Sie sind — und stellt ein kurzlebiges Zertifikat aus, das diese Identität an den öffentlichen Schlüssel bindet. Der private Schlüssel wird kurz nach der Verwendung vernichtet, das Zertifikat läuft ab. Und der Vorgang wird in einem Transparenzprotokoll namens Rekor mit Zeitstempel festgehalten.

4:49 Ein Schlüssel, den es nur für Minuten gab, kann später nicht gestohlen werden — das ist die ganze Idee. Vier Schritte: Identität nachweisen, Zertifikat erhalten, signieren, im Protokoll bezeugen. Der vierte ist der, der die Konstruktion erst trägt. Denn ein abgelaufenes Zertifikat wirft eine Frage auf: Wie prüfe ich später, ob die Signatur zum Zeitpunkt des Signierens gültig war?

5:13 Die Antwort liefert das Transparenzprotokoll — es bezeugt den Vorgang mit einem Zeitstempel. Ohne diesen Baustein müssten Sie den Schlüssel aufbewahren, und dann wären wir wieder beim alten Problem. So aber ersetzt ein öffentliches Protokoll den Tresor. Zwei Befehle, und auf zwei Details kommt es an. Erstens wird der Digest signiert, nicht der Tag — der Tag könnte morgen woanders hinzeigen.

5:37 Zweitens, und das ist der eigentliche Punkt dieser Folie: Der Prüfbefehl nennt die erwartete Identität und den erwarteten Aussteller. Genau diese beiden Angaben machen aus einer technischen Prüfung eine inhaltliche. Die Fußzeile sagt, was ohne sie übrig bleibt — die Bestätigung, dass überhaupt jemand signiert hat. Und das ist in einer Welt, in der jeder signieren kann, ungefähr so aussagekräftig wie ein Brief mit Unterschrift ohne Absender.

6:04 Der Signaturvorgang wird öffentlich bezeugt und mit einem Zeitstempel versehen — damit ist nachvollziehbar, wann eine Identität etwas signiert hat. Das hat eine Nebenwirkung, die manche überrascht: Auch ein Angreifer, der Ihre Identität missbraucht, hinterlässt einen Eintrag. Es gibt also eine Spur, die sich prüfen lässt.

6:23 Der dritte Punkt ist der schon genannte Kern: Ein Schlüssel, den es nur für Minuten gab, kann nicht gestohlen werden. Und der vierte ist praktisch wichtig für das nächste Kapitel — Signaturen liegen als eigenständige Artefakte in der Registry, nicht im Image. Der erste Punkt ist der Tag-Fehler, diesmal mit voller Wirkung: Die Signatur gilt für einen Zeiger, der später auf ein anderes Image zeigt.

6:46 Der zweite ist menschlich nachvollziehbar und trotzdem fatal — die erwartete Identität wird im Prüfbefehl weggelassen, weil es dann zuverlässiger grün wird. Der dritte ist ein Prozessfehler: Signiert wird von einem Arbeitsplatz aus statt aus der Pipeline; damit hängt die Aussage an einer Person und nicht an einem nachvollziehbaren Ablauf.

7:05 Und der vierte fällt oft erst spät auf — beim Umkopieren zwischen Registries bleibt die Signatur zurück.

Provenance erzeugen und verifizieren

7:12 Im dritten Kapitel geht es um die dritte Stufe: die Attestierung über die Entstehung eines Artefakts. Sie ist das Bindeglied zwischen allem, was wir bisher gebaut haben — sie verbindet den Commit mit dem Build und den Build mit dem Image, das gleich im Cluster startet. Build-Provenance ist eine Attestierung über die Entstehung eines Artefakts. Sie benennt das Artefakt über seinen Digest und hält die Eingaben des Builds fest.

7:36 Und jetzt kommt der Punkt, an dem die SLSA-Stufen wieder auftauchen: Ab Build-Stufe zwei erzeugt die Steuerungsebene der Plattform diese Angaben selbst — damit der Auftraggeber des Builds sie nicht beeinflussen kann. Der Unterschied ist entscheidend. Eine Provenance, die Ihr eigenes Build-Skript schreibt, sagt nur, was Ihr Skript behauptet.

7:55 Eine, die die Plattform schreibt, sagt, was die Plattform beobachtet hat. Vier Angaben, und die rechte Spalte ist die eigentliche Arbeit: Wogegen wird geprüft? Das Artefakt gegen das ausgerollte Image. Die Herkunft gegen das erwartete Repository — nicht gegen irgendein Repository. Die Plattform gegen die erwartete Build-Instanz.

8:16 Und die Parameter gegen die erwarteten Parameter, also zum Beispiel gegen den erwarteten Branch. Die Fußzeile bringt es auf den Punkt: Erst wenn alle vier Zeilen eine Erwartung haben, ist die Verifikation mehr als eine Formsache. Eine Attestierung ohne Erwartung ist nur ein Dokument, das mitgeliefert wird. Fünf Schritte zu einer Regel, die tatsächlich wirkt. Festlegen, aus welchem Repository ein Artefakt stammen darf. Festlegen, welche Identität und welcher Aussteller gültig sind.

8:46 Die Bindung an den Digest verlangen. Und dann der Schritt, der über Wirkung oder Wirkungslosigkeit entscheidet: Die Regel im Deployment erzwingen, nicht nur in der Pipeline prüfen. Denn wer an der Pipeline vorbei ausrollt, umgeht eine Pipeline-Prüfung mühelos. Die Fußzeile nennt den letzten Schritt und seinen Grund: Eine Regel, deren Ablehnungsfall nie erprobt wurde, ist eine Vermutung.

9:10 Der erste Punkt ist der Ablagefehler, den wir schon bei der Stückliste hatten: Die Provenance liegt im Build-Lauf, wo das Deployment sie nicht sieht. Der zweite ist oberflächliche Prüfung — geprüft wird die Existenz der Attestierung, nicht ihr Inhalt; das kommt häufiger vor, als man denkt, weil es einfach zu bauen ist. Der dritte ist ein Ort-Problem: Die Erwartungen stehen im Prüfbefehl statt an einer zentralen, geschützten Stelle, und damit kann sie jeder ändern, der den Befehl ändert.

9:37 Und der vierte ist ein Denkfehler in der Architektur — die Verifikation läuft in derselben Pipeline, die auch signiert hat.

Übung

9:44 In der Übung signieren Sie Image und Stückliste der Deichwacht und richten eine Verifikation ein. Und dann kommt der Teil, den ich für den wichtigsten der ganzen Übung halte: Sie bauen absichtlich ein abweichendes Image und weisen nach, dass die Prüfung es zurückweist. Drei Ergebnisse: schlüssellos signiertes Image und signierte Stückliste, der Vorgang im Transparenzprotokoll auffindbar, und ein von Hand nachgebautes Image scheitert an der Prüfung.

10:10 Der Hinweis erklärt, warum der Gegenversuch dazugehört — eine Prüfung, die nie etwas ablehnt, beweist nichts. Das ist eine allgemeine Regel für Sicherheitsmaßnahmen, die weit über dieses Modul hinausreicht: Der Beleg für eine Kontrolle ist nicht, dass der gute Fall durchgeht. Der Beleg ist, dass der schlechte Fall hängen bleibt.

10:29 Digest ermitteln und festhalten. Image und Stückliste aus der Pipeline heraus signieren — aus der Pipeline, nicht vom Arbeitsplatz. Den Eintrag im Transparenzprotokoll wiederfinden, damit Sie einmal gesehen haben, wie dieser Nachweis aussieht. Mit erwarteter Identität und erwartetem Aussteller verifizieren. Und schließlich der Gegenversuch. Die Fußzeile sagt alles über die Rolle des letzten Schritts: Er ist der einzige, der belegt, dass die vorherigen vier gewirkt haben.

10:58 Der erste Punkt ist genau das Auslassen des Gegenversuchs, weil der Hauptfall grün war. Der zweite ist eine Reihenfolgefalle mit technischer Ursache: Signiert wird nach dem Umkopieren in eine andere Registry, wobei sich der Digest ändert — dann passt die Signatur nicht mehr. Der dritte betrifft die Stückliste, die unsigniert bleibt, obwohl sie später als Auskunft an Kunden dient; eine unsignierte Auskunft ist auf dem Weg veränderbar.

11:23 Und der vierte ist das Ortsproblem von vorhin — die Erwartungen leben im Übungsbefehl und stehen nirgends fest. Morgen bringen wir das alles in die SLSA-Systematik.