vmward is a two-part solution: a central authorization server and a per-hypervisor client: that keeps every VM’s disk encrypted with a key that lives only at yREMORA-grade standards on your authority server, never on the machine that runs the disk. When a VM boots, the client asks the server for that VM’s passphrase; the server checks the licence, the source, and the machine’s cryptographic identity, then hands back the key sealed to that host alone. The client opens the LUKS volume, hands it to QEMU, and drops the key. A disk image stolen off the hypervisor is inert.
Built on battle-tested open source (LUKS2/dm-crypt, X25519/Ed25519/AES via OpenSSL, Python 3, SQLite) with modern deployment flexibility and sold to run entirely inside your own infrastructure.
Key Capabilities
Flexible Deployment Models
The server is a single-file Python service (RHEL / Rocky / Fedora, shipped as an RPM) that binds to loopback behind your existing Apache or nginx reverse proxy Docker, VMware, KVM, OpenStack or bare-metal. The client ships for both hypervisor worlds: an RPM for libvirt/KVM, and a Debian package for Proxmox VE in two flavors — A (qcow2 + QEMU-native LUKS) and B (LUKS2 on the raw zvol via cryptsetup). One protocol, one server, every estate.
Keys That Never Rest on the Hypervisor
The passphrase is fetched at boot, used to open the disk, and immediately dropped QEMU holds the open volume, so the key is gone from the host. There is no keyfile on disk, no secret in the VM config, nothing for an attacker with the image to find.
Per-Restart Keyslot Rotation
Every boot can rotate the LUKS keyslot: the key that opened the disk is retired and replaced on a strict commit-before-erase order, so a crash never locks the VM out. A key that leaks ages out of usefulness within a single reboot.
Sealed, End-to-End Delivery
Each passphrase is sealed to the requesting host’s X25519 public key and signed by a per-customer Ed25519 key that chains to a 50-year certificate authority. The secret is unreadable in transit safe even over a plain HTTP hop inside your network and provably from yREMORA, not an impostor on the path.
Layered, Zero-Trust Access Control
Every hypervisor-facing request clears three independent gates: a mutual-TLS client certificate per hypervisor (terminated at your proxy), a bearer token, and a source-IP allowlist that accepts single hosts or CIDR blocks, IPv4 and IPv6, validated at startup. Enrolment binds a licence to exactly one machine’s fingerprint on first use.
Authenticated Encryption & Tamper Detection
Optional per-VM dm-integrity (AEAD) upgrades confidentiality-only disks to authenticated ones: silent bit-rot or tampering of the ciphertext at rest becomes a hard I/O error, raised to the operator as a CLIENT INTEGRITY FAILURE alarm.
Downgrade & Tamper Tripwires
A request that omits the sealing nonce, the signature of a downgraded or impersonated client, is not answered with a key: the VM fails to boot as though the disk were corrupt, and the real event goes only to the server log, teaching an attacker nothing.
Per-VM Licensing & Policy
Every VM is a licence with an owner (customer), an expiry, a revoke switch, and a release policy: auto (released without asking) or approve (an operator confirms each boot). Revoke a licence and that VM never boots again; let it expire and it stops on schedule.
RESTful Admin API & Operator Console
vmward-adm and a read-only web console drive customers, hypervisors, licences, live boot approvals, a full authorization audit trail, a log / integrity view, consistent online database backups, and break-glass key recovery all over admin tokens surface, never exposed through the proxy.
Ideal For
Hosting providers, managed-service providers, and enterprises running fleets of VMs on Proxmox VE or libvirt/KVM that must prove their data-at-rest encryption keeps the keys off the machine that runs the disks: multi-tenant estates, data-sovereignty and compliance regimes (GDPR and friends), and anyone who needs a stolen or seized disk image to be worthless without the authority server’s blessing.
Commercial Competition Analysis
| Solution | Where it falls short for VM disk keys | vmward’s difference |
|---|---|---|
| HashiCorp Vault (auto-unseal / Transit) | General secrets manager; no VM-boot integration, no per-boot rotation, no decoy defense | Purpose-built for Proxmox/libvirt boot, per-restart rotation, sealed-to-host delivery |
| Cloud KMS (AWS KMS, Azure Key Vault) | Ties your keys to a cloud you may be trying to leave | Runs on your own infrastructure, zero cloud dependency |
| KMIP appliances (Thales, Fortanix) | HSM-centric, costly, heavyweight to operate | Software, open foundation, per-VM licensing, no appliance |
| SED / TCG Opal (self-encrypting drives) | Hardware-bound, weak key lifecycle, nothing per-VM or per-boot | Software keys held off-host, rotated every boot, per-VM scoped |
| clevis / tang (network-bound disk encryption) | Unseals from a network server, but no rotation, no per-VM policy/licensing, no host-sealing, no tamper/decoy defense | Adds licensing, rotation, sealing, tamper tripwires, and Proxmox/libvirt integration |
| Manual LUKS + keyfile | The key sits with the disk it protects | Removes the key from the host entirely |
Open-Source Foundation
No proprietary crypto and no black boxes: vmward stands on LUKS2 / dm-crypt (cryptsetup), X25519 / Ed25519 / AES (OpenSSL), Python 3 all auditable, all industry-standard, no vendor lock-in. yREMORA integrates, hardens, deploys, and supports the complete solution.
Deployment & Licensing
vmward is delivered to run on your infrastructure both the authority server and the hypervisor clients live inside your estate, and keys, licences, and audit never leave your control. Licensed per hypervisor fleet, with deployment and hardening by yREMORA. Contact for a quote.
Get vmward
- Get a Quote — tell us your hypervisor platform (Proxmox VE / libvirt) and fleet size.
- WhatsApp: +39 33 38611161
Pairs with yREMORA Security Consultancy, Deployment Services, and Monitoring Services. Join our newsletter for free telecom & security tips.