Securely design your applications and protect your sensitive data with VBS enclaves

In November 2023, Microsoft’s Brad Smith and Charlie Bell announced the Secure Future Initiative (SFI), a new initiative to pursue our next generation of cybersecurity protection. At Microsoft and Windows, we have a unique responsibility and leading role to play in securing the future for our customers and our community. As you saw in David Weston’s blog post on Windows 11 security, we have a longstanding commitment to security in Windows. We introduced the Secured-core PC to help secure from chip to cloud and that critical layer of computing. In Windows 11, hardware and software work together to help shrink the attack surface, protect system integrity, and shield valuable data. Windows 11 comes with several security advances that protect our customers from Credential and identity theft, such as Local Security Authority protection, Advanced key protection using VBS, Windows Hello hardening etc.

 

Along with credential protection, we also prioritized helping app developers better protect people from phishing attacks and malware. One of the key advances we have made in this area is a feature called VBS enclaves. With Windows 11* and Windows Server 2025, VBS enclaves are now available to third-party application developers.

 

The next sections of this blog post will describe VBS Enclaves, its internals and how to use VBS Enclaves as a developer.

 

VBS enclaves

A VBS enclave is a software-based trusted execution environment (TEE) inside a host application. This is a revolutionary change in our security model for the application, allowing an app to protect its secrets using the power of VBS, from admin-level attacks.

 

Some background: Virtualization Based Security (VBS) is the core feature of Windows used to the high value secrets stored within Windows (e.g., Credential Guard). VBS utilizes the Hyper-V hypervisor to create an environment that is higher privileged than the rest of the system kernel. Like VM isolation, the hypervisor sets memory protections in the second level address tables and IOMMU tables to isolate this environment from the rest of the system kernel. The secure kernel (part of VBS) can also provide memory integrity protection to the system kernel, ensuring the system loads only signed drivers that are not tampered with.

 

We are now extending the isolated user mode in the VBS environment to allow developers to protect portions of application data in a software-based trusted execution environment (TEE) known as a VBS enclave.

 

As mentioned, a VBS enclave is a software-based TEE inside the address space of a host application. It is a Dynamic Link Library (DLL) loaded by a standard Windows application. VBS enclaves can help secure secrets and sensitive operations in memory. The basic premise is that a VBS enclave can isolate a portion of your application that you want to secure while it is in memory – for example, to securely decrypt and process sensitive information. To understand how a VBS enclave isolates secrets, you’ll need to understand the underlying technology it leverages, VBS. As mentioned earlier, VBS uses the Windows Hyper-V hypervisor to create an isolated, privileged virtual environment known as Virtual Trust Level 1 (or VTL1) that becomes the root of trust of the OS. The traditional Windows environment is called VTL0. VTL1 is further split into isolated user mode and the secure kernel. Windows uses VTL1 to host many of its security features. The hypervisor uses the second level address tables to maintain access and privileges for these virtual trust levels. The higher the number, the higher the privilege level. This means everything in a higher VTL is isolated from everything in a lower VTL.

 

The isolation provided by VBS is the core technology that allows a VBS enclave to isolate a portion of an application in higher-privilege VTL1, inaccessible to VTL0. Let’s look at what an application hosting a VBS enclave looks like: 

 

 

The enclave hosting application lives in VTL0 and calls into the enclave when it needs to perform sensitive operations. Control is transferred to the VBS enclave, and the CPU register state is cleaned (except for specific parameter and result registers). Note that code and data inside a VBS enclave is inaccessible to VTL0 (including its own host application) and to other processes in VTL1. Code and data inside of a VBS enclave is visible only to the enclave itself, the VTL1 secure kernel, and the hypervisor.

 

At this point, you might be thinking “What’s stopping an attacker from exploiting the enclave in VTL1?” Good question! Though there is usually a process boundary between a non-Enclave application and a malicious actor in VTL0, by moving part of the application into VTL1, we add an additional boundary for the attacker to cross. This additional boundary is enforced by the hypervisor and is designed to be much more rigid. Think of VBS enclaves as a way to further harden your applications. VTL1 is a privileged space, and we don’t allow code other than Microsoft-signed code to run in the VTL1 secure kernel. The boundary between VTL0 and VTL1 is much more rigid to ensure that we can maintain this high bar.

 

This strong boundary doesn’t come for free. Accessing VTL1 is – at least more expensive than accessing VTL0 (we’re talking fractions of a millisecond here). Additionally, unlike VTL0 which has a lower barrier to entry, VTL1 requires all code to be signed. So, although VTL1 is a higher-privileged space, this privilege is maintained by requiring additional efforts by developers who wish to leverage VTL1. The nature of these efforts can be illustrated through some of the tenets VBS enclaves were designed with:

 

