Enterprise Edge

Local Vault

Local Vault est un composant customer edge outbound-only pour connector secret storage, source attestation signing, offline spooling, event relay, optional customer-side witness operation et, dans Local Vault 2.x, le provenance mode Attesto 3, où les capsules restent sur l'hôte edge et seuls les commitments atteignent la plateforme. Ce n'est pas HashiCorp Vault.

Responsibilities

Encrypt les connector credentials localement.
Signer les source attestations avant relay.
Spool les events pendant les network outages.
Replay les spooled events dans l'ordre avec idempotency.
Opérer comme customer-side witness lorsque la tenant policy l'active.

La provenance locale des images utilise le provider isolé et le registre keyed chiffré décrits dans le guide AttestoMark Image.

Installer et exécuter

Installez Local Vault sur l’hôte edge contrôlé par le client. Les coordonnées runtime peuvent venir de flags ou variables d’environnement, mais les signing keys, spool encryption keys et connector credentials doivent venir du secret manager local de déploiement. Ne les placez pas dans l’historique shell, la configuration frontend ou les docs Attesto.

L'installation recommandée est le canal conteneur signé : un installer en une commande récupère l'image du vault épinglée par digest, crée les répertoires state et config et installe un wrapper attesto-local-vault pour que chaque commande CLI s'exécute de façon transparente dans le conteneur. Docker est requis (Docker Desktop sur macOS et 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

Sur macOS et Windows, le vault et sa provider sandbox Linux-only s'exécutent dans la VM Linux de Docker Desktop ; les garanties d'isolation s'appliquent à l'intérieur de cette VM. Un processus natif macOS ou Windows ne les porterait pas — c'est précisément pourquoi les installers sont des wrappers de conteneur. Désinstallation : supprimez le wrapper, supprimez l'image avec docker rmi et, seulement si l'évidence n'est plus nécessaire, supprimez le répertoire state — install.sh --help affiche les commandes exactes.

Sur macOS et Linux, le même wrapper conteneur s'installe aussi via Homebrew. Les hashes de la formula sont copiés tels quels depuis le manifest de canal signé par cosign et Homebrew les impose à chaque installation ; les caveats répètent l'exigence Docker et la note d'honnêteté ci-dessus :

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

Sur les hôtes Debian/Ubuntu et Fedora/RHEL, des packages natifs installent le même wrapper en /usr/bin/attesto-local-vault, exécutant la même image épinglée par digest. Le deb dépend d'un moteur compatible Docker (docker-ce | docker.io | podman-docker) ; rpm ne peut pas exprimer cette alternative entre dépôts et se contente donc de recommander docker — le moteur reste requis à l'exécution. Vérifiez le manifest signé, contrôlez le hash du package, puis installez :

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

Le canal wheel Python reste disponible pour les hôtes qui exécutent le vault nativement sous Linux :

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

Contrôle de santé

Exécutez attesto-local-vault doctor après le bootstrap et pendant le troubleshooting opérateur. Le doctor vérifie la configuration, les secrets locaux, les permissions de secrets.env, le readback du spool chiffré, les règles HTTPS de relay URL, l'accessibilité du backend, le server clock skew, les en-têtes serveur Date invalides et la dead-letter depth. Les failures retournent un code non nul. Les warnings gardent le spool utilisable mais doivent être revus par l'opérateur.

attesto-local-vault doctor

Enrollment

Un tenant owner ou admin crée un enrollment token court avec POST /v2/tenant/local-vault/enrollment-tokens. L'edge host échange ce token via POST /v2/local-vault/enroll et reçoit l'installation metadata plus la credential nécessaire au outbound relay. Les enrollment tokens sont single-use; Attesto ne stocke que leur hash après création.

Accusé de livraison

Local Vault marque un élément delivered uniquement quand Attesto renvoie un receipt JSON 2xx avec localVaultAck.envelopeHash, stream binding et canonical event id correspondants. Un proxy 2xx, malformed body, mismatched receipt ou revoked installation reste une livraison échouée soumise à retry ou dead-letter policy.

Outbound relay flow

La customer source crée un attestation event.
Local Vault signe et stocke l'event dans l'encrypted spool.
Local Vault relaie l'event vers POST /v2/local-vault/installations/{installation_id}/events sur https://verify.attesto.eu.
Attesto retourne le Proofstream receipt.
Local Vault enregistre receipt state et conserve retry metadata jusqu'à completion de delivery.

{
  "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

Le spool préserve les events pendant les network outages. Le replay est ordonné et idempotent: la même source reference et le même body peuvent être retried, mais changed content pour la même source reference est rejeté.

State	Signification
`queued`	Stocké localement et en attente de relay.
`relaying`	Outbound request en cours.
`receipted`	Attesto a retourné un Proofstream receipt.
`conflict`	Source reference rejouée avec un canonical content différent.

Security model

Aucune inbound internet route n'est requise pour relay mode.
Les connector credentials restent encrypted au customer edge.
Les relay endpoints rejettent replay conflicts et tampered envelopes.
Revocation fail closed: une revoked installation ne peut pas continuer à relay accepted events.

Customer witness mode

Lorsqu'il est activé, Local Vault peut signer des monotonic checkpoints pour ses tenant streams. Une policy 2-of-3 peut combiner des statements Attesto-operated, customer-operated et assurance witness afin qu'aucun service unique ne soit traité comme seule source of history.

En witness mode, Local Vault signe les checkpoint statements seulement lorsqu'ils étendent le last accepted checkpoint du tenant stream. Un conflict crée fork visibility côté client.

Les witness checkpoint statements sont soumis à POST /v2/local-vault/installations/{installation_id}/witness/checkpoints et acceptés uniquement lorsque l'installation est enabled, scoped au tenant et monotonic pour le stream.

Commande witness

Utilisez la commande opérateur pour signer un monotonic checkpoint statement ou renvoyer fork evidence pour un checkpoint conflictuel. La commande affiche uniquement du matériel public receipt/fork; elle n’affiche jamais la 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 fonctionne dans l'un de trois modes, commutés avec attesto-local-vault mode --set legacy-relay|provenance|shadow. legacy-relay est le flux de relay ci-dessus. En mode provenance, le vault construit une capsule par asset avec son Rust edge core épinglé, exécute les providers activés dans la provider sandbox (AttestoMark Image, Audio et Video, C2PA) ou comme daemons mesurés (l'inference gateway qui porte AttestoMark Text), évalue la policy multi-signaux, conserve la capsule dans le capsule store local chiffré, et relaie une envelope ATTESTO-PROVENANCE-001 qui ne porte que des commitments : le subject commitment, la capsule root, les roots claims, evidence et policy-results, le key id de l'installation, son niveau d'assurance signé et, en L1/L2, une attestation reference. Le contenu brut, les prompts, les noms de fichiers et la sortie des providers ne quittent jamais l'hôte; la plateforme ne peut pas renvoyer une capsule parce qu'elle n'en détient jamais. shadow fait tourner les deux lanes pour une migration pilotée par attesto-local-vault migration status|advance|roll-back|cutover-evidence; il n'existe pas de --force, par conception.

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

Le vault relaie vers POST /v2/local-vault/installations/{installation_id}/provenance-events, le chemin que l'objet installation annonce comme provenanceEndpointPath; la signature Ed25519 de l'envelope est le credential. La plateforme répond avec le receipt Proofstream plus un provenanceAck. Le stream doit être un provenance stream créé avec POST /v2/provenance/streams sous une witness policy déclarée au préalable avec PUT /v2/tenant/witness/policies/{policy_id}; le guide API liste chaque route.

Niveaux d'assurance et hardware custody

Niveau	Prérequis	Ce que la plateforme vérifie
`L0`	Une clé logicielle (par défaut).	La signature Ed25519.
`L1`	La même clé Ed25519 détenue dans un token PKCS#11, non extractible.	Un attestation record `pkcs11-key-custody` signé par la clé.
`L2`	L1 plus un quote TPM 2.0 sur la mesure du vault : version du vault, checksum de l'edge core, provider manifests et signing key.	La signature du quote, sa liaison au measurement digest et l'attestation key.
`L3`	Jamais signé par un vault.	Dérivé par le vérificateur de `L2` plus un witness quorum atteint sur le checkpoint englobant; l'anchoring ne promeut jamais un niveau.

L'algorithme de signature ne change pas entre les niveaux. Un attestation record (ATTESTO-VAULT-ATTESTATION-001) est enregistré sur POST /v2/local-vault/installations/{installation_id}/attestations; la plateforme le vérifie et refuse une envelope L1/L2 qu'elle ne peut pas étayer. L2 ne signifie pas que l'hôte ne peut pas être compromis : cela signifie qu'un TPM a signé une déclaration sur ce que le vault a mesuré au démarrage. Les providers PKCS#11 et TPM 2.0 sont exercés en intégration continue contre SoftHSM2 et swtpm, des doublures logicielles de ces interfaces; aucune installation de production n'a encore signé avec du matériel, et l'installation du rollout first-party signe avec une clé logicielle en L0.

Key lifecycle et révocation

Révoquer une installation (DELETE /v2/tenant/local-vault/installations/{installation_id}) enregistre l'horloge de la plateforme comme instant de révocation et le publie sur GET /v2/local-vault/installations/{installation_id}/key-status, public à dessein pour qu'un vérificateur qui n'est pas un utilisateur du tenant puisse contrôler les preuves hors ligne. La révocation est évaluée contre le platform receipt time de chaque événement, jamais contre le occurred_at revendiqué par le vault, avec une borne inclusive; une revendication antérieure à la révocation alors que son receipt ne l'est pas reçoit le drapeau suspect_backdated. Un verifier bundle sur un provenance stream porte le key lifecycle du moment de sa construction, une révocation ultérieure n'y figure donc pas.

État du déploiement

La provenance lane est active en production. La phase A du rollout contrôlé a été exécutée en production le 2026-08-23 avec un tenant first-party : 15 receipts, 0 détection de privacy canary sur les bodies HTTP, les logs backend et 92 tables de base de données, le stream checkpointé et witnessed. Le rollback par lane, qui renvoie les nouveaux événements vers la legacy lane et ne réécrit rien, a été répété contre la production. Les phases B à D, y compris les migrations de design partners et le passage par défaut des nouvelles configurations à la provenance, n'ont pas commencé.

Modes offline et online

Online relay: events sont signed, spooled, relayed et receipted rapidement.
Temporary offline relay: events restent encrypted dans le local spool jusqu'au retour de l'outbound network.
Witness online: checkpoint statements sont vérifiés et signés selon policy.
Witness unavailable: quorum peut être retardé; receipts restent indépendants de witness availability.