Security architecture

Abstract

This document presents a technical analysis of SparkVault's cryptographic security architecture, which implements a Triple Zero-Trust model requiring cryptographic contributions from three mathematically independent key hierarchies. We detail our implementation of NIST-standardized post-quantum lattice-based key encapsulation (ML-KEM-1024), authenticated encryption with associated data (AES-256-GCM, ChaCha20-Poly1305), HMAC-SHA512 for deterministic salt generation, HKDF-SHA512 for key derivation, and hardware-bound cryptographic operations within FIPS 140-3 Level 3 validated Hardware Security Modules (HSMs). Our architecture ensures that decryption is computationally infeasible without simultaneous possession of all three root keys, a property that holds even against adversaries with full infrastructure access, legal compulsion authority, or access to cryptographically-relevant quantum computers.

I. Executive summary

SparkVault implements a cryptographic architecture wherein data confidentiality is guaranteed by the mathematical impossibility of decryption without simultaneous access to three independent master keys, each held by separate trust domains with orthogonal security boundaries. This represents a fundamental departure from traditional encryption models where a single key holder possesses complete decryption authority.

Our implementation combines ML-KEM-1024 (CRYSTALS-Kyber) lattice-based post-quantum key encapsulation, HMAC-SHA512 via hardware security modules for deterministic salt generation, HKDF-SHA512 for cryptographic key derivation, and dual authenticated encryption modes (AES-256-GCM and ChaCha20-Poly1305) to achieve defense-in-depth across all cryptographic operations.

Independent key roots

3

Symmetric security

256-bit

PQC

Quantum resistant

FIPS

140-3 Level 3

II. Platform and infrastructure security

Strong cryptography means nothing if the underlying infrastructure is vulnerable. SparkVault implements defense-in-depth across every layer of our platform, built on cloud infrastructure with security controls that exceed even the most stringent regulatory requirements.

Our infrastructure operates within SOC 1/2/3, ISO 27001, PCI DSS Level 1, and FedRAMP High certified data centers, then adds multiple layers of our own cryptographic hardening on top. The result is an infrastructure security posture that rivals or exceeds most Fortune 500 financial institutions.

Enterprise security stack

We deploy a multi-layered, cloud-native security stack with defense-in-depth architecture to create a perimeter around your data. Every component is configured according to CIS Benchmarks, NIST 800-53 controls, and industry-recognized security frameworks with continuous compliance validation.

DDoS mitigation layer

Volumetric attack neutralization with terabit-scale scrubbing capacity, BGP Flowspec integration, and 24/7 Security Operations Center response team.

Intelligent application firewall

Layer 7 inspection with ML-based threat classification, custom rule engines blocking SQL injection, XSS, and OWASP Top 10 attack vectors at the network edge.

Neural threat detection

Deep learning-powered behavioral analysis engine continuously monitoring for anomalous activity patterns, lateral movement, and indicators of compromise across all workloads.

Cryptographic audit ledger

Immutable, hash-chained audit trail with SHA-256 integrity validation. Write-once storage in cryptographically isolated account with tamper-evident logging.

Compliance attestation engine

Continuous configuration compliance monitoring with declarative policy enforcement, automatic drift remediation, and real-time security baseline validation.

Hardware-backed credential vault

HSM-protected secrets management with automatic credential rotation, envelope encryption using AES-256-GCM, and zero hardcoded credentials across the entire codebase.

Also enabled: unified security posture management, continuous vulnerability assessment, ML-based PII detection, network flow telemetry, and customer-managed encryption keys.

100% serverless architecture

SparkVault runs entirely on serverless infrastructure. There are no traditional servers, no VMs to patch, and no persistent compute instances that could be compromised over time. Each request spawns an ephemeral execution environment that exists only for the duration of that request, then vanishes completely. Ephemeral compute leaves zero persistent attack surface.

No hard drives

All computation occurs in RAM-only environments. No data ever touches persistent disk storage during processing.

Ephemeral runtime

Execution environments are destroyed after each request. No state persists between invocations.

No SSH access

There are no servers to SSH into. No backdoors, no remote access vectors, no persistent shells.

Auto-scaling

Infrastructure scales automatically. No manual provisioning that could introduce configuration drift.

Why this matters for security

Traditional servers can be infected with persistent malware, rootkits, or backdoors that survive reboots. With serverless, there's nothing to infect. Every execution environment is freshly created from immutable, cryptographically verified container images. An attacker would need to compromise our deployment pipeline (protected by multiple approval gates) to inject malicious code, and even then it would only affect new deployments, not running systems.

Network security and isolation

Network security is defense in depth with zero public exposure.

Network architecture

Private subnets only

All compute resources run in private subnets with no direct internet access

No public IP addresses

Internal services are only reachable over private network endpoints and private links

Private endpoints

All internal service traffic traverses dedicated private links, never the public internet

NAT gateways

Outbound traffic routed through managed NAT with logging

Perimeter defense

Global edge network

400+ points of presence with TLS 1.3 termination and geographic access controls

Request ingress controller

Adaptive rate limiting, cryptographic API key validation, and per-client usage enforcement

Security groups

Stateful firewalls with deny-by-default policies

Network ACLs

Subnet-level stateless filtering as secondary defense

TLS configuration

Minimum version

TLS 1.2

Preferred version

TLS 1.3

Cipher suites

AEAD only

Certificate

RSA-4096 / ECDSA P-384

Infrastructure as code and immutable deployments

Infrastructure is GitOps-driven, with cryptographic verification.

100% infrastructure as code

Every resource in Git

