Security

Qpher is built as a microservices platform with clear security boundaries. The API Gateway handles authentication and rate limiting before routing requests to internal services. Private key operations are confined to the KMS-Orchestrator service, which is the only component with access to key material. All inter-service communication is authenticated with service tokens, and every request carries tenant context for isolation enforcement.

Qpher uses liboqs (Open Quantum Safe) as the underlying implementation of all post-quantum cryptographic algorithms. We do not implement cryptographic primitives from scratch — we build on a peer-reviewed, widely adopted open-source C library maintained by academic and industry cryptographers. liboqs implements NIST FIPS 203 (ML-KEM-768 / Kyber768) for key encapsulation and NIST FIPS 204 (ML-DSA-65 / Dilithium3) for digital signatures. The Open Quantum Safe project is used by organizations including IBM, Amazon, and Cloudflare for PQC integration, and provides the oqs-provider for OpenSSL. The liboqs version used in Qpher production is pinned and recorded in every Docker image build for full traceability.

Qpher supports both PQC-only and hybrid modes. PQC-only mode uses Kyber768 and Dilithium3 by default. Hybrid mode combines PQC algorithms with proven classical algorithms for defense-in-depth. For encryption: X-Wing hybrid KEM (X25519 + ML-KEM-768), following the IETF CFRG draft adopted by Google Cloud KMS. For signatures: Composite ML-DSA (ECDSA P-256 + ML-DSA-65), following the IETF LAMPS draft. Hybrid mode ensures security even if a future cryptanalytic breakthrough weakens PQC algorithms — the classical component provides a fallback. This follows the approach used by AWS, Google Cloud, and Cloudflare in their production PQC deployments.

Private keys are generated and stored exclusively within the KMS-Orchestrator secure enclave. No API endpoint, administrative interface, or internal service can export private key material. The database stores a key handle (a reference to the encrypted key file), never the key bytes themselves. All cryptographic operations requiring the private key — decryption and signing — are performed within the KMS-Orchestrator and the result is returned to the calling service.

All private key files are encrypted using AES-256-GCM with a Key Encryption Key (KEK) that is itself managed through a multi-provider strategy. The KEK is a 256-bit key stored in environment secrets (transitioning to AWS KMS / GCP Cloud KMS for production). Each key file uses a unique initialization vector (IV) to ensure ciphertext uniqueness even for identical key material.

Qpher uses a shared database with strict application-level tenant isolation enforced through four layers: (1) TenantScopedRepository base class that injects tenant_id into every query, (2) database-level CHECK constraints and composite unique indexes, (3) ServiceContext propagation ensuring tenant_id flows through all internal calls, and (4) API Gateway injection of tenant_id from the authenticated API key — tenant_id is never derived from user input.

Every API request is evaluated by a dedicated Policy Engine service before reaching the target service. The engine applies a first-deny-wins rule chain that checks plan-based restrictions, quota limits, and method-level access controls. The Policy Engine fails closed by default: if the engine is unavailable, all requests are denied. An emergency fail-open mode exists with strict safeguards — it auto-reverts to closed after a configurable timeout (default 5 minutes) and generates critical audit events.

Qpher is on a roadmap toward SOC 2 Type II certification. Phase 1 (v1.0): internal security controls documented and trust center published. Phase 2 (v1.1, 3-6 months post-launch): engage an independent auditor for SOC 2 Type I assessment. Phase 3 (v1.2, 6-12 months post-launch): complete the SOC 2 Type II observation period. All security practices described in this trust center are designed to satisfy SOC 2 Trust Services Criteria.

All external traffic to Qpher APIs is encrypted via TLS 1.2+ (TLS 1.3 preferred). Internal service-to-service communication within the cluster uses mutual TLS where supported. The KMS-Orchestrator, which handles the most sensitive operations, requires TLS for all inbound connections. API keys are transmitted in request headers over HTTPS and are never included in URL parameters or query strings.