Security Architecture

Security Design

The security controls built into QUORUM, as implemented at code baseline e9c2cf7. QUORUM is deployed in each institution's environment, so network, host and operational controls are set up with that institution. No independent penetration test or certification has been performed yet.

Signatures and Keys

Every audit-ledger entry is signed twice — with Ed25519 and with ML-DSA-65 (NIST FIPS 204) — and both signatures must verify. ML-DSA-65 comes from the Rust fips204 crate compiled to WebAssembly; every WebAssembly module is hash-pinned and checked before it is loaded.

  • ML-DSA-65: public key 1,952 bytes, signature 3,309 bytes, NIST security category 3.
  • In production, the master HMAC key and the ML-DSA-65 key pair are decrypted only inside a measured AWS Nitro Enclave; the application never sees them and will not start in production without the enclave. This is implemented but not yet exercised on Nitro hardware.
  • AWS KMS (HMAC only) is supported as an alternative provider. There is no PKCS#11 or Thales HSM integration.

Tamper-Evident Audit Ledger

Each decision is recorded before it is returned and sealed every few seconds under a Merkle root into a hash-chained ledger entry. A scheduled scan every 15 minutes checks every link and signature and alerts on any break; it never repairs or re-signs.

  • Merkle inclusion and decision proofs can be verified by a third party with SHA-256 and the published public keys.
  • When a timestamp authority is configured, ledger roots are timestamped under RFC 3161.
  • The ledger is stored in PostgreSQL. It is tamper-evident, not immutable; institutions should restrict write access and archive anchored roots outside the database.

Continuous Identity Verification

On authenticated institutional requests, QUORUM re-scores behavioural signals sent by the browser SDK against the user's running baseline (Welford's method). By default, a score of 55 adds a warning header and 82 blocks the request as identity drift. A client that normally sends signals and suddenly stops is given a higher risk floor.

Operator Access

  • Role-based operator access (platform_admin, security_admin) with WebAuthn step-up for privileged actions.
  • FROST threshold approvals (RFC 9591) with distributed key generation for rule promotion and user reinstatement; each approval names one action and target and is used once.
  • An optional single-use challenge ("atomic handshake") binds sensitive institutional calls to a short-lived state held in Redis, to frustrate replay.
  • Secrets can be loaded from HashiCorp Vault; production Vault connections require a pinned CA certificate.
  • Insider-threat sandbox: a security_admin can route a flagged console account to decoys for 1–168 hours; changes are audited and API traffic is never affected.

Container Hardening

  • Multi-stage build from a minimal Alpine base; only compiled output and runtime assets reach the production image.
  • Runs as a dedicated non-root user (UID 1001).
  • Node.js permission model with explicit filesystem allow-lists; writes limited to /tmp, /app/storage and /app/.healer.
  • Container health check on /health every 15 seconds.

Supply Chain

  • Software bill of materials for 837 components (CycloneDX and Cargo metadata). No GPL or AGPL components.
  • Rust crates checked with cargo-deny for licences, advisories and sources; full git history scanned for secrets with gitleaks.
  • npm audit reports 25 advisories, all in OpenTelemetry packages and assessed as not exploitable in QUORUM's configuration; an upgrade is scheduled.
  • A CI workflow for lockfile, audit and secret checks is defined in the repository; hosted CI and signed build provenance are not yet in place.

Runtime Monitoring

QUORUM ships Falco rules for its container (unexpected file writes, outbound connections, shells, privilege changes and sensitive-file reads), plus OpenTelemetry tracing and Prometheus metrics. Alert routing and on-call are configured with each institution's operations team.

Perimeter

  • Per-institution IP blocking enforced on API requests and written to the ledger.
  • Honeypot paths and response tarpits (5 s / 30 s delays) for scanners — application-level, not a network tarpit.
  • JA3 TLS fingerprints compared with the claimed user agent.
  • A global rate limiter on the API runs before tenant resolution.
  • The in-process request scanner is advisory by default; a dedicated edge WAF (Cloudflare, AWS WAF, ModSecurity/Coraza) is expected in front of QUORUM in production.

Security Contact

To report a vulnerability or arrange an institutional security assessment, email [email protected].