CipherPlate — Internal architecture

The sidecar that ZorblaxCorp ships to every customer. This doc is the architectural reference for new engineers and for security auditors during diligence.

Layered design

  1. gRPC envelope layer (Rust, tonic 0.12.x). Receives client requests, validates against the policy file, attaches a request ID, and dispatches.
  2. Policy resolver (Rust). Resolves the request against policy.yaml. Decides algorithm, audit verbosity, and rate limit.
  3. Algorithm dispatcher (Rust + C FFI for FALCON / SPHINCS+ / ML-KEM via the Open Quantum Safe liboqs 0.11.0 bindings).
  4. Key custody (Rust). Either local-fs (default), HashiCorp Vault, or HSM-passthrough (PKCS#11 to a customer-provided HSM).
  5. Audit sink (Rust). Writes structured JSON Lines to one of: local file, S3-compatible object storage, or a customer Splunk HEC endpoint.

Crash and recovery

  • The sidecar runs with systemd's Restart=always on Linux; equivalents documented for other init systems.
  • Inflight operations are NOT replayed on restart — clients are expected to retry with the same request ID and CipherPlate dedupes.
  • The audit log is fsync'd per record on the Sovereign tier; per second on the lower tiers (configurable).

Threat model invariants

  • The sidecar trusts the local OS kernel and policy.yaml. It does NOT trust the application that calls it.
  • All algorithm calls go through the dispatcher; there is no fallback path to "raw OpenSSL." This is enforced at compile time via a feature flag locked in CI.
  • Key material never leaves the custody layer in plaintext. Operations are returned to the caller, but raw keys are unreachable through any public API.

Facts

  • Implementation language: Rust 1.78 (locked in CI)
  • C FFI dependency: liboqs 0.11.0
  • gRPC stack: tonic 0.12.x
  • Linter: clippy at warn(clippy::pedantic); CI fails on warning
  • Test suite: 1,847 tests, 94.3% line coverage as of 3.4.1 release
  • Median CI pipeline duration: 18 minutes