Ihre Downloads verifizieren

bits-Binaries laufen auf Ihren Hosts mit privilegierter Sicht, und bitcollector erzeugt die Nachweise, auf die Sie und Ihr Auditor sich stützen. Nachweise sind immer nur so vertrauenswürdig wie das Instrument, das sie erzeugt hat.

Bevor Sie also irgendetwas installieren, sollten Sie genau belegen können, welche Bytes Sie gleich ausführen. Diese Seite zeigt Ihnen, wie — ausschließlich mit veröffentlichten Werkzeugen, offline.

Wenn eine Prüfung fehlschlägt

Installieren Sie das Binary nicht. Laden Sie es nicht „einfach noch einmal herunter und hoffen“. Bewahren Sie die Dateien auf und schreiben Sie an [email protected], mit der Release-Version und der Ausgabe des fehlgeschlagenen Befehls.

Was jedem Release beiliegt

Datei	Was sie ist
bitcollector-<os>-<arch>	Das Binary selbst
bitcollector-<os>-<arch>.sbom.json	CycloneDX-SBOM — alles, was in diesem Binary steckt
bitcollector-<os>-<arch>.sig	Cosign-Signaturbündel über genau diese Bytes
bitcollector-<os>-<arch>.att	Cosign-Attestierung, die die SBOM an genau diese Bytes bindet
SHA256SUMS	Prüfsummen jeder Datei oben
SHA256SUMS.sig	Cosign-Signatur über SHA256SUMS
release-provenance.json	Commit, Go-Toolchain und Plattformen, aus denen das Release gebaut wurde

bitscanner-, bitenforcer- und bitmapper-Releases haben denselben Aufbau, mit ihrem eigenen Namen anstelle von bitcollector. Alle vier Produkte werden mit demselben Release-Schlüssel signiert, eine Schlüsselprüfung deckt also die ganze Familie ab — und ein Schlüssel, der sich zwischen zweien von ihnen unterscheidet, ist ein Grund anzuhalten, nicht Ihre Kopie zu aktualisieren.

Schritt 0 — die Werkzeuge besorgen

Sie brauchen cosign v3 oder neuer und sha256sum (Teil von coreutils; unter macOS shasum -a 256 oder brew install coreutils).

cosign version

Schritt 1 — den öffentlichen Schlüssel holen und prüfen, dass es der richtige ist

Laden Sie den Release-Signaturschlüssel neben das Release-Verzeichnis herunter, nicht hinein:

# aus dem Verzeichnis, das Ihr Release-Verzeichnis ENTHÄLT
# DNS route — works from a CLI and inside CI. The HTTPS copy of this key is
# currently behind a bot challenge, so `curl` cannot fetch it; see the note below.
dig +short TXT _cosign-key.cert-ix.com | tr -d '"' | sed 's/.*key=//' \
  | base64 -d | openssl pkey -pubin -inform DER -out cosign.pub

Legen Sie den Schlüssel neben die Release, nicht hinein

verify-release.sh behandelt jede Datei innerhalb eines Release-Verzeichnisses als etwas, das signiert sein sollte. Legen Sie cosign.pub dort ab, meldet es eine nicht zuordenbare Datei — das liest sich genau wie eine manipulierte Release, ist aber keine. Halten Sie den Schlüssel eine Ebene darüber. Aus demselben Grund geben Sie ihn mit absolutem Pfad an: Das Skript wechselt in das Release-Verzeichnis, ein relatives --key cosign.pub wird dadurch nicht mehr aufgelöst, und der ausgegebene Fehler ist von einer ungültigen Signatur nicht zu unterscheiden.

→ cosign.pub

Überspringen Sie das nicht. Das ist die Prüfung, die alles Übrige erst bedeutsam macht.

Ein Angreifer, der ein Binary auf unserer Website ersetzen kann, kann auch den öffentlichen Schlüssel ersetzen, der daneben liegt. Die Verifizierung würde dann bestehen — gegen seinen Schlüssel. Sie würden sein Binary ausführen und einen grünen Haken bekommen.

