Signaturschlüssel

IronFlock signiert alles, was Geräte und Appliances installieren. Jedes Gerät und jede Appliance prüft die Signatur gegen Schlüssel, die bereits darauf vorhanden sind, bevor das Heruntergeladene ausgeführt oder verwendet wird. Diese Seite nennt diese Schlüssel, was jeder von ihnen signiert und wie ein Schlüssel ersetzt (rotiert) wird, ohne dass danach ein Gerät oder eine Appliance das nächste Update nicht mehr prüfen kann.

Die Schlüssel

Die beiden OpenPGP-Schlüssel lassen sich für eine Prüfung von Hand herunterladen: der Appliance-Schlüssel von https://instance-registry.ironflock.com/dl/appliance/appliance-release.asc (siehe Installer vor der ersten Installation prüfen), der Bootstrap-Schlüssel von https://instance-registry.ironflock.com/dl/device-init/ironflock-bootstrap.asc (siehe Optional: Installer zuerst prüfen). Vergleichen Sie den Fingerabdruck, den gpg meldet, mit dem auf dieser Seite. Die Schlüssel des Geräte-Agenten sind in den Agenten eingebaut; hier gibt es nichts von Hand zu prüfen.

Unter Windows prüft der Geräte-Agent jedes Update und jede frpc.exe, die er herunterlädt, gegen das in ihn eingebaute Code-Signing-Stammzertifikat: Die Datei muss eine gültige Signatur eines Signierschlüssels tragen, dessen Zertifikat dieses Stammzertifikat ausgestellt hat. Ab Version 1.5.6 wird eine Datei, die die Prüfung nicht besteht, gelöscht und nicht ausgeführt; die Versionen 1.5.4 und 1.5.5 haben den Fehler nur protokolliert. Das Zertifikat des Signierschlüssels wird zum Zeitpunkt der Prüfung geprüft, daher aktualisiert sich ein Windows-Gerät, dessen Uhr außerhalb der Gültigkeit des Zertifikats liegt, erst, wenn seine Uhr stimmt. Bei jedem Start prüft der Agent außerdem seine eigene ausführbare Datei und schreibt codesign: self-check passed oder codesign: self-check FAILED in sein Log, C:\ProgramData\IronFlock\DeviceAgent\device-agent.log; ein Gerät, das FAILED protokolliert, lehnt Updates ab, die so signiert sind wie der Agent, den es ausführt.

Der Installer des Agenten fügt das Code-Signing-Stammzertifikat außerdem den vertrauenswürdigen Stammzertifikaten des Computers hinzu. Die Prüfung des Agenten braucht es dort nicht, daher prüft ein Gerät, das installiert wurde, bevor der Installer das tat, seine Updates genauso. Um zu prüfen, dass es das Stammzertifikat auf dieser Seite ist, führen Sie in PowerShell Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -like '*IronFlock Code Signing Root*' | Format-List Subject, Thumbprint, NotAfter aus; der Fingerabdruck (Thumbprint) muss 6083E7E2446B8C95A6F6B2E3CFE354AE02859196 lauten. Ist das Stammzertifikat dort vorhanden, zeigt Get-AuthenticodeSignature "$env:ProgramData\IronFlock\DeviceAgent\device-agent.exe" | Select-Object Status, @{ n = 'Serial'; e = { $_.SignerCertificate.SerialNumber } } den Status Valid; Windows schreibt die Seriennummer mit führender 00, also 00D137272B35F0ED5211219674E8B052B4. Geräte-Agenten vor Version 1.5.4 und frpc.exe bis frp-Version 0.71.1 tragen das vorherige Zertifikat des Windows-Signierschlüssels, Seriennummer 481360741E254378C38A5236940BFFA44CFDD809, ausgestellt vom selben Stammzertifikat. Mit ihm wird nichts Neues mehr signiert; der Agent akzeptiert seine Signaturen, bis das Zertifikat im Oktober 2028 endet.

