Evidencia que un auditor puede verificar

Cada lote de telemetría que produce bitcollector se firma en el host que lo produjo y se encadena con el lote anterior, y el host conserva una copia idéntica byte a byte. Eso es lo que permite que otra persona — su auditor, no nosotros — compruebe la evidencia sin conexión, y que se le diga exactamente qué lote está mal cuando alguno lo está.

Esta página cubre la cadena, cómo verificar usted mismo un spool, el único atacante que no detiene y cuánto tiempo permanece la evidencia en el host. Para saber qué recopila el agente y cómo ejecutarlo, empiece por la visión general de bitcollector.

La cadena de evidencia

Esta es la parte que hace que el dato sea defendible y no meramente útil.

Cada lote lleva una atestación ECDSA sobre el sobre completo, encadenada por hash con el lote anterior. Un spool local en el host guarda bytes idénticos byte a byte a los que se enviaron por POST a Cert-IX. Así que la copia que usted conserva y la copia que nosotros recibimos son los mismos bytes, y ambas están firmadas por una clave que se generó en su host y que nunca sale de él.

Su auditor lo verifica sin nosotros

# 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 no requiere acceso a la red ni acceso a Cert-IX. No es que "funcione sin conexión por comodidad" — es la clave del asunto. Una evidencia que solo puede comprobarse preguntando al proveedor que la produjo no es evidencia. export-pubkey existe para que el propio ancla de confianza salga de su host y no de nosotros.

export-pubkey también imprime la huella SHA-256 de la clave. Ese es el mismo valor que cada lote lleva como key_fingerprint, de modo que el fichero de clave queda ligado a la evidencia que usted tiene. Verifique con la clave equivocada y todos los lotes se reportarán como [INVALID] con una línea explícita de key_fingerprint mismatch — un ancla de confianza que no coincide nunca puede confundirse con evidencia manipulada.

Un lote modificado se detecta y se nombra

Cambie un solo byte de un lote en el spool y vuelva a ejecutar 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 modificación, el borrado, el reordenamiento y la duplicación se detectan todos, y se nombra el seq exacto. Cada línea de cada fichero de entrada queda contabilizada en un recuento que usted puede contrastar con wc -lc, de modo que "lotes reportados + líneas omitidas" nunca puede describir en silencio un fichero distinto del que hay en disco.

Códigos de salida

verify termina con un código estable sobre el que una canalización de auditoría puede ramificar:

Código	Significado
0	Todo correcto — auténtico, sin modificar, secuencia intacta.
1	Al menos un lote no superó la verificación, o se rechazó una entrada. Trátelo como un hallazgo, no como un error de la herramienta.
2	Todos los lotes son auténticos individualmente, pero la secuencia es incorrecta — falta uno, está duplicado o está fuera de orden.
3	No se verificó nada — uso incorrecto, falta --pubkey, ruta ilegible, entrada vacía. Corrija la invocación; esto no es un veredicto sobre su evidencia.

Un detalle que conviene conocer

No use un glob de shell para un spool rotado. cat batches-*.ndjson | bitcollector verify ordena lexicográficamente, de modo que batches-10 va antes que batches-7, y una evidencia genuina y no manipulada se reporta como cadena rota (código de salida 2). Pase el directorio en su lugar — verify leerá entonces los ficheros en orden numérico.

El límite honesto

Cualquiera que pueda leer agent.key puede falsificar una cadena

La clave de atestación vive en el host, en el directorio de datos del agente. Demuestra que el lote fue producido por esa identidad de agente y que no se ha alterado desde entonces. No protege frente a un atacante que ya ha conseguido root en el host y puede leer la clave privada — un atacante así puede firmar la cadena que quiera.

Lo declaramos en lugar de ocultarlo. Cerrarlo requiere depósito (escrow) de la huella fuera del host en el momento del enrolamiento, que no está en esta versión. Proteja agent.key en consecuencia: está en 0600 dentro de un directorio 0700, y esa es una frontera que vale la pena monitorizar.

Retención local de la evidencia

El spool atestado es su copia de la evidencia. Vive bajo el directorio de datos del agente (directorio 0700, ficheros 0600):

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

El límite honesto de disco

max_files × max(max_file_size_mb, largest single batch) — es decir, el mayor lote individual, y no max_files × max_file_size_mb. Un lote individual mayor que el umbral se escribe entero (la integridad de la evidencia prevalece sobre el límite de tamaño) y el fichero rota inmediatamente después. Dimensione el disco para el mayor lote que un host ocupado pueda producir; el agente avisa cada vez que escribe uno sobredimensionado.

max_age_days es el límite de limitación del plazo de conservación que los topes de tamaño no pueden expresar (RGPD art. 5(1)(e)): con solo max_files, un host tranquilo conserva la evidencia para siempre mientras que uno ocupado conserva un par de horas de ella.

Próximos pasos

• Visión general de bitcollector — qué recopila y cuánto cuesta ejecutarlo.
• Privacidad y cuentas locales — los valores por defecto que deciden, de entrada, qué acaba en la evidencia.
• Verificación de sus descargas — la otra verificación: demostrar el binario que produjo la evidencia. Una clave distinta, y una comprobación aparte.