Security Architecture
Threat model, key custody architecture, BYOC integration, HSM mode, air-gapped security, post-quantum algorithms, evidence bundles, revocation model, and known limitations.
Threat Model
Six adversary profiles with documented mitigations. QuantumLock is designed for the classical-to-post-quantum transition era.
Classical Attacker
Vector: Classical cryptanalysis aimed at forging licence tokens.
Mitigation: Licence tokens are signed with ML-DSA-65 (FIPS 204 algorithm) via liboqs (not CAVP-validated), which does not rely on integer factoring.
Quantum Attacker
Vector: Shor algorithm on large-scale fault-tolerant quantum computer.
Mitigation: Licence tokens are signed with ML-DSA-65 (FIPS 204 algorithm) via liboqs (not CAVP-validated). Evidence bundles are sealed with SHA-256 hashing, not signed.
Insider Threat
Vector: Compromised operator or stolen API key with signing privileges.
Mitigation: Scoped API keys (quantumlock:use/keys/sign/read). Tamper-evident audit trail (90-day retention). RBAC roles.
Supply Chain
Vector: Tampered software distribution or compromised build pipeline.
Mitigation: Server images are built and deployed by SoftQuantus. The published quantumlock PyPI client ships readable Python source.
Replay Attacks
Vector: Reuse of a previously valid licence token.
Mitigation: Epoch-based revocation with anti-rollback. Monotonically increasing epoch numbers. HMAC-protected local store.
Evidence Tampering
Vector: Modified or deleted audit log entries.
Mitigation: SHA-256-chained audit log (90-day retention). Each entry includes the hash of the previous entry, so an edit or deletion is detectable by recomputing the chain.
Key Custody Model
Strict separation between policy decisions (QuantumLock) and key custody (your KMS or HSM). QuantumLock never accesses private key material.
Policy Engine
Decides which algorithm to use, which key to call, when to sign, when to rotate, and lifecycle rules.
KMS Integration
Routes cryptographic operations to the correct KMS provider via native SDK. AWS, Azure, GCP, or PKCS#11.
Private Key Material
Stored exclusively in your cloud KMS or HSM. QuantumLock never accesses, transmits, or stores your private keys.
HSM Hardware
Thales Luna, Entrust nShield, Utimaco, YubiHSM 2. You procure, configure, and physically secure the HSM.
Cloud Account & IAM
AWS, Azure, or GCP account. You control IAM roles, service accounts, and billing.
Access Control & Scopes
QuantumLock enforces scopes. Your organization manages API key distribution and role assignments.
Post-Quantum Cryptography
QuantumLock signs licence tokens with ML-DSA (FIPS 204 algorithm) via liboqs, which is not CAVP-validated. ML-KEM and SLH-DSA are key generation only; no encapsulation or SLH-DSA signing is implemented.
| Algorithm | Standard | Level | Use |
|---|---|---|---|
| ML-DSA-65 | FIPS 204 | 3 | Licence-token signatures (liboqs; not CAVP-validated) |
| ML-DSA-87 | FIPS 204 | 5 | Higher security level for licence-token signatures (liboqs; not CAVP-validated) |
| ML-KEM-768 | FIPS 203 | 3 | Key generation only (liboqs); no encapsulation/decapsulation implemented |
| SLH-DSA-SHAKE-256S | FIPS 205 | 5 | Key generation only (liboqs); no signing operation implemented |
Licence-token signatures
Licence tokens are signed with ML-DSA-65 via liboqs, which is not CAVP-validated. Evidence bundles are not signed: they are sealed under a SHA-256 Merkle root that a reviewer can recompute offline with softquantus-verify.
Sealed evidence bundles
Evidence bundles are sealed under a SHA-256 Merkle root over JCS RFC 8785 canonical artifacts and can be verified offline with softquantus-verify. Bundles are sealed, not signed.
Compliance Alignment
QuantumLock aligns with recognized cryptographic standards and regulatory frameworks.
Limitations
Honest disclosure of what QuantumLock does not claim or provide. Enterprise procurement requires clear boundaries.
- Local KMS mode (software keys) is not equivalent to FIPS 140-3 certified HSM. Defense deployments require PKCS#11 HSM.
- PQC-ready means QuantumLock implements NIST-standardized post-quantum algorithms. It does not mean quantum-proof certification.
- SecNumCloud-ready means the software is compatible for deployment on SecNumCloud-qualified infrastructure. It is not itself SecNumCloud certified.
- License validation provides software-based protection. It is not a hardware security module and does not prevent physical tampering.
Review the full security architecture
Schedule a 30-minute security review with our engineering team. We walk through threat model, key custody, and deployment architecture.
Security advisories and architecture updates
Get notified about threat model updates, new PQC algorithm support, and security best practices.