Eine Signaturprüfung ist nur so viel wert wie der Vertrauensanker dahinter. Bestätigen Sie den Fingerabdruck des Schlüssels aus einer zweiten, unabhängigen Quelle, bevor Sie ihm vertrauen. Genau darum geht es in den nächsten Zeilen, und es ist der Schritt, den die meisten Verifizierungsanleitungen weglassen.

Der Fingerabdruck

Berechnen Sie den Fingerabdruck des Schlüssels, den Sie heruntergeladen haben:

# The robust form: SHA-256 of the DER-encoded public key.
# Independent of PEM whitespace, so copy-paste through a browser cannot change it.
openssl pkey -pubin -in cosign.pub -outform DER | sha256sum

Er muss exakt lauten:

552839f6b1b1eb0934557e1886326c7270584fa602fbf56f84754a98be3de822

Wenn Sie die Datei lieber so hashen möchten, wie sie ist:

sha256sum cosign.pub
# 150eacccc1bc26a83c746a1e441b0b0bdc8104c3ef07efd75c62deb5b069f914

Dieser zweite Wert deckt die exakten Bytes der veröffentlichten Datei ab, Zeilenumbruch eingeschlossen; er passt also nur, wenn Sie die Datei heruntergeladen und nicht ihren Inhalt hineinkopiert haben.

Der Schlüssel selbst ist kurz genug zum Lesen. Das ist er vollständig:

-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEPA6gi66NIBXbSwYS3CL16Ien3sho
wCNOR8dRivdd07SQWto107QMDelUKMeebJQHSlOchNO4PJSWjCcrsUYb5w==
-----END PUBLIC KEY-----

Es ist ein öffentlicher ECDSA-P-256-Schlüssel (prime256v1). Das können Sie selbst bestätigen:

openssl pkey -pubin -in cosign.pub -text -noout | head -2
# Public-Key: (256 bit)

Zweitquellen für den Fingerabdruck

Nehmen Sie den Fingerabdruck nach Möglichkeit nicht von derselben Seite, die Ihnen den Schlüssel ausgeliefert hat. Gleichen Sie ihn mit mindestens einer dieser Quellen ab:

• Ein DNS-Eintrag, ausgeliefert von einer anderen Infrastruktur als dieser Website. Derselbe Fingerabdruck ist als TXT-Eintrag unter _cosign.cert-ix.com veröffentlicht, und ein einziger Befehl prüft ihn: dig +short TXT _cosign.cert-ix.com. Das ist der Abgleich, der sich lohnt: Ein Angreifer, der diesen Webserver übernommen hat, müsste zusätzlich unser DNS übernehmen, damit beide übereinstimmen — verschiedene Systeme, verschiedene Zugangsdaten. Wenn sie nicht übereinstimmen, halten Sie an: Führen Sie die Binaries nicht aus und schreiben Sie an [email protected].
• Ihr Cert-IX-Kontakt, out of band. Bitten Sie Ihren Kunden- oder Sicherheitskontakt, Ihnen den Fingerabdruck über einen Kanal vorzulesen, der nicht diese Website ist — ein Telefonat, eine signierte E-Mail von [email protected] oder Ihren bestehenden Support-Kanal.
• Ein Schlüssel, den Sie bereits haben. Wenn Sie ein früheres bits-Release verifiziert haben, vergleichen Sie mit dem Schlüssel, den Sie aufbewahrt haben. Ein Release-Schlüssel, der sich ohne Ankündigung ändert, ist ein Grund innezuhalten und nachzufragen, kein Grund, Ihre Kopie zu aktualisieren.

Sobald Sie den Fingerabdruck bestätigt haben, bewahren Sie Ihre Kopie des Schlüssels auf und verwenden Sie sie weiter. Der Wert eines Vertrauensankers entsteht daraus, dass er sich nicht ändert.

Schritt 2 — zuerst das Prüfsummen-Manifest verifizieren

Die Reihenfolge zählt. Verifizieren Sie die Signatur über SHA256SUMS, bevor Sie irgendeiner Prüfsumme darin trauen — eine unsignierte Prüfsummendatei beweist nichts, denn wer ein Binary ersetzen kann, kann eine einfache Prüfsummenliste genauso leicht ersetzen.

