Security Architecture

QuantumLock™ security design and implementation details.

Overview

QuantumLock™ is designed with a defense-in-depth approach, using multiple layers of cryptographic protection to ensure license integrity and prevent tampering.

┌─────────────────────────────────────────────────────────────────┐
│                    SECURITY LAYERS                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  Layer 1: Post-Quantum Cryptography                             │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │  ML-DSA-65 (FIPS 204) - Quantum-resistant signatures        ││
│  │  Hybrid RSA-PSS + ML-DSA for transition security            ││
│  └─────────────────────────────────────────────────────────────┘│
│                                                                  │
│  Layer 2: Revocation & Anti-Rollback                            │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │  Epoch-based revocation with cryptographic proofs           ││
│  │  OS-level secure storage for epoch state                    ││
│  └─────────────────────────────────────────────────────────────┘│
│                                                                  │
│  Layer 3: Device Binding                                        │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │  Hardware fingerprinting with SHA-256 binding               ││
│  │  Salt-based fingerprint protection                          ││
│  └─────────────────────────────────────────────────────────────┘│
│                                                                  │
│  Layer 4: Binary Protection (SDK/CLI)                           │
│  ┌─────────────────────────────────────────────────────────────┐│
│  │  Nuitka compilation to native code                          ││
│  │  Anti-debugging and obfuscation                             ││
│  └─────────────────────────────────────────────────────────────┘│
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Post-Quantum Cryptography

Why Post-Quantum?

Quantum computers threaten current cryptographic algorithms:

Algorithm	Status	Quantum Threat
RSA-2048	⚠️ Transition	Broken by Shor's algorithm
ECDSA	⚠️ Transition	Broken by Shor's algorithm
AES-256	✅ Safe	Grover reduces to 128-bit (still secure)
SHA-256	✅ Safe	Grover reduces to 128-bit (still secure)
ML-DSA	✅ PQC	Designed for quantum resistance

ML-DSA (FIPS 204)

QuantumLock™ uses ML-DSA-65 (Module-Lattice Digital Signature Algorithm):

Based on lattice problems (hard for quantum computers)
NIST standardized (FIPS 204)
Security level: 192-bit classical, 128-bit quantum

# ML-DSA signature in license artifact
{
  "header": {
    "alg": "RSA-PSS-SHA256",     # Classical signature
    "alg_pqc": "ML-DSA-65"       # Post-quantum signature
  },
  "signatures": {
    "classic": "RSA-PSS signature...",
    "pqc": "ML-DSA signature..."
  }
}

Hybrid Signing

We use hybrid signatures for transition security:

RSA-PSS-SHA256: Current standard, widely trusted
ML-DSA-65: Future-proof against quantum attacks

Both signatures must verify for the license to be valid.

Verification:
  ✓ RSA-PSS signature valid
  ✓ ML-DSA signature valid
  → License accepted

If either fails:
  ✗ Signature verification failed
  → License rejected

Revocation System

Epoch-Based Revocation

Traditional CRL (Certificate Revocation Lists) have issues:

Large lists to download
Stale data problems
Easy to bypass offline

QuantumLock™ uses epoch-based revocation:

Epoch 0: Initial state (no revocations)
    ↓
Epoch 1: License A revoked
    ↓
Epoch 2: License B revoked
    ↓
Epoch 3: License A restored
    ...

How It Works

Each license stores the minimum valid epoch
Client stores the current epoch securely
On validation, client checks: current_epoch >= license.min_epoch
If client epoch < server epoch, sync is required

Anti-Rollback Protection

Prevents attackers from using old revocation sets:

# Secure epoch storage per platform
macOS:    Keychain Services
Windows:  DPAPI (Data Protection API)
Linux:    Secret Service (libsecret)

Attack attempt:
Attacker captures epoch 40 revocation set
License X is revoked at epoch 42
Attacker tries to use old epoch 40 set

Defense:
Client stored epoch 42 securely
Epoch 40 < stored epoch 42
Rollback detected → validation fails

Device Binding

Hardware Fingerprinting

Licenses can be bound to specific devices:

binding = {
  "type": "hardware",
  "value": "sha256:9f86d081884c7d659a2feaa0c55ad015...",
  "algorithm": "SHA-256",
  "salt": "random-salt-value",
  "properties": ["cpu_id", "motherboard_serial", "disk_serial"]
}

Fingerprint Generation

# Client-side fingerprint generation
fingerprint = {
    "cpu_id": get_cpu_id(),
    "motherboard_serial": get_motherboard_serial(),
    "disk_serial": get_disk_serial(),
    "mac_address": get_primary_mac()
}

# Hash with salt
fingerprint_json = json.dumps(fingerprint, sort_keys=True)
salted = salt + fingerprint_json
binding_value = "sha256:" + sha256(salted).hexdigest()

