Evidenze di manomissione su larga scala implicano tre garanzie separabili. Integrità: ogni artefatto in un'esportazione ha il valore a cui si è impegnato un manifest firmato. Completezza: la raccolta che ha prodotto l'esportazione copriva la popolazione dichiarata o si rifiutava di sigillarsi. Verificabilità indipendente: un revisore esterno può eseguire nuovamente i controlli di integrità dal solo pacchetto, offline, e vedere il confine esatto di ciò che dimostrano tali controlli. Questo post illustra il modo in cui la pipeline delle prove spedite da KLA implementa ciascuna garanzia, dalla raccolta impaginata da un registro di sola aggiunta fino alla sigillatura, all'ancoraggio e alla verifica offline.
Audit trail dell'agente AI spiega perché i record di esecuzione necessitano di questo livello di prova e cosa contiene concettualmente un evidence pack. Questo compagno rimane nella sala macchine: costruzione dell'hash, formati di firma, invarianti di impaginazione e modalità di errore che ciascuno chiude.
Cosa significa pronto per l'audit una volta che il registro è grande
Ogni azione governata in KLA finisce in un registro immudb per tenant, di sola aggiunta: voci di audit, decisioni politiche, valutazioni dei gate, istantanee dei pacchetti di politiche e ricevute di governance firmate. In un inquilino impegnato il registro cresce senza limiti e arriva una richiesta di esportazione con un ambito: un'esecuzione, una decisione, una policy o una finestra di controllo completa.
A volume ridotto, un'esportazione è una query più un archivio. A volume elevato compaiono tre modalità di guasto silenzioso. Un limite di scansione lato server tronca un set di risultati senza errori. Una raccolta di lunga durata vede le scritture correre oltre il cursore. Un'esportazione parziale sembra identica a una completa, poiché l'assenza non lascia artefatti.
La risposta progettuale è trattare la completezza come una proprietà verificabile di prima classe della raccolta e l'integrità come una proprietà verificabile di prima classe dell'output sigillato. I due sono applicati da meccanismi diversi e verificati da controlli diversi, e il resto di questo post li tiene separati.
| Garanzia | Domanda a cui risponde | Imposto da | Controllato da |
|---|---|---|---|
| Integrità | Questi byte sono i byte sigillati? | Digest SHA-256, radice Merkle, doppie firme ES256 su un manifest canonico | Verificatore offline: firma manifest, inclusione merkle |
| Completezza | La raccolta ha coperto la popolazione dichiarata? | Impaginazione verificata dal cursore che non riesce a chiudersi in caso di violazione della copertura | Errori al momento della raccolta; connettività con grafico hash; maglie della catena di ricevute |
| Verificabilità indipendente | Un revisore può confermarlo senza fidarsi dell'infrastruttura KLA? | Materiale di verifica incorporato nel pacchetto: chiavi, prove, ancore | La CLI @kla/evidence-verifier viene eseguita offline nella directory del bundle |
Il bundle su disco
Un Sealed Evidence Bundle è un archivio zip con un layout fisso. Tutto ciò di cui un verificatore ha bisogno viaggia al suo interno: il manifest, la firma distaccata, le chiavi pubbliche, entrambe le prove di ancoraggio, e gli artefatti stessi.
Il manifest registra l'identità e l'ambito dell'esportazione, l'entità richiedente, gli snapshot delle policy con gli hash dei pacchetti, l'elenco completo degli artefatti con digest e dimensioni SHA-256 per file, la radice Merkle su tale elenco, il profilo di redazione, le omissioni dichiarate e un blocco di integrità che nomina gli algoritmi di hash e firma e il set di ancoraggi.
<bundle-dir>/
bundle.json seal summary: digests, signer set, anchor references
manifest.json full manifest: population, artifacts, integrity block
manifest.jws.json detached ES256 JWS over the manifest digest
keys/jwks.json public verification keys embedded for offline use
timestamp.ots OpenTimestamps proof over the manifest digest
ledger_anchor.json immudb anchor record for the sealed digest
artifacts/
exports/... exported evidence files
index/artifact_index.jsonSigillatura: byte canonici, un digest, due firme
La firma JSON in modo sicuro richiede una rappresentazione stabile in byte. L'esportatore canonicalizza il manifest con JSON canonico in stile JCS (RFC 8785): chiavi ordinate per punto di codice, nessun valore indefinito, nessun numero non finito. I campi che possono essere compilati solo dopo la firma, come l'hash manifest stesso e l'hash del valore di ancoraggio del registro, vengono cancellati prima della digestione in modo che i byte impegnati siano ben definiti. Lo SHA-256 di quei byte canonici è il digest manifest e ogni impegno downstream si lega ad esso.
Sono necessarie due firme su quel digest, prodotte come ES256 JWS distaccato. La chiave dell'ambiente di servizio (SEK) afferma quale ambiente KLA ha sigillato il pacchetto. La chiave di prova dell'inquilino (TEK) vincola il sigillo a un inquilino; il suo ID chiave porta l'identificatore del tenant. L'esportatore impone che le due chiavi siano distinte e che in produzione risiedano entrambe in HashiCorp Vault Transit come chiavi ECDSA P-256 non esportabili, quindi la firma avviene all'interno di Vault e il materiale privato non raggiunge mai il processo di esportatore.
L'integrità dell'artefatto utilizza una costruzione Merkle dedicata, kla-merkle-v1. Ogni foglia ha un byte di separazione del dominio, il percorso dell'artefatto e il digest dell'artefatto; l'elenco delle foglie è ordinato per byte di percorso; i nodi interni hanno un prefisso distinto sui loro figli. Il manifest sigilla la radice e il bundle contiene una prova di inclusione per artefatto, in modo che un revisore possa confermare che un singolo file appartiene al set sigillato senza rielaborare l'intero archivio.
Le ricevute di governance arrivano nel pacchetto già firmato. Durante un'esecuzione governata, ogni passaggio sigilla una ricevuta firmata ed25519- il cui contenuto include prevReceiptHash, l'indirizzo del contenuto della ricevuta precedente. L'hash risiede all'interno del payload firmato, quindi la firma copre l'anello stesso della catena. Le voci di controllo contengono una seconda catena di hash a livello di applicazione: ogni record memorizza l'hash del suo predecessore, calcolato al momento della scrittura rispetto all'ultimo hash del registro del tenant.
{
"bundleSpec": "evidence-room-bundle-v1",
"manifestDigestSha256": "4b7f0e0d2b9a51c6f3e8d1a07c5b2e94a6d803f1c2e75b09d4a1f6c8e3b25a70",
"merkleRootSha256": "a1c9f2d84e07b6531f8c0d2ae95b47c6d310e8f2a7c54b90e6d1a3f8c2b7e415",
"artifactCount": 214,
"requiredSigners": [
"sek",
"tek"
],
"timestamping": {
"type": "opentimestamps-bitcoin-mainnet",
"receiptPath": "timestamp.ots"
},
"ledger": {
"type": "immudb",
"anchorPath": "ledger_anchor.json"
}
}Ancoraggio della guarnizione all'esterno dell'impianto
Una firma prova chi ha sigillato la lista. Ancoraggi vincolati quando e registrazione del sigillo in sistemi che l'esportatore non controlla successivamente.
Il primo ancoraggio è una prova OpenTimestamps sul manifest digest, impegnata nei confronti della blockchain di Bitcoin. Il timestamp è fail-closed: un'esportazione con timestamp disabilitato o un timbro non riuscito si rifiuta di sigillare e una distribuzione può inoltre richiedere che la prova sia attestata da Bitcoin prima del completamento dell'esportazione.
La seconda ancora riscrive il digest manifest nel registro immudb con una chiave derivata dal tenant e dagli ID di esportazione, utilizzando una scrittura verificabile. Il record di ancoraggio nel pacchetto contiene l’ID della transazione e la prova della transazione del server, e il verificatore offline verifica successivamente che la prova leghi effettivamente quella chiave e quel valore a quella transazione. Se la scrittura dell'ancora fallisce, l'esportazione fallisce.
Gli errori di ancoraggio e gli errori di prova non mascherano mai un'azione eseguita. Un percorso di scrittura danneggiato viene registrato come danneggiato e un bundle sigillato che non è riuscito a ottenere l'ancoraggio richiesto viene segnalato in uno stato di errore con un motivo denominato.
Raccolta sotto carico: impaginazione come protocollo verificato
Il server immudb limita la scansione del prefisso alle voci 1,000 per pagina. Un'ingenua scansione senza pagine di un grande registro degli inquilini tronca silenziosamente, il che è il peggior fallimento possibile come prova: un fascio plausibile a cui manca la coda. Il collector pertanto tratta l'impaginazione come un protocollo con invarianti e ogni violazione di invarianti interrompe l'esportazione con un IncompleteLedgerCoverageError.
Ogni pagina viene richiesta con una chiave di ricerca esplicita, l'ultima chiave consegnata dalla pagina precedente. Le pagine scorrono attraverso un gestore non appena arrivano; nulla si accumula illimitatamente nella memoria. Una scansione termina solo quando una pagina non raggiunge il limite o viene superato il limite configurato dell'intervallo e ogni pagina viene controllata prima che le sue righe vengano considerate coperte.
Per scansioni estese e di volume elevato, i corpi dei record candidati si riversano sul disco come JSON delimitato da nuova riga durante la scansione e vengono reidratati successivamente in batch limitati con un budget ponderato in byte, mantenendo in memoria al massimo una pagina di corpi di dimensione massima alla volta. Budget fissi legati a letture, byte, concorrenza e tempo di clock, inclusa una scadenza di inattività che viene reimpostata da una pagina di avanzamento verificata e una scadenza assoluta che non viene reimpostata da nulla. Raggiungere un budget significa rifiutarsi di sigillarlo, con il budget indicato nell'errore.
- Pagina di grandi dimensioni: una pagina con più righe di quelle richieste interrompe la scansione.
- Riga senza chiave: ogni riga deve contenere la chiave da cui dipende l'impaginazione.
- Chiave fuori dal prefisso: una chiave restituita all'esterno del prefisso scansionato viene interrotta.
- Chiave di regressione: le chiavi devono rigorosamente avanzare in ordine di byte tra le pagine.
- Chiave duplicata: una chiave vista due volte in una scansione viene interrotta.
- Cursore che non avanza: una pagina incompleta il cui ultimo tasto non riesce a spostare la posizione di ricerca viene interrotta, chiudendo contemporaneamente i casi di ciclo infinito e di troncamento silenzioso.
Affermare la completezza alla fine
Sopravvivere alla scansione è necessario e non sufficiente. Quando una raccolta con ambito termina, il raccoglitore asserisce che ogni selettore richiesto (ID di esecuzione, ID di record di derivazione, ID di richiesta di decisione, ID di policy, framework, controlli) è stato effettivamente soddisfatto dalle voci raccolte e interrompe con i selettori mancanti elencati se non lo erano.
Ogni voce raccolta deve inoltre contenere un'attestazione attendibile: proviene dalla fonte immudb, la risposta del server è stata verificata rispetto allo stato di attendibilità mantenuto localmente e la prova di inclusione verificata rispetto alla root della risposta. Le voci che non soddisfano tale predicato vengono escluse e registrate come omissioni con un codice motivo stabile anziché esportate come se fossero affidabili. Il manifest riporta quindi la copertura per sezione come completa, parziale, mancante o non applicabile, con le motivazioni per qualsiasi cosa non sia completa.
Due controlli strutturali chiudono i casi che l'impaginazione non può vedere. Il grafico hash di audit deve essere connesso: poiché gli autori concorrenti possono competere con il puntatore dell'hash più recente, il registro forma un grafico aciclico diretto anziché una linea rigorosa e il verificatore richiede esattamente una radice; una seconda radice indica che manca un membro nell'esportazione o che esiste una seconda genesi. Le catene di ricevute verificano i loro collegamenti prevReceiptHash dalla genesi all'ultimo; una catena non può rilevare il troncamento alla sua estremità solo dai collegamenti, quindi la completezza è il contratto del chiamante e il verificatore accetta un hash terminale previsto per colmare quel divario finale quando il chiamante ne ha uno.
| Meccanismo | Modalità di errore chiusa | Esito in caso di violazione |
|---|---|---|
| Impaginazione verificata dal cursore | Troncamento lato server, pagine saltate o ripetute | Errore di copertura del registro incompleto; l'esportazione si interrompe |
| Asserzione del selettore di fine scansione | Un record richiesto, silenziosamente assente dalla scansione del registro | Errore nell'elenco di tutti i selettori insoddisfatti |
| Predicato di fiducia dell'attestazione | Una risposta del server contraffatta o non verificata che entra nel bundle | Voce omessa con codice motivo stabile |
| Connettività con grafico hash (radice singola) | Un membro rimosso dal centro del registro esportato | il controllo della catena hash del registro non riesce offline |
| Collegamenti della catena di ricevute + hash terminale previsto | Un percorso governato troncato a metà del corso d'acqua o alla sua fine | il controllo delle firme delle ricevute non riesce offline |
Verifica indipendente: cosa esegue effettivamente un revisore
Il pacchetto @kla/evidence-verifier fornisce una CLI che prende una directory del bundle ed esegue nuovamente i controlli di integrità offline, solo dal contenuto del bundle, senza alcun servizio KLA nel ciclo. Ogni report di controllo supera o fallisce con i propri errori e il processo esce con un valore diverso da zero in caso di errore, quindi l'esecuzione passa direttamente a uno script o a un lavoro CI. Una modalità JSON emette il risultato completo leggibile dalla macchina. Un controllo opzionale analizza il pacchetto alla ricerca di indicatori vietati forniti dal chiamante, segnalando le corrispondenze solo come prefissi hash.
$ evidence-verifier ./export-2026-08 --json > result.json
$ evidence-verifier ./export-2026-08
Evidence bundle: ./export-2026-08
PASS manifest-signature SEK and TEK ES256 signatures verify over the manifest digest
PASS receipt-signatures 41 receipt chains verify from genesis to last
PASS ledger-hash-chain 1,842 ledger records recompute; hash graph resolves to one root
PASS merkle-inclusion 214 artifacts match their digests and inclusion proofs
PASS ots-anchor timestamp.ots commits to the manifest digest
Result: PASS (5/5 checks passed)| Controllo | Cosa ricalcola | Ciò che stabilisce un passaggio |
|---|---|---|
| firma-manifesto | Digest manifesto canonico; Firme SEK e TEK ES256; identità di ancoraggio del registro, hash del valore e prova della transazione | I byte manifest sono i byte firmati da entrambe le chiavi e la prova di ancoraggio lega il digest sigillato a una transazione del registro |
| firme di ricevuta | Ogni firma di ricevuta ed25519 su byte di ricevuta canonici; collegamenti prevReceiptHash, dalla genesi all'ultimo | La ricevuta di ogni passaggio regolato è autentica e l'ordine di esecuzione è l'ordine firmato |
| ledger-hash-chain | L'hash memorizzato di ciascun record del registro; connettività del grafico nel set esportato | Nessun record di controllo esportato è stato modificato e non manca alcun membro all'interno del grafico |
| inclusione di Merkle | Ogni manufatto viene riassunto e dimensionato; ogni prova di inclusione fino alla radice Merkle sigillata | Ogni file nell'archivio è il file su cui è stato eseguito il commit del manifest, senza aggiunta o sostituzione di nessuno |
| ots-ancora | Il digest impegnato della prova OpenTimestamps rispetto al digest manifest ricalcolato | La prova del timestamp si impegna a questo manifest esatto |
I limiti dichiarati della prova offline
Una storia di verifica onesta definisce il proprio confine e il confine del verificatore è dichiarato nella sua documentazione e nella pagina pubblicata prove a prova di manomissione.
La verifica offline dimostra la coerenza interna. Le chiavi pubbliche viaggiano all'interno del pacchetto, quindi per legarle a KLA è necessario fissarle fuori banda rispetto a un set di chiavi pubblicato da KLA; senza questo passaggio, una falsificazione effettuata da zero con chiavi nuove si autoverificherebbe. L'attestazione Bitcoin all'interno della prova del timestamp porta un'altezza di blocco che il controllo offline accetta come richiesta; confermarlo o aggiornare una ricevuta del calendario in sospeso richiede la catena live. La prova di ancoraggio di immudb lega il digest sigillato a una transazione del registro e la conferma dell'inclusione della transazione rispetto allo stato firmato del registro richiede un controllo in rete.
Questi limiti sono modellati piuttosto che vaghi: ognuno corrisponde a una verifica specifica che un revisore motivato può eseguire con l’infrastruttura pubblica, e nessuno di essi indebolisce ciò che l’esecuzione offline dimostra sui byte in mano.
Percorsi negativi: la suite antimanomissione
La suite di test del verificatore costruisce un bundle di dispositivi valido e poi lo suddivide un byte alla volta, affermando che ogni superficie trasforma esattamente il segno di spunta rosso giusto: un byte capovolto in un file di prova fallisce l'inclusione di Merkle; in una firma di ricevuta o nel corpo della ricevuta, firme di ricevuta; in un record di registro o nel suo hash archiviato, ledger-hash-chain; nella radice Merkle sigillata o nel digest dichiarato, il corrispondente controllo del sigillo; nella prova timestamp, ots-anchor.
Gli attacchi alla forma della firma sono coperti insieme alla manomissione del contenuto: una variante malleabile con S alta di una firma ECDSA valida viene rifiutata, così come una firma RSA valida presentata sotto un'intestazione ES256 e qualsiasi firma che non sia esattamente la codifica 64-byte P-1363. Il comportamento di chiusura in caso di errore ottiene una propria suite: una prova di timestamp mancante, chiavi mancanti, un'ancora del registro mancante, una ricevuta firmata da una chiave revocata e un percorso di artefatto che sfugge alla directory del bundle falliscono tutti e il percorso di fuga viene rifiutato senza leggere il file esterno.
Dal lato della raccolta, i test dell'esportatore spingono il cercapersone oltre il limite di scansione del server, riproducono chiavi duplicate e regredenti, forzano i budget di byte oltre i loro limiti e affermano che le raccolte con ambito non vengono chiuse quando un intervallo non può stabilire un'impaginazione completa. Il meccanismo della completezza si esercita come comportamento in prova, sugli stessi percorsi di codice che percorrono le esportazioni di produzione.
Domande frequenti
Cosa contiene un pacchetto di prove sigillate?
Un manifest che elenca l'ambito dell'esportazione, gli snapshot delle policy e ogni artefatto con il relativo digest SHA-256; un ES256 JWS separato con le firme del servizio e dell'inquilino sul digest canonico del manifest; le chiavi pubbliche di verifica; una prova OpenTimestamps e un'ancora di registro immudb sullo stesso digest; e gli artefatti con una prova di inclusione Merkle ciascuno.
In che modo l'esportazione dimostra la completezza anziché solo l'integrità?
La completezza viene applicata durante la raccolta: l'impaginazione verificata dal cursore si interrompe su qualsiasi pagina troncata, duplicata, regredita o che non avanza; le asserzioni di fine scansione richiedono che ogni selettore richiesto sia soddisfatto; e l'output sigillato comporta controlli strutturali (un grafico hash a radice singola e catene di ricevute firmate) che falliscono offline se un membro viene rimosso.
Un revisore può verificare un pacchetto senza accedere ai sistemi KLA?
SÌ. La CLI @kla/evidence-verifier esegue nuovamente i controlli offline della firma del manifest, della firma della ricevuta, della catena di hash del registro, dell'inclusione di Merkle e dell'ancoraggio del timestamp solo dalla directory del bundle ed esce con un valore diverso da zero in caso di errore. L'associazione delle chiavi incorporate a KLA richiede un passaggio fuori banda: fissarle a un set di chiavi pubblicato da KLA.
Cosa succede quando la raccolta non riesce a coprire la popolazione richiesta?
L'esportazione si rifiuta di sigillare. Le violazioni della copertura generano un errore nella denominazione dell'invariante violato o dei selettori insoddisfatti, l'esaurimento del budget genera un errore nella denominazione del budget e le voci prive di un'attestazione attendibile vengono omesse con un codice motivo stabile registrato nel manifest.
Cosa non può stabilire la verifica offline?
Tre cose, ciascuna chiudibile con un passaggio in rete: provenienza della chiave (appuntare le chiavi incorporate su un set pubblicato), l'altezza del blocco dell'attestazione Bitcoin (confermare contro la catena) e l'inclusione dell'ancora immudb nello stato firmato del registro (un controllo del registro in rete).
Perché il registro di revisione viene verificato come un grafico anziché come una linea retta?
Gli scrittori simultanei possono competere con il puntatore dell'hash più recente, quindi due record possono fare legittimamente riferimento allo stesso predecessore. Il verificatore quindi controlla la connettività: l’hash predecessore di ogni record non di genesi deve risolversi all’interno dell’esportazione e il grafico deve avere esattamente una radice. Una seconda radice significa che manca un membro o che è presente una seconda genesi.
Punti chiave
Il controllo su larga scala si decompone in meccanismi ciascuno dei quali fallisce clamorosamente: byte canonici sotto due firme, una radice Merkle su ogni artefatto, due ancoraggi indipendenti sul digest sigillato, impaginazione che tratta ogni violazione della copertura come un rifiuto di sigillare e un verificatore offline che esegue nuovamente i controlli e definisce i propri limiti. Per il livello concettuale sopra questa pipeline, iniziare con audit trail dell'agente AI e la definizione di evidence pack; per valutare un processo di prova rispetto a queste proprietà, utilizzare l'elenco di controllo del pacchetto di prove e il riferimento record di esecuzione dell'agente AI.