Des preuves que votre auditeur peut vérifier

Chaque lot de télémétrie que produit bitcollector est signé sur l'hôte qui l'a produit et chaîné au lot précédent, et l'hôte en conserve une copie identique au bit près. C'est ce qui permet à quelqu'un d'autre — votre auditeur, pas nous — de contrôler les preuves hors ligne, et de se voir désigner exactement le lot fautif lorsqu'il y en a un.

Cette page couvre la chaîne, la façon de vérifier vous-même un spool, le seul attaquant qu'elle n'arrête pas, et la durée pendant laquelle les preuves restent sur l'hôte. Pour ce que l'agent collecte et comment l'exécuter, commencez par la présentation de bitcollector.

La chaîne de preuves

C'est la partie qui rend la donnée défendable, et pas seulement utile.

Chaque lot porte une attestation ECDSA sur l'enveloppe entière, chaînée par hachage au lot précédent. Un spool local sur l'hôte conserve des octets identiques au bit près à ce qui a été envoyé (POST) à Cert-IX. La copie que vous gardez et la copie que nous avons reçue sont donc les mêmes octets, et toutes deux sont signées par une clé qui a été générée sur votre hôte et qui ne le quitte jamais.

Votre auditeur le vérifie sans nous

# 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 n'exige aucun accès réseau et aucun accès à Cert-IX. Ce n'est pas un « fonctionne hors ligne, par commodité » — c'est le principe même. Une preuve qui ne peut être vérifiée qu'en demandant au fournisseur qui l'a produite n'est pas une preuve. export-pubkey existe pour que l'ancre de confiance elle-même provienne de votre hôte plutôt que de nous.

export-pubkey affiche aussi l'empreinte SHA-256 de la clé. C'est la même valeur que chaque lot porte dans key_fingerprint, si bien que le fichier de clé est lié aux preuves que vous détenez. Vérifiez avec la mauvaise clé et chaque lot est rapporté [INVALID] avec une ligne explicite key_fingerprint mismatch — une ancre de confiance qui ne correspond pas ne pourra jamais être confondue avec une preuve altérée.

Un lot modifié est détecté et nommé

Changez un seul octet d'un lot du spool et relancez verify :

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

La modification, la suppression, la réorganisation et la duplication sont toutes détectées, et le seq exact est nommé. Chaque ligne de chaque fichier d'entrée est comptabilisée dans un recensement que vous pouvez confronter à wc -lc, de sorte que « lots rapportés + lignes ignorées » ne puisse jamais décrire discrètement un autre fichier que celui présent sur le disque.

Codes de sortie

verify se termine avec un code stable sur lequel une chaîne d'audit peut se brancher :

Code	Signification
0	Tout est vérifié — authentique, non modifié, séquence ininterrompue.
1	Au moins un lot a échoué à la vérification, ou une entrée a été refusée. À traiter comme un constat, pas comme une erreur d'outillage.
2	Chaque lot est individuellement authentique, mais la séquence est erronée — il en manque un, ou un lot est dupliqué ou dans le désordre.
3	Rien n'a été vérifié — mauvaise utilisation, pas de --pubkey, chemin illisible, entrée vide. Corrigez l'invocation ; ce n'est pas un verdict sur vos preuves.

Un piège à connaître

N'utilisez pas un glob shell pour un spool qui a été alterné (rotation). cat batches-*.ndjson | bitcollector verify trie dans l'ordre lexicographique, si bien que batches-10 passe avant batches-7, et des preuves authentiques et intactes sont rapportées comme une chaîne rompue (code 2). Passez plutôt le répertoire — verify lit alors les fichiers dans l'ordre numérique.

La limite honnête

Quiconque peut lire agent.key peut forger une chaîne

La clé d'attestation réside sur l'hôte, dans le répertoire de données de l'agent. Elle prouve que le lot a été produit par cette identité d'agent et qu'il n'a pas été altéré depuis. Elle ne protège pas contre un attaquant qui a déjà obtenu les droits root sur l'hôte et qui peut lire la clé privée — un tel attaquant peut signer une chaîne de son choix.

Nous l'énonçons plutôt que de le cacher. Fermer cette faille exige un séquestre hors hôte de l'empreinte au moment de l'enrôlement, ce qui n'est pas dans cette version. Protégez agent.key en conséquence : elle est en 0600 dans un répertoire 0700, et c'est une frontière qui mérite d'être surveillée.

Conservation locale des preuves

Le spool attesté est votre copie des preuves. Il réside sous le répertoire de données de l'agent (répertoire en 0700, fichiers en 0600) :

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

La borne disque honnête

max_files × max(max_file_size_mb, largest single batch) — et non max_files × max_file_size_mb. Un lot unique plus gros que le seuil est écrit en entier (la complétude de la preuve prime sur le plafond de taille) et le fichier fait l'objet d'une rotation immédiatement après. Dimensionnez le disque pour le plus gros lot qu'un hôte chargé peut produire ; l'agent émet un avertissement chaque fois qu'il en écrit un hors gabarit.

max_age_days est la borne de limitation de conservation que les plafonds de taille ne peuvent pas exprimer (RGPD art. 5(1)(e)) : avec max_files seul, un hôte tranquille conserve ses preuves indéfiniment tandis qu'un hôte chargé n'en garde que quelques heures.

Étapes suivantes

• Présentation de bitcollector — ce qu'il collecte, et ce qu'il coûte à exécuter.
• Confidentialité et comptes locaux — les valeurs par défaut qui décident, en amont, de ce qui finit dans les preuves.
• Vérifier vos téléchargements — l'autre vérification : prouver le binaire qui a produit les preuves. Une autre clé, et une vérification distincte.