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). The KEK is managed by GCP Cloud KMS using envelope encryption (FIPS 140-2 Level 1) — the master key never leaves Google's secure KMS boundary. Each key file is wrapped via the Cloud KMS Encrypt API and stored as opaque ciphertext. Every operation 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 supports multi-factor authentication on both the SaaS Portal and the Vault iOS app. Users can enroll a TOTP authenticator (RFC 6238) together with ten single-use recovery codes, with email OTP offered only as a last-resort fallback after two failed primary attempts. SMS OTP is deliberately not supported (NIST SP 800-63B restricted, SIM-swap risk). Enterprise and Enterprise+ organizations can require MFA for every member: logins from unenrolled members are rejected, with a seven-day grace period for existing members and no grace period for new invites. MFA state is held independently per product, so a user with both a SaaS and a Vault account can choose to enroll on one, the other, or both.

Sensitive actions — password change, API key rotation, team-member removal, subscription checkout or cancel, and PQC key rotation — require a second proof of presence taken immediately before the action, even inside an already-authenticated session. The user enters their TOTP code (or current password if MFA is not enabled) and receives a short-lived, single-use step-up token carried as the X-Step-Up-Token header on the sensitive request. This reduces the blast radius if a session cookie is ever compromised: the stolen session alone cannot rotate a key, remove a teammate, or change the password. API-key integrations bypass step-up by design — API keys are already the highest-trust credential and do not gain meaningfully from a second factor at that tier.

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.