cosign verify-blob --key cosign.pub --bundle SHA256SUMS.sig \
  --insecure-ignore-tlog=true SHA256SUMS

Erwartete Ausgabe:

WARNING: Skipping tlog verification is an insecure practice that lacks transparency and
auditability verification for the blob.
Verified OK

Diese Warnung ist zu erwarten — hier steht genau, was sie bedeutet

Cert-IX ist eine souveräne EU-Plattform und betreibt kein öffentliches Sigstore-Transparenzprotokoll. Signaturen sind schlüsselbasiert. Ohne --insecure-ignore-tlog=true sucht cosign v3 nach einem Transparenzprotokoll-Eintrag, den es absichtlich nicht gibt, und meldet „no signatures found“.

Das Flag schwächt die Signaturprüfung selbst nicht. Was es bedeutet: Sie erhalten keinen unabhängigen, nur anfügbaren Nachweis darüber, dass diese Signatur jemals existiert hat — deshalb leistet der Fingerabdruck-Abgleich aus Schritt 1 die Arbeit, die Ihnen ein Transparenzprotokoll sonst abnehmen würde. Das ist der Handel, klar benannt.

Schritt 3 — verifizieren, dass jede Datei zu ihrer Prüfsumme passt

sha256sum -c SHA256SUMS

Schritt 4 — das Binary verifizieren, das Sie installieren wollen

cosign verify-blob --key cosign.pub --bundle bitcollector-linux-amd64.sig \
  --insecure-ignore-tlog=true bitcollector-linux-amd64

Schritt 5 — verifizieren, dass die SBOM wirklich diese Bytes beschreibt

cosign verify-blob-attestation --key cosign.pub --bundle bitcollector-linux-amd64.att \
  --type cyclonedx --insecure-ignore-tlog=true bitcollector-linux-amd64

Die SBOM ist die Art, wie Sie erfahren, was in dem Collector steckt, der Ihre Nachweise erzeugen wird. Ein Binary, dessen Attestierung nicht zu seinen Bytes passt, ist ein Binary, dessen Inhalt Sie nicht aufzählen können.

Das Ganze in einem Befehl

Cert-IX liefert dasselbe Verifizierungsskript aus, das es vor der Veröffentlichung gegen die eigenen Releases laufen lässt, unter ci/verify-release.sh im Repository:

./verify-release.sh "$PWD/bitcollector-release" "$PWD/cosign.pub"

[verify-release] verifying the signature over SHA256SUMS
[verify-release]   SHA256SUMS signature OK
[verify-release] verifying checksums of every artefact
[verify-release]   all checksums OK
[verify-release]   bitcollector-darwin-amd64 signature OK
[verify-release]   bitcollector-darwin-amd64 SBOM attestation OK
[verify-release]   bitcollector-darwin-arm64 signature OK
[verify-release]   bitcollector-darwin-arm64 SBOM attestation OK
[verify-release]   bitcollector-linux-amd64 signature OK
[verify-release]   bitcollector-linux-amd64 SBOM attestation OK
[verify-release]   bitcollector-linux-arm64 signature OK
[verify-release]   bitcollector-linux-arm64 SBOM attestation OK
[verify-release]   bitcollector-windows-amd64.exe signature OK
[verify-release]   bitcollector-windows-amd64.exe SBOM attestation OK
[verify-release] VERIFIED: 5 binary/binaries, checksums, and signatures all valid
[verify-release] built from commit 8819759 with go1.25.12
OK: 5 verified

Exit-Code 0 und eine Zeile OK: <n> verified bedeuten, dass jedes Binary authentisch und unversehrt ist. Alles andere bedeutet: nicht installieren.

Absolute Pfade übergeben

Das Skript wechselt in das Release-Verzeichnis, bevor es mit der Arbeit beginnt; ein relativer Pfad zum öffentlichen Schlüssel lässt sich dann nicht mehr auflösen, und jede Signaturprüfung schlägt fehl mit:

[verify-release] REFUSED: the signature over SHA256SUMS is NOT valid for this key.

