Nachweise, die ein Auditor verifizieren kann

Jeder Telemetrie-Batch, den bitcollector erzeugt, wird auf dem Host signiert, der ihn erzeugt hat, und an den vorherigen Batch gekettet, und der Host behält eine byte-identische Kopie. Genau das erlaubt es jemand anderem — Ihrem Auditor, nicht uns —, die Nachweise offline zu prüfen und, wenn ein Batch nicht stimmt, genau gesagt zu bekommen, welcher.

Diese Seite behandelt die Kette, wie Sie einen Spool selbst verifizieren, den einen Angreifer, den sie nicht aufhält, und wie lange Nachweise auf dem Host bleiben. Was der Agent erfasst und wie Sie ihn betreiben, steht im bitcollector-Überblick.

Die Nachweiskette

Das ist der Teil, der die Daten belastbar macht und nicht bloß nützlich.

Jeder Batch trägt eine ECDSA-Attestierung über den gesamten Envelope, per Hash an den vorherigen Batch gekettet. Ein lokaler Spool auf dem Host hält Bytes, die byte-identisch mit dem sind, was an Cert-IX gePOSTet wurde. Die Kopie, die Sie behalten, und die Kopie, die wir empfangen haben, sind also dieselben Bytes, und beide sind mit einem Schlüssel signiert, der auf Ihrem Host erzeugt wurde und ihn nie verlässt.

Ihr Auditor verifiziert sie ohne uns

# 1. Export the trust anchor — the agent's enrolment PUBLIC key.
#    --out must be OUTSIDE the data directory.
bitcollector export-pubkey --data-dir /var/lib/bitcollector --out /tmp/enrolment.pub.pem

# 2. Verify the spool. Pass the DIRECTORY, not a file list.
bitcollector verify --input /var/lib/bitcollector/attested --pubkey /tmp/enrolment.pub.pem

[VALID] batch 0 (batch-1785095415100718111, agent=e5efd43f-…, seq=0)
[VALID] batch 1 (batch-1785095418211672665, agent=e5efd43f-…, seq=1)
[VALID] batch 2 (batch-1785095466180395769, agent=e5efd43f-…, seq=2)
[VALID] batch 3 (batch-1785095515907595299, agent=e5efd43f-…, seq=3)
[CHAIN]  intact
[RANGE]  observed attested seq range [0,3]

SUMMARY: 4/4 batches valid — all checks passed

verify benötigt weder Netzwerkzugang noch Cert-IX-Zugang. Nicht „funktioniert nebenbei auch offline“ — das ist der Punkt. Nachweise, die sich nur prüfen lassen, indem man den Hersteller fragt, der sie erzeugt hat, sind keine Nachweise. export-pubkey existiert, damit der Vertrauensanker selbst von Ihrem Host stammt und nicht von uns.

export-pubkey gibt außerdem den SHA-256-Fingerabdruck des Schlüssels aus. Das ist derselbe Wert, den jeder Batch als key_fingerprint trägt, sodass die Schlüsseldatei an die Nachweise gebunden ist, die Sie in Händen halten. Verifizieren Sie mit dem falschen Schlüssel, wird jeder Batch als [INVALID] gemeldet, mit einer expliziten Zeile key_fingerprint mismatch — ein nicht passender Vertrauensanker kann niemals mit manipulierten Nachweisen verwechselt werden.

Ein veränderter Batch wird erkannt und benannt

Ändern Sie ein einziges Byte eines gespoolten Batches und führen Sie verify erneut aus:

[INVALID] batch 4 (batch-1785095515907595299, agent=e5efd43f-…, seq=4)
         - attestation verification failed: attest: payload_hash mismatch: attestation
           claims 9f2c…, canonical bytes hash to 4ab1…

Veränderung, Löschung, Umsortierung und Duplizierung werden alle erkannt, und die genaue seq wird benannt. Jede Zeile jeder Eingabedatei wird in einer Zählung ausgewiesen, die Sie gegen wc -lc prüfen können, sodass „gemeldete Batches + übersprungene Zeilen“ niemals stillschweigend eine andere Datei beschreiben kann als die auf der Platte.

Exit-Codes

verify beendet sich mit einem stabilen Code, auf den eine Audit-Pipeline verzweigen kann:

Code	Bedeutung
0	Alles in Ordnung — authentisch, unverändert, ununterbrochene Sequenz.
1	Mindestens ein Batch hat die Verifizierung nicht bestanden, oder eine Eingabe wurde abgelehnt. Als Feststellung behandeln, nicht als Werkzeugfehler.
2	Jeder Batch ist für sich authentisch, aber die Sequenz stimmt nicht — einer fehlt, ist doppelt oder außer der Reihe.
3	Es wurde nichts verifiziert — falsche Verwendung, kein --pubkey, unlesbarer Pfad, leere Eingabe. Korrigieren Sie den Aufruf; das ist kein Urteil über Ihre Nachweise.

Ein Fallstrick, den Sie kennen sollten

Verwenden Sie für einen rotierten Spool kein Shell-Glob. cat batches-*.ndjson | bitcollector verify sortiert lexikografisch, sodass batches-10 vor batches-7 kommt und echte, unmanipulierte Nachweise als gebrochene Kette gemeldet werden (Exit 2). Übergeben Sie stattdessen das Verzeichnis — verify liest die Dateien dann in numerischer Reihenfolge.

Die ehrliche Grenze

Wer agent.key lesen kann, kann eine Kette fälschen

Der Attestierungsschlüssel liegt auf dem Host, im Datenverzeichnis des Agenten. Er belegt, dass der Batch von dieser Agenten-Identität erzeugt und seither nicht verändert wurde. Er schützt nicht gegen einen Angreifer, der auf dem Host bereits Root erlangt hat und den privaten Schlüssel lesen kann — ein solcher Angreifer kann eine Kette seiner Wahl signieren.

Wir sagen das, statt es zu verschweigen. Das zu schließen erfordert eine Hinterlegung des Fingerabdrucks außerhalb des Hosts zum Zeitpunkt der Registrierung, die in diesem Release nicht enthalten ist. Schützen Sie agent.key entsprechend: Er hat 0600 in einem 0700-Verzeichnis, und diese Grenze ist es wert, überwacht zu werden.

Lokale Aufbewahrung der Nachweise

Der attestierte Spool ist Ihre Kopie der Nachweise. Er liegt unter dem Datenverzeichnis des Agenten (0700-Verzeichnis, 0600-Dateien):

spool:
  enabled: true
  path: attested
  max_file_size_mb: 50     # rotation threshold, NOT a hard cap
  max_files: 10
  max_age_days: 30

Die ehrliche Plattengrenze

max_files × max(max_file_size_mb, largest single batch) — nicht max_files × max_file_size_mb. Ein einzelner Batch, der größer ist als die Schwelle, wird vollständig geschrieben (Vollständigkeit der Nachweise schlägt die Größenobergrenze), und die Datei rotiert unmittelbar danach. Dimensionieren Sie die Platte für den größten Batch, den ein ausgelasteter Host erzeugen kann; der Agent warnt jedes Mal, wenn er einen übergroßen schreibt.

max_age_days ist die Grenze der Speicherbegrenzung, die die Größenobergrenzen nicht ausdrücken können (DSGVO Art. 5 Abs. 1 lit. e): Mit nur max_files bewahrt ein ruhiger Host Nachweise für immer auf, während ein ausgelasteter Host ein paar Stunden davon behält.

Nächste Schritte

• bitcollector — Überblick — was er erfasst und was sein Betrieb kostet.
• Datenschutz und lokale Konten — die Voreinstellungen, die überhaupt erst entscheiden, was in den Nachweisen landet.
• Ihre Downloads verifizieren — die andere Verifizierung: der Beweis für das Binary, das die Nachweise erzeugt hat. Ein anderer Schlüssel und eine separate Prüfung.