Tiefer Einblick in die Technik: Manipulationssichere Beweise im großen Maßstab

Was revisionsbereit bedeutet, wenn das Hauptbuch groß ist¶

Jede kontrollierte Aktion in KLA landet in einem immudb-Ledger pro Mandant, das nur angehängt werden kann: Prüfeinträge, Richtlinienentscheidungen, Gate-Bewertungen, Richtlinienpaket-Snapshots und signierte Governance-Belege. Bei einem ausgelasteten Mandanten wächst das Hauptbuch unbegrenzt und eine Exportanforderung kommt mit einem Umfang an: einer Ausführung, einer Entscheidung, einer Richtlinie oder einem vollständigen Prüffenster.

Bei kleinen Mengen ist ein Export eine Abfrage plus Archiv. Bei großer Lautstärke erscheinen drei leise Fehlermodi. Eine serverseitige Scan-Obergrenze schneidet einen Ergebnissatz ohne Fehler ab. Bei einer Sammlung mit langer Laufzeit rasen die Schreibvorgänge über den Cursor hinaus. Ein teilweiser Export sieht genauso aus wie ein vollständiger Export, da bei Abwesenheit keine Artefakte zurückbleiben.

Die Designantwort besteht darin, Vollständigkeit als erstklassige, überprüfbare Eigenschaft der Sammlung und Integrität als erstklassige, überprüfbare Eigenschaft der versiegelten Ausgabe zu behandeln. Die beiden werden durch unterschiedliche Mechanismen durchgesetzt und durch unterschiedliche Prüfungen überprüft, und im Rest dieses Beitrags werden sie getrennt gehalten.

Das Bundle auf der Festplatte¶

Ein Sealed Evidence Bundle ist ein Zip-Archiv mit einem festen Layout. Alles, was ein Verifizierer benötigt, bewegt sich darin: das Manifest, die getrennte Signatur, die öffentlichen Schlüssel, beide Ankernachweise und die Artefakte selbst.

Das Manifest zeichnet die Exportidentität und -umfang, den anfordernden Prinzipal, Richtlinien-Snapshots mit ihren Paket-Hashes, die vollständige Artefaktliste mit SHA-256-Digests und -Größen pro Datei, den Merkle-Root über dieser Liste, das Schwärzungsprofil, deklarierte Auslassungen und ein Integritäts-block auf, das die Hash- und Signaturalgorithmen sowie den Ankersatz benennt.

<Bundle-Verzeichnis>/
  bundle.json-Siegelzusammenfassung: Digests, Unterzeichnersatz, Ankerreferenzen
  manifest.json vollständiges Manifest: Population, Artefakte, Integrität block
  manifest.jws.json hat ES256 JWS über den Manifest-Digest getrennt
  Die öffentlichen Verifizierungsschlüssel von „keys/jwks.json“ sind für die Offline-Verwendung eingebettet
  timestamp.ots OpenTimestamps-Proof über den Manifest-Digest
  ledger_anchor.json immudb-Ankerdatensatz für den versiegelten Digest
  Artefakte/
    exportiert/... exportierte Beweisdateien
    index/artifact_index.json

Versiegelung: kanonische Bytes, ein Digest, zwei Signaturen¶

Das sichere Signieren von JSON erfordert eine bytestabile Darstellung. Der Exporter kanonisiert das Manifest mit kanonischem JSON im JCS-Stil (RFC 8785): Schlüssel nach Codepunkt sortiert, keine undefinierten Werte, keine nicht endlichen Zahlen. Felder, die erst nach dem Signieren ausgefüllt werden können, wie etwa der Manifest-Hash selbst und der Ledger-Ankerwert-Hash, werden vor dem Digest ausgeblendet, sodass die festgeschriebenen Bytes genau definiert sind. Der SHA-256 dieser kanonischen Bytes ist der Manifest-Digest, an den sich jede nachgelagerte Verpflichtung bindet.

Für diesen Digest sind zwei Signaturen erforderlich, die als getrennter ES256-JWS erstellt werden. Der Service Environment Key (SEK) gibt an, welche KLA-Umgebung das Paket versiegelt hat. Der Mieternachweisschlüssel (TEK) bindet das Siegel an einen Mieter; seine Schlüssel-ID trägt die Mieter-ID. Der Exporteur erzwingt, dass die beiden Schlüssel unterschiedlich sind, und in der Produktion leben beide in HashiCorp Vault Transit als nicht exportierbare ECDSA P-256-Schlüssel, sodass die Signatur innerhalb von Vault erfolgt und privates Material niemals den Exportprozess erreicht.

Die Artefaktintegrität verwendet eine spezielle Merkle-Konstruktion, kla-merkle-v1. Jedes Blatt hasht ein Domänentrennungsbyte, den Artefaktpfad und den Artefakt-Digest; die Blattliste ist nach Pfadbytes sortiert; Innere Knoten haben ein eindeutiges Präfix über ihre untergeordneten Knoten. Das Manifest versiegelt das Stammverzeichnis und das Bundle enthält einen Einschlussnachweis für jedes Artefakt, sodass ein Prüfer bestätigen kann, dass eine einzelne Datei zum versiegelten Satz gehört, ohne das gesamte Archiv erneut aufzubereiten.

Die Governance-Belege kommen im Paket bereits unterschrieben an. Während eines kontrollierten Laufs versiegelt jeder Schritt eine ed25519-signierte Quittung, deren Inhalt prevReceiptHash enthält, die Inhaltsadresse der vorherigen Quittung. Der Hash befindet sich in der signierten Nutzlast, sodass die Signatur das Kettenglied selbst abdeckt. Prüfeinträge tragen eine zweite Hash-Kette auf Anwendungsebene: Jeder Datensatz speichert den Hash seines Vorgängers, der zum Zeitpunkt des Schreibens anhand des neuesten Ledger-Hashs des Mandanten berechnet wird.

{
  „bundleSpec“: „evidence-room-bundle-v1“,
  „manifestDigestSha256“: „4b7f0e0d2b9a51c6f3e8d1a07c5b2e94a6d803f1c2e75b09d4a1f6c8e3b25a70“,
  „merkleRootSha256“: „a1c9f2d84e07b6531f8c0d2ae95b47c6d310e8f2a7c54b90e6d1a3f8c2b7e415“,
  "artifactCount": 214,
  „requiredSigners“: [
    „sek“,
    „tek“
  ],
  „Zeitstempel“: {
    „Typ“: „opentimestamps-bitcoin-mainnet“,
    „receiptPath“: „timestamp.ots“
  },
  „Hauptbuch“: {
    „type“: „immudb“,
    „anchorPath“: „ledger_anchor.json“
  }
}

Verankerung der Dichtung außerhalb der Anlage¶

Eine Unterschrift beweist, wer das Manifest versiegelt hat. Anker binden wann und registrieren das Siegel in Systemen, die der Exporteur im Nachhinein nicht kontrolliert.

Der erste Anker ist ein OpenTimestamps-Beweis über den Manifest-Digest, der an die Bitcoin-Blockchain übergeben wird. Der Zeitstempel ist fehlgeschlagen: Ein Export mit deaktiviertem Zeitstempel oder einem fehlgeschlagenen Stempel lässt sich nicht versiegeln, und eine Bereitstellung kann zusätzlich erfordern, dass der Nachweis mit Bitcoin bestätigt wird, bevor der Export abgeschlossen wird.

Der zweite Anker schreibt den Manifest-Digest mit einem überprüfbaren Schreibvorgang unter einem von den Mandanten- und Export-IDs abgeleiteten Schlüssel zurück in das immudb-Ledger. Der Ankerdatensatz im Bundle enthält die Transaktions-ID und den Transaktionsnachweis des Servers, und der Offline-Verifizierer überprüft später, ob der Nachweis diesen Schlüssel und Wert tatsächlich an diese Transaktion bindet. Wenn das Schreiben des Ankers fehlschlägt, schlägt der Export fehl.

Ankerfehler und Beweisfehler verschleiern niemals eine ausgeführte Aktion. Ein beeinträchtigter Schreibpfad wird als beeinträchtigt aufgezeichnet, und ein versiegeltes Bündel, das einen erforderlichen Anker nicht erhalten konnte, ist ein Fehlerzustand mit benannter Ursache.

Sammlung unter Last: Paginierung als verifiziertes Protokoll¶

Der immudb-Server begrenzt einen Präfix-Scan auf 1.000 Einträge pro Seite. Ein naiver, nicht ausgelagerter Scan eines großen Mieterbuchs schneidet stillschweigend ab, was den schlimmsten möglichen Beweisfehler darstellt: ein plausibles Bündel, dem sein Ende fehlt. Der Kollektor behandelt die Paginierung daher als ein Protokoll mit Invarianten, und jede Invariantenverletzung bricht den Export mit einem IncompleteLedgerCoverageError ab.

Jede Seite wird mit einem expliziten Suchschlüssel angefordert, dem letzten Schlüssel, der von der vorherigen Seite geliefert wurde. Seiten werden beim Eintreffen durch einen Handler gestreamt; nichts sammelt sich grenzenlos im Gedächtnis an. Ein Scan wird nur dann beendet, wenn eine Seite den Grenzwert unterschreitet oder das konfigurierte Bereichsende überschritten wird, und jede Seite wird überprüft, bevor ihre Zeilen als abgedeckt gelten.

Bei umfassenden, hochvolumigen Scans werden Kandidatendatensatzkörper während des Scans als durch Zeilenumbrüche getrennte JSON-Daten auf die Festplatte übertragen und später in begrenzten Stapeln im Rahmen eines bytegewichteten Budgets rehydriert, wobei jeweils höchstens eine Körperseite mit maximaler Größe im Speicher gehalten wird. Feste Budgets für Lesevorgänge, Bytes, Parallelität und Arbeitszeit, einschließlich einer Leerlauffrist, die durch eine verifizierte fortschreitende Seite zurückgesetzt wird, und einer absoluten Frist, die durch nichts zurückgesetzt wird. Das Erreichen eines Budgets ist eine Verweigerung des Siegels, wobei das Budget im Fehler genannt wird.

• Übergroße Seite: Eine Seite mit mehr Zeilen als angefordert führt zum Abbruch des Scans.
• Schlüssellose Zeile: Jede Zeile muss den Schlüssel enthalten, von dem die Paginierung abhängt.
• Schlüssel außerhalb des Präfixes: Ein zurückgegebener Schlüssel außerhalb des gescannten Präfixes führt zum Abbruch.
• Regressiver Schlüssel: Schlüssel müssen seitenübergreifend strikt in der Byte-Reihenfolge vorrücken.
• Doppelter Schlüssel: Ein Schlüssel, der in einem Scan zweimal gesehen wird, wird abgebrochen.
• Nicht vorrückender Cursor: Eine unvollständige Seite, deren letzte Taste die Suchposition nicht verschieben kann, wird abgebrochen, wodurch die Fälle der Endlosschleife und der stillen Kürzung sofort geschlossen werden.

Behauptung der Vollständigkeit am Ende¶

Den Scan zu überleben ist notwendig und unzureichend. Wenn eine bereichsbezogene Sammlung abgeschlossen ist, stellt der Collector sicher, dass jeder angeforderte Selektor (Ausführungs-IDs, Herkunftsdatensatz-IDs, Entscheidungsanfrage-IDs, Richtlinien-IDs, Frameworks, Kontrollen) tatsächlich durch die gesammelten Einträge erfüllt wurde, und bricht den Vorgang ab, wobei die fehlenden Selektoren aufgelistet werden, falls dies nicht der Fall war.

Jeder gesammelte Eintrag muss außerdem über eine vertrauenswürdige Bescheinigung verfügen: Er stammt von der immudb-Quelle, die Serverantwort wurde anhand des lokal verwalteten Vertrauensstatus überprüft und der Einschlussnachweis wurde anhand des Antwortstamms überprüft. Einträge, die dieses Prädikat nicht erfüllen, werden ausgeschlossen und als Auslassungen mit einem stabilen Ursachencode aufgezeichnet und nicht als vertrauenswürdig exportiert. Im Manifest wird dann die Abdeckung für jeden Abschnitt als vollständig, teilweise, fehlend oder nicht anwendbar gemeldet, mit Begründungen für alles, was nicht vollständig ist.

Zwei Strukturprüfungen schließen die Fälle ab, die die Paginierung nicht sehen kann. Der Audit-Hash-Graph muss verbunden sein: Da gleichzeitige Autoren den Zeiger auf den neuesten Hash laufen lassen können, bildet das Ledger einen gerichteten azyklischen Graphen statt einer strengen Linie, und der Verifizierer benötigt genau eine Wurzel; Eine zweite Wurzel bedeutet, dass ein Mitglied im Export fehlt oder eine zweite Genese vorhanden ist. Empfangsketten überprüfen ihre prevReceiptHash-Links von der Entstehung bis zum letzten; Eine Kette kann die Kürzung an ihrem Ende nicht allein anhand der Links erkennen. Daher ist der Vertrag des Aufrufers vollständig, und der Verifizierer akzeptiert einen erwarteten Terminal-Hash, um diese letzte Lücke zu schließen, wenn der Aufrufer einen hat.

Unabhängige Überprüfung: Was ein Prüfer tatsächlich durchführt¶

Das @kla/evidence-verifier-Paket enthält eine CLI, die ein Bundle-Verzeichnis verwendet und die Integritätsprüfungen offline erneut ausführt, und zwar ausschließlich anhand des Bundle-Inhalts, ohne dass ein KLA-Dienst in der Schleife ist. Jede Prüfung meldet „Bestanden“ oder „Fehlgeschlagen“ mit eigenen Fehlern, und der Prozess wird bei jedem Fehler mit einem Wert ungleich Null beendet, sodass die Ausführung direkt in ein Skript oder einen CI-Job übergeht. Ein JSON-Modus gibt das vollständige maschinenlesbare Ergebnis aus. Eine optionale Prüfung durchsucht das Paket nach vom Anrufer bereitgestellten verbotenen Markierungen und meldet Übereinstimmungen nur als Hash-Präfixe.

$ Evidence-Verifier ./export-2026-08 --json > result.json
$ Evidence-Verifier ./export-2026-08
Beweisbündel: ./export-2026-08
PASS Manifest-Signatur SEK- und TEK ES256-Signaturen werden über den Manifest-Digest überprüft
PASS-Quittungssignaturen 41 Quittungsketten verifizieren von der Entstehung bis zum Schluss
PASS-Ledger-Hash-Chain 1.842 Ledger-Datensätze neu berechnen; Das Hash-Diagramm wird in eine Wurzel aufgelöst
PASS Merkle-Inklusion 214 Artefakte stimmen mit ihren Digests und Inklusionsnachweisen überein
PASS ots-anchor timestamp.ots übernimmt den Manifest-Digest
Ergebnis: PASS (5/5 Prüfungen bestanden)

Die angegebenen Grenzen des Offline-Beweises¶

Eine ehrliche Verifizierungsgeschichte nennt ihre Grenze, und die Grenze des Verifizierers wird in seiner Dokumentation und auf der veröffentlichten Seite manipulationssichere Beweise angegeben.

Die Offline-Überprüfung beweist die interne Konsistenz. Die öffentlichen Schlüssel bewegen sich innerhalb des Bündels. Um sie an KLA zu binden, müssen sie daher außerhalb des Bandes an einen von KLA veröffentlichten Schlüsselsatz angeheftet werden. Ohne diesen Schritt würde sich eine Fälschung von Grund auf mit neuen Schlüsseln selbst verifizieren. Der Bitcoin-Nachweis im Zeitstempelnachweis trägt eine block-Höhe, die bei der Offline-Überprüfung als Anspruch akzeptiert wird; Um dies zu bestätigen oder einen ausstehenden Kalenderbeleg zu aktualisieren, ist die Live-Kette erforderlich. Der immudb-Ankernachweis bindet den versiegelten Digest an eine Ledger-Transaktion, und um die Einbeziehung dieser Transaktion in den signierten Zustand des Ledgers zu bestätigen, ist eine Netzwerkprüfung erforderlich.

Diese Grenzwerte sind eher scheckförmig als vage: Jede einzelne entspricht einer spezifischen Überprüfung, die ein motivierter Prüfer mit der öffentlichen Infrastruktur durchführen kann, und keine davon schwächt die Ergebnisse des Offline-Laufs über die vorhandenen Bytes.

Negative Pfade: die Manipulationssuite¶

Die Testsuite des Verifizierers erstellt ein gültiges Fixture-Bundle und zerlegt es dann Byte für Byte. Dabei wird sichergestellt, dass jede Oberfläche genau das richtige Prüfrot annimmt: Ein umgedrehtes Byte in einer Beweisdatei schlägt bei der Merkle-Einbindung fehl; in einer Empfangsunterschrift oder einem Empfangstext, Empfangssignaturen; in einem Ledger-Datensatz oder seinem gespeicherten Hash, Ledger-Hash-Chain; in der versiegelten Merkle-Wurzel oder dem angegebenen Digest die entsprechende Siegelprüfung; im Zeitstempelnachweis, ots-anchor.

Signatur-Shape-Angriffe werden ebenso abgedeckt wie Inhaltsmanipulation: Eine formbare High-S-Variante einer gültigen ECDSA-Signatur wird ebenso abgelehnt wie eine gültige RSA-Signatur, die unter einem ES256-Header präsentiert wird, und jede Signatur, die nicht genau der 64-Byte-P-1363-Kodierung entspricht. Das Fail-Closing-Verhalten erhält eine eigene Suite: Ein fehlender Zeitstempelnachweis, fehlende Schlüssel, ein fehlender Ledger-Anker, eine mit einem widerrufenen Schlüssel signierte Quittung und ein Artefaktpfad, der das Bundle-Verzeichnis verlässt, schlagen alle fehl, und der Escape-Pfad wird abgelehnt, ohne die externe Datei zu lesen.

Auf der Sammlungsseite treiben die Tests des Exporteurs den Pager über das Server-Scan-Limit hinaus, geben doppelte und regressive Schlüssel wieder, zwingen Byte-Budgets über ihre Obergrenzen und stellen fest, dass bereichsbezogene Sammlungen nicht geschlossen werden können, wenn ein Bereich keine vollständige Paginierung herstellen kann. Die Vollständigkeitsmaschinerie wird als zu testendes Verhalten auf denselben Codepfaden ausgeführt, auf denen Produktionsexporte ausgeführt werden.