Advancing key protection in Windows using VBS

Today, we are excited to bring you the next step in key protection for Windows. Now in Windows 11 Insider Preview Build 26052 and Windows Server Insider Preview Build 26052, developers can use the Cryptography API: Next Generation (CNG) framework to help secure Windows keys with virtualization-based security (VBS). With this new capability, keys can be protected from admin-level key theft attacks with negligible effect on performance, reliability, or scale.

Now let’s explore how you can create, import, and protect your keys using VBS.

The current state of key protection in Windows

As attackers advance their techniques to steal keys and credentials, Microsoft continues to evolve capabilities to help protect valuable assets across Windows. This is crucial work as when attackers get hold of important keys, they can impersonate users and access resources without their knowledge and consent. Consider the theft of third-party encryption keys - these types of attacks may have privacy and security consequences and could compromise the availability of applications and services.

The default method of protecting keys in Windows is to store them in the memory of a local system process known as the Local Security Authority (LSA). LSA is a great option for storing keys that do not protect high-value assets or require the best performance available. While LSA helps prevent code injection and non-authorized processes from reading memory, an admin or system-level attacker can still steal keys from this memory space.

For a more secure option, the industry is moving towards hardware-based isolation, where keys are stored directly on a hardware security processor like a managed HSM (Hardware Security Module), Trusted Platform Module (TPM) or a Microsoft Pluton security processor, which help provide stronger security against tampering with and exporting keys. While hardware isolation should be used for keys wherever possible, if there are performance or scale requirements that require usage of the central processing unit (CPU) core, VBS is a robust alternative that helps offer stronger security than currently available software protection.

Introducing key protection with VBS in Windows

The security capability we’re introducing today addresses the limitations in the current software and hardware key protection mechanisms on Windows. You can now protect your keys with VBS, which uses the virtualization extension capability of the CPU to create an isolated runtime outside of the normal OS. When in use, VBS keys are isolated in a secure process, allowing key operations to occur without ever exposing the private key material outside of this space. At rest, private key material is encrypted by a TPM key which binds VBS keys to the device. Keys protected in this way cannot be dumped from process memory or exported in plain text from a user’s machine, preventing exfiltration attacks by any admin-level attacker.

VBS helps to offer a higher security bar than software isolation, with stronger performance compared to hardware-based solutions, since it is powered by the device's CPU. While hardware keys offer strong levels of protection, VBS is helpful for services with high security, reliability, and performance requirements.

The following section will show you how to use these capabilities by creating and using VBS keys with NCrypt, which is part of the Cryptography API: Next Generation (CNG) framework.

Tutorial: Leverage the NCrypt API to create and use VBS keys

The core functionality to create and import VBS keys is as simple as passing in an additional flag into the NCrypt API.

NCryptCreatePersistedKey and NCryptImportKey accept two flags to request that VBS should be leveraged to protect the client key's private material:

When it comes to creating VBS keys, the standard CNG encryption algorithms and key lengths for software keys are supported.

Ephemeral and per-boot keys

The default behavior of NCryptCreatePersistedKey and NCryptImportKey is that of a cross-boot persisted key stored on disk that persists across reboot cycles.

Calling NCryptCreatePersistedKey with pszKeyName == NULL creates an ephemeral key rather than a persisted key, and its lifetime is managed by the client process. Ephemeral keys are not written to disk and live in secure memory. An additional flag can be passed in along with the above VBS flags to indicate that a per-boot key should be used to help protect the client key rather than default cross-boot key.

Example: Creating a key with virtualization-based security

The following sample code shows how to create a 2048-bit VBS key with the RSA algorithm:

void
CreatePersistedKeyGuardKey(
    void
    )
{
    SECURITY_STATUS status;
    NCRYPT_PROV_HANDLE hProv = 0;
    NCRYPT_KEY_HANDLE hKey = 0;
    DWORD dwKeySize = 2048;

    status = NCryptOpenStorageProvider(&hProv, MS_KEY_STORAGE_PROVIDER, 0);
    if (status != ERROR_SUCCESS)
    {
        wprintf(L"NCryptOpenStorageProvider failed with %x\n", status);
        goto clean;
    }

    status = NCryptCreatePersistedKey(hProv, &hKey, NCRYPT_RSA_ALGORITHM, L"MyKeyName", 0, NCRYPT_REQUIRE_VBS_FLAG);
    if (status != ERROR_SUCCESS)
    {
        wprintf(L"NCryptCreatePersistedKey failed with %x\n", status);
        goto clean;
    }

    status = NCryptSetProperty(hKey, NCRYPT_LENGTH_PROPERTY, (PBYTE)&dwKeySize, sizeof(DWORD), 0);

    status = NCryptFinalizeKey(hKey, 0);
    if (status != ERROR_SUCCESS)
    {
        wprintf(L"NCryptFinalizeKey failed with %x\n", status);
        goto clean;
    }

    wprintf(L"Created a persisted Key Guard key!\n");

clean:

    if (hKey)
    {
        NCryptFreeObject(hKey);
    }

    if (hProv)
    {
        NCryptFreeObject(hProv);
    }
}

Using VBS keys

Beyond stricter key export policies, a VBS key can be treated like any other Cryptographic Next Generation (CNG) key when it comes to API usage, so developers can refer to the NCrypt API here. This applies to use cases like signing and encryption.

Try protecting your keys with VBS today

This feature is now in Preview and accessible via the Windows Insider Program for both client (Windows 11 Insider Preview Build 26052) and Server (Windows Server Insider Preview Build 26052) The following requirements must be met:

• VBS enabled
  • VBS also has several hardware requirements to run, including Hyper-V (Windows hypervisor), 64-bit architecture, and IOMMU support. See the full list of VBS hardware requirements.
• TPM enabled: For bare-metal environments, TPM 2.0 is required. For VM environments, vTPM (Virtual TPM) is supported.
• UEFI with Secure Boot enabled

Having trouble?

Enable event log to investigate errors:

• Search “Event Viewer” in the start menu
• On the left panel open Applications and Services Logs > Microsoft > Windows > Crypto-NCrypt
• Right-click Operational and select Enable Log (it may already be enabled)
• Right click error events with Event ID 13, 14, or 15 and Task Category “VBS Key Isolation Operation”

We recommend sending any suggestions, questions, or logs through Feedback Hub under Security and Privacy > VBS Key Protection.

You may also reach out to VBSkeyprotection@microsoft.com with questions.

What’s next?

Stay on the lookout for further announcements to support key protection with VBS, and we’ll continue updating our documentation and support guidelines accordingly. We hope that you’ll be able to leverage this security capability to help protect your keys on Windows.

Continue the conversation. Find best practices. Bookmark the Windows Tech Community, then follow us @MSWindowsITPro on X/Twitter. Looking for support? Visit Windows on Microsoft Q&A.