Diese Ablehnung liest sich exakt wie ein manipuliertes Release. Wenn Sie sie sehen, führen Sie den Befehl mit absoluten Pfaden ("$PWD/cosign.pub") erneut aus, bevor Sie irgendetwas schlussfolgern — und wenn es mit einem absoluten Pfad weiterhin fehlschlägt, behandeln Sie es als echt und wenden Sie sich an [email protected].

Zwei Details sind bemerkenswert, denn sie sind der Unterschied zwischen einer Prüfung und einem Ritual:

• Es meldet eine Anzahl. Eine Verifizierung, die nichts zu prüfen findet, darf keinen Erfolg melden; deshalb verweigert das Skript den Dienst, wenn das Verzeichnis keine Binaries enthält, und gibt aus, wie viele es tatsächlich verifiziert hat.
• Es verweigert bei einer fehlenden Signatur. Ein unsigniertes Binary in einem signierten Release ist genau das, wonach ein Lieferkettenangriff aussieht; deshalb schlägt das Skript fehl, statt es zu überspringen.

Was die Signatur heute beweist

Seien Sie hier präzise, denn „signiert“ wird oft als mehr verstanden, als es ist.

Was sie beweist: Genau diese Bytes wurden von der Cert-IX-Release-Pipeline erzeugt und von der Inhaberin oder dem Inhaber des Schlüssels signiert, dessen Fingerabdruck Sie in Schritt 1 geprüft haben, und sie haben sich seither nicht verändert. Zusammen mit SHA256SUMS und der SBOM-Attestierung können Sie aufzählen, was im Binary steckt, und sicher sein, dass diese Aufzählung zu den Bytes passt.

Was sie nicht beweist, ehrlich benannt:

• Der Signaturschlüssel liegt derzeit auf dem Build-Host, als Datei geschützt mit einer Passphrase, die außerhalb der Versionsverwaltung gehalten wird. Er liegt nicht in einem Hardware-Sicherheitsmodul. Die Signatur beweist also „das ist das Binary, das dieser Build erzeugt hat“ — sie beweist nicht, dass der Build-Host selbst zum Zeitpunkt der Signatur unkompromittiert war.
• Es gibt kein Transparenzprotokoll. Sie können keinen unabhängigen, nur anfügbaren Nachweis heranziehen, um zu sehen, ob unter diesem Schlüssel jemals eine Signatur für irgendein anderes Binary ausgestellt wurde.

Beides ist der Grund, warum der reproduzierbare Build weiter unten zählt, und warum der Fingerabdruck-Abgleich in Schritt 1 nicht optional ist.

Das Binary selbst neu bauen

Sie müssen uns nicht glauben, was im Binary steckt — Sie können es neu bauen und vergleichen. bits-Releases sind reproduzierbar: Derselbe Commit, mit derselben Go-Toolchain gebaut, erzeugt byte-identische Ausgabe.

Beginnen Sie bei release-provenance.json, das genau festhält, woraus das Release gebaut wurde:

{
  "service": "bitcollector",
  "version": "0.1.0-ga",
  "commit": "8819759",
  "go_toolchain": "go1.25.12",
  "source_date_epoch": 1786277293,
  "build_time": "2026-08-09T12:08:13Z",
  "platforms": ["linux/amd64", "linux/arm64", "darwin/amd64", "darwin/arm64", "windows/amd64"],
  "reproducible": true,
  "signed": true
}

Mit der Quelle und der dort genannten Toolchain:

git checkout <commit from release-provenance.json>

SOURCE_DATE_EPOCH=<source_date_epoch from release-provenance.json>
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -trimpath \
  -ldflags="-s -w -buildid= \
    -X main.version=<version> \
    -X main.buildTime=$(date -u -d @$SOURCE_DATE_EPOCH +%Y-%m-%dT%H:%M:%SZ) \
    -X main.gitCommit=<commit>" \
  -o bitcollector-linux-amd64 ./cmd/bitcollector

sha256sum bitcollector-linux-amd64   # must equal the value in SHA256SUMS

Ein passender Hash bedeutet, dass das veröffentlichte Binary nichts enthält, was nicht in der Quelle steht, die Sie gerade gelesen haben.

Aktuelle Releases