Binding Verification

During validation:

# Server-side verification
client_fingerprint = request.device_fingerprint
expected_hash = license.binding.value

computed_hash = compute_fingerprint_hash(
    fingerprint=client_fingerprint,
    salt=license.binding.salt,
    algorithm=license.binding.algorithm
)

if computed_hash != expected_hash:
    return ValidationResult(
        is_valid=False,
        error="BINDING_MISMATCH"
    )

License Artifact Structure

JWT-like Format

header.payload.signature_classic.signature_pqc

{
  "typ": "QL-LICENSE",
  "ver": "1.0",
  "alg": "RSA-PSS-SHA256",
  "alg_pqc": "ML-DSA-65",
  "kid": "ql-api-v2-default"
}

Payload

{
  "jti": "unique-license-id",
  "sub": "customer:acme-corp",
  "iss": "quantumlock.softquantus.com",
  "iat": 1735570068,
  "nbf": 1735570068,
  "exp": 1767106068,
  "grace_until": 1768315668,
  "revocation_epoch": 0,
  "entitlements": [...],
  "binding": {...},
  "metadata": {...}
}

Canonical Serialization

For signature verification, payload is canonicalized:

Keys sorted alphabetically
No whitespace
UTC timestamps as Unix epoch
UTF-8 encoding

Key Management

Key Hierarchy

Root Key (HSM-stored, offline)
    │
    ├── Issuing Key (ql-api-v2-default)
    │   ├── RSA-4096 private key
    │   └── ML-DSA-65 private key
    │
    └── Backup Key (ql-api-v2-backup)
        ├── RSA-4096 private key
        └── ML-DSA-65 private key

Key Rotation

New key pair generated
New key marked active
Old key marked rotated (still valid for verification)
Grace period for clients to update
Old key marked expired

Key Storage

Environment	Storage
Production	Azure Key Vault HSM
Staging	Azure Key Vault
Development	File-based (encrypted)

Binary Protection

SDK/CLI Compilation

The SDK and CLI are compiled with Nuitka for protection:

Python Source → Nuitka → Native Binary (.so/.pyd/.exe)

Protection Layers

Code Compilation: Python bytecode → machine code
String Encryption: Sensitive strings encrypted
Anti-Debug: Detection of debuggers/reversing tools
Integrity Checks: Binary self-verification

Limitations

Binary protection is not a security boundary—it's a deterrent:

Determined attackers can still reverse engineer
Server-side validation is always authoritative
Offline validation has inherent trust limitations

Threat Model

What We Protect Against

Threat	Mitigation
License key guessing	Cryptographic signatures
License forgery	Dual RSA + ML-DSA signatures
License modification	Signature verification
Revocation bypass	Epoch-based anti-rollback
Device cloning	Hardware fingerprint binding
Replay attacks	Timestamps + nonces
Quantum attacks	ML-DSA-65 signatures

What We Don't Protect Against

Threat	Reason
Full system compromise	Attacker has root access
Memory dumping	Runtime decryption visible
Hardware keyloggers	Out of scope
Social engineering	Human factor

Compliance

Standards

NIST FIPS 204: ML-DSA signature algorithm
NIST FIPS 203: ML-KEM (future key exchange)
RFC 7518: JSON Web Algorithms
RFC 7519: JWT structure (adapted)

Certifications

SOC 2 Type II (in progress)
ISO 27001 (planned)

Security Recommendations

For Implementers

Always verify both signatures (RSA + ML-DSA)
Sync revocation epoch regularly
Use device binding for high-value licenses
Store proofs securely for offline validation
Monitor for anomalies in validation patterns

For Users

Protect API keys like passwords
Use environment variables not hardcoded keys
Implement rate limiting in your application
Log validation failures for security monitoring
Report suspicious activity to support

Reporting Security Issues

Found a vulnerability? Please report responsibly:

📧 security@softquantus.com

We offer a bug bounty program for qualifying issues.

Overview​

Post-Quantum Cryptography​

Why Post-Quantum?​

ML-DSA (FIPS 204)​

Hybrid Signing​

Revocation System​

Epoch-Based Revocation​

How It Works​

Anti-Rollback Protection​

Device Binding​

Hardware Fingerprinting​

Fingerprint Generation​

Binding Verification​

License Artifact Structure​

JWT-like Format​

Header​

Payload​

Canonical Serialization​

Key Management​

Key Hierarchy​

Key Rotation​

Key Storage​

Binary Protection​

SDK/CLI Compilation​

Protection Layers​

Limitations​

Threat Model​

What We Protect Against​

What We Don't Protect Against​

Compliance​

Standards​

Certifications​

Security Recommendations​

For Implementers​

For Users​

Reporting Security Issues​