Jedes Service-Image der IronFlock-Plattform, das ab dem 6. November 2026 veröffentlicht wird, trägt seine Build-Provenienz als signierte Attestierungen, eine für jede Plattform des Images, im Format SLSA v1 Provenance: das Quell-Repository, den Commit, den Build und die Basis-Images, aus denen es gebaut wurde. Die Attestierungen liegen zusammen mit dem Image in der Registry und werden in keinem öffentlichen Transparenzprotokoll erfasst. Um ein Image zu prüfen, das Sie pullen können, speichern Sie den öffentlichen Schlüssel unten als image-provenance.pub, vergleichen Sie seinen Fingerabdruck mit dem in der Tabelle (erster Befehl) und prüfen Sie das Image über seinen Digest mit cosign ab Version 3 (zweiter Befehl):

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEjyfZEmjD3ErGVqBO5fsNl+aPy+oO
vDGv410tK7HUUZgD+EMbmXYq/qhXuJ0QhjYi/zDEozRRhLT3AnsgIOabrQ==
-----END PUBLIC KEY-----

openssl pkey -pubin -in image-provenance.pub -outform DER | openssl dgst -sha256
cosign verify-attestation --key image-provenance.pub --type slsaprovenance1 --insecure-ignore-tlog <image>@sha256:<digest>

--insecure-ignore-tlog sagt cosign nur, dass es keinen Eintrag in einem Transparenzprotokoll suchen soll; die Signatur wird trotzdem gegen den Schlüssel geprüft. Jede Attestierung nennt ihre Plattform in predicate.buildDefinition.internalParameters.targetPlatform. Ein früher veröffentlichtes Image trägt keine signierte Provenienz, daher kann eine IronFlock-Version Images mit und ohne sie enthalten, bis jeder ihrer Dienste erneut veröffentlicht wurde.

Die Provenienz erfüllt SLSA Build Level 3. Jedes Image wird auf einer frischen Maschine eines gehosteten Build-Dienstes gebaut, getrennt von jedem anderen Build und ohne einen Build-Cache, den es mit anderen Builds teilt. Die Provenienz wird in einem eigenen Schritt auf einer anderen Maschine signiert, der nichts von dem Code ausführt, der gebaut wird, und das Quell-Repository, den Commit und den Build prüft, die die Provenienz nennt; nur dieser Schritt kann den Schlüssel verwenden. Ein Image kann auch Daten enthalten, die ein früherer Schritt desselben Releases vorbereitet hat, zum Beispiel einen Suchindex; die Provenienz nennt eine solche Eingabe, nicht ihren Inhalt. Einige Images, die am 5. November 2026 veröffentlicht wurden, tragen bereits eine signierte Provenienz; sie erfüllt Level 2, weil der Schlüssel noch nicht auf den Signierschritt beschränkt war.

Wie die Schlüssel aufbewahrt werden

• Die Schlüssel auf dieser Seite lassen sich nicht exportieren, mit Ausnahme des Code-Signing-Stammzertifikats. Ihre privaten Schlüssel liegen in der Schlüsselverwaltung von IronFlock, und dort wird auch signiert. Das Code-Signing-Stammzertifikat signiert keine Software, sondern nur das Zertifikat des Windows-Signierschlüssels, und sein Schlüssel wird nur verwendet, wenn dieses Zertifikat ersetzt wird.
• Releases werden von ihrer Release-Pipeline signiert. Der Schlüssel, mit dem die Releases eines Produkts signiert werden, kann nur vom automatisierten Release dieses Produkts verwendet werden, nachdem dessen Prüfungen und Tests bestanden sind.
• Der Geräte-Agent vertraut zwei unabhängigen Schlüsseln. Neue Releases werden mit dem ersten signiert. Der zweite hat die früheren Releases signiert und signiert von Hand weiterhin die Updates für ältere Agents und ältere ironflock-init-Versionen, die nur diesem Schlüssel vertrauen. Außerdem wird er für den Fall vorgehalten, dass sich der erste nicht mehr verwenden lässt; dann werden Updates mit ihm signiert, sodass sich Geräte weiter aktualisieren, ohne dass eine Einstellung nötig ist, die die Prüfung überspringen würde.

Einen Schlüssel rotieren

Ein Schlüssel wird ersetzt, wenn er das Ende seiner geplanten Lebensdauer erreicht, oder sofort, wenn der Verdacht besteht, dass er kompromittiert ist. Dieser Abschnitt betrifft die Signaturschlüssel oben; die eigenen internen Secrets der Appliance werden mit ironflock-update --rotate ersetzt, siehe Secrets auf dem Host. Eine Rotation läuft immer in drei Schritten ab, damit jedes Gerät und jede Appliance jedes Update auf dem Weg prüfen kann:

1. Der neue Schlüssel wird hinzugefügt. Ein Release fügt den neuen Schlüssel zu den Schlüsseln hinzu, denen ein Gerät oder eine Appliance vertraut. Dieses Release ist noch mit dem aktuellen Schlüssel signiert, sodass alles, was darauf aktualisiert wird, es akzeptiert.
2. Die Signierung wechselt zum neuen Schlüssel. Sobald im Feld ein Release läuft, das beiden Schlüsseln vertraut, signiert IronFlock mit dem neuen Schlüssel. Dem alten Schlüssel wird in dieser Zeit weiterhin vertraut.
3. Der alte Schlüssel wird zurückgezogen. Ein späteres Release entfernt den alten Schlüssel. Ab dann wird eine Signatur mit dem alten Schlüssel abgelehnt, und der Schlüssel wird unter Zurückgezogene Schlüssel aufgeführt.

Was das für die einzelnen Schlüssel bedeutet:

• Appliance-Release-Schlüssel. Eine Appliance vertraut den Schlüsseln, mit denen ihr ironflock-update geschrieben wurde, daher muss die Appliance das Release aus Schritt 1 installieren, bevor sie Updates prüfen kann, die in Schritt 2 signiert wurden. Eine Appliance, die während der gesamten Übergangszeit nicht aktualisiert wurde, bricht ihr Update ab, bevor sich etwas ändert; führen Sie den Installer einmal von Hand aus, geprüft gegen den neuen Schlüssel, wie unter Installer vor der ersten Installation prüfen beschrieben.
• Update-Schlüssel des Geräte-Agenten. Ein Gerät vertraut den Schlüsseln, die in den Agenten eingebaut sind, den es ausführt. Ein Gerät, das während der gesamten Übergangszeit offline war, kann Updates, die mit dem neuen Schlüssel signiert sind, nicht prüfen; installieren Sie seinen Agenten mit dem Geräte-Installer neu, der dem neuen Schlüssel vertraut.
• Bootstrap-Schlüssel. install.sh wird für jede Installation neu heruntergeladen und bringt den Schlüssel mit, gegen den es prüft, daher wirkt ein neuer Schlüssel ab dem nächsten Release des Installers, ohne Übergangszeit. Nur die Prüfung von Hand ändert sich: Vergleichen Sie mit dem Fingerabdruck auf dieser Seite.
• Windows-Code-Signing. Ein Windows-Gerät vertraut dem Code-Signing-Stammzertifikat, nicht dem Signierschlüssel. Ein neues Zertifikat für den Signierschlüssel, ausgestellt vom selben Stammzertifikat, wirkt ab dem nächsten Release, ohne Übergangszeit, und auf dem Gerät ist nichts zu tun. Da der Agent das Zertifikat des Signierschlüssels zum Zeitpunkt der Prüfung prüft, wird eine Datei abgelehnt, deren Zertifikat abgelaufen ist; ein Zertifikat für den Signierschlüssel wird daher lange vor seinem Ende ersetzt. Das Stammzertifikat selbst wird in den drei Schritten oben ersetzt, lange bevor es im Juli 2036 endet; ein Windows-Gerät, das während der gesamten Übergangszeit offline war, braucht eine Neuinstallation seines Agenten. Die vertrauenswürdigen Stammzertifikate des Computers behalten das Stammzertifikat, das der Installer hinzugefügt hat, daher zeigt die PowerShell-Prüfung oben nach einer Rotation des Stammzertifikats unter Umständen nur das frühere Stammzertifikat; der Agent prüft gegen die in ihn eingebauten Stammzertifikate.
• Schlüssel für die Image-Provenienz. Kein Gerät und keine Appliance prüft diesen Schlüssel, daher wirkt ein neuer Schlüssel ab dem nächsten Image-Release, ohne Übergangszeit. Ein Image behält die Attestierungen, mit denen es veröffentlicht wurde: Prüfen Sie es gegen den Schlüssel, der bei seiner Veröffentlichung in Gebrauch war, aufgeführt auf dieser Seite oder unter Zurückgezogene Schlüssel.

Während einer Übergangszeit führt diese Seite beide Schlüssel mit ihren Fingerabdrücken auf, und die Versionshinweise kündigen jeden Schritt an. Auf einer Appliance oder einem Gerät, die aktuell gehalten werden, ist nichts zu tun.

Wird ein Schlüssel kompromittiert, stellt IronFlock die Signierung damit sofort ein, rotiert ihn wie oben beschrieben in kurzer Frist und veröffentlicht einen Sicherheitshinweis.

Zurückgezogene Schlüssel

Bisher keine.