La preuve inviolable à grande échelle signifie trois garanties séparables. Intégrité : chaque artefact d'une exportation est haché à la valeur pour laquelle un manifeste signé s'est engagé. Exhaustivité : la collection qui a produit l'exportation soit couvrait sa population déclarée, soit refusait de sceller. Vérifiabilité indépendante : un examinateur externe peut réexécuter les contrôles d'intégrité à partir du seul ensemble, hors ligne, et voir la limite exacte de ce que prouvent ces contrôles. Cet article explique comment le pipeline de preuves expédié par KLA met en œuvre chaque garantie, depuis la collecte paginée à partir d'un grand livre en annexe uniquement jusqu'au scellement, à l'ancrage et à la vérification hors ligne.
Pistes d'audit des agents IA explique pourquoi les enregistrements d'exécution ont besoin de cette couche de preuves et ce qu'un pack de preuves contient conceptuellement. Ce compagnon reste dans la salle des machines : construction du hachage, formats de signature, invariants de pagination et modes de défaillance que chacun ferme.
Ce que signifie prêt pour l'audit une fois que le grand livre est volumineux
Chaque action gouvernée dans KLA atterrit dans un grand livre immudb par locataire, en annexe uniquement : entrées d'audit, décisions politiques, évaluations de porte, instantanés du pack de politiques et reçus de gouvernance signés. Sur un locataire occupé, ce grand livre grandit sans limite et une demande d'exportation arrive avec une portée : une exécution, une décision, une politique ou une fenêtre d'audit complète.
À petit volume, un export est une requête plus une archive. À volume élevé, trois modes de défaillance silencieux apparaissent. Un plafond d'analyse côté serveur tronque un ensemble de résultats sans erreur. Une collection de longue durée voit les écritures dépasser son curseur. Une exportation partielle semble identique à une exportation complète, car l’absence ne laisse aucun artefact.
La réponse de conception est de traiter l'exhaustivité comme une propriété testable de première classe de la collection, et l'intégrité comme une propriété testable de première classe de la sortie scellée. Les deux sont appliqués par des mécanismes différents et vérifiés par des contrôles différents, et le reste de cet article les maintient séparés.
| Garantie | Question à laquelle elle répond | Appliquée par | Vérifiée par |
|---|---|---|---|
| Intégrité | Ces octets sont-ils les octets qui ont été scellés ? | SHA-256 digests, racine Merkle, double signature ES256 sur un manifeste canonique | Vérificateur hors ligne : signature du manifeste, inclusion merkle |
| Complétude | La collection a-t-elle couvert la population déclarée ? | Pagination vérifiée par le curseur qui échoue fermée en cas de violation de couverture | Erreurs au moment de la collecte ; connectivité avec graphique de hachage ; Maillons de la chaîne de réception |
| Vérifiabilité indépendante | Un examinateur peut-il le confirmer sans faire confiance à l'infrastructure de KLA ? | Matériel de vérification intégré dans le bundle : clés, preuves, ancres | La CLI @kla/evidence-verifier, exécutée hors ligne sur le répertoire du bundle |
Le bundle sur le disque
A Sealed Evidence Bundle est une archive zip avec une mise en page fixe. Tout ce dont un vérificateur a besoin voyage à l'intérieur : le manifeste, la signature détachée, les clés publiques, les deux preuves d'ancrage et les artefacts eux-mêmes.
Le manifeste enregistre l'identité et la portée de l'exportation, le principal demandeur, les instantanés de politique avec leurs hachages de pack, la liste complète des artefacts avec SHA-256 digests et tailles par fichier, la racine Merkle sur cette liste, le profil de rédaction, les omissions déclarées et un bloc d'intégrité nommant les algorithmes de hachage et de signature et l'ensemble d'ancres.
<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.jsonScellement : octets canoniques, un résumé, deux signatures
La signature JSON en toute sécurité nécessite une représentation stable en octets. L'exportateur canonise le manifeste avec un JSON canonique de style JCS (RFC 8785) : clés triées par point de code, pas de valeurs indéfinies, pas de nombres non finis. Les champs qui ne peuvent être remplis qu'après la signature, tels que le hachage du manifeste lui-même et le hachage de la valeur d'ancrage du grand livre, sont masqués avant la digestion afin que les octets validés soient bien définis. Le SHA-256 de de ces octets canoniques est le résumé du manifeste, et chaque engagement en aval s'y lie.
Deux signatures sur ce résumé sont requises, produites sous la forme d'un JWS ES256 détaché. La clé d'environnement de service (SEK) indique quel environnement KLA a scellé le bundle. La clé de preuve du locataire (TEK) lie le sceau à un locataire ; son ID de clé porte l'identifiant du locataire. L'exportateur impose que les deux clés soient distinctes et qu'en production, les deux résident dans HashiCorp Vault Transit en tant qu'ECDSA non exportable P-256 keys, de sorte que la signature a lieu dans Vault et que le matériel privé n'atteint jamais le processus d'exportateur.
L'intégrité des artefacts utilise une construction Merkle dédiée, kla-merkle-v1. Chaque feuille hache un octet de séparation de domaine, le chemin de l'artefact et le résumé de l'artefact ; la liste des feuilles est triée par octets de chemin ; les nœuds internes hachent un préfixe distinct sur leurs enfants. Le manifeste scelle la racine et le bundle contient une preuve d'inclusion par artefact, de sorte qu'un réviseur peut confirmer qu'un seul fichier appartient à l'ensemble scellé sans ressasser l'intégralité de l'archive.
Les reçus de gouvernance arrivent dans le paquet déjà signé. Lors d'une exécution gouvernée, chaque étape scelle un reçu signé ed25519 dont le contenu inclut « prevReceiptHash », l'adresse de contenu du reçu précédent. Le hachage réside à l'intérieur de la charge utile signée, la signature couvre donc le maillon de la chaîne lui-même. Les entrées d'audit comportent une deuxième chaîne de hachage au niveau de l'application : chaque enregistrement stocke le hachage de son prédécesseur, calculé au moment de l'écriture par rapport au dernier hachage du grand livre du locataire.
{
"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"
}
}Ancrage du sceau à l'extérieur du système
Une signature prouve qui a scellé le manifeste. Les ancres sont liées qu et enregistrent le sceau dans des systèmes que l'exportateur ne contrôle pas après coup.
La première ancre est une preuve OpenTimestamps sur le résumé du manifeste, engagée envers la blockchain Bitcoin. L'horodatage est fermé en cas d'échec : une exportation avec l'horodatage désactivé ou un tampon échoué refuse de sceller, et un déploiement peut en outre exiger que la preuve soit attestée par Bitcoin avant la fin de l'exportation.
La deuxième ancre réécrit le résumé du manifeste dans le grand livre immudb sous une clé dérivée des ID de locataire et d'exportation, à l'aide d'une écriture vérifiable. L'enregistrement d'ancrage dans le bundle contient l'ID de transaction et la preuve de transaction du serveur, et le vérificateur hors ligne vérifie ensuite que la preuve lie réellement cette clé et cette valeur à cette transaction. Si l’écriture de l’ancre échoue, l’exportation échoue.
Les échecs d'ancrage et les échecs de preuves ne masquent jamais une action exécutée. Un chemin d'écriture dégradé est enregistré comme dégradé, et un paquet scellé qui n'a pas pu obtenir une ancre requise est un état d'erreur avec une raison nommée.
Collection sous charge : la pagination comme protocole vérifié
Le serveur immudb limite une analyse de préfixe à 1,000 entries par page. Une analyse naïve et non paginée d'un grand livre de locataires est tronquée silencieusement, ce qui constitue le pire échec possible en matière de preuve : un paquet plausible sans queue. Le collecteur traite donc la pagination comme un protocole avec des invariants, et chaque violation d'invariant annule l'exportation avec une IncompleteLedgerCoverageError.
Chaque page est demandée avec une clé de recherche explicite, la dernière clé délivrée par la page précédente. Les pages sont diffusées via un gestionnaire dès leur arrivée ; rien ne s'accumule sans limite dans la mémoire. Une analyse se termine uniquement lorsqu'une page revient en deçà de la limite ou que la fin de plage configurée est dépassée, et chaque page est vérifiée avant que ses lignes soient considérées comme couvertes.
Pour des analyses larges et à volume élevé, les corps d'enregistrement candidats se déversent sur le disque sous forme de JSON délimité par des nouvelles lignes pendant l'analyse et sont réhydratés ultérieurement par lots limités dans le cadre d'un budget pondéré en octets, contenant au plus une page de corps de taille maximale en mémoire à la fois. Des budgets fixes limitaient les lectures, les octets, la simultanéité et le temps d'horloge, y compris un délai d'inactivité qu'une page en cours de progression vérifiée réinitialise et un délai absolu que rien ne réinitialise. Atteindre un budget est un refus de sceller, le budget étant nommé dans l'erreur.
- Page surdimensionnée : une page contenant plus de lignes que demandé annule l'analyse.
- Ligne sans clé : chaque ligne doit porter la clé dont dépend la pagination.
- Clé hors préfixe : une clé renvoyée en dehors du préfixe analysé est abandonnée.
- Clé régressive : les clés doivent strictement avancer dans l'ordre des octets sur les pages.
- Clé en double : une clé vue deux fois au cours d'une analyse est abandonnée.
- Curseur non avancé : une page incomplète dont la dernière clé ne parvient pas à déplacer la position de recherche est abandonnée, fermant simultanément les cas de boucle infinie et de troncature silencieuse.
Affirmer l'exhaustivité à la fin
Survivre à l'analyse est nécessaire et insuffisant. Lorsqu'une collection étendue se termine, le collecteur affirme que chaque sélecteur demandé (ID d'exécution, ID d'enregistrement de lignée, ID de demande de décision, ID de politique, cadres, contrôles) a été réellement satisfait par les entrées collectées et abandonne avec les sélecteurs manquants répertoriés s'il y en a qui ne l'étaient pas.
Chaque entrée collectée doit également porter une attestation de confiance : elle provient de la source immudb, la réponse du serveur vérifiée par rapport à l'état de confiance maintenu localement et la preuve d'inclusion vérifiée par rapport à la racine de la réponse. Les entrées qui échouent à ce prédicat sont exclues et enregistrées comme des omissions avec un code de motif stable plutôt que exportées comme si elles étaient dignes de confiance. Le manifeste indique ensuite que la couverture par section est complète, partielle, manquante ou non applicable, avec les raisons pour lesquelles elle n'est pas complète.
Deux contrôles structurels ferment les cas que la pagination ne peut pas voir. Le graphe de hachage d'audit doit être connecté : étant donné que les rédacteurs concurrents peuvent utiliser le dernier pointeur de hachage, le grand livre forme un graphe acyclique orienté plutôt qu'une ligne stricte, et le vérificateur nécessite exactement une racine ; une deuxième racine signifie qu'un membre est manquant dans l'exportation ou qu'une deuxième genèse existe. Les chaînes de réception vérifient leurs liens prevReceiptHash depuis la genèse jusqu'à la fin ; une chaîne ne peut pas détecter la troncature à son extrémité à partir des seuls liens, le contrat de l'appelant est donc complet et le vérificateur accepte un hachage de terminal attendu pour combler cet écart final lorsque l'appelant en a un.
| Mécanisme | Mode d'échec fermé | Résultat en cas de violation |
|---|---|---|
| Pagination vérifiée par le curseur | Troncation côté serveur, pages sautées ou répétées | IncompleteLedgerCoverageError ; l'exportation est abandonnée |
| Assertion du sélecteur de fin d'analyse | Un enregistrement demandé est discrètement absent de l'analyse du grand livre | Erreur répertoriant tous les sélecteurs insatisfaits |
| Prédicat de confiance d'attestation | Une réponse de serveur falsifiée ou non vérifiée entrant dans le bundle | Entrée omise avec un code motif stable |
| Connectivité du graphique de hachage (racine unique) | Un membre supprimé du milieu du grand livre exporté | La vérification de la chaîne de hachage du grand livre échoue hors ligne |
| Les maillons de la chaîne de réception + le hachage de terminal attendu | Une exécution gouvernée tronquée à mi-parcours ou à sa fin | La vérification des signatures de réception échoue hors ligne |
Vérification indépendante : ce qu'un auditeur exécute réellement
Le package @kla/evidence-verifier fournit une CLI qui prend un répertoire de bundle et réexécute les contrôles d'intégrité hors ligne, à partir du seul contenu du bundle, sans aucun service KLA dans la boucle. Chaque vérification signale la réussite ou l'échec avec ses propres erreurs, et le processus se termine avec une valeur différente de zéro en cas d'échec, de sorte que l'exécution passe directement dans un script ou une tâche CI. Un mode JSON émet le résultat complet lisible par machine. Une vérification facultative balaie le paquet à la recherche des marqueurs interdits fournis par l'appelant, signalant les correspondances uniquement sous forme de préfixes de hachage.
$ 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)| Vérifiez | Ce qu'il recalcule | Ce qu'une passe établit |
|---|---|---|
| signature manifeste | Résumé canonique du manifeste ; Signatures SEK et TEK ES256 ; identité d'ancre du grand livre, hachage de valeur et preuve de transaction | Les octets du manifeste sont les octets signés par les deux clés, et la preuve d'ancrage lie le résumé scellé à une transaction du grand livre |
| signatures de réception | Chaque signature de réception ed25519 sur les octets de réception canoniques ; prevLiensReceiptHash, la genèse pour durer | Le reçu de chaque étape régie est authentique et l'ordre d'exécution est l'ordre signé |
| ledger-hash-chain | Le hachage stocké de chaque enregistrement du grand livre ; connectivité du graphique dans l'ensemble exporté | Aucun enregistrement d'audit exporté n'a été modifié et aucun membre ne manque à l'intérieur du graphique |
| merkle-inclusion | Chaque résumé et taille d'artefact ; chaque preuve d'inclusion jusqu'à la racine Merkle scellée | Chaque fichier de l'archive est le fichier dans lequel le manifeste est validé, sans aucun ajout ou remplacement |
| ots-anchor | Le résumé validé de la preuve OpenTimestamps par rapport au résumé du manifeste recalculé | La preuve d'horodatage s'engage sur ce manifeste exact |
Les limites indiquées de la preuve hors ligne
Une histoire de vérification honnête nomme sa limite, et la limite du vérificateur est indiquée dans sa documentation et dans la page publiée [preuve inviolable] (/tamper-proof-evidence). Sources : source
La vérification hors ligne prouve la cohérence interne. Les clés publiques voyagent à l'intérieur du paquet, donc les lier à KLA nécessite de les épingler hors bande sur un ensemble de clés publié par KLA ; sans cette étape, une contrefaçon à partir de zéro avec de nouvelles clés s'auto-vérifierait. L'attestation Bitcoin à l'intérieur de la preuve d'horodatage comporte une hauteur de bloc que la vérification hors ligne accepte comme réclamation ; sa confirmation ou la mise à niveau d'un reçu de calendrier en attente nécessite la chaîne en direct. La preuve d'ancrage immudb lie le résumé scellé à une transaction du grand livre, et la confirmation de l'inclusion de cette transaction par rapport à l'état signé du grand livre nécessite une vérification en réseau.
Ces limites sont sous forme de contrôle plutôt que vagues : chacune correspond à une vérification spécifique qu'un auditeur motivé peut effectuer avec une infrastructure publique, et aucune d'entre elles n'affaiblit ce que l'exécution hors ligne prouve sur les octets disponibles.
Chemins négatifs : la suite de falsification
La suite de tests du vérificateur construit un ensemble de luminaires valide, puis le décompose un octet à la fois, affirmant que chaque surface devient exactement le bon contrôle rouge : un octet inversé dans un fichier de preuve échoue à l'inclusion merkle ; dans une signature de récépissé ou un corps de récépissé, les signatures de récépissé ; dans un enregistrement de grand livre ou son hachage stocké, ledger-hash-chain ; dans la racine de Merkle scellée ou dans le digest déclaré, le contrôle de sceau correspondant ; dans la preuve d'horodatage, ots-anchor.
Les attaques de forme de signature sont couvertes parallèlement à la falsification de contenu : une variante malléable high-S d'une signature ECDSA valide est rejetée, tout comme une signature RSA valide présentée sous un en-tête ES256, et toute signature qui n'est pas exactement le 64-byte P-1363 encoding. Le comportement de fermeture en cas d'échec a sa propre suite : une preuve d'horodatage manquante, des clés manquantes, une ancre de grand livre manquante, un reçu signé par une clé révoquée et un chemin d'artefact qui échappe au répertoire du bundle échouent tous, et le chemin d'échappement est refusé sans lire le fichier externe.
Du côté de la collecte, les tests de l'exportateur poussent le téléavertisseur au-delà de la limite d'analyse du serveur, rejouent les clés en double et en régression, forcent les budgets d'octets au-delà de leurs plafonds et affirment que les collections étendues échouent lorsqu'une plage ne peut pas établir une pagination complète. La machinerie d'exhaustivité est exercée en tant que comportement testé, sur les mêmes chemins de code que les exportations de production.
Foire aux questions
Que contient un Sealed Evidence Bundle ?
Un manifeste répertoriant la portée de l'exportation, les instantanés de politique et chaque artefact avec son SHA-256 digest ; un JWS ES256 détaché avec les signatures de service et de locataire sur le résumé canonique du manifeste ; les clés publiques de vérification ; une preuve OpenTimestamps et une ancre de grand livre immudb sur le même résumé ; et les artefacts avec chacun une preuve d'inclusion Merkle.
Comment l'exportation prouve-t-elle l'exhaustivité plutôt que seulement l'intégrité ?
L'exhaustivité est appliquée lors de la collecte : la pagination vérifiée par le curseur est abandonnée sur toute page de troncature, de duplication, de régression ou de non-avancement ; les assertions de fin d'analyse exigent que chaque sélecteur demandé soit satisfait ; et la sortie scellée comporte des contrôles structurels (un graphique de hachage à racine unique et des chaînes de réception signées) qui échouent hors ligne si un membre a été supprimé.
Un auditeur peut-il vérifier un ensemble sans accès aux systèmes KLA ?
Oui. La CLI @kla/evidence-verifier réexécute la signature du manifeste, la signature du reçu, la chaîne de hachage du grand livre, l'inclusion Merkle et les vérifications de l'ancre d'horodatage hors ligne à partir du répertoire du bundle uniquement, et quitte une valeur différente de zéro en cas d'échec. La liaison des clés intégrées à KLA nécessite une étape hors bande : les épingler à un jeu de clés publié par KLA.
Que se passe-t-il lorsque la collecte ne peut pas couvrir la population demandée ?
L'exportation refuse de sceller. Les violations de couverture génèrent une erreur nommant l'invariant violé ou les sélecteurs insatisfaits, l'épuisement du budget génère une erreur nommant le budget et les entrées dépourvues d'attestation fiable sont omises avec un code de raison stable enregistré dans le manifeste.
Qu'est-ce que la vérification hors ligne ne peut pas établir ?
Trois choses, chacune pouvant être fermée avec une étape en réseau : la provenance de la clé (épingler les clés intégrées à un ensemble publié), la hauteur du bloc de l'attestation Bitcoin (confirmer par rapport à la chaîne) et l'inclusion de l'ancre immudb dans l'état signé du grand livre (une vérification du grand livre en réseau).
Pourquoi le grand livre d'audit est-il vérifié sous forme de graphique plutôt que de ligne droite ?
Les rédacteurs simultanés peuvent utiliser le dernier pointeur de hachage, de sorte que deux enregistrements peuvent légitimement faire référence au même prédécesseur. Le vérificateur vérifie donc la connectivité : le hachage prédécesseur de chaque enregistrement non-genèse doit être résolu à l'intérieur de l'exportation, et le graphique doit avoir exactement une racine. Une deuxième racine signifie qu'un membre est manquant ou qu'une deuxième genèse est présente.
Points clés à retenir
Prêt pour l'audit à grande échelle se décompose en mécanismes qui échouent chacun bruyamment : des octets canoniques sous deux signatures, une racine Merkle sur chaque artefact, deux ancres indépendantes sur le résumé scellé, une pagination qui traite chaque violation de couverture comme un refus de sceller et un vérificateur hors ligne qui réexécute les vérifications et nomme ses propres limites. Pour la couche conceptuelle située au-dessus de ce pipeline, commencez par les pistes d'audit des agents IA et la définition du pack de preuves ; pour évaluer un processus de preuve par rapport à ces propriétés, utilisez la liste de contrôle du pack de preuves et la référence Enregistrement d'exécution de l'agent AI.