Velocity • Durability

AI SOLUTIONS / END-TO-END ENCRYPTION

Encrypted before it leaves the client. Keys that never leave your control.

AES-256 protects data from the moment it leaves the client, through transit, and at rest. One implementation instead of a TLS stack bolted to self-encrypting drives, with per-volume keys you hold in your own KMS.

✓ AES-256 end to end ✓ BYOK over KMIP ✓ No keys on storage
CIPHERTEXT FROM THE CLIENT ONWARD
KEY PLANE · KMIP Directors create the key Your external KMS KMIP v1.4+ · Vault, Entrust, Thales client retrieves it DATA PLANE · PLAINTEXT NEVER LEAVES THE CLIENT DirectFlow client AES-256-XTS FIPS 140-validated ciphertext · no separate TLS step VPOD cluster stores ciphertext only holds no keys Keys never leave your control, and never reach the storage tier. A stolen drive, JBOD, or whole server exposes nothing.
AES-256-XTS
CIPHER
FIPS 140-validated, 256-bit keys. The same algorithm from client to flash.
Per volume
KEY GRANULARITY
Tenant-scoped key material, established at volume creation. Never shared across tenants or volumes.
Zero
KEYS ON STORAGE
Storage nodes never receive or hold a key, and never see plaintext.
KMIP v1.4+
KEY MANAGEMENT
Bring your own keys from Vault, Entrust, or Thales with mutual-cert auth.
THE PATCHWORK PROBLEM

Two half-measures stitched together is not end to end.

The common approach pairs TLS for data in flight with self-encrypting drives for data at rest. Each piece works. The seam between them is the problem, because that is where plaintext lives, where two key hierarchies have to be reconciled, and where an auditor starts asking questions.

THE SEAM
Plaintext lives between the two halves
TLS terminates at the storage front end, and self-encrypting drives take over at the drive controller. In between, your data sits decrypted in someone else's memory and on someone else's bus.
VDURA: The client encrypts before data leaves the compute node. There is no seam, because there is no point at which the storage tier holds plaintext.
TWO STACKS
Two systems, two key hierarchies
Certificate rotation on one side, drive-level key management on the other, and a compliance story that has to reconcile both. Each is a place to be misconfigured.
VDURA: One unified implementation. Per-volume key scope, one KMIP integration, one thing to audit and rotate.
HOW IT WORKS

Four steps, and the storage tier is not trusted in any of them.

Encryption is a property of the DirectFlow client, not a service in front of the disks. That single decision is what makes the guarantee hold all the way down.

STEP 1 · PROVISION
Directors create the key
At volume creation, a Director requests key material for the volume from your external KMS over KMIP. The key reference is bound to the volume.
STEP 2 · RETRIEVE
The client fetches it
The DirectFlow client retrieves the key directly with mutual-certificate authentication. Storage nodes are not party to the exchange.
STEP 3 · ENCRYPT
Ciphertext before the wire
AES-256-XTS runs on the compute node as part of the client's write path, alongside erasure coding, before any shard is transmitted.
STEP 4 · STORE
Ciphertext at rest
VPODs store what they receive. No decryption on the storage tier, no separate at-rest layer, no self-encrypting drives required.
KEY CUSTODY

You hold the keys. We hold the ciphertext.

Keys live in your external key manager and are reached over KMIP v1.4 or later with mutual-certificate authentication. Directors create a key at volume creation; the client retrieves it to encrypt and decrypt. Storage nodes are never in that conversation.

Per-tenant keys give you per-tenant cryptographic isolation rather than one fleet-wide secret
You hold the keys in your own KMS, which is what data-sovereignty commitments actually require
Key scope is unambiguous: every volume's data is protected under its own tenant-scoped key material
Mutual-certificate authentication on every KMIP exchange between Directors, clients, and your key manager
Revoking access at your KMS is a real control, because ciphertext without the key is inert
THE SPEC, PLAINLY
CipherAES-256-XTS, FIPS 140-validated
Key length256-bit
GranularityPer tenant, per volume
Key managerExternal KMS over KMIP v1.4 or later
Validated withHashiCorp Vault, Entrust, Thales
AuthenticationMutual-certificate
Key flowDirectors create, client retrieves
Secure eraseNIST 800-88
Audit retentionSix years, immutable
WHAT IS AND ISN'T COVERED

The scope, stated before you ask.

Client-side encryption buys a real guarantee, and it has real consequences. Both belong on the same page.

COVERED
File data in transit, from the moment it leaves the client through the network
File data at rest on flash and on capacity media, as ciphertext only
Per-tenant separation, cryptographic rather than administrative
Physical media exposure: drive theft, JBOD loss, or full server loss reveals nothing
KNOW BEFORE YOU DEPLOY
·On client-side encrypted volumes, access is DirectFlow only. NFS, SMB, and S3 gateways are disabled by design.
·Encryption is decided at volume creation. A volume is encrypted from its first byte; it is not converted in place later.
·File metadata, including names, sizes, and layout, is not encrypted by the client path.
GOVERNANCE AND COMPLIANCE

Encryption is one control. The audit needs the rest.

RBAC
Granular role-based access control on all administrative access.
Immutable Audit Logs
UTC-stamped and immutable, retained six years. Every API call lands in the log, including RBAC-scoped token use.
Secure Erase
NIST 800-88 compliant erase for decommissioning, on top of ciphertext-only media that is already inert without its key.
HIPAA Capable
Six-year audit retention, NIST 800-88 erase, and BAA capability for regulated workloads.
WHAT THIS MEANS FOR THE BUSINESS

The security review stops being the thing that stalls the deal.

Enterprise Renters Say Yes
Per-tenant keys, BYOK over KMIP, RBAC and immutable audit logs answer the security questionnaire before it becomes a blocker.
One Stack To Operate
No TLS termination tier to run alongside a self-encrypting drive fleet. One integration, one rotation process, one thing to audit.
Sovereignty You Can Sign
Keys stay in your key manager in your jurisdiction. That is a commitment you can put in a contract rather than a diagram.
Cryptographic Tenant Isolation
Separation enforced by keys rather than by configuration. The strongest form of the multi-tenancy claim you are already making.

See what end-to-end encryption means for your security review, and for the tenants asking about it.