All infrastructure defined in version-controlled Terraform/CDK

No manual changes

Console access is read-only; all changes require code review

Drift detection

Automatic alerts if infrastructure deviates from code

Policy as code

Security policies enforced via OPA/Sentinel before deployment

Immutable deployment pipeline

Signed container images

All images cryptographically signed and verified at deploy

Blue/green deployments

Zero-downtime releases with instant rollback capability

Multiple approval gates

Automated tests + security scan + manual approval required

SBOM generation

Software Bill of Materials for every release

Supply chain security

Supply chain attacks (like SolarWinds) represent one of the most sophisticated threats facing modern software. We implement controls to ensure that only verified, trusted code reaches production. Verification runs from source to production, end to end.

Dependency verification

• Lockfile integrity validation
• Checksum verification for all packages
• Automatic CVE scanning on every build
• No new dependencies without security review

Build integrity

• Reproducible builds from source
• Isolated build environments
• Signed build artifacts
• Build provenance attestation (SLSA Level 3)

Third-party risk

• Vendor security assessments
• Minimal dependency footprint
• No runtime dependencies on third-party services
• Regular dependency audits

Passwordless and zero standing access

Access is protected by mandatory MFA with just-in-time privilege escalation.

100% passwordless authentication

• No passwords exist in our infrastructure (employee or system)
• Hardware security keys (FIDO2/WebAuthn) required for all access
• Phishing-resistant authentication eliminates credential theft
• Mandatory multi-factor for every authentication event

Least privilege access model

• Zero standing privileges. All access is just-in-time
• Time-boxed access windows with automatic revocation
• Peer approval required for sensitive operations
• Every access request logged and auditable

Automated security checks

These checks run on pull requests, on deploys and every Monday.

Dependency vulnerability audit

Every third-party package the platform depends on, at its locked version, is checked against published security advisories.

• Runs on every pull request
• Runs every Monday against the main branch, so a newly published advisory surfaces within a week
• Fails on any advisory of moderate severity or higher
• Each accepted exception is recorded with why it is accepted

Committed credential scanning

Source code is scanned for live credentials committed by mistake.

• Every pull request scans every application, package and infrastructure-as-code tree
• The same scan runs every Monday against the main branch
• Every deploy of the Forge scans the source its image ships, and a match stops the deploy
• Detects payment-processor secret keys and cloud access key IDs
• Reports the file, never the matched value

Infrastructure as code checks

Production infrastructure is defined in version-controlled code, and every change to that code is checked automatically.

• Format and configuration validation on every change
• A plan of each change against production, on pull requests and on the main branch
• Infrastructure code is part of the credential scan on every pull request and every Monday
• A deploy of the Forge stops when its infrastructure plan would change anything else

Independent security validation

Third parties run our penetration testing and security audits.

Monthly penetration testing

Independent security firms conduct monthly penetration tests against our production infrastructure, APIs, and web applications.

• External network penetration testing
• API security assessment
• Web application testing (OWASP methodology)
• Social engineering assessment
• Findings remediated within 72 hours (critical) / 30 days (others)

Annual security audits and compliance

Annual security audits validate our controls against industry standards and regulatory requirements.

• SOC 2 Type II audit (Trust Services Criteria)
• Security framework alignment assessment
• Cryptographic implementation review
• Source code security audit
• Third-party vendor security assessment

Data isolation and segregation

The architecture is multi-tenant, with cryptographic isolation.

Tenant isolation

Cryptographic isolation

Each account has unique encryption keys, so data is unreadable even with database access

Network isolation

Private network segmentation prevents cross-tenant network access

Logical isolation

Row-level security enforced at database layer

Data residency

US East deployment

All data stored in US East data centers with multi-AZ redundancy

Backup isolation

Encrypted backups stored in separate availability zones

Single-region storage

Data remains within our US East infrastructure

Real-time monitoring and threat detection

Security monitoring is automated and runs 24/7, with ML-powered anomaly detection.

Continuous monitoring

Real-time telemetry

Sub-second metrics aggregation across all services with automated anomaly-based alarming

Centralized logging

All logs aggregated and analyzed in real-time

Anomaly detection

ML-powered identification of unusual patterns

Distributed tracing

End-to-end request correlation with cryptographic span identifiers and microsecond-precision latency analysis

Alerting and response

Instant alerts

On-call paging for immediate notification

Automated response

Event-driven auto-remediation for common issues

Runbook automation

Documented procedures for all alert types

SIEM integration

Security events correlated across all sources

Disaster recovery and business continuity

The architecture is multi-AZ, with automated failover and rapid recovery.

Uptime SLA

99.99%

RTO (recovery time)

< 1 min

RPO (data loss)

0

Availability zones

3+

High availability

• Multi-AZ deployment across 3+ availability zones
• Automatic failover with health checks
• Load balancing with intelligent routing
• No single points of failure in architecture
• Database with synchronous replication

Backup and recovery

• Continuous encrypted backups
• Point-in-time recovery (35-day retention)
• Multi-AZ backup replication
• Regular disaster recovery drills
• Documented recovery procedures

Employee and operational security

We run a security-first culture with rigorous controls.

Personnel security

• Background checks on all employees
• Security training during onboarding
• Annual security awareness training
• Regular phishing simulations
• NDA and confidentiality agreements

Device security

• Managed devices with MDM
• Full disk encryption required
• Automatic security updates
• Endpoint detection & response (EDR)
• Remote wipe capability

Operational controls

• Principle of least privilege
• Separation of duties
• Change management process
• Incident response procedures
• Regular access reviews

Controls at a glance

