HSM / KMIP Ready
Sovereign Cryptographic Key Custody
Hardware Security Module (HSM) key hierarchy, KMIP integration, and zero-knowledge client encryption.
Last updated: Sep 20, 2026
•
Format: Markdown / GFM
Sovereign Cryptographic Key Custody
Security in Aarkam is governed by a foundational principle: the storage layer never holds plaintext or master keys.
The Key Encryption Hierarchy
Aarkam uses an industry-standard Envelope Encryption Hierarchy integrated with enterprise Key Management Interoperability Protocol (KMIP) servers or PKCS#11 hardware security modules (e.g. Thales Luna HSM, Fortanix DSM, or Entrust nShield):
┌────────────────────────────────────────────────────────┐
│ Customer Hardware Security Module (HSM) │
│ • Master Key Encryption Key (KEK) │
│ • Stays physically locked inside customer datacenter │
└──────────────────────────┬─────────────────────────────┘
│
[Wrap / Unwrap via KMIP]
▼
┌────────────────────────────────────────────────────────┐
│ Aarkam.IO Gateway Memory │
│ • Ephemeral Data Encryption Key (DEK) │
│ • Used to encrypt 4KB file chunks client-side │
│ • Never written to disk or logs │
└──────────────────────────┬─────────────────────────────┘
│
[Encrypted Chunks & Parity]
▼
┌────────────────────────────────────────────────────────┐
│ Rokka Storage Nodes & Kdouja Engine │
│ • Store 100% Ciphertext blocks │
│ • Completely zero knowledge of plaintext data │
└────────────────────────────────────────────────────────┘
Caution
Zero Backdoors Guarantee: Neither Aarkam engineers, support personnel, nor physical datacenter technicians have access to your KEK. Without customer HSM authorization, stored data blocks cannot be decrypted under any circumstances.