Threat Model
This document describes what Qpher protects, what it does not, and where the trust boundaries lie. It is intended for security teams evaluating Qpher for production use.
What Qpher Protects
Primary Threat: Harvest Now, Decrypt Later (HNDL)
Nation-state adversaries and well-funded attackers are intercepting encrypted traffic today with the expectation that quantum computers will eventually break classical encryption (RSA, ECC). This attack pattern is known as Harvest Now, Decrypt Later (HNDL).
Qpher mitigates HNDL by providing NIST-standardized post-quantum algorithms:
- ML-KEM-768 (FIPS 203) for key encapsulation — shared secrets are quantum-resistant
- ML-DSA-65 (FIPS 204) for digital signatures — signatures remain verifiable in the quantum era
- X-Wing (X25519 + ML-KEM-768) and Composite ML-DSA (ECDSA P-256 + ML-DSA-65) for hybrid defense-in-depth
These algorithms are recommended by NIST (IR 8413) and NSA (CNSA 2.0 Suite) for immediate adoption. Data encrypted with Qpher today remains safe even if a cryptographically relevant quantum computer is built in the future.
Data at Rest Protection
Qpher's KEM-DEM scheme (Kyber768 + HKDF-SHA256 + AES-256-GCM) produces a quantum-safe shared secret. You use this shared secret to encrypt data at rest in your own environment. The encrypted data remains quantum-resistant regardless of where it is stored.
Digital Signature Integrity
Dilithium3 (ML-DSA-65) signatures created through Qpher will remain verifiable even after quantum computers become available. Use cases include document signing, software supply chain integrity, audit log tamper-proofing, and contract non-repudiation.
Key Lifecycle Security
Qpher manages the full lifecycle of PQC keys — generation, rotation, retirement, and archival. Every key has an explicit version number. Every cryptographic operation requires a specific key version. This prevents silent key confusion and provides a complete audit trail of all key operations.
Trust Boundaries
Trust Boundary 1: Customer Environment
Your plaintext data stays in your environment. When using the KEM API, the SDK sends a KEM request to Qpher and receives a quantum-safe shared secret. The SDK then uses this shared secret locally with AES-256-GCM to encrypt your data. Plaintext never leaves your environment in this mode.
If you use the full-service /kem/encrypt endpoint, the plaintext is sent to
Qpher over TLS for server-side encryption. Choose the mode that matches your trust
requirements.
Trust Boundary 2: Qpher Platform
- Private keys are generated inside the KMS-Orchestrator and never leave it
- No API endpoint can export or return private key material
- Keys are encrypted at rest with AES-256-GCM and referenced by handle, not by value
- 4-layer tenant isolation ensures strict separation: Repository filters, DB constraints, context propagation, and gateway enforcement
- All key operations are recorded in a SHA-256 hash chain with Dilithium-signed anchors
Trust Boundary 3: Transport Layer
- Cloud Run manages TLS 1.3 termination for all API traffic
- Google Cloud supports PQ hybrid TLS (X25519Kyber768) on select services
- Qpher does not provide its own TLS layer — transport security is delegated to the cloud provider
What Qpher Does NOT Protect
The following items are explicitly outside Qpher's protection scope. Understanding these boundaries is essential for a complete security evaluation.
Transport Layer Attacks
Qpher does not provide a PQC-TLS proxy. Transport layer security is handled by Cloud Run's TLS 1.3 implementation. If your threat model includes quantum attacks on the transport layer, consider layering a PQ-TLS-capable CDN (such as Cloudflare, which supports X25519Kyber768) in front of your application.
Note: HNDL attacks primarily target data at rest — encrypted archives, database dumps, stored ciphertexts. Transport-layer interception is a separate concern that TLS addresses.
Client-Side Security
Qpher does not protect your application code, your server environment, or your API key storage. Securing your API keys, managing environment variables, and hardening your runtime environment are your responsibility.
The shared secret returned by the KEM API exists in your application's memory. Its lifetime and secure erasure are governed by your runtime environment and coding practices.
Real-Time Communication Encryption
Qpher is optimized for data-at-rest encryption and digital signatures. It is not designed for real-time messaging encryption (e.g., end-to-end encrypted chat). If you need PQC protection for real-time communication, consider protocols like Signal's PQXDH.
Availability Guarantees
Qpher follows a fail-closed design — if the platform is unavailable, cryptographic operations will fail rather than fall back to weaker algorithms. This is a deliberate security decision, but it means your application must handle temporary unavailability gracefully.
Verification and Auditability
Qpher provides mechanisms for you to verify the platform's security claims:
| Claim | How to Verify |
|---|---|
| Private keys are non-exportable | No API endpoint returns private key material. Verify by inspecting the API Reference. |
| All operations are audited | Audit log API (Growth+ plans) returns hash-chained entries. Each entry references the previous entry's hash. |
| Audit logs are tamper-evident | Periodic anchors are signed with Dilithium3. Verify the signature chain independently. |
| Tenant isolation | Each API key resolves to exactly one tenant. Cross-tenant requests return 403 or 404. |
| Fail-closed behavior | If the Policy Engine is unreachable, all requests return 503. Test by observing behavior during planned maintenance windows. |
Comparison: Qpher vs Other Approaches
| Approach | HNDL Protection | Key Management | Compliance | Complexity |
|---|---|---|---|---|
| Qpher | NIST Level 3 | Full lifecycle | Audit trails | Low |
| DIY liboqs | NIST Level 3 | Self-managed | Self-built | High |
| Cloud KMS (PQC) | Not yet available | Provider-managed | Provider certs | Medium |
| Do Nothing | Vulnerable | N/A | Non-compliant | None |
Frequently Asked Security Questions
If I can securely reach your API, why do I need you?
Qpher's value is not encryption itself — it is PQC key infrastructure. OpenSSL is free, yet AWS KMS generates billions in annual revenue. The reason: enterprises need managed key lifecycle (generation, rotation, retirement, archival), audit trails, multi-tenant isolation, compliance reporting, and algorithm migration — not just cryptographic primitives.
Using liboqs directly gives you the algorithms. Qpher gives you the infrastructure around those algorithms: versioned keys, rotation without downtime, tamper-evident audit logs, per-tenant policy enforcement, and a path to compliance.
How do I know you are not saving my keys?
The architecture makes unauthorized key access structurally difficult:
- Private keys exist only inside the KMS-Orchestrator. No other service can access them.
- No API endpoint returns private key material. This is enforced at the code level.
- Keys are encrypted at rest with AES-256-GCM and referenced by file handle, not by value.
- All key operations are recorded in a hash chain with Dilithium-signed anchors, providing tamper-evident audit logs.
- SOC 2 Type II audit (roadmap) will provide third-party verification of these controls.
What if TLS is broken by quantum computers?
Qpher protects data at rest, not transport. The HNDL threat model targets encrypted data that is stored long-term — database dumps, file archives, backup tapes. This is exactly what Qpher's KEM-DEM scheme protects.
Transport layer security is handled by TLS 1.3 (managed by Cloud Run). Google Cloud already supports PQ hybrid TLS (X25519Kyber768) on select services, and this coverage is expanding. The two layers — PQC for data at rest and TLS for transport — are complementary, not competing.
Next Steps
- Security Architecture — Service diagram and auth pipeline
- Non-Exportable Keys — How private keys are protected
- Why Qpher? — Build vs. buy decision framework