SecureGate Docs

Encryption hierarchy, Cloud HSM, MPC threshold signing, per-tenant data isolation, and zero-knowledge architecture

Encryption Hierarchy

SecureGate uses a four-level key hierarchy. Key material for the top level never leaves the HSM.

Cloud HSM (shared, FIPS 140-2 Level 3)
|
+-- Org Root Key (OEK) -- per org, stored in HSM
|   |                     never exported, all operations on-HSM
|   |
|   +-- Tenant Encryption Key (TEK) -- per tenant
|   |   |   wrapped by OEK, stored in KMS
|   |   |
|   |   +-- Customer CEK -- per customer (default: per-tenant)
|   |   |   wrapped by TEK
|   |   |   encrypts: face_embeddings, PII
|   |   |
|   |   +-- Session DEK -- ephemeral, derived from CEK
|   |       used for in-memory encrypt/decrypt
|   |       discarded on request completion
|   |
|   +-- MPC Signing Key -- threshold (3-of-5)
|       for wallet operations, document signing
|       key shares never recombined outside MPC nodes
|
+-- Platform Root Key -- wraps all OEKs
    only accessible via HSM quorum (break-glass)

Key Types

Key	Scope	Storage	Lifetime
OEK	Per org	HSM key slot	Permanent (rotatable)
TEK	Per tenant	KMS (wrapped by OEK)	Until tenant deletion
CEK	Per customer	KMS (wrapped by TEK)	Until customer deletion
DEK	Per request	Memory only	Single request

Deleting a tenant destroys the TEK. Without the TEK, all CEKs wrapped by it are unrecoverable, which makes all face embeddings and PII encrypted with those CEKs permanently unreadable. The data files can be left in place or deleted at leisure — the cryptographic destruction is what matters.

Cloud HSM

Property	Value
Provider	GCP Cloud HSM (or AWS CloudHSM)
Certification	FIPS 140-2 Level 3
Interface	PKCS#11 via Hanzo KMS
Isolation	Per-org key slots (CKA_ID scoped by org)
Key types	AES-256 (encryption), ECDSA P-256 (signing), RSA-4096 (wrapping)
Operations	OEK generation, TEK wrapping/unwrapping, signing

Key material never leaves the HSM. All cryptographic operations (generation, wrap, unwrap, sign) execute on the HSM hardware. Every operation is logged to an immutable audit trail.

MPC Threshold Signing

For operations requiring cryptographic signatures (document signing, wallet operations), SecureGate uses MPC threshold signing through Hanzo KMS.

StatefulSet: 5 replicas (mpc-0 through mpc-4)
Threshold: 3-of-5
Protocols: CGGMP21 (ECDSA/secp256k1), FROST (EdDSA/Ed25519)

Level	MPC Key	Use Case
Org	Root MPC key group (3-of-5)	Org-level signing, TEK wrapping
Tenant	Derived child key (BIP-32 style)	Tenant wallet, document signing
User	Optional shard holder	Self-custody, user co-signs

Key shares are never recombined outside the MPC nodes. LSS (Lagrangian Sub-group Sharing) enables resharing without key reconstruction — if a node is compromised, its share can be rotated without regenerating the entire key.

Per-Tenant Data Isolation

Database Isolation

Each tenant gets separate SQLite database files:

/data/tenants/\{tenant_id\}/
+-- securegate.db     <-- collections (events, rooms, cameras, attendees)
+-- embeddings.db     <-- sqlite-vec (512-d face vectors, CEK-encrypted)

There is no shared database between tenants. A query in tenant A's context cannot access tenant B's data because tenant B's data is in a different file, encrypted with a different TEK.

Object Storage Isolation

Face crops and enhanced images are stored in S3/R2 with per-tenant prefixes:

s3://securegate-data/\{tenant_id\}/crops/...
s3://securegate-data/\{tenant_id\}/enhanced/...

IAM policies restrict access to the tenant's prefix. Even if a tenant's S3 objects are accessed, face crops are encrypted with the tenant's CEK.

Network Isolation

All inter-service communication is over mTLS within the K8s cluster network. Tenant context flows via HTTP headers (X-Org-Id, X-Tenant-Id) injected by the gateway after JWT validation. Backend services trust these headers (internal network only).

Zero-Knowledge Architecture

No party can unilaterally access customer data:

Actor	Can Access
Platform operators	Cannot decrypt. No CEKs held. HSM operations audited. Break-glass requires multi-officer quorum + WORM audit trail.
Org admins	Can manage tenant TEKs via KMS API. Cannot access individual CEKs. TEK unwrap requires `org:admin` IAM role.
Tenant admins	Can manage their tenant's CEKs via KMS API. CEK unwrap requires `tenant:admin` IAM role.
Customers	Data encrypted with their CEK. CEK unlocked by IAM session.
Legal/law enforcement	Requires KMS escrow flow: court order triggers cooperative reconstruction (org officer + regulator shard). Time-limited break-glass token. WORM audit logged.

Cross-Customer Isolation

Customer A's CEK cannot decrypt Customer B's data. Even if the entire tenant database is exfiltrated, each customer's embeddings are encrypted with a unique CEK. Compromising one customer's key does not compromise any other customer.

SSO Integration

When SSO is enabled (Okta, Azure AD, etc.):

Auth goes through the org's IdP via SAML/OIDC.
IAM validates the assertion and issues a JWT.
The CEK is unlocked by the IAM session, not by the user's password directly.
SSO only changes the authentication path — the encryption hierarchy is unchanged.

Security Hardening Checklist

Every production service implements:

Satschel IAM JWT validation (via Gateway or direct JWKS)
Org-scoped data queries (tenant isolation via owner claim)
Argon2id password hashing (never plaintext, never MD5/SHA)
Parameterized queries (no string interpolation in SQL)
Input validation at service boundaries
Rate limiting (per-endpoint via Gateway, per-IP via Ingress)
Structured logging (no secrets in logs)
Health checks (readiness + liveness probes)
Resource limits (CPU + memory)
Secrets via KMS (never in env files committed to git)
CORS restricted to explicit origins

Security