Limited API Surface

This is by design and serves a couple of purposes. Firstly, the smaller the range of functionality is within an enclave, the smaller the attack surface becomes. This ensures we can maintain the integrity of VTL1. Secondly, having a small API surface requires that you, the developer, think about how to best design your application so you only isolate what is critical in VTL1. Again, accessing VTL1 is comparatively expensive, so design your application wisely.

 

Code Integrity

Only code signed by Microsoft using a Trusted Signing VBS enclave certificate profile is permitted to run in an enclave. This includes loaded DLLs into the enclave. When control is handed from the VTL0 host application to the enclave, the VTL1 secure kernel will first verify that all the enclave code and data are authentic and are authorized to run inside of an enclave using image signature verification on the enclave image. This allows us to maintain our high bar for what we allow into VTL1.

 

This requirement means that developers are required to use Trusted Signing to obtain a certificate to production-sign their enclaves.

 

Attestation

Together with code integrity, VBS enclaves can generate attestation reports to attest to the state of the host system, the enclave itself, all DLLs that may have been loaded into the enclave, and whether the enclave is executing in debug mode. Note that once an enclave is initialized by the host application, the host can no longer modify the enclave and , to maintain the attestation state of the enclave throughout its lifetime. Attestation ensures that the code running in the enclave is exactly what you expect. Using a VBS enclave-generated attestation report and the MAA attestation service, you can attest to the state of the Enclave.

 

How do I use a VBS enclave?

You can use VBS enclaves to store secrets, seal data and perform decrypt operations, all in an isolated environment. The first step, as with any security feature, is thinking about secure design. VBS enclaves limit what you can do to maintain their security guarantees, so it isn’t as simple as moving the bulk of your application to live inside one.

 

Some considerations as you design an enclave:

• A VBS enclave can be loaded by any application, not just the intended host application. Design your enclave without placing trust in the host application.
• VBS enclaves operate by isolating from VTL0. To maintain the security promises of a VBS enclave, treat VTL0 as an untrusted environment. This includes not sending sensitive data outside of a VBS enclave. Only trust the enclave itself.
• Ensure you understand the APIs available to you from within the enclave. Networking, for example, is not supported.

A sample use case of a VBS enclave is in Always Encrypted with secure enclaves for Azure SQL Database and SQL Server.

 

 

Always Encrypted protects the confidentiality of sensitive data from the database engine and administrators, placing trust only in the database clients to whom the data belongs. In the database, the sensitive data exists in an encrypted state. The data is only decrypted on the client side, where operations can be performed on it. In the database engine, operations are limited to equality checks.

 

Always Encrypted with secure enclaves, however, adds a VBS enclave to the database engine. When the database engine encounters computations on encrypted data, it delegates these computations to a VBS enclave, where the enclave decrypts the data and performs computations on plaintext. Employing a VBS enclave here makes it so database administrators cannot see the data inside the VBS enclave. With the use of VBS enclaves, Always Encrypted with secure enclaves can perform richer confidential queries and in-place cryptographic operations than Always Encrypted without secure enclaves, all without having to place trust in the database administrators.

 

The database client establishes a secure channel with the database engine containing the VBS enclave and identifies which columns are encrypted and manages encryption of these parameters in both directions. Now, when the database engine encounters operations on encrypted columns, it can delegate these to the VBS enclave. In the enclave the data can securely be decrypted if needed, and the operation can be performed.

 

Always Encrypted with secure enclaves is a fantastic use case of VBS enclaves:

 

• The VBS enclave never reveals the decrypted information to the host application – the database engine in this case. It only trusts itself.
• The database engine hosting the VBS enclave uses a secure channel (Transport Layer Security or TLS) to communicate with the database client.
• By utilizing VBS enclaves, the database client no longer  performs all of the operations on sensitive data client-side after decrypting them.

 

The Always Encrypted with secure enclaves use case illustrates the importance of secure design when thinking about how to employ VBS enclaves in your application. When used effectively, VBS enclaves are a powerful tool.

 

Now that you understand VBS enclaves and all that they can do, jump into the docs here, or read on for a guide on how to build your first VBS enclave by following the development guide here.

 

We hope this blog has you as excited as we are to begin developing secure applications with VBS Enclaves on Windows 11* and Windows Server 2025! We look forward to your feedback! Also take a look at the Windows Security Book to learn more about Windows Security technologies.

 

Hilal Asmat, Akash Trehan, and Hari (on behalf of the enclaves team) 

 

*VBS Enclaves are available on Windows 11 Build 26100.2314 or later and Windows Server 2025 or later