In the evolving landscape of cybersecurity, the implementation of a trusted execution environment on personal computers transcends the mere safeguarding of artificial intelligence. It serves as a robust shield for sensitive data, introducing an additional layer of security that extends beyond the traditional paradigms of data protection—namely, data at rest and in motion—by focusing on data in use. Although the process of defining and utilizing a Virtualization-Based Security (VBS) Enclave may require a bit more effort, the enhanced security it offers, coupled with only a marginal impact on performance, makes it a worthwhile endeavor.
Windows 11 introduces advanced memory integrity tools that leverage the operating system’s built-in hypervisor to establish a new, isolated, high-privilege segment of system memory known as Virtual Trust Level 1 (VTL 1). While the majority of your code, along with the Windows environment itself, operates at Virtual Trust Level 0 (VTL 0), VTL 1 is dedicated to a secure version of the Windows kernel, complete with its own isolated user mode. This is the operational domain of your VBS Enclave, which functions as part of an application that seemingly traverses the boundary between these two trust levels. In actuality, the VTL 1 enclave is compartmentalized, utilizing secure channels for communication with the rest of the application residing in VTL 0.
Using VBS Enclaves in your applications
To embark on the journey of building and utilizing VBS Enclaves, certain prerequisites must be met. Firstly, ensure that you are operating on Windows 11 or Windows Server 2019 or a later version, with VBS enabled. This can be accomplished through the Windows security tool, via Group Policy, or by utilizing Intune for Mobile Device Management (MDM). As VBS is an integral component of the Memory Integrity service, enabling it across all supported devices is advisable to mitigate security risks, even if the immediate intention is not to incorporate VBS Enclaves into your code.
