VBS Enclaves represent the latest initiative from Microsoft to leverage virtualization for securing Windows by compartmentalizing critical functions within encrypted virtual machines, utilizing the low-level Krypton hypervisor.
Krypton plays a pivotal role in modern Windows by enabling virtual machines and the host operating system to share a scheduler. This capability permits features such as Windows login to operate independently from the rest of the OS. Consequently, they can maintain their functions while safeguarding passwords and biometric data, remaining protected from malware that may infiltrate the host Windows environment.
This technology serves as the backbone of much of the hardware security in Windows 11, working in conjunction with your PC’s trusted platform modules (TPM) to oversee encryption keys, digital signatures, and verification hashes. You can think of it as significantly mitigating the risk of sensitive data being compromised and also diminishing the threat of malware undermining typically trusted Windows processes.
The concept of virtualization-based security has been within Microsoft’s vision for quite some time, tracing its lineage back to Windows Server 2016 and the launch of Secure Windows containers. Although Windows supported Docker and various container-based application isolation tools that permitted a degree of process isolation, it was not without its flaws.
Secure Windows containers combine both the functions of containers and the security features of Hyper-V, allowing for enhanced isolation by operating secure containers within a virtual machine as opposed to directly on the host operating system. Although this method does introduce the added overhead of managing a separate OS for application containers, solutions like Nano Server and Windows Server Core help mitigate this impact, with ongoing updates resulting in significantly smaller server image sizes.
Microsoft has incorporated this method with TPM capabilities to bolster security in Windows over the years, making it a requirement in Windows 11. This requirement explains why Windows 11 mandates hardware that supports TPM 2.0.
The TPM is responsible for storing keys and certificates to handle digital signatures, enabling tools like the Windows memory integrity service to operate within a fortified virtualized environment through Hyper-V-secured VMs utilizing the Krypton hypervisor. With memory integrity, kernel-mode drivers and binaries are verified for valid signatures prior to execution; any unsigned code is prevented from running and potentially jeopardizing your PC.
Recently, Microsoft has expanded its virtualization-based security framework to include what it terms VBS Enclaves. If you have explored the implementation of confidential computing on Windows Server or in Azure, you may be familiar with the concept of enclaves, which utilize Intel’s SGX instruction set to secure specific memory regions, creating a trusted execution environment. This approach necessitates particular processor configurations, with the most recent generation of SGX being restricted to enterprise Xeon hardware.
VBS Enclaves provide a similar method for safeguarding memory without the need for specialized hardware. This allows Microsoft to deliver secure enclaves across Intel, AMD, and Arm platforms. Consequently, Recall operates solely in trusted memory managed by the Krypton hypervisor, with encryption keys administered by your PC’s TPM and access controlled by Windows Hello, ensuring user verification.
Implementing a trusted execution environment on a PC serves a purpose beyond just AI security. It secures sensitive information, introducing an additional layer of protection that covers not only data at rest and in transit but also data in use. Although defining and utilizing a VBS Enclave requires extra effort, the enhanced security it provides with minimal performance compromise is invaluable.
With the memory integrity features in Windows 11, a VBS Enclave leverages Windows’ built-in hypervisor to establish a new, isolated, high-privilege segment of system memory known as Virtual Trust Level 1. Most applications and Windows itself will continue operating at Virtual Trust Level 0. VTL 1 hosts a secure version of the Windows kernel with its own separate user mode. This environment is where your VBS Enclave operates, as part of an application that seems to span the boundary dividing the two zones. In reality, you are isolating the VTL 1 enclave and using secure channels for communication with it, distinct from the rest of your application in VTL 0.
So how can you construct and utilize VBS Enclaves? To start, ensure you have Windows 11 or Windows Server 2019 or later, with VBS enabled. This can be accomplished through the Windows security tool, a Group Policy, or Intune for MDM control. Since it is part of the Memory Integrity service, it is advisable to activate it on all compatible devices to mitigate security risks, even if you do not intend to implement VBS Enclaves in your development.
The most effective way to understand this concept is as a method for securely utilizing encrypted storage. For instance, if you’re managing sensitive data within a database, you can employ code that operates in an enclave to handle and query that data, subsequently relaying the results to the remainder of your application. This process encapsulates the data within a secure setting, allowing for only necessary access. Other components of your system do not have access to the decryption keys, ensuring that the data on disk remains protected.
In order for code to operate in the VTL 1 environment, it must be signed by Microsoft, and there is an OS-level handoff between the two trust zones that resets CPU registers. This reset minimizes the risk of state transferring between relatively less secure user modes and your VBS Enclave. Naturally, utilizing a VBS Enclave demands more computational resources, which means operations may take longer to execute (although they still only require microseconds).
VBS Enclaves are essentially DLLs and necessitate a host application to function. You are confined to a limited subset of the available Windows system-level C++ APIs, with documentation specifying which Universal C Runtime APIs are accessible. Additionally, supported APIs can be found within the VBS Enclave Runtime (Vertdll) and the Bcrypt cryptographic library.
Microsoft has made available a helpful sample application that demonstrates the lifecycle of a VBS Enclave application, illustrating how to invoke enclave functions from the host application. It is important to explicitly export external functions, as only those functions can be accessed by the host. The compilation of an enclave requires specific configurations in the linker to ensure that the appropriate libraries are included and that the resulting DLL is correctly instrumented. Additional measures are in place to safeguard the VBS Enclave against attacks that may arise from forged platform DLLs.
After your code is compiled, the next step is to sign it. A VBS Enclave signature requires three essential EKUs (Extended Key Usage): one designated for code signing, another for the enclave itself, and one for the author. For production environments, you can utilize Microsoft’s Trusted Signing service, which provides a specific profile for signing enclaves. This method allows for automation of the signing process using the Azure CLI.
When writing code that will utilize VBS Enclaves, there are several critical considerations. Since any application running on the host PC can load these enclaves, it is vital to compose code within the enclave that treats everything external to it as untrusted.
The same underlying technology powers the Always Encrypted feature in Azure SQL and SQL Server. This method guarantees that only those with proper authorization can access sensitive data. T-SQL operations can traverse the secure enclave boundary through confidential queries using an internal TLS channel. These operations occur within the enclave, ensuring that the foundational data remains encrypted at all times.
VBS Enclaves are inherently intricate, imposing substantial limitations on standard DLLs. However, without these restrictions, their security would merely mirror that of standard DLLs. By enforcing stringent controls on code at the library and header levels to function within a trusted execution environment, you effectively mitigate the risk of potential data leaks, whether intentional or accidental.
While it may take a bit more time and require additional system resources, opting for enhanced security is a worthwhile compromise when dealing with sensitive information. Implementing VBS Enclaves and encrypted storage is crucial whenever personally identifiable information (PII) is involved, whether it’s a user’s vector-indexed Recall history, payment details, or health records.
If there’s any potential risk linked to the data, you must have a strong justification for not utilizing this technology. For handling sensitive data, VBS Enclaves ought to be the primary option.