Security Architecture
Qpher is built from the ground up as a security product. Every layer of the platform enforces strict boundaries around your cryptographic keys and data. This page explains the key architectural decisions that keep your keys safe.
Your private keys never leave our secure enclave. All cryptographic operations happen server-side, inside the KMS-Orchestrator boundary.
Service Diagramâ
Qpher uses a microservices architecture. Each service has a single responsibility, and communication between services is authenticated with service tokens.
The KMS-Orchestrator is the only service that can access private key material. The KEM Service and Signature Service send operation requests to the KMS-Orchestrator and receive results (ciphertexts, signatures) back. They never see the underlying keys.
Gateway Auth Pipelineâ
Every API request passes through a 7-stage authentication and authorization pipeline before reaching any backend service.
| Stage | What Happens | On Failure |
|---|---|---|
| 1. Skip check | Health and metrics endpoints bypass auth | -- |
| 2. Extract API key | Read the x-api-key header | 401 Missing API key |
| 3. Resolve tenant | Hash the key and look up the tenant | 401 Invalid API key |
| 4. Inject context | Attach X-Tenant-ID and X-Request-ID headers | -- |
| 5. Rate limit | Check per-tenant rate limits via Redis | 429 Rate limit exceeded |
| 6. Policy check | Evaluate access rules in the Policy Engine | 403 Access denied |
| 7. Route | Forward the request to the appropriate service | -- |
No request reaches a backend service without passing all seven stages.
Private Keys Stay in the KMS-Orchestratorâ
The most important security boundary in Qpher is the KMS-Orchestrator enclave:
- Private keys are generated inside the KMS-Orchestrator and never leave it.
- Keys are encrypted at rest using AES-256-GCM before being written to disk.
- The database stores a handle (a reference path), not the key bytes themselves.
- There is no API endpoint to export or download a private key.
When you call /kem/encrypt or /signature/sign, the KEM Service or Signature Service
forwards your request to the KMS-Orchestrator. The KMS-Orchestrator loads the private key,
performs the operation, and returns only the result.
Tenant Isolationâ
Qpher is a multi-tenant platform. Every tenant's data is strictly separated through four layers of isolation:
- Repository layer -- Every database query includes a
tenant_idfilter. There is no way to query data across tenants. - Database constraints -- Unique indexes are scoped to
(tenant_id, ...), preventing data collisions between tenants. - Context propagation -- The gateway injects
X-Tenant-IDinto every downstream request. Services never derive the tenant ID from user input. - Gateway enforcement -- The API key lookup determines the tenant. A tenant can only access resources associated with their own API key.
Even if a bug existed in a service, database constraints and repository-level filtering prevent one tenant from accessing another tenant's keys or data.
Fail-Closed Designâ
Qpher follows a fail-closed philosophy: when something goes wrong, the system denies access rather than allowing it.
| Scenario | Behavior |
|---|---|
| Policy Engine is unavailable | All requests are denied (503) |
| Tenant lookup fails | Request is rejected (401) |
| Rate limit service is down | Requests are denied, not allowed through |
| Missing configuration at startup | Service refuses to start |
| PQC cryptographic operation fails | Error is returned, never falls back to weaker crypto |
This approach means brief outages may temporarily block requests, but it guarantees that a failure condition never silently weakens your security posture.
What's Nextâ
- Non-Exportable Keys -- How private keys are protected
- Encryption at Rest -- AES-256-GCM key storage
- Zero Trust -- Per-request authorization
- Compliance -- Standards and certifications