This document outlines the security postures, hardware-enforced encryption frameworks, and memory isolation paradigms governing our Sovereign Infrastructure platform.
We separate infrastructure engineering into two distinct, production-ready tiers designed around specific enterprise threat models: Physical Infrastructure Sovereignty (Tier 1) vs. Cryptographic Identity Sovereignty (Tier 2). By aligning our software block virtualization architectures directly with advanced AMD silicon features (SME and SEV-SNP), we deliver confidential computing primitives that mirror or exceed high-end global public cloud security profiles.
🛑 Infrastructure Prerequisite Notice: Bare-Metal Enforcement
⚠️ Critical Deployment Requirements
The hardware-enforced cryptographic and memory isolation primitives detailed in this document require deployment on our Bare-Metal Dedicated Server tiers.
Because these security architectures rely on low-level BIOS adjustments, direct hypervisor access to physical memory controller buses, and advanced AMD processor extensions, these features are structurally unavailable on standard Cloud-Instances or Virtual Private Servers (VPS). True confidential computing requires absolute control over the physical silicon, which is only possible on single-tenant, dedicated bare-metal hardware.
🛠️ The Two-Tier Confidential Computing Framework
Our appliance leverages hardware-assisted cryptographic primitives to secure data both at rest on physical storage flash blocks and in transit within bare-metal physical RAM cells.
===================================================================================
TIER 1: PHYSICAL INFRASTRUCTURE SOVEREIGNTY
[ Physical SSD ] ──► [ Host LUKS2 Container ] ──► [ Thin LVM Pool ] ──► [ Native Linux Guest ]
[ Physical RAM ] ──► [ AMD SME (Transparent Host-Wide Hardware Key Encryption) ]
===================================================================================
===================================================================================
TIER 2: CRYPTOGRAPHIC IDENTITY SOVEREIGNTY
[ Physical SSD ] ──► [ Pass-Through Block Allocation ] ──► [ Guest-Isolated LUKS Container ]
[ Physical RAM ] ──► [ AMD SEV-SNP (Isolated VM Silicon Cryptographic Bubble) ]
===================================================================================
Tier 1: The Sovereign Appliance Tier (Standard Bare-Metal Configuration)
Recommended for most mid-market customers. View the Reference Architecture for this tier.
- Perimeter Posture: Full physical security with zero virtualization performance trade-offs.
- Threat Model Target: Mitigates risk against physical disk theft, data center hardware leaks, physical intrusion, or chain-of-custody drive retirement oversights. Trust is placed in your cloud platform architects and system administrators, but zero trust is placed in the physical data center facility.
- Storage Ingress Layer: Host-Level LUKS Full-Disk Encryption + Unencrypted LVM-Thin Pools. Guest VMs run standard, plain-text Linux file systems (
ext4/XFS) natively mapped down to the host’s secured pool. - Silicon Enforcement (AMD SME): Secure Memory Encryption (SME) is activated at the bare-metal host BIOS level. The AMD Secure Processor dynamically generates a single system-wide cryptographic key at boot time, transparently encrypting the server’s entire physical RAM array directly on the memory bus.
- Operational Outcome: Absolute protection against advanced physical hardware memory vectors (e.g., Cold Boot Attacks where physical RAM cells are frozen, extracted, and scraped for cryptographic key material). Because memory translation occurs seamlessly at the hardware controller level, the hypervisor retains clean visibility into guest VM memory blocks. This preserves native platform management features, including live automated snapshots, cluster cloning, and robust GUI metrics.
Tier 2: The Zero-Trust Enclave Tier (Premium Dedicated Upgrade)
- Perimeter Posture: Absolute cryptographic privacy. The hypervisor and host environment are treated as untrusted runtime zones.
- Threat Model Target: Tailored for ultra-high-compliance industries (e.g., Fintech, Healthcare, Sovereign Identity) whose threat parameters state they cannot blindly trust a data center technician, a hosting infrastructure provider, or an infrastructure architect with low-level hypervisor console terminal access.
- Storage Ingress Layer: Plain-text, unencrypted host block allocation. Cryptographic boundaries are pushed completely into the guest, utilizing individual, isolated LUKS encryption containers compiled inside each distinct Virtual Machine.
- Silicon Enforcement (AMD SEV-SNP): Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) isolates each virtual machine inside its own cryptographically sealed silicon bubble managed directly by the CPU.
- Operational Outcome: Every running VM receives a unique, isolated, hardware-managed RAM encryption key completely hidden from the host system. If an attacker compromises the underlying bare-metal hypervisor or gains unauthorized root terminal access, dumping the active memory of your Core Identity Provider (Defguard OIDC) or secure mail server yields completely unreadable, randomized noise.
Deep-Dive Comparison: Tier 1 vs. Tier 2
| Architectural Feature | Tier 1: Sovereign Appliance (Standard Dedicated) | Tier 2: Zero-Trust Enclave (Premium Dedicated Upgrade) | Standard Cloud-Instance / VPS Tiers |
|---|---|---|---|
| Hardware Dependency | Dedicated Bare-Metal (Requires AMD SME BIOS support) | Dedicated Bare-Metal (Requires AMD SEV-SNP processor extensions) | Shared Virtualization (No access to hardware CPU features) |
| Primary Threat Model | Physical drive theft / Datacenter hardware decommissioning | Hypervisor compromise / Untrusted datacenter administrator | Basic software configuration risks |
| Storage Security Layout | Host-level LUKS (Single master unlock boundary) | Guest-level LUKS (Isolated cryptographic VM barriers) | Shared host storage volume (No baseline physical ownership) |
| Memory Security | AMD SME (System-wide transparent hardware encryption) | AMD SEV-SNP (Hardware-enforced VM enclaves) | None. Memory paths readable by hypervisor neighbors/host. |
| Storage Allocation Efficiency | Maximum. Native LVM-Thin provisioning works out of the box. | Constrained. Block writes require non-wipe configuration formatting. | Variable noisy-neighbor allocation limitations |
| Hypervisor Control Plane | Supports native live snapshots, cloning, and automated GUI backups. | Restricted. Requires specialized guest orchestration and attestation. | Managed entirely by third-party vendor portal |
| Optimal Workloads | Latency-sensitive media streaming (LiveKit), large-scale public storage sharing. | Core Identity Services (Defguard OIDC), secure transaction databases, credential vaults. | Basic testing environments, low-traffic internal web apps |
⚠️ Anti-Pattern Mitigation: The Trap of “Double Encryption”
Our standard Tier 1 environment intentionally isolates encryption to the hypervisor host level rather than utilizing LUKS inside individual virtual guests. Implementing guest-level encryption on top of an already encrypted host environment introduces a critical structural anti-pattern known as Double Encryption.
[ VM Guest Data ] ──► [ LUKS inside VM ] ──► [ Hypervisor I/O ] ──► [ LUKS on Host SSD ] ──► [ Raw Flash Blocks ]
(Decrypted) (Encrypted 1x) (VirtIO Bus) (Encrypted 2x) (Secured)
Running this multi-layered layout outside of a specialized Tier 2 SEV-SNP enclave context introduces three severe architectural degradation vectors:
1. Severe I/O Performance Degradation
Double encryption forces every single write instruction to be processed twice through the Linux kernel’s cryptographic sub-system (dm-crypt). This introduces heavy CPU cycles and drives up disk I/O latency. For real-time, latency-sensitive workflows—such as your LiveKit audio/video streams or Matrix messaging routes—this compounding latency induces packet jitter, stuttering, and frame drops.
2. Destruction of Thin-Provisioning Efficiency
LVM-Thin pools optimize physical storage arrays by allocating disk blocks dynamically only when data is actively written. However, standard encryption algorithms (such as AES-XTS) purposefully populate unallocated virtual space with pseudo-random noise to obscure structural boundaries. Formatting a virtual drive with LUKS inside a guest immediately flushes randomized bits across the entire allocated canvas. The hypervisor reads this noise as an active block instruction, instantly consuming the full allocation from your physical SSD array and destroying thin-provisioning space optimization.
3. High Operational Friction
Deploying LUKS within every individual guest breaks automated recovery pipelines. In the event of a system power loss or scheduled node maintenance, a platform administrator would be forced to supply credentials four separate times: once via a secure remote shell (Dropbear) to unlock the bare-metal machine, and three individual times via the hypervisor console to pass initialization passwords down into each distinct VM during the boot phase.
🔒 Production Verification
By executing LUKS Full-Disk Encryption transparently at the Host Bare-Metal layer, our Tier 1 Sovereign Base functions exactly like an enterprise public cloud array (such as an AWS EBS block device backed by an infrastructure KMS key):
- Inside the Guests: Virtual machines run at 0% cryptographic processing overhead. Standard LVM thin-provisioning strategies run with maximum efficiency, and the operating systems have zero awareness of the underlying security mechanics.
- At Rest: The absolute second the physical machine loses power or undergoes hard shut-down routines, the master LUKS2 block container locks down at the kernel level. If physical storage drives are extracted from the server blades, the contents of your identity databases, secure emails, and communication logs are entirely indistinguishable from random, cryptographically secure noise.