Alle vier bits sind veröffentlicht, und alle vier sind mit demselben Schlüssel signiert — dem, dessen Fingerabdruck Sie in Schritt 1 geprüft haben. Eine Schlüsselprüfung deckt die Familie ab.

Produkt	Version	Commit	Toolchain	Plattformen
bitcollector	0.1.0-ga	8819759	go1.25.12	linux amd64/arm64, macOS amd64/arm64, Windows amd64
bitscanner	0.1.3-ga	7db3d4c	go1.25.12	linux amd64/arm64
bitenforcer	0.1.0-ga	4c6ce93	go1.25.12	linux amd64/arm64
bitmapper	0.1.0-ga	64ebc64	go1.25.12	linux amd64

Die Plattformspalten sind nicht alle gleich, und die Unterschiede sind beabsichtigt. Wo eine Plattform fehlt, liegt es daran, dass der Agent dort seine Aufgabe nicht erfüllen würde, nicht daran, dass der Build vergessen wurde. Jede Produktseite nennt den Grund:

Produkt	Was zurückgehalten wird, und warum
bitcollector	Nichts. Er wird auf allen fünf ausgeliefert — Plattformen
bitscanner	Kein macOS/Windows: Seine Nachbar- und Routen-Leser sind Linux-Implementierungen, und eine leere Nachbartabelle läse sich wie ein ruhiges Segment — Plattformen
bitenforcer	Kein macOS/Windows: Seine gesamte Fläche ist iptables/sysctl/systemd/SELinux, ein Build dort meldete also jedes Modul als NOT EXAMINED — Plattformen
bitmapper	Nur linux amd64: Der Mitschnitt braucht ein einkompiliertes libpcap, lässt sich also nicht cross-kompilieren. Windows baut, wurde dort aber nie ausgeführt und wird daher als Testlücke zurückgehalten — Plattformen

Prüfen Sie die Version, die Sie tatsächlich heruntergeladen haben

Die Commits oben sind die, aus denen die aktuellen Releases gebaut wurden. release-provenance.json in Ihrem Release-Verzeichnis ist der maßgebliche Nachweis für dieses Verzeichnis — gleichen Sie es mit der Tabelle ab, statt zu vermuten, und das Binary selbst gibt dieselben Werte aus den Bytes aus, die Sie gleich ausführen. Wenn die drei nicht übereinstimmen, halten Sie an und schreiben Sie an [email protected].

Der Befehl ist nicht bei allen vier Binaries derselbe. Nehmen Sie den für Ihr Binary:

Binary	Befehl, der die Version ausgibt
bitcollector	bitcollector --version
bitscanner	bitscanner version
bitenforcer	bitenforcer version
bitmapper	bitmapper version

Bitte genau diese Schreibweisen verwenden — der falsche Befehl gibt nicht einfach einen Fehler aus:

• Bei bitcollector bis einschließlich 0.1.0-ga ist bitcollector version kein Versionsbefehl. Das Argument wird ignoriert und das Binary STARTET DEN AGENTEN: es legt seinen Identitätsschlüssel im Datenverzeichnis an und beginnt zu sammeln. Falls Sie das ausgeführt haben, beenden Sie den Prozess und löschen Sie das Datenverzeichnis (/var/lib/bitcollector, sofern nicht geändert), bevor Sie den Host wirklich enrollen. bitcollector --version gibt aus und beendet sich — und tat das immer schon.
• Bei bitscanner, bitenforcer und bitmapper gibt es --version nicht; der Befehl scheitert mit unknown flag: --version. Das ist harmlos, nur nutzlos.

Die Binaries und ihr Signaturschlüssel liegen auf der Download-Seite. Die Schritte oben funktionieren offline gegen jedes Release-Verzeichnis, das Sie haben — Sie können also auf einer Maschine verifizieren, die unsere Website nie berührt.

Nächste Schritte

• bitcollector — was er erfasst und wie seine Nachweiskette verifiziert wird (ein anderer Schlüssel und eine separate Prüfung).
• bitenforcer — was v1 tut und was nicht.
• bits-Überblick — fangen Sie hier an, wenn Sie zuerst auf dieser Seite gelandet sind.