The SC//HyperCore™ HyperVisor gives modern workloads the cryptographic building blocks they expect. It offers a verified UEFI boot chain for guests and virtual TPMs to protect keys inside VMs. It also uses AES-256 encryption for all data replicated between clusters. This page covers boot-time integrity, encryption at rest, and encryption in flight.
Secure Boot and UEFI
The SC//HyperCore software supports UEFI, which makes Secure Boot possible for guest virtual machines. Secure Boot is a best practice for virtual machines. When it is active for a VM, the firmware checks the cryptographic signatures of the operating system and other boot-level software. It does this before it lets them run:
- If the signatures are authenticated, the VM boots as normal.
- If the signatures fail validation, compromised or unsigned boot software is blocked from loading.
Secure Boot matters most for protecting guests against certain kinds of malware. That malware tries to insert itself into the boot process and stay in place across reboots.
Virtual Trusted Platform Module (vTPM)
The software exposes a virtual Trusted Platform Module (vTPM) to guest VMs. It gives encryption keys the same kind of security as a physical TPM. vTPM is essential for the secure handling of keys and other sensitive data inside the guest. It is often used with:
- Microsoft BitLocker for full-disk encryption on Windows guests.
- LUKS (Linux Unified Key Setup) for full-disk encryption on Linux guests.
Pair a vTPM with BitLocker or LUKS to encrypt guest storage. The encryption is bound to the VM and protected from offline tampering, and you need no external key infrastructure.
See vTPM Support in SC//HyperCore for how to create a vTPM-equipped VM. That page also covers the difference between the UEFI + vTPM and UEFI + vTPM (Compatibility) Boot Types, and DR/replication considerations. For Secure Boot certificate maintenance, see Updating Expired Secure Boot Certificates on VMs.
Encryption at rest
Inside a cluster, the SCRIBE storage layer in the SC//HyperCore software gives high availability and strong data integrity. The storage layer does not automatically apply native encryption to VM disk data at rest. Instead, the software fully supports customer-managed encryption at the guest operating system level.
Some customers must encrypt data at rest for legal or compliance reasons. For them, this approach has real benefits:
- You keep full control of the encryption keys and key management policy.
- You can tune encryption settings and algorithms to match your compliance program, rather than the platform’s defaults.
- The same encryption setup travels with the guest if it is moved, cloned, or replicated.
Common choices are BitLocker on Windows guests and LUKS on Linux guests. You can back either one with the vTPM described above.
Encryption in flight
When data moves between clusters over public or untrusted networks, the SC//HyperCore software secures it with AES-256 encryption over SSH tunnels. This protects replication traffic during remote-site sync and disaster recovery between clusters.
The replication channel has more safeguards beyond the encrypted tunnel:
- The replication connection requires the SC//HyperCore web interface password. The password authenticates access to the target cluster before the remote connection can start.
- Replication is started explicitly between paired clusters, not against arbitrary endpoints.
Within a site, the system also protects data exchanges. It uses isolated internal backplane networking for cluster traffic, as described in Platform Security Features. So in-flight encryption protects data between sites, and a physically or logically isolated backplane protects it within a site. Together they keep cluster and replication traffic safe from network-layer threats.