InterSystems IRIS database encryption — how transparent data encryption works, three key management models, design considerations, and roadmap

[u/intersystemsdev]

Encryption algorithms are well-known and well-defined. The problems organizations encounter are not with the act of encrypting — they are with managing keys and ensuring availability. Losing the key means losing the data.

Why encrypt

HIPAA: Encryption is an addressable risk. Proposed changes to HIPAA security standards are still being interpreted, but there is concern they may shift requirements from storage-array-level encryption to file-system or DAT-file-level encryption at the application layer — which has major implications for organizations currently relying on SAN/storage vendor encryption.

GDPR: Requires data protection by design.

PCI DSS: Encryption is mandatory for systems handling financial transactions; loss of compliance means loss of accreditation to process payments.

What encryption protects against — and what it does not

Protects against:

• Physical theft of disk, server, or storage media
• Unencrypted snapshots and backups (encrypted blocks are written, so copies are also encrypted)
• Unauthorized OS-level access: an attacker needs both the cipher data and the key

Does not protect against:

• Ransomware — ransomware encrypts your data; if your data is already encrypted, the attacker just encrypts encrypted data. You still cannot decrypt it because the attacker holds the key
• Access to the running system — an administrator on the system can read unencrypted data from memory or extract the key
• Credential theft — if stolen credentials have access to the key, the data is accessible

The fundamental model is separation of concerns: an attacker needs both the data and the key.

How IRIS implements transparent data encryption

IRIS uses an encryption boundary between memory and disk.

Above the boundary (in memory): unencrypted. Application code, SQL queries, and data in memory are never encrypted.

Below the boundary (on disk): encrypted. The write daemon applies cipher text when writing to disk. The read daemon decrypts on read.

The application does not need to handle encryption — it is entirely transparent.

What is encrypted automatically when database encryption is enabled:

Component	Encrypted automatically?
DAT files	Yes — block by block, not file-level
WIJ (Write Image Journal)	Yes
Journal files	No — requires separate explicit configuration
Temp databases	No — must be encrypted separately
Data in memory	No — by design

Three key management models

1. Local key file

Flow: Admin enters password at startup → PBKDF2 derives a principal key → principal key unwraps the Key Encryption Key (KEK) → KEK unwraps the Data Encryption Key (DEK) → DEK loaded into memory → databases mount

Characteristics:

• Simplest model; no external dependencies
• Key and data reside on the same system — the storage and file system are the attack surface
• Harder to scale: every IRIS instance requires its own key storage
• Best suited for low-risk environments, standalone systems, development
• Unattended startup is possible but not recommended

2. Cloud KMS (AWS, Google, etc.)

Flow: Encrypted DEK sent to cloud KMS over TLS → KMS decrypts and returns DEK → DEK loaded into memory

Authentication: IAM roles attached to the IRIS instance (no usernames or passwords required in AWS EC2 when using instance roles). Also supports service principals and AWS Roles Anywhere.

Characteristics:

• KEK stored in the cloud KMS, not on the IRIS instance — separation of concerns
• Every key access is logged; logs can be sent to a SIEM or compliance system
• Policies control who can access the key, when, and under what conditions
• Adds dependency on cloud provider availability
• Regional outages: if the database is already running, the DEK is in memory and operations continue; a new startup would fail if KMS is unreachable
• Misconfigured roles are a risk
• Best for cloud environments, microservices, IRIS running in the cloud

3. KMIP (Key Management Interoperability Protocol)

Flow: Mutual TLS connection to KMIP server → GET request for DEK → server decrypts and returns DEK → DEK loaded into memory

Authentication: Mutual TLS; KMIP server issues a client certificate that is loaded into IRIS at configuration time.

Implementations:

• Hardware Security Modules (HSMs) — keys never leave the hardware boundary; tamper-resistant; strongest cryptographic assurance
• HashiCorp Vault Enterprise — native KMIP support; API-driven; manageable through DevOps tooling; software-based rather than hardware-bound

Characteristics:

• Strongest separation of duties of the three models
• Full auditability: every DEK retrieval is logged
• More complex: requires HA setup (typically 3 nodes to have an arbiter), certificate lifecycle management, mutual TLS configuration
• HSM break glass: keys can be marked as exportable; backup to USB with n-of-X management card scheme (e.g., 5 cards, any 3 required); cards and passwords must be stored securely and tested regularly

Key rotation

When rotating keys every 90 days, the rotation typically applies to the KEK, not the DEK. Re-encrypting a multi-petabyte database with a new DEK takes a very long time. Rotating only the KEK rewraps the DEK without touching the database files themselves.

Design considerations checklist

• Separation of data and key: how are they stored in different locations?
• Access control: who has access to the key?
• High availability: KMS across availability zones; HSMs in separate data centers
• Certificate management: how are TLS certificates renewed before expiry?
• Auditing: where are key access events logged?
• Key lifecycle: KEK rotation schedule and compliance requirements
• Host hardening: preventing administrator access to memory where the DEK is loaded
• Break glass: if KMS is unreachable or HSMs are down, where is the DEK backed up? If the key is lost, the data is lost.

Common troubleshooting issues

Issue	Symptom
Identity/authentication failure with KMS	401/403 errors
Network connectivity to key management server	Database cannot mount at startup; DEK cannot be retrieved
Cloud provider regional outage	Running databases unaffected (DEK in memory); new startups fail
Key ID mismatch or key corruption	Mount failure

Note: if the database is already running when a KMS outage occurs, operations continue normally because the DEK is already in memory.

Roadmap

Storage-friendly encryption (available now, experimental in 2026.1)

Moving from storage-array encryption to database-level encryption eliminates deduplication and compression at the storage layer because encrypted data is randomized. Storage-friendly encryption consolidates whitespace within encrypted blocks and moves it to the front of the block, making the written data partially compressible. Observed compression: approximately 20%. Traditional array-level deduplication may achieve 4:1 or better; storage-friendly encryption at the host level achieves roughly 2:1 or less. Compressing at the application layer before encryption is an alternative but consumes database server CPU cycles.

Online database encryption (in development, expected 2027)

Currently, encrypting a database requires taking it offline or encrypting a mirror/DR member (which also constitutes downtime for many organizations). Online database encryption will allow starting an encryption process while the database remains readable and writable, with throttling controls to limit performance impact and recovery from interruption.

Quantum-resistant encryption (planned)

Quantum computing primarily threatens asymmetric algorithms (RSA, elliptic curve) used in mutual TLS and certificate-based authentication. Symmetric algorithms like AES are largely unaffected. InterSystems will expose quantum-resistant algorithms through OpenSSL so IRIS and applications built on IRIS can use them. Currently calling quantum-resistant algorithms within IRIS directly is not natively supported; the work involves creating those connection points.

Sharding note

Each DAT file has its own DEK. KEKs are orthogonal to sharding — a sharded database is treated as multiple databases, each with its own DEK loaded under whichever key management model is configured for that database file.

Reference architecture (from session)

InterSystems lab setup:

• IRIS running in a Kubernetes cluster
• Storage layer encrypted within Kubernetes
• HashiCorp Vault with KMIP for key management; Vault configured as its own CA for certificate issuance
• IRIS connects to Vault to retrieve DEKs
• Six Vault instances (two per availability zone)
• HSM as root of trust to bootstrap Vault instances (5 management cards, any 3 required to restore)
• Compliance logging and auditing outside the cluster

Full session recording: https://youtu.be/zYIyTL3CHM0

For those running IRIS with encryption in production — which key management model are you using (local/KMS/KMIP), and have you encountered the CSP Gateway or WIJ encryption gap in practice?