# Beweispaket selbst pruefen

Ohne Installation von ALEX, ohne Vertrauen in Bewusst.Ki noetig — dieser Pruefer ist
unabhaengiger, deterministischer Code, der ausschliesslich lokal rechnet (kein Netzwerkzugriff,
keine Rueckmeldung an ALEX/Bewusst.Ki).

**Seit 05.09.2026 (RFC-3161-Zertifikatsketten-Pruefung):** fuer die reine ASN.1/CMS-Zerlegung des
Zeitstempel-Tokens werden drei kleine, quelloffene `@peculiar/asn1-*`-Pakete benoetigt (dieselben,
mit denen ALEX selbst RFC-3161-Tokens erzeugt) -- ein `npm install` ist deshalb jetzt einmalig
noetig, siehe Schritt 2 unten. Kein Netzwerkzugriff waehrend der eigentlichen Pruefung.

Voraussetzung: Node.js ab Version 20 (https://nodejs.org).

## Schritte

1. `verify.js`, `package.json` und diese Anleitung in denselben Ordner legen wie dein
   Beweispaket (die heruntergeladene `.json`-Datei aus dem ALEX-Pilot-Dashboard). Die
   `package.json` ist notwendig, sonst meldet Node einen Syntaxfehler (`verify.js` ist ein
   ES-Modul).
2. Terminal in diesem Ordner oeffnen, einmalig `npm install` ausfuehren.
3. `node verify.js dein-beweispaket.json`

## Ausgabe

- `VERIFIED` — Signatur und Hash-Kette sind intakt und stammen vom hinterlegten Schluessel.
- `FAILED` — das Paket widerspricht sich selbst (z. B. nachtraeglich veraendert).
- `INCONCLUSIVE` — die im Paket enthaltenen Angaben reichen nicht aus, um zu entscheiden.

## Trust-Anchor (Evidence Package V2)

Der zu verwendende oeffentliche Schluessel wird unabhaengig vom einzelnen Paket bezogen,
niemals aus dem Paket selbst:

https://bewusstki.de/.well-known/alex-pubkey.json (Feld `public_key_pem`)

Bei V2-Paketen zusaetzlich uebergeben:

```
node verify.js dein-beweispaket.json trusted-public-key.pem
```

## Zum Ausprobieren

`sample-bundle.json` (gueltig) und `invalid-tampered-bundle.json` (absichtlich manipuliert,
muss `FAILED` liefern) liegen bei — damit laesst sich der Pruefer testen, bevor man ihm
das eigene Beweispaket anvertraut. Zwei weitere Faelle (ein durch echte Laufzeitbeobachtung
erzwungener Netzwerk-Verstoss, ein unaufgeloester Widerspruch ueber zwei Laeufe) liegen unter
https://bewusstki.de/downloads/verify-bundle/devtask-network-violation-example.json bzw.
`.../devtask-contradiction-example.json` — volle Sammlung mit allen Faellen und dem jeweils
tatsaechlichen Pruefergebnis: `tools/verify-bundle/examples/README.md` im Repository.

## evidence-package@2.3: Pflicht-epistemic_gate (28.09.2026)

Seit `evidence-package@2.3` ist ein gueltiges `epistemic_gate` fuer jedes neu ausgestellte Bundle
PFLICHT, nicht mehr additiv-optional wie bei 2.0-2.2. Vier oeffentliche Canary-Bundles, signiert
mit dem ECHTEN, aktuell vertrauten Produktionsschluessel (kein Wegwerf-Testschluessel -- pruefbar
direkt gegen `/.well-known/alex-pubkey.json`, ohne zweiten Parameter), zeigen die vier Faelle, die
ein Pruefer kennen muss:

| Datei | Fall | Erwartetes Ergebnis |
|---|---|---|
| `evidence-package-2-3-canary-gate-missing.json` | gueltig signiertes 2.3-Bundle, nie ein Gate angehaengt | `epistemic_gate_epistemic_gate_not_attached` (Exit 2) |
| `evidence-package-2-3-canary-gate-tampered.json` | Gate angehaengt, `gate.decision` nachtraeglich veraendert | `epistemic_gate_invalid_epistemic_gate_signature` (Exit 2) |
| `evidence-package-2-3-canary-gate-replayed.json` | kryptografisch gueltiges Gate eines ANDEREN Bundles wiederverwendet | `epistemic_gate_epistemic_gate_hash_mismatch` (Exit 2) |
| `evidence-package-2-3-canary-downgrade-2-2.json` | echtes, gueltig signiertes 2.2-Bundle (Gate additiv-optional) | fuer sich allein `verified` (Exit 0) -- s.u. fuer den Downgrade-Schutz |

Das vierte Bundle ist absichtlich fuer sich allein gueltig: `evidence-package@2.2` verlangt kein
Gate, ein authentisches 2.2-Bundle bleibt also unveraendert pruefbar (Rueckwaertskompatibilitaet).
Der Downgrade-Schutz zeigt sich erst, wenn ein Konsument `epistemic_gate: "required"` verlangt
(`evidence-package-2-3-example-policy-requires-gate.json`, per `ALEX_VERIFY_POLICY_FILE`):

```
ALEX_VERIFY_POLICY_FILE=evidence-package-2-3-example-policy-requires-gate.json \
  node verify.js evidence-package-2-3-canary-downgrade-2-2.json
```

Das Bundle bleibt kryptografisch `verified`, die Proof-Policy blockiert die gated action trotzdem
(`blocked_by: ["epistemic_gate"]`, Exit 6) -- ein authentisches aelteres Bundle wird nie
stillschweigend als gleichwertig zu einer strengeren Anforderung behandelt.

## Ein echtes Bundle pruefen, kein Beispiel

Sieben tatsaechliche, signierte Evidence-Bundles zu oeffentlich nachvollziehbaren Demo-PRs
(Alex-Proof/alex-controlled-agent-demo) sind direkt herunterladbar, kein Login noetig:
`demo-pr-31.json`, `demo-pr-33.json`, `demo-pr-35.json`, `demo-pr-36.json`, `demo-pr-37.json`,
`demo-pr-38.json`, `demo-pr-39.json` unter https://bewusstki.de/downloads/verify-bundle/ .

Beispiel (PR #37):

```
curl -O https://bewusstki.de/downloads/verify-bundle/demo-pr-37.json
node verify.js demo-pr-37.json
```

Alle sieben Demo-Bundles sind mit inzwischen abgeloesten Schluesseln signiert (Server-Umzug
14.09.2026 und/oder KMS-Migration 04.09.2026, siehe https://bewusstki.de/evidence-key-rotation.html)
und liefern mit dem aktuellen Anker allein deshalb erwartungsgemaess `untrusted_signer` -- kein
Zeichen von Manipulation. Aufloesung im naechsten Abschnitt. Derselbe PR laesst sich parallel auf
GitHub ansehen (https://github.com/Alex-Proof/alex-controlled-agent-demo/pull/37).

## Wenn `verify.js` mit `untrusted_signer`/`untrusted_approval_signer` abbricht: historischen Schluessel suchen

Der aktuelle Trust-Anchor unter `/.well-known/alex-pubkey.json` gilt nur ab seinem `valid_from`-
Zeitpunkt. Ein Bundle, das mit einem inzwischen abgeloesten Schluessel signiert wurde (z. B. vor
einer geplanten KMS-Migration), liefert mit dem aktuellen Anker `untrusted_signer` (Evidence-
Schluessel) oder `untrusted_approval_signer` (separater Freigabe-Schluessel) -- das ist kein
Zeichen von Manipulation, beide Schluessel rotieren unabhaengig voneinander. Im selben
Well-known-Dokument steht unter `trust_anchor_registry.revocations[]` fuer jeden abgeloesten
Schluessel (beider Arten) ein eigener Eintrag mit `key_id`, `public_key_pem`, `valid_from` und
`revoked_at`. Jeweils den Eintrag suchen, dessen `key_id` dem `signer_key_id` bzw.
`approval_attestation.signer_key_id` im eigenen Bundle entspricht, `public_key_pem` in eine Datei
legen und wie oben als Trust-Anchor uebergeben:

```
node verify.js dein-beweispaket.json historischer-schluessel.pem historischer-freigabe-schluessel.pem
```

Betrifft aktuell alle sieben oeffentlichen Demo-Bundles: PR #31/#33/#35/#36 (Schluessel vor der
KMS-Migration vom 04.09.2026) und PR #37/#38/#39 (Schluessel vor dem Server-Umzug Alex-Souverrain
-> alex-core am 14.09.2026, Details: https://bewusstki.de/evidence-key-rotation.html). Beide
Vorgaenger-Schluessel stehen seit 15.09.2026 vollstaendig in `trust_anchor_registry.revocations[]`
-- keines der sieben Pakete ist dauerhaft ausgeschlossen, je aelter das Paket, desto weiter zurueck
der passende Registry-Eintrag.

## Den Diff selbst gegen GitHub nachrechnen, nicht nur dem JSON glauben

`VERIFIED` oben beweist: Signatur und Hash-Kette sind in sich stimmig. Es beweist noch nicht,
dass der im Paket signierte Diff auch tatsaechlich der Diff ist, den GitHub fuer denselben Commit
zeigt. Ein Skript, das genau das zusaetzlich nachrechnet -- Klon des Verifiers, Klon des
Demo-Repos, `git diff` zwischen den beiden Commits aus dem Paket, SHA-256 gegen `diff_full_sha256`
im Paket vergleichen -- ohne Vorbedingungen ausser bash/curl/git/Node:

```
curl -O https://raw.githubusercontent.com/bewusstki-hue/alex-mrtb-verify-bundle/main/prove-pr-33.sh
bash prove-pr-33.sh
```

Das Skript beweist Integritaet und die Uebereinstimmung des signierten Diffs mit GitHub. Ob die
Loesung den Auftrag fachlich erfuellt, entscheidet weiterhin die menschliche Review.

## Rechtliche Einordnung

Ein `VERIFIED`-Ergebnis beweist, dass das Paket seit der Signatur unveraendert ist und vom
hinterlegten Schluessel stammt. Es ersetzt keine qualifizierte elektronische Signatur nach
eIDAS und begruendet keine gesetzliche Echtheitsvermutung. Details:
https://bewusstki.de/evidence-beweiskraft.html