Our infrastructure security exceeds what most Fortune 500 companies implement internally.

• SOC 2 Type II
• Zero Trust
• FIPS 140-3 L3 HSMs
• Monthly pentests
• 100% serverless
• Zero standing access
• Passwordless auth
• Post-quantum ready
• DDoS mitigation
• Neural threat detection
• Private subnets only
• Immutable deploys
• SLSA Level 3
• 99.99% uptime SLA
• Zero RPO
• TLS 1.3

Your data is protected by cloud infrastructure certified for the world's largest banks, healthcare providers, and government agencies, with additional layers of cryptographic protection that make it mathematically impossible for anyone (including SparkVault) to access your data without your authorization.

III. Threat model and security objectives

Adversarial capabilities considered

SparkVault's cryptographic architecture is designed to maintain semantic security (IND-CCA2) and ciphertext indistinguishability against polynomial-time adversaries possessing any combination of the following capabilities, a threat model exceeding that of virtually any comparable secrets management platform:

Complete infrastructure compromise (adaptive CCA)

Full read/write access to all SparkVault servers, databases, HSM clusters, and network infrastructure with root-level privileges. Adversary may observe all RAM contents, intercept all I/O operations, and execute arbitrary code, yet cryptographic guarantees remain intact.

Legal compulsion and coercion resistance

Lawful requests requiring SparkVault to produce decrypted data, including FISA orders, national security letters, and extraterritorial legal demands. Our architecture provides cryptographic deniability: we cannot comply even under duress.

Malicious insider (collusion-resistant)

Malicious employees with administrative access including DBAs, SREs, and security personnel. Even collusion between multiple SparkVault employees cannot compromise vault contents due to key isolation across independent trust domains.

Cryptographically-relevant quantum computers (CRQC)

Adversaries with fault-tolerant quantum computers capable of running Shor's algorithm against RSA-4096, ECDSA P-384, and classical Diffie-Hellman. Our ML-KEM-1024 lattice-based KEM provides NIST Level 5 post-quantum security (equivalent to AES-256).

Side-channel exploitation (DPA/SPA/EMA)

Differential Power Analysis (DPA), Simple Power Analysis (SPA), electromagnetic emanation analysis (EMA), cache-timing attacks (Flush+Reload, Prime+Probe), and speculative execution vulnerabilities (Spectre/Meltdown variants). Constant-time implementations with hardware isolation.

Advanced persistent network adversary

Complete visibility into all network traffic with BGP hijacking capability, valid CA certificates, and ability to perform active MITM attacks. Ephemeral key exchange with cryptographic binding defeats session hijacking.

An obsessively paranoid guarantee

Under our threat model, an adversary with any two of the three root keys cannot decrypt protected data, not even with unlimited computational resources. The data encryption key (DEK) is derived via HKDF-SHA512 from the concatenation of three cryptographically independent shared secrets: ss₁ || ss₂ || ss₃. Without all three inputs, the resulting DEK has 256-bit entropy indistinguishable from random noise.

Decryption is a mathematical impossibility here, with no policy decision or access control involved: SparkVault cannot decrypt your data, and neither can our cloud provider or a nation-state adversary with complete infrastructure access. Few secrets managers go this far.

Pr[Decrypt(C) | K₁, K₂] ≤ 2⁻²⁵⁶ (computationally infeasible)

IV. Triple Zero-Trust architecture

SparkVault's Triple Zero-Trust model implements a novel threshold-free multi-party key agreement protocol distributing cryptographic authority across three mathematically independent trust domains with zero shared entropy. Unlike traditional 2-of-3 threshold schemes (Shamir's Secret Sharing), our architecture requires all three independent Master Keys for any decryption operation, providing strictly stronger security guarantees.

Each key resides in a physically and logically isolated security boundary: (1) post-quantum KEM ciphertext encapsulated under NIST FIPS 203 ML-KEM-1024, (2) hardware-bound HMAC-SHA512 keys non-extractable from FIPS 140-3 Level 3 HSMs, and (3) user-derived passphrase key material combined via HKDF-SHA512. The combination of any two keys without the third produces cryptographically random output with no correlation to the plaintext. We trust no single party, including ourselves.

SVMK (SparkVault Master Key)

ML-KEM-1024 post-quantum KEM: CRYSTALS-Kyber lattice-based encapsulation.

Module Learning With Errors (M-LWE) based key encapsulation providing IND-CCA2 security against both classical and quantum adversaries. 256-bit shared secret derived from 3168-byte ciphertext with computational security equivalent to AES-256.

NIST FIPS 203 | M-LWE (k=4, η₁=2, η₂=2) | 256-bit classical / 256-bit quantum security

AMK (Account Master Key)

HSM-bound HMAC-SHA512: a hardware-protected MAC key.

Per-account HMAC-SHA512 key that never leaves the FIPS 140-3 Level 3 Hardware Security Module. Generates deterministic 64-byte salts for HKDF key derivation. Non-extractable design means even SparkVault engineers cannot access the raw key material.

HMAC-SHA512 | FIPS 140-3 Level 3 | 512-bit security | Non-extractable

VMK (Vault Master Key)

HKDF-SHA512 hardware-bound key: a user-derived key with HSM attestation.

HMAC-based Key Derivation Function per RFC 5869 with 512-bit extract and expand phases. Key material derived from user passphrase + vault ID + hardware attestation, then cryptographically bound to FIPS 140-3 Level 3 HSM. Private key operations never leave the tamper-resistant boundary.

RFC 5869 | SHA-512 | FIPS 140-3 Level 3 | Hardware attestation chain

Key combination protocol

The three root keys are combined via a cryptographically secure key agreement protocol:

// Key 1: Post-quantum KEM decapsulation (SVMK)
svmk_shared_secret = ML-KEM-1024.Decaps(ciphertext, svmk_private_key)
// Key 2: Hardware HMAC for deterministic salt (AMK)
salt = HSM.GenerateMac(HMAC_SHA512, amk_key_id, account_id || vault_id)
// Key 3: User passphrase (VMK)
vmk = user_passphrase // 12-24 character Base62 string
// Final data encryption key via HKDF
DEK = HKDF-SHA512(ikm=svmk_shared_secret || vmk, salt=salt, info="VAK")

V. Cryptographic key hierarchy

SparkVault Master Key (SVMK)

Post-quantum key encapsulation mechanism.

Cryptographic parameters

Algorithm

ML-KEM-1024 (CRYSTALS-Kyber)

Standard

NIST FIPS 203

Public key size

1,568 bytes

Ciphertext size

1,568 bytes

Shared secret

32 bytes (256 bits)

Security properties

IND-CCA2 security

Indistinguishability under adaptive chosen-ciphertext attack

Quantum resistance

Security based on Module-LWE hardness assumption

Classical security

≥192-bit equivalent security level

Quantum security

≥128-bit post-quantum security level

Account Master Key (AMK)

Hardware-bound symmetric key.

Cryptographic parameters

Algorithm

HMAC-SHA512

Standard

FIPS 198-1, RFC 2104

Key size

512 bits

Output size

512 bits

Storage

Hardware Security Module

Security properties

Hardware isolation

Key material never leaves HSM boundary

Tamper resistance

FIPS 140-3 Level 3 physical security

Non-extractable

Cryptographic operations only, no key export

Per-account isolation

Unique key material per customer account

Vault Master Key (VMK)

Client-derived zero-knowledge key.

Cryptographic parameters

Input

12-24 character passphrase

KDF algorithm

Argon2id (RFC 9106)

Memory cost

64 MiB

Time cost

3 iterations

Output size

256 bits

Security properties

Zero-knowledge

SparkVault never receives or stores the passphrase

Memory-hard

ASIC/GPU-resistant key derivation

Side-channel resistant

Data-independent memory access patterns

Unrecoverable

Lost passphrase = permanently inaccessible data

Critical security note. The VMK is derived entirely client-side and is never transmitted to SparkVault servers. This provides cryptographic proof that SparkVault cannot decrypt vault contents, even under legal compulsion or infrastructure compromise. Loss of the passphrase results in permanent, irrecoverable data loss. This is the mathematical guarantee of your privacy.

VI. Post-quantum cryptography

Quantum threat analysis

Shor's algorithm, when executed on a cryptographically-relevant quantum computer (CRQC), can efficiently factor large integers and compute discrete logarithms, breaking RSA, DSA, and elliptic-curve cryptography. SparkVault proactively deploys NIST-standardized post-quantum algorithms to ensure long-term data confidentiality against "harvest now, decrypt later" attacks.

Vulnerable primitives (not used)

• RSA (Integer Factorization)
• ECDSA/ECDH (Discrete Log)
• DSA (Discrete Log)
• Classic Diffie-Hellman

Quantum-resistant primitives (in use)

• ML-KEM-1024 (Lattice-based KEM)
• AES-256 (Grover's: 128-bit effective)
• SHA-512 (Grover's: 256-bit effective)
• ChaCha20-Poly1305 (256-bit key)

ML-KEM-1024 implementation details

ML-KEM (Module-Lattice Key Encapsulation Mechanism), standardized as NIST FIPS 203, provides IND-CCA2 security based on the computational hardness of the Module Learning With Errors (M-LWE) problem over polynomial rings. Our implementation uses the highest security level (ML-KEM-1024) with parameters (k=4, η₁=2, η₂=2, du=11, dv=5) for maximum long-term protection against both classical and quantum adversaries.

Lattice parameters

Ring

R_q = ℤ_q[X]/(X²⁵⁶+1)

Modulus q

3329 (NTT-friendly prime)

Dimension n

256

Module rank k

4

Noise distribution

CBD(η) centered binomial

Security reductions

M-LWE hardness

Reduces to worst-case lattice problems (SVP, SIVP)

NTT acceleration

Number Theoretic Transform for O(n log n) polynomial multiplication

Fujisaki-Okamoto

CPA→CCA2 transform with re-encryption check

QROM security

Proven secure in Quantum Random Oracle Model

// Key Generation: sample secret s, error e ← CBD(η₁), compute A·s + e
(pk, sk) ← ML-KEM-1024.KeyGen(d ← SHAKE256(entropy))
// Encapsulation: sample r, e₁, e₂ ← CBD(η₂), compute (u, v) = (Aᵀr + e₁, tᵀr + e₂ + ⌈q/2⌋·m)
(ct, K) ← ML-KEM-1024.Encaps(pk; m ← SHAKE256(pk, random))
// Decapsulation: compute m' = Compress(v - sᵀu), re-encapsulate, verify ct' = ct
K ← ML-KEM-1024.Decaps(sk, ct) // implicit rejection on failure

VII. Key encapsulation and exchange

ML-KEM-1024 key encapsulation

SparkVault employs ML-KEM-1024 (NIST FIPS 203) for post-quantum secure key encapsulation. Each vault and spark operation generates a unique encapsulated shared secret that contributes to the final encryption key, providing quantum-resistant key exchange with NIST Security Level 5.

Protocol parameters

Algorithm

ML-KEM-1024 (CRYSTALS-Kyber)

Public key

1,568 bytes

Ciphertext

1,568 bytes

Shared secret

32 bytes (256 bits)

Security level

NIST Level 5 (~AES-256)

Security guarantees

Quantum resistant

Secure against Shor's algorithm and known quantum attacks

IND-CCA2 secure

Indistinguishable under adaptive chosen-ciphertext attack

Lattice-based

Security reduces to Module-LWE problem hardness

NIST standardized

FIPS 203 compliant implementation

Key derivation pipeline

SparkVault derives encryption keys through a multi-stage pipeline combining ML-KEM-1024, hardware-backed HMAC-SHA512, and HKDF-SHA512:

// Stage 1: ML-KEM decapsulation (SVMK contribution)
svmk_shared_secret = ML-KEM-1024.Decaps(kem_ciphertext, svmk_private_key)
// Stage 2: Hardware HMAC for deterministic salt (AMK contribution)
salt = HSM.GenerateMac(HMAC_SHA512, amk_key_id, account_id || vault_id)
// Stage 3: HKDF key derivation (combines all three roots)
encryption_key = HKDF-SHA512(
  ikm = svmk_shared_secret || vmk, // VMK = user passphrase
  salt = salt, // From HSM HMAC
  info = "SparkVault-VAK-v1",
  length = 32 // 256-bit key
)

VIII. Authenticated encryption schemes

AES-256-GCM (Galois/Counter Mode)

Primary AEAD cipher for data-at-rest encryption. Combines AES-256 in counter mode (CTR) for confidentiality with GHASH universal hashing for authentication, providing IND-CPA security with INT-CTXT integrity under a single 256-bit key.

Standard

NIST SP 800-38D, FIPS 197

Key schedule

14 rounds, 60-word expanded key

Nonce (IV)

96 bits (CSPRNG-generated, never reused)

Authentication tag

128-bit GHASH over GF(2¹²⁸)

Max plaintext

2³⁹ - 256 bits per nonce

Security bound

2⁶⁴ blocks before birthday collision

Hardware-accelerated via AES-NI + PCLMULQDQ | Constant-time GHASH multiplication | CAVP validated

ChaCha20-Poly1305 (RFC 8439)

Secondary AEAD cipher for VMK channel encryption. Combines ChaCha20 stream cipher (20-round ARX construction) with Poly1305 Wegman-Carter authenticator for IND-CPA + INT-CTXT security without hardware dependencies.

Stream cipher

ChaCha20 (ARX: add-rotate-xor)

MAC

Poly1305 over GF(2¹³⁰-5)

State size

512 bits (16 × 32-bit words)

Quarter rounds

80 per block (20 rounds × 4)

Max message

2⁷⁴ bytes per nonce

Forgery bound

2⁻¹⁰⁶ per authentication attempt

Constant-time implementation | No table lookups (cache-timing safe) | SIMD vectorized | IETF TLS 1.3 cipher suite

VMK channel protection

When Secure File Transfer is activated, ephemeral VMKs are vaulted and exchanged via a secure channel wrapped with ChaCha20-Poly1305 authenticated encryption:

// VMK channel encryption
channel_key = HKDF-SHA512(
  ikm = ecdh_shared_secret,
  salt = channel_nonce,
  info = "VMK-Channel-ChaCha20-Poly1305"
)
encrypted_vmk = ChaCha20-Poly1305.Seal(
  key = channel_key,
  nonce = random_96_bits,
  plaintext = vmk_material,
  aad = session_context
)

IX. Key derivation functions

HKDF-SHA512

HMAC-based Key Derivation Function (RFC 5869) used for cryptographic key expansion and domain separation throughout the SparkVault protocol.

// Extract phase
PRK = HMAC-SHA512(salt, IKM)
// Expand phase
OKM = HMAC-SHA512(PRK, info || counter)

Applications: session key derivation, sub-key generation, key combination.

Argon2id (RFC 9106)

Memory-hard password hashing function used for VMK derivation. Hybrid construction combining Argon2i (data-independent addressing for side-channel resistance) and Argon2d (data-dependent addressing for GPU/ASIC resistance). Winner of the Password Hashing Competition (PHC).

Memory (m)

65536 KiB (64 MiB)

Time cost (t)

3 iterations

Parallelism (p)

4 lanes

Tag length

32 bytes (256 bits)

Salt

16 bytes (128 bits, unique per vault)

Block size

1024 bytes (8 × 128-bit lanes)

Security: memory-hard (TMTO resistant), ASIC/GPU/FPGA cost prohibitive, cache-timing safe, ~2¹⁸ hash evaluations/sec/core attack cost.

X. Hardware Security Module integration

All cryptographic operations involving the Account Master Key (AMK) occur exclusively within FIPS 140-3 Level 3 validated Hardware Security Modules. These tamper-resistant, tamper-evident devices provide hardware-enforced isolation of key material with cryptographic attestation of code integrity via PKCS#11 (Cryptoki) interface and proprietary secure enclave protocols.

Physical security (Level 3)

• Tamper-evident epoxy encapsulation
• Active zeroization on tamper detect
• Environmental failure protection (EFP)
• Multi-factor operator authentication
• Physical key + PIN + smart card

Cryptographic boundary

• CKA_EXTRACTABLE = FALSE enforcement
• CKA_SENSITIVE = TRUE for all keys
• Hardware TRNG (SP 800-90B)
• CAVP/CMVP validated algorithms
• Key wrap with AES-KWP (RFC 5649)

Operational security

• M-of-N quorum for admin operations
• Cryptographic audit log (signed)
• Key ceremony with dual control
• Secure backup via key splitting
• Geographic key escrow separation

// HSM key generation via PKCS#11 (CKM_AES_KEY_GEN)
CK_MECHANISM mech = { CKM_AES_KEY_GEN, NULL, 0 };
CK_ATTRIBUTE tmpl[] = {
  { CKA_CLASS, &CKO_SECRET_KEY },
  { CKA_KEY_TYPE, &CKK_AES },
  { CKA_VALUE_LEN, &256 },
  { CKA_EXTRACTABLE, &CK_FALSE }, // Cannot leave HSM
  { CKA_SENSITIVE, &CK_TRUE }, // Cannot be revealed
  { CKA_TOKEN, &CK_TRUE } // Persistent across sessions
};
C_GenerateKey(hSession, &mech, tmpl, 6, &hKey);

Hardware entropy generation

All cryptographic random numbers are generated using hardware-based entropy sources within the HSM boundary, compliant with NIST SP 800-90B requirements:

Entropy sources

• Thermal noise generators
• Shot noise circuits
• Ring oscillator jitter
• Hardware interrupt timing

DRBG construction

• CTR_DRBG with AES-256
• Continuous health testing
• Automatic reseeding
• Prediction resistance mode

XI. Vault unseal ceremony

The Vault Unseal Ceremony is the cryptographic protocol by which all three root keys are combined to derive the Data Encryption Key (DEK) required for vault access. This ceremony implements time-bound HMAC verification and produces an AES-256-GCM authenticated cipher for decryption.

1. Client-side VMK derivation. User passphrase processed through Argon2id to derive VMK (never transmitted)
2. Hardware HMAC salt generation. HSM generates deterministic HMAC-SHA512 salt using non-extractable account key
3. VMK channel wrapping. VMK wrapped with ChaCha20-Poly1305 for secure transit to HSM
4. Time-bound HMAC verification. HKDF with time-bound HMAC prevents replay attacks and enforces session expiration
5. DEK derivation via HKDF. Combined via HKDF with a 4th ephemeral key derived via time-bound HMAC, producing AES-256-GCM authenticated cipher

// Time-bound session key
timestamp = current_unix_epoch()
time_key = HMAC-SHA512(session_key, timestamp || vault_id)
// Final DEK derivation
DEK = HKDF-SHA512(
  ikm = SVMK_secret || AMK_secret || VMK || time_key,
  salt = vault_nonce,
  info = "SparkVault-Unseal-DEK-v1"
)
// Authenticated decryption
plaintext = AES-256-GCM.Open(DEK, nonce, ciphertext, aad)

XII. Transport layer security

All data in transit is protected by TLS 1.3 (RFC 8446) with modern cipher suites providing authenticated encryption, perfect forward secrecy, and protection against downgrade attacks.

Supported cipher suites

• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_GCM_SHA256

Key exchange groups

• x25519 (preferred)
• secp256r1
• secp384r1

In summary: TLS 1.3 in transit, encrypted at rest, zero knowledge, Triple Zero-Trust, perfect forward secrecy.

XIII. Technical specifications summary

Cryptographic algorithms

ML-KEM-1024

Post-quantum KEM, NIST FIPS 203, Module-LWE

AES-256-GCM

AEAD encryption, NIST SP 800-38D, FIPS 197

ChaCha20-Poly1305

AEAD encryption, RFC 8439, VMK channel

HMAC-SHA512

MAC/PRF, FIPS 198-1, RFC 2104

HKDF-SHA512

Key derivation, RFC 5869

Argon2id

Password KDF, RFC 9106, memory-hard

Security parameters

Symmetric security

256-bit keys (AES-256, ChaCha20)

MAC security

512-bit (HMAC-SHA512)

Post-quantum security

≥128-bit (ML-KEM-1024)

Hash security

SHA-512 (256-bit collision resistance)

Authentication tags

128-bit (GCM, Poly1305)

Entropy generation

NIST SP 800-90B, hardware RNG

HSM validation

FIPS 140-3 Level 3

XIV. Mathematical notation and definitions

The following notation is used throughout this document to formally specify cryptographic operations and security properties.

Sets and spaces

{0,1}ⁿ

Set of all n-bit binary strings

𝔽_q

Finite field with q elements

ℤ_q

Ring of integers modulo q

R_q

Polynomial ring ℤ_q[X]/(Xⁿ+1)

𝒦

Key space

Operations

x ←$ S

Sample x uniformly at random from S

a || b

Concatenation of strings a and b

|x|

Length of string x in bits

⊕

Bitwise XOR operation

⌈x⌉

Ceiling function

Security game notation

Advantage functions

Adv^IND-CCA2_KEM(𝒜)

Adversary 𝒜's advantage in IND-CCA2 game against KEM

Adv^AUTH_AEAD(𝒜)

Adversary 𝒜's advantage in authenticity game

Adv^PRF_F(𝒜)

Adversary 𝒜's advantage distinguishing F from random

Complexity classes

PPT

Probabilistic Polynomial Time

negl(λ)

Negligible function in security parameter λ

poly(λ)

Polynomial function in λ

XV. Formal security reductions

SparkVault's security properties are formally reducible to well-studied computational hardness assumptions. We provide security reductions demonstrating that breaking our cryptographic constructions implies solving problems believed to be computationally intractable.

Theorem 1: KEM security

Let ML-KEM-1024 be instantiated with parameters (k=4, n=256, q=3329). For any PPT adversary 𝒜 making at most q_D decapsulation queries:

AdvIND-CCA2ML-KEM(𝒜) ≤ AdvMLWEk,η(ℬ) + qD · 2-γ

where ℬ is an efficient reduction and γ ≈ 174 is the failure probability parameter. The Module-LWE problem with these parameters provides ≥192-bit classical security.

Theorem 2: AEAD security

AES-256-GCM provides IND-CPA security and INT-CTXT authenticity. For any adversary 𝒜 making at most q queries with total plaintext length σ blocks:

AdvAEGCM(𝒜) ≤ AdvPRPAES(ℬ) + (σ + q + 1)2/2129

Security degrades gracefully with the birthday bound on the number of blocks encrypted under a single key.

Theorem 3: Key derivation security

HKDF-SHA512 is a secure key derivation function when HMAC-SHA512 is a PRF:

AdvKDFHKDF(𝒜) ≤ AdvPRFHMAC-SHA512(ℬ) + εextract

where ε_extract is negligible when the input key material has sufficient min-entropy.

Theorem 4: HSM-bound HMAC security

The HSM-bound HMAC-SHA512 provides PRF security with non-extractable keys:

AdvPRFHMAC-SHA512(𝒜) ≤ negl(λ) for λ ≥ 256

HSM-bound keys provide hardware attestation and physical tamper resistance. Key material never leaves the FIPS 140-3 Level 3 boundary, preventing key extraction attacks.

Compositional security

The Triple Zero-Trust architecture composes individual primitive securities. Under the assumption that compromising the combined system requires breaking at least one primitive:

// Combined system security
AdvSV(𝒜) ≤ min(
  AdvIND-CCA2ML-KEM-1024(𝒜),
  AdvPRFHMAC-SHA512(𝒜),
  AdvAEAES-256-GCM(𝒜),
  AdvKDFHKDF-SHA512(𝒜)
)

XVI. Side-channel attack mitigations

Side-channel attacks extract secret information through physical characteristics of cryptographic implementations rather than mathematical weaknesses. SparkVault implements mitigations against timing, cache, power, and electromagnetic side-channels.

Constant-time operations

• All comparisons use constant-time equality checks
• No secret-dependent branching or memory access
• Fixed iteration counts independent of input
• Scalar multiplication via Montgomery ladder

Cache-timing resistance

• AES-NI hardware instructions bypass cache
• No table lookups with secret-dependent indices
• Bitsliced implementations where applicable
• Memory access patterns independent of secrets

Memory protection

• Secure memory allocation with guard pages
• Immediate zeroization of sensitive data
• Memory locking to prevent swapping (mlock)
• Stack canaries and ASLR enabled

Power analysis resistance

• HSM provides physical isolation
• Algorithmic blinding for RSA operations
• Randomized projective coordinates for ECC
• Constant power consumption profiles

Secure memory zeroization

All sensitive cryptographic material is securely erased immediately after use:

// Secure zeroization (compiler-safe)
volatile uint8_t *p = secret_key;
size_t n = sizeof(secret_key);
while (n--) *p++ = 0;
memory_barrier(); // Prevent reordering
// Or platform-specific secure_zero:
explicit_bzero(secret_key, sizeof(secret_key));
SecureZeroMemory(secret_key, sizeof(secret_key)); // Windows

XVII. Nonce and initialization vector management

Nonce uniqueness is critical for AEAD security. Reusing a nonce with the same key catastrophically breaks confidentiality and authenticity. SparkVault implements multiple strategies to guarantee nonce uniqueness across all cryptographic operations.

Security requirement

For AES-GCM with 96-bit nonces, nonce reuse reveals the XOR of plaintexts and enables forgery attacks. For ChaCha20-Poly1305, nonce reuse similarly compromises security. Our nonce management ensures P(collision) < 2^-64 under normal operation.

Counter mode (primary)

Used for sequential encryption operations within a session:

nonce = session_id (32-bit) || counter (64-bit)
// Counter incremented after each encryption
// Session ID unique per key instantiation

Random nonce (stateless)

Used when counter state cannot be maintained:

nonce = CSPRNG(96 bits)
// Birthday bound: 2^48 encryptions
// before P(collision) = 2^-32

Nonce construction by context

XVIII. Cryptographic agility

Cryptographic agility enables SparkVault to migrate to new algorithms if vulnerabilities are discovered in current primitives, without requiring re-encryption of all existing data. Our architecture supports versioned algorithm negotiation and transparent migration paths.

Algorithm versioning

Each encrypted object includes an unencrypted header specifying the cryptographic suite version:

// Ciphertext format
struct EncryptedObject {
  version: u8, // Algorithm suite version
  kem_id: u16, // KEM algorithm identifier
  aead_id: u16, // AEAD algorithm identifier
  kdf_id: u16, // KDF algorithm identifier
  encapsulated_key: [u8],
  nonce: [u8; 12],
  ciphertext: [u8],
  tag: [u8; 16],
}

Current suite (v1)

KEM

ML-KEM-1024

AEAD

AES-256-GCM, ChaCha20-Poly1305

KDF

HKDF-SHA512

Signature

Ed25519 (API auth)

Reserved (future v2)

KEM

ML-KEM-1024 or successor

Signature

ML-DSA-87 (Dilithium)

Hash

SHA-3-512 (if SHA-2 weakened)

AEAD

AES-256-GCM-SIV

Migration protocol

1. Announcement phase. New algorithm suite published with 6-month deprecation notice for old suite
2. Dual support. System accepts both old and new suites; new encryptions use new suite
3. Background re-encryption. Optional background process re-encrypts existing data with new suite
4. Deprecation. Old suite support removed after migration window closes

XIX. Audit logging and non-repudiation

SparkVault maintains cryptographically-verifiable audit logs of all security-relevant operations. These logs provide non-repudiation and tamper evidence through hash chain construction, enabling forensic analysis and compliance reporting.

Hash chain construction

Each audit log entry includes a hash of the previous entry, creating a tamper-evident chain:

// Audit log entry structure
entry[n] = {
  sequence: n,
  timestamp: RFC3339,
  event_type: string,
  actor_id: hash(user_id),
  resource_id: hash(resource),
  action: string,
  prev_hash: SHA-256(entry[n-1]),
  signature: HMAC-SHA256(entry, audit_key)
}

Logged events

• Authentication attempts (success/failure)
• Key generation and derivation
• Encryption and decryption operations
• Vault unseal ceremonies
• API key creation and revocation
• Permission changes
• Data deletion requests

Security properties

Tamper evidence

Hash chain detects modifications

Non-repudiation

HMAC signatures prove authenticity

Append-only

No deletion or modification of entries

Privacy-preserving

User IDs hashed in logs

Retention

90 days (configurable per plan)

Verification protocol

Audit log integrity can be verified by recomputing the hash chain:

// Verify audit log integrity
function verify_audit_chain(entries):
  for i in 1..len(entries):
    expected_hash = SHA-256(entries[i-1])
    if entries[i].prev_hash != expected_hash:
      return TAMPERED_AT(i)
    if !HMAC_verify(entries[i], audit_key):
      return SIGNATURE_INVALID(i)
  return VALID

XX. Incident response procedures

SparkVault maintains incident response procedures for cryptographic emergencies including key compromise, algorithm breaks, and security breaches. Our response framework prioritizes data protection while maintaining service availability.

Key compromise response (critical severity)

1. Immediate isolation. Compromised key removed from active use within 15 minutes
2. Key rotation. New keys generated and distributed to affected systems
3. Re-encryption. Data protected by compromised key re-encrypted with new key
4. Notification. Affected users notified within 72 hours per breach notification requirements
5. Forensics. Root cause analysis and audit log review

Algorithm vulnerability response (high severity)

1. Assessment. Evaluate severity and exploitability of vulnerability
2. Mitigation. Deploy countermeasures if available (e.g., parameter changes)
3. Migration. Activate cryptographic agility to transition to secure alternative
4. Communication. Publish security advisory with timeline and recommendations

HSM failure response (medium severity)

1. Failover. Automatic failover to standby HSM cluster
2. Diagnosis. Hardware diagnostics and tamper detection verification
3. Recovery. Key restoration from encrypted backup if required
4. Replacement. Failed HSM securely decommissioned and replaced

Response time SLAs

XXI. References and bibliography

NIST standards

• [FIPS 197] Advanced Encryption Standard (AES). NIST, 2001.
• [FIPS 198-1] The Keyed-Hash Message Authentication Code (HMAC). NIST, 2008.
• [FIPS 203] Module-Lattice-Based Key-Encapsulation Mechanism Standard. NIST, 2024.
• [SP 800-38D] Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM). NIST, 2007.
• [SP 800-90B] Recommendation for the Entropy Sources Used for Random Bit Generation. NIST, 2018.
• [FIPS 140-3] Security Requirements for Cryptographic Modules. NIST, 2019.

IETF RFCs

• [RFC 2104] Krawczyk, H., Bellare, M., Canetti, R. "HMAC: Keyed-Hashing for Message Authentication." 1997.
• [RFC 5869] Krawczyk, H., Eronen, P. "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)." 2010.
• [RFC 7748] Langley, A., Hamburg, M., Turner, S. "Elliptic Curves for Security." 2016.
• [RFC 8439] Nir, Y., Langley, A. "ChaCha20 and Poly1305 for IETF Protocols." 2018.
• [RFC 8446] Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.3." 2018.
• [RFC 9106] Biryukov, A., Dinu, D., Khovratovich, D. "Argon2 Memory-Hard Function for Password Hashing and Proof-of-Work Applications." 2021.

Academic publications

• [Kyber] Avanzi, R., et al. "CRYSTALS-Kyber: Algorithm Specifications and Supporting Documentation." NIST PQC Submission, 2020.
• [Curve25519] Bernstein, D.J. "Curve25519: New Diffie-Hellman Speed Records." PKC 2006.
• [ChaCha20] Bernstein, D.J. "ChaCha, a variant of Salsa20." SASC 2008.
• [Poly1305] Bernstein, D.J. "The Poly1305-AES Message-Authentication Code." FSE 2005.
• [Argon2] Biryukov, A., Dinu, D., Khovratovich, D. "Argon2: The Memory-Hard Function for Password Hashing and Other Applications." Password Hashing Competition Winner, 2015.
• [GCM] McGrew, D., Viega, J. "The Galois/Counter Mode of Operation (GCM)." NIST, 2004.

Security analysis

• [LWE] Regev, O. "On Lattices, Learning with Errors, Random Linear Codes, and Cryptography." STOC 2005.
• [MLWE] Langlois, A., Stehlé, D. "Worst-Case to Average-Case Reductions for Module Lattices." Designs, Codes and Cryptography, 2015.
• [Shor] Shor, P.W. "Algorithms for Quantum Computation: Discrete Logarithms and Factoring." FOCS 1994.
• [Grover] Grover, L.K. "A Fast Quantum Mechanical Algorithm for Database Search." STOC 1996.

Encrypt with AES-256-GCM and ML-KEM-1024

Deploy SparkVault's multi-layered cryptographic architecture to achieve mathematically-guaranteed data confidentiality.