Skip to content

Key Management and Encryption Architecture

Including key durability and loss prevention controls.

Executive Summary

This page explains how eXate manages encryption keys, and why key loss is not a realistic risk within the platform architecture.

Key points:

  • eXate does not store or custody customer master keys
  • All master keys are generated and retained inside the customer's enterprise KMS or HSM
  • Master keys are non-exportable and protected by hardware-backed cryptographic modules
  • Cloud KMS platforms provide multi-zone replication and high durability guarantees
  • Accidental key deletion is prevented by enforced waiting periods, access controls, and audit logging
  • Optional escrow controls such as Shamir Secret Sharing can be implemented for additional organisational assurance
  • Encrypted data only becomes unrecoverable if a customer deliberately deletes a master key and allows the deletion window to complete

In summary, eXate does not introduce additional key loss risk beyond the durability guarantees of the customer's selected enterprise KMS provider.

1. Encryption Philosophy

eXate employs a cell-based encryption model, ensuring granular protection of sensitive data.

Encryption is decoupled from decryption through policy-based access controls, ensuring that data is only accessible to authorised consumers in the appropriate format. Industry-standard algorithms are used throughout, with AES as the default encryption standard, aligned to global security benchmarks.

2. Dual-Key Derivation Strategy

Each encryption event uses a dynamically derived key constructed from two independent data keys:

  • Data Type Key: relates to the classification of the data, for example first name, address, SSN
  • Subject Key: relates to the specific entity or individual to whom the data refers

This ensures:

  • Compromise of one key does not expose the full dataset
  • Granular enforcement of Right to be Forgotten through destruction of specific subject keys
  • Strong logical separation across datasets and individuals

3. Infrastructure and Integration

eXate is KMS-agnostic and integrates with enterprise-grade key management systems and secret stores, including:

  • Cloud Providers: Azure Key Vault, AWS KMS, IBM Cloud Hyper Protect Crypto Services
  • On-Premise / Hybrid: HashiCorp Vault
  • Hardware Security Modules: Azure HSM, IBM HSM

4. Key Hierarchy and Storage Model

eXate follows a strict root-of-trust hierarchy designed to ensure that ultimate cryptographic control remains with the customer.

4.1 Master / Region Key

  • Generated within the customer's KMS during installation, or assigned from an existing key
  • Non-exportable by design
  • Never leaves the KMS boundary
  • Used only for wrapping and unwrapping data keys

eXate sends keys to the KMS for cryptographic operations. It never extracts or stores master keys.

4.2 Data Keys

Data keys are:

  • Generated either by the KMS or by eXate's internal generation algorithms, depending on configuration
  • Immediately wrapped using the Master Key
  • Stored in encrypted form within the designated secret store

If the secret store were compromised, wrapped keys remain unusable without authorised KMS access.

5. Key Rotation Policies

5.1 Master / Region Key Rotation

Master keys can be rotated in accordance with corporate compliance policies. When rotation occurs, a new version of each data key is generated, the new data key version is wrapped under the new Master Key, and the previous version is disabled.

Rotation can be performed via eXate administrative tools or native cloud provider SDKs and management consoles.

5.2 Data Key Rotation (Lazy Rotation Model)

Data key rotation is triggered when the platform configuration snapshot date is updated. New data is encrypted using the latest key version, and legacy ciphertext remains decryptable using historical key versions. eXate does not automatically disable old data keys.

Because eXate operates in a stateless manner and does not persist customer ciphertext, re-keying legacy data requires customers to reprocess that data through the platform.

5.3 Key Deletion

eXate does not remove data keys. Key disabling or deletion must be performed by the customer through the KMS or secret store management console, subject to provider safeguards.

6. Key Durability and Loss Prevention

6.1 Customer-Owned Root of Trust

The Master Key is created and stored inside the customer's KMS, protected by FIPS-validated hardware cryptographic modules, and governed by the cloud provider's durability SLAs. eXate does not store or export this key. Loss would require deletion within the customer's own KMS environment.

6.2 Cloud KMS Durability Guarantees

Enterprise KMS providers implement multi-availability-zone replication, hardware-backed storage, consensus-based control planes, and high durability service levels. Keys are not files stored on a single disk, they are replicated control plane objects managed by hyperscale cloud infrastructure. Loss would require catastrophic regional provider failure.

6.3 Accidental Deletion Safeguards

All supported KMS platforms enforce scheduled deletion windows, soft-delete mechanisms, role-based access controls, audit logging of all key operations, and optional MFA for destructive actions. Keys cannot be immediately and silently destroyed.

6.4 Optional Escrow and Custodial Controls

For customers requiring additional organisational assurance, master key control can be augmented through cryptographic escrow mechanisms such as Shamir Secret Sharing. Under this model, a master secret or recovery material can be mathematically split into multiple shares, distributed to independent custodians, with a predefined threshold of custodians required to reconstruct the secret.

This ensures no single individual can unilaterally access or destroy recovery material, insider risk is reduced through separation of duties, and governance and board-level assurance requirements can be satisfied. This is an optional customer-side governance enhancement and does not alter eXate's non-custodial architecture.

6.5 Secret Store Compromise Scenario

If the secret store is compromised, data keys remain wrapped under the Master Key, and wrapped keys are cryptographically unusable without authorised KMS access. Storage compromise does not equal key compromise.

7. Metadata and Disaster Recovery

7.1 Ciphertext Metadata

Each encrypted cell includes versioning metadata identifying the key version used. This metadata should be stored in a high-availability environment such as Global Redis with robust backup configuration.

Loss of metadata does not result in permanent data loss, but may increase decryption latency.

7.2 Emergency Recovery via HMAC Matching

In a total metadata loss scenario, eXate can utilise HMAC components derived during encryption to cryptographically match keys to ciphertext. This process is resource-intensive, intended strictly for disaster recovery, and preserves decryptability even in extreme scenarios.

8. When Does Data Become Unrecoverable?

Encrypted data becomes permanently unrecoverable only if the customer deliberately schedules deletion of the Master Key, and the provider's mandatory waiting period completes. This is an intentional cryptographic destruction event, not an operational failure or platform risk.

9. Vendor Independence and Cryptographic Portability

Master keys are owned and controlled by the customer. eXate does not custody root cryptographic material. Wrapped data keys can be rewrapped under alternative master keys if required, and the encryption model does not create dependency on proprietary key storage. As a result, customers retain full cryptographic sovereignty independent of platform lifecycle decisions.

Conclusion

eXate's architecture ensures the customer retains full control of cryptographic root keys, master keys never leave enterprise-grade KMS infrastructure, keys are protected by hardware-backed replicated cloud control planes, and accidental deletion is safeguarded by enforced waiting periods and access controls. Optional escrow mechanisms such as Shamir Secret Sharing can further strengthen governance controls. Metadata loss does not equal key loss, and permanent data loss requires deliberate key destruction.

eXate does not introduce incremental key loss risk beyond the inherent durability characteristics of the customer's chosen KMS provider.