tpt-citadel

Rust

Zero-trust secrets vault in Rust — encryption-as-a-service, dynamic credential rotation, Shamir's Secret Sharing key management, and a cryptographically signed immutable audit ledger for HIPAA/GDPR/SOC2-grade compliance.

0 stars0 forks0 watchers

Languages

Rust100.0%
README

tpt-citadel — Zero-Trust Vault

tpt-citadel is a Rust, Vault-style "Zero-Trust Vault" for HIPAA/GDPR/SOC2-relevant workloads. It provides:

  • Shamir-sealed secrets store — the master key is split into N shards; a quorum is required to unseal, and the key is zeroized from memory on seal.
  • Hardware-enclave abstraction — software fallback, plus AWS Nitro / Intel SGX enclave backends (transport/runtime stubbed; see crates/crypto/src/attest.rs).
  • Dynamic database credentials — short-lived, TTL'd DB roles with automatic revocation on expiry (background sweeper) and root-credential rotation.
  • Encryption-as-a-Service (EaaS) — named, non-exportable keys with randomized or convergent (searchable) encryption modes and per-service rate limiting, for app-side PII encryption.
  • Path-based policy / AuthZ over tpt-identity mTLS identity, with short-lived scoped vault tokens.
  • Immutable audit ledger — SHA-256 hash-chained + Merkle-tree log with HMAC-signed checkpoints for tamper-evidence.

See COMPLIANCE.md, THREAT_MODEL.md, and docs/DEPLOYMENT.md for the compliance story and a step-by-step deploy.

Build & test

cargo build --workspace
cargo test  --workspace

Fuzz targets live in the standalone fuzz/ cargo-fuzz workspace:

cargo +nightly fuzz run policy_parser -- -max_total_time=60
cargo +nightly fuzz run api_hex_decode  -- -max_total_time=60

Run

tpt-citadel serve            # dev mode (see below)

Dev vs. production mode

tpt-citadel has two run modes (RunMode in crates/core/src/config.rs):

  • Dev (run_mode = "dev", the default) is for local development only. It binds a wildcard admin policy to the anonymous identity, signs audit checkpoints with a fixed dev key, uses a hardcoded root DB password, and issues credentials against an in-memory mock database. Never expose dev mode to a real network.

  • Production (run_mode = "production", or CITADEL_MODE=production) fails loudly at boot if it would fall back to any insecure default:

    • CITADEL_CHECKPOINT_KEY — HMAC key for signing audit checkpoints (no source literal).
    • CITADEL_ROOT_DB_PASSWORD — root DB password (no "change-me-in-production").
    • The postgres feature and CITADEL_POSTGRES_DSN — a real database connector (no MockDbConnector).

    In production, anonymous carries no policy, so every identity must be bound to explicitly-scoped policies via tpt-identity mTLS.

Security model notes

  • Every sensitive route enforces a required capability (crates/api/src/routes.rs), resolved from a bearer vault token (production) or the x-actor header (dev).
  • Tokens can only be scoped down to policies the caller's identity already holds — they cannot grant new capabilities.
  • GET /audit/verify reports hash_chain_ok, merkle_ok (compared against the latest signed checkpoint), and checkpoints_ok. The audit ledger is persisted through the configured KeystoneDb backend.

Status: the cryptographic and audit design is sound; the wiring gaps described in REVIEW.md have been remediated. The enclave attestation signature check is still a structural stub (verify_cose_signature_ unverified_stub) and must be completed before any EnclaveMode::Nitro deployment — do not treat an enclave measurement as verified until then.