Enterprise Edge

Local Vault

Local Vault ist eine outbound-only Customer Edge Component für Connector Secret Storage, Source Attestation Signing, Offline Spooling, Event Relay, optionalen Customer-side Witness Betrieb und, in Local Vault 2.x, den Attesto 3 Provenance Mode, bei dem Capsules auf dem Edge Host bleiben und nur Commitments die Plattform erreichen. Es ist nicht HashiCorp Vault.

Responsibilities

Connector Credentials lokal encrypten.
Source Attestations vor Relay signieren.
Events während Network Outages spoolen.
Spooled Events in Reihenfolge mit Idempotency replayen.
Als Customer-side Witness operieren, wenn Tenant Policy es aktiviert.

Lokale Image Provenance nutzt den isolierten Provider und das verschlüsselte keyed Register aus dem AttestoMark Image Leitfaden.

Installieren und ausführen

Installieren Sie Local Vault auf dem kundenseitig kontrollierten Edge Host. Runtime-Koordinaten können aus Flags oder Environment Variables kommen, aber Signing Keys, Spool Encryption Keys und Connector Credentials müssen aus dem lokalen Deployment Secret Manager kommen. Speichern Sie sie nicht in Shell History, Frontend-Konfiguration oder Attesto-Docs.

Die empfohlene Installation ist der signierte Container-Kanal: ein One-Command-Installer zieht das per Digest gepinnte Vault-Image, legt die State- und Config-Verzeichnisse an und installiert einen attesto-local-vault Wrapper, sodass jedes CLI-Kommando transparent im Container läuft. Docker ist erforderlich (Docker Desktop auf macOS und Windows).

# Linux / macOS
curl -fsSL https://get.attesto.eu/local-vault/install.sh | sh

# Windows (PowerShell)
irm https://get.attesto.eu/local-vault/install.ps1 | iex

# Image pinned by digest (override: ATTESTO_LOCAL_VAULT_IMAGE):
# git.attesto.eu/attesto/local-vault@sha256:5799e7f0669c9b42a55a338f4233cfa5afb5aa6a2627c2c50f7545a41bff1551

Auf macOS und Windows laufen der Vault und seine Linux-only Provider Sandbox in der Linux-VM von Docker Desktop; die Isolationszusagen gelten innerhalb dieser VM. Ein nativer macOS- oder Windows-Prozess würde sie nicht tragen — genau deshalb sind die Installer Container-Wrapper. Deinstallation: den Wrapper entfernen, das Image mit docker rmi löschen und das State-Verzeichnis nur löschen, wenn die Evidenz nicht mehr gebraucht wird — install.sh --help zeigt die exakten Kommandos.

Auf macOS und Linux installiert sich derselbe Container-Wrapper auch über Homebrew. Die Formula-Hashes werden wörtlich aus dem cosign-signierten Kanal-Manifest übernommen, und Homebrew erzwingt sie bei jeder Installation; die Caveats wiederholen die Docker-Anforderung und den Honesty-Hinweis oben:

brew tap attesto/attesto https://git.attesto.eu/attesto/homebrew-attesto.git
brew trust attesto/attesto
brew install attesto-local-vault

Auf Debian/Ubuntu- und Fedora/RHEL-Hosts installieren native Pakete denselben Wrapper als /usr/bin/attesto-local-vault, mit demselben per Digest gepinnten Image. Das deb hängt hart von einer Docker-kompatiblen Engine ab (docker-ce | docker.io | podman-docker); rpm kann diese Alternation nicht über Repositories hinweg ausdrücken und empfiehlt daher nur docker — die Engine bleibt zur Laufzeit erforderlich. Verifizieren Sie das signierte Manifest, prüfen Sie den Paket-Hash und installieren Sie dann:

curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/SHA256SUMS
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/SHA256SUMS.sig
cosign verify-blob --key https://get.attesto.eu/cosign.pub --insecure-ignore-tlog --signature SHA256SUMS.sig SHA256SUMS

# Debian / Ubuntu (run the install as root)
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/attesto-local-vault_2.0.1-1_all.deb
sha256sum -c --ignore-missing SHA256SUMS
apt install ./attesto-local-vault_2.0.1-1_all.deb

# Fedora / RHEL (run the install as root)
curl -fsSLO https://get.attesto.eu/local-vault/2.0.1/attesto-local-vault-2.0.1-1.noarch.rpm
sha256sum -c --ignore-missing SHA256SUMS
dnf install ./attesto-local-vault-2.0.1-1.noarch.rpm

Der Python-Wheel-Kanal bleibt für Hosts verfügbar, die den Vault nativ auf Linux betreiben:

pipx install attesto-local-vault

export ATTESTO_LOCAL_VAULT_SPOOL_DB=/var/lib/attesto/local-vault.sqlite3
export ATTESTO_LOCAL_VAULT_INSTALLATION_ID="$ATTESTO_LOCAL_VAULT_INSTALLATION_ID"
export ATTESTO_LOCAL_VAULT_RELAY_URL="https://verify.attesto.eu/v2/local-vault/installations/$ATTESTO_LOCAL_VAULT_INSTALLATION_ID/events"
export ATTESTO_LOCAL_VAULT_KEY_ID="$ATTESTO_LOCAL_VAULT_KEY_ID"

attesto-local-vault drain-loop

Health Check

Führen Sie attesto-local-vault doctor nach dem Bootstrap und während Operator Troubleshooting aus. Der Doctor prüft Config, lokale Secrets, secrets.env-Berechtigungen, encrypted Spool Readback, Relay URL HTTPS Regeln, Backend Erreichbarkeit, Server Clock Skew, ungültige Server Date Header und Dead-letter Depth. Failures liefern einen non-zero Exit Code. Warnings halten den Spool nutzbar, müssen aber vom Operator geprüft werden.

attesto-local-vault doctor

Enrollment

Ein tenant owner oder admin erzeugt ein kurzlebiges enrollment token mit POST /v2/tenant/local-vault/enrollment-tokens. Der Edge Host tauscht dieses Token über POST /v2/local-vault/enroll gegen installation metadata und das Credential für outbound relay. Enrollment tokens sind single-use; Attesto speichert nach Erstellung nur ihren Hash.

Delivery Acknowledgement

Local Vault markiert ein Element nur dann als delivered, wenn Attesto ein 2xx JSON Receipt mit passendem localVaultAck.envelopeHash, Stream Binding und canonical event id zurückgibt. Ein Proxy 2xx, malformed body, mismatched receipt oder revoked installation bleibt eine fehlgeschlagene Delivery und unterliegt Retry oder Dead-letter Policy.

Outbound Relay Flow

Die Customer Source erstellt ein Attestation Event.
Local Vault signiert und speichert das Event im encrypted Spool.
Local Vault relayt das Event an POST /v2/local-vault/installations/{installation_id}/events auf https://verify.attesto.eu.
Attesto gibt das Proofstream Receipt zurück.
Local Vault zeichnet Receipt State auf und behält Retry Metadata, bis Delivery complete ist.

{
  "source_ref": "local-source-2026-0001",
  "event_type": "source.attestation",
  "payload_hash": "sha256-hex",
  "local_signature": {
    "alg": "Ed25519",
    "kid": "local-vault-key-epoch",
    "signature": "hex-encoded-signature"
  }
}

Encrypted Spool

Der Spool bewahrt Events während Network Outages. Replay ist geordnet und idempotent: dieselbe Source Reference und derselbe Body können retried werden, aber changed Content für dieselbe Source Reference wird abgelehnt.

State	Bedeutung
`queued`	Lokal gespeichert und wartet auf Relay.
`relaying`	Outbound Request läuft.
`receipted`	Attesto gab ein Proofstream Receipt zurück.
`conflict`	Source Reference wurde mit anderem canonical Content replayed.

Security Model

Für Relay Mode ist keine inbound Internet Route erforderlich.
Connector Credentials bleiben an der Customer Edge encrypted.
Relay Endpoints lehnen Replay Conflicts und tampered Envelopes ab.
Revocation fails closed: eine revoked Installation kann keine accepted Events weiter relayen.

Customer Witness Mode

Wenn aktiviert, kann Local Vault monotonic Checkpoints für seine Tenant Streams signieren. Eine 2-of-3 Policy kann Attesto-operated, customer-operated und Assurance Witness Statements kombinieren, sodass kein einzelner Service als einzige Source of History behandelt wird.

Im Witness Mode signiert Local Vault Checkpoint Statements nur, wenn sie den last accepted Checkpoint für den Tenant Stream erweitern. Ein Conflict erzeugt Fork Visibility auf Kundenseite.

Witness checkpoint statements werden an POST /v2/local-vault/installations/{installation_id}/witness/checkpoints gesendet und nur akzeptiert, wenn die installation enabled, auf den Tenant scoped und für den Stream monotonic ist.

Witness Command

Nutzen Sie den Operator Command, um ein monotonic checkpoint statement zu signieren oder fork evidence für einen conflicting checkpoint zurückzugeben. Der Command gibt nur öffentliches Receipt/Fork-Material aus; er druckt niemals den private signing key.

attesto-local-vault --witness-db /var/lib/attesto/local-vault-witness.sqlite3 \
  witness-checkpoint \
  --tenant-id ten_... \
  --stream-id str_... \
  --checkpoint-id chk_... \
  --checkpoint-seq-no 42 \
  --checkpoint-hash "$CHECKPOINT_HASH" \
  --previous-checkpoint-hash "$PREVIOUS_CHECKPOINT_HASH"

Provenance Mode (Attesto 3)

Local Vault 2.x läuft in einem von drei Modi, umgeschaltet mit attesto-local-vault mode --set legacy-relay|provenance|shadow. legacy-relay ist der Relay-Ablauf oben. Im provenance Mode baut der Vault pro Asset eine Capsule mit seinem gepinnten Rust Edge Core, führt die aktivierten Provider in der Provider Sandbox aus (AttestoMark Image, Audio und Video, C2PA) oder als gemessene Daemons (das Inference Gateway, das AttestoMark Text trägt), wertet die Multi-Signal-Policy aus, hält die Capsule im verschlüsselten lokalen Capsule Store und relayt einen ATTESTO-PROVENANCE-001-Envelope, der nur Commitments trägt: das Subject Commitment, die Capsule Root, die Claims-, Evidence- und Policy-Results-Roots, die Key-ID der Installation, ihre signierte Assurance-Stufe und, auf L1/L2, eine Attestation Reference. Roher Inhalt, Prompts, Dateinamen und Provider-Ausgaben verlassen den Host nie; die Plattform kann keine Capsule zurückgeben, weil sie nie eine hält. shadow betreibt beide Lanes für eine Migration, gesteuert über attesto-local-vault migration status|advance|roll-back|cutover-evidence; ein --force gibt es bewusst nicht.

attesto-local-vault mode --set provenance
attesto-local-vault provenance self-test
attesto-local-vault provenance relay-loop

Der Vault relayt an POST /v2/local-vault/installations/{installation_id}/provenance-events, den Pfad, den das Installationsobjekt als provenanceEndpointPath ankündigt; die Ed25519-Signatur des Envelopes ist das Credential. Die Plattform antwortet mit dem Proofstream Receipt plus einem provenanceAck. Der Stream muss ein Provenance Stream sein, angelegt mit POST /v2/provenance/streams unter einer Witness Policy, die zuvor mit PUT /v2/tenant/witness/policies/{policy_id} deklariert wurde; der API-Leitfaden listet jede Route.

Assurance-Stufen und Hardware Custody

Stufe	Voraussetzung	Was die Plattform verifiziert
`L0`	Ein Software-Schlüssel (Standard).	Die Ed25519-Signatur.
`L1`	Derselbe Ed25519-Schlüssel in einem PKCS#11-Token, nicht extrahierbar.	Ein `pkcs11-key-custody` Attestation Record, signiert mit dem Schlüssel.
`L2`	L1 plus ein TPM-2.0-Quote über die Messung des Vaults: Vault-Version, Edge-Core-Prüfsumme, Provider Manifests und Signing Key.	Die Signatur des Quotes, seine Bindung an den Measurement Digest und den Attestation Key.
`L3`	Wird nie von einem Vault signiert.	Vom Verifier aus `L2` plus einem erreichten Witness Quorum auf dem umgebenden Checkpoint abgeleitet; Anchoring hebt nie eine Stufe an.

Der Signaturalgorithmus ändert sich zwischen den Stufen nicht. Ein Attestation Record (ATTESTO-VAULT-ATTESTATION-001) wird unter POST /v2/local-vault/installations/{installation_id}/attestations registriert; die Plattform verifiziert ihn und lehnt einen L1/L2-Envelope ab, den sie nicht belegen kann. L2 bedeutet nicht, dass der Host nicht kompromittiert werden kann: es bedeutet, dass ein TPM eine Aussage darüber signiert hat, was der Vault beim Start gemessen hat. Die PKCS#11- und TPM-2.0-Provider werden in der Continuous Integration gegen SoftHSM2 und swtpm geprüft, Software-Doubles dieser Schnittstellen; noch keine Produktionsinstallation hat mit Hardware signiert, und die First-Party-Rollout-Installation signiert mit einem Software-Schlüssel auf L0.

Key Lifecycle und Revocation

Das Widerrufen einer Installation (DELETE /v2/tenant/local-vault/installations/{installation_id}) hält die Plattformuhr als Widerrufszeitpunkt fest und veröffentlicht ihn unter GET /v2/local-vault/installations/{installation_id}/key-status, das bewusst öffentlich ist, damit ein Verifier, der kein Benutzer des Tenants ist, Nachweise offline prüfen kann. Revocation wird gegen die Platform Receipt Time jedes Events bewertet, nie gegen das vom Vault behauptete occurred_at, mit inklusiver Grenze; ein Claim, der vor dem Widerruf liegt, während das Receipt es nicht tut, wird mit suspect_backdated markiert. Ein Verifier Bundle über einen Provenance Stream trägt den Key Lifecycle zum Zeitpunkt des Bundle-Baus, ein späterer Widerruf ist also nicht im Bundle.

Rollout-Stand

Die Provenance Lane ist in der Produktion aktiv. Phase A des kontrollierten Rollouts lief am 2026-08-23 in der Produktion mit einem First-Party-Tenant: 15 Receipts, 0 Privacy-Canary-Treffer über die HTTP-Bodies, die Backend-Logs und 92 Datenbanktabellen, der Stream mit Checkpoint und Witness. Der Lane-basierte Rollback, der neue Events in die Legacy Lane zurückführt und nichts umschreibt, wurde gegen die Produktion geprobt. Die Phasen B bis D, einschließlich Design-Partner-Migrationen und der Standardumstellung neuer Setups auf Provenance, haben nicht begonnen.

Offline und Online Modes

Online relay: Events werden schnell signed, spooled, relayed und receipted.
Temporary offline relay: Events bleiben encrypted im local spool, bis outbound network zurückkehrt.
Witness online: Checkpoint Statements werden gemäß Policy verifiziert und signiert.
Witness unavailable: Quorum kann verzögert werden; Receipts bleiben unabhängig von Witness Availability.