Evidenze che un auditor può verificare

Ogni batch di telemetria prodotto da bitcollector è firmato sull'host che lo ha generato e concatenato al batch precedente, e l'host ne conserva una copia identica a livello di byte. È questo che permette a qualcun altro — il tuo auditor, non noi — di verificare le evidenze offline e di sapere esattamente quale batch è sbagliato, quando uno lo è.

Questa pagina copre la catena, come verificare tu stesso uno spool, l'unico attaccante che non ferma e per quanto tempo le evidenze restano sull'host. Per cosa raccoglie l'agente e come eseguirlo, parti dalla panoramica di bitcollector.

La catena delle evidenze

È questa la parte che rende il dato difendibile e non semplicemente utile.

Ogni batch porta un'attestazione ECDSA sull'intero envelope, concatenata tramite hash al batch precedente. Uno spool locale sull'host conserva byte identici a livello di byte a quelli inviati in POST a Cert-IX. Quindi la copia che conservi tu e la copia che abbiamo ricevuto noi sono gli stessi byte, ed entrambe sono firmate da una chiave generata sul tuo host e che non lo abbandona mai.

Il tuo auditor la verifica senza di noi

# 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 non richiede alcun accesso di rete né alcun accesso a Cert-IX. Non è un "funziona offline per comodità" — è il punto centrale. Un'evidenza che può essere verificata solo chiedendo al fornitore che l'ha prodotta non è un'evidenza. export-pubkey esiste perché l'ancora di fiducia (trust anchor) stessa provenga dal tuo host anziché da noi.

export-pubkey stampa anche l'impronta SHA-256 della chiave. È lo stesso valore che ogni batch porta come key_fingerprint, così il file della chiave è legato all'evidenza che detieni. Se verifichi con la chiave sbagliata, ogni batch viene riportato come [INVALID] con una riga esplicita key_fingerprint mismatch — un'ancora di fiducia che non corrisponde non può mai essere confusa con un'evidenza manomessa.

Un batch modificato viene rilevato e nominato

Cambia un solo byte di un batch nello spool e riesegui 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…

Modifica, cancellazione, riordino e duplicazione vengono tutti rilevati, e viene nominato l'esatto seq. Ogni riga di ogni file di input è contabilizzata in un censimento che puoi confrontare con wc -lc, così "batch riportati + righe saltate" non può mai descrivere in silenzio un file diverso da quello su disco.

Codici di uscita

verify termina con un codice stabile su cui una pipeline di audit può ramificarsi:

Codice	Significato
0	Tutto verificato — autentico, non modificato, sequenza integra.
1	Almeno un batch non ha superato la verifica, oppure un input è stato rifiutato. Trattalo come un rilievo, non come un errore dello strumento.
2	Ogni batch è autentico singolarmente, ma la sequenza è sbagliata — uno manca, è duplicato o è fuori ordine.
3	Non è stato verificato nulla — uso errato, nessun --pubkey, percorso illeggibile, input vuoto. Correggi l'invocazione; questo non è un verdetto sulle tue evidenze.

Un tranello che vale la pena conoscere

Non usare una glob di shell per uno spool ruotato. cat batches-*.ndjson | bitcollector verify ordina lessicograficamente, quindi batches-10 viene prima di batches-7, ed evidenze autentiche e non manomesse vengono riportate come catena spezzata (uscita 2). Passa invece la directory — verify legge allora i file in ordine numerico.

Il limite dichiarato

Chiunque possa leggere agent.key può falsificare una catena

La chiave di attestazione risiede sull'host, nella directory dati dell'agente. Dimostra che il batch è stato prodotto da quell'identità di agente e che non è stato alterato da allora. Non protegge da un attaccante che ha già ottenuto root sull'host e può leggere la chiave privata: un attaccante simile può firmare una catena a suo piacimento.

Lo dichiariamo invece di nasconderlo. Chiuderlo richiede il deposito (escrow) fuori host dell'impronta al momento dell'enrolment, che non è presente in questa release. Proteggi agent.key di conseguenza: è 0600 in una directory 0700, ed è un confine che vale la pena monitorare.

Conservazione locale delle evidenze

Lo spool attestato è la tua copia delle evidenze. Risiede sotto la directory dati dell'agente (directory 0700, file 0600):

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

Il limite di disco dichiarato con onestà

max_files × max(max_file_size_mb, largest single batch) — non max_files × max_file_size_mb. Un singolo batch più grande della soglia viene scritto per intero (la completezza dell'evidenza prevale sul limite di dimensione) e il file ruota subito dopo. Dimensiona il disco per il batch più grande che un host trafficato può produrre; l'agente avvisa ogni volta che ne scrive uno fuori misura.

max_age_days è il vincolo di limitazione della conservazione che i limiti di dimensione non possono esprimere (GDPR Art. 5(1)(e)): con il solo max_files, un host tranquillo conserva le evidenze per sempre mentre uno trafficato ne conserva un paio d'ore.

Passi successivi

• Panoramica di bitcollector — cosa raccoglie e quanto costa eseguirlo.
• Privacy e account locali — le impostazioni predefinite che decidono, già in partenza, cosa finisce nelle evidenze.
• Verificare i tuoi download — l'altra verifica: dimostrare il binario che ha prodotto le evidenze. Una chiave diversa, e un controllo separato.