This commit is contained in:
Paolo Matarazzo
2023-10-02 16:54:12 -04:00
parent 0ba5c016df
commit 67ff759f20
8 changed files with 37 additions and 19 deletions

View File

@ -23,15 +23,15 @@ To defend against malicious reset attacks, BitLocker uses the TCG Reset Attack M
## Security policies
Pre-boot authentication and DMA policies provide additional protection for BitLocker.
Preboot authentication and DMA policies provide extra protection for BitLocker.
### Pre-boot authentication
### Preboot authentication
Pre-boot authentication with BitLocker can require the use of either user input, such as a PIN, a startup key, or both to authenticate prior to making the contents of the system drive accessible.
Preboot authentication with BitLocker can require the use of either user input, such as a PIN, a startup key, or both to authenticate prior to making the contents of the system drive accessible.
BitLocker accesses and stores the encryption keys in memory only after pre-boot authentication is completed. If Windows can't access the encryption keys, the device can't read or edit the files on the system drive. The only option for bypassing pre-boot authentication is entering the *recovery key*.
BitLocker accesses and stores the encryption keys in memory only after preboot authentication is completed. If Windows can't access the encryption keys, the device can't read or edit the files on the system drive. The only option for bypassing preboot authentication is entering the *recovery key*.
Pre-boot authentication is designed to prevent the encryption keys from being loaded to system memory without the trusted user supplying another authentication factor. This feature helps mitigate DMA and memory remanence attacks.
Preboot authentication is designed to prevent the encryption keys from being loaded to system memory without the trusted user supplying another authentication factor. This feature helps mitigate DMA and memory remanence attacks.
On devices with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in four ways:
@ -40,12 +40,14 @@ On devices with a compatible TPM, operating system drives that are BitLocker-pro
- **TPM with PIN**: in addition to the protection that the TPM provides, BitLocker requires that the user enters a PIN. Data on the encrypted volume can't be accessed without entering the PIN. TPMs also have [anti-hammering protection](/windows/security/hardware-protection/tpm/tpm-fundamentals#anti-hammering) that is designed to prevent brute force attacks that attempt to determine the PIN
- **TPM with startup key and PIN**: in addition to the protection that the TPM provides, part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the TPM. This configuration provides multifactor authentication so that if the USB key is lost or stolen, it can't be used for access to the drive, because the PIN is also required
Pre-boot authentication with a PIN can mitigate an attack vector for devices that use a bootable eDrive because an exposed eDrive bus can allow an attacker to capture the BitLocker encryption key during startup. Pre-boot authentication with a PIN can also mitigate DMA port attacks during the window of time between when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port-related policies that have been configured.
Preboot authentication with a PIN can mitigate an attack vector for devices that use a bootable eDrive because an exposed eDrive bus can allow an attacker to capture the BitLocker encryption key during startup. Preboot authentication with a PIN can also mitigate DMA port attacks during the window of time between when BitLocker unlocks the drive and Windows boots to the point that Windows can set any port-related policies that have been configured.
On the other hand, Pre-boot authentication-prompts can be inconvenient to users. In addition, users who forget their PIN or lose their startup key are denied access to their data until they can contact their organization's support team to obtain a recovery key. Pre-boot authentication can also make it more difficult to update unattended or remotely administered devices because a PIN must be entered when a device reboots or resumes from hibernation.
On the other hand, Preboot authentication-prompts can be inconvenient to users. In addition, users who forget their PIN or lose their startup key are denied access to their data until they can contact their organization's support team to obtain a recovery key. Preboot authentication can also make it more difficult to update unattended or remotely administered devices because a PIN must be entered when a device reboots or resumes from hibernation.
To address these issues, [BitLocker Network Unlock](network-unlock.md) can be deployed. Network Unlock allows systems that meet the hardware requirements and have BitLocker enabled with TPM+PIN to boot into Windows without user intervention. It requires direct ethernet connectivity to a Windows Deployment Services (WDS) server.
To learn more, see the policy setting [Require additional authentication at startup](policy-settings.md?tabs=os#require-additional-authentication-at-startup).
### Protect DMA ports
It's important to protect DMA ports, as external peripherals may gain unauthorized access to memory. Depending on the device capabilities, there are different options to protect DMA ports. To learn more, see the policy setting [Disable new DMA devices when this computer is locked](policy-settings.md?tabs=common#disable-new-dma-devices-when-this-computer-is-locked).
@ -90,9 +92,9 @@ Therefore, organizations that use BitLocker may want to use Hibernate instead of
### Tricking BitLocker to pass the key to a rogue operating system
An attacker might modify the boot manager configuration database (BCD), which is stored on a non-encrypted partition and add an entry point to a rogue operating system on a different partition. During the boot process, BitLocker code makes sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, we don't recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5.
An attacker might modify the boot manager configuration database (BCD), which is stored on a nonencrypted partition and add an entry point to a rogue operating system on a different partition. During the boot process, BitLocker code makes sure that the operating system that the encryption key obtained from the TPM is given to, is cryptographically verified to be the intended recipient. Because this strong cryptographic verification already exists, we don't recommend storing a hash of a disk partition table in Platform Configuration Register (PCR) 5.
An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This won't succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the BitLocker key.
An attacker might also replace the entire operating system disk while preserving the platform hardware and firmware and could then extract a protected BitLocker key blob from the metadata of the victim OS partition. The attacker could then attempt to unseal that BitLocker key blob by calling the TPM API from an operating system under their control. This can't succeed because when Windows seals the BitLocker key to the TPM, it does it with a PCR 11 value of 0, and to successfully unseal the blob, PCR 11 in the TPM must have a value of 0. However, when the boot manager passes the control to any boot loader (legitimate or rogue) it always changes PCR 11 to a value of 1. Since the PCR 11 value is guaranteed to be different after exiting the boot manager, the attacker can't unlock the BitLocker key.
## Attacker countermeasures
@ -106,15 +108,15 @@ This attacker of opportunity doesn't use destructive methods or sophisticated fo
Mitigation:
- Pre-boot authentication set to TPM only (the default)
- Preboot authentication set to TPM only (the default)
### Attacker with skill and lengthy physical access
Targeted attack with plenty of time; this attacker will open the case, will solder, and will use sophisticated hardware or software.
Targeted attack with plenty of time; the attacker opens the case, solder, and uses sophisticated hardware or software.
Mitigation:
- Pre-boot authentication set to TPM with a PIN protector (with a sophisticated alphanumeric PIN [enhanced pin] to help the TPM anti-hammering mitigation).
- Preboot authentication set to TPM with a PIN protector (with a sophisticated alphanumeric PIN [enhanced pin] to help the TPM anti-hammering mitigation).
-And-
@ -128,7 +130,7 @@ Mitigation:
> [!IMPORTANT]
> These settings are **not configured** by default.
For some systems, bypassing TPM-only may require opening the case, and may require soldering, but could possibly be done for a reasonable cost. Bypassing a TPM with a PIN protector would cost much more, and require brute forcing the PIN. With a sophisticated enhanced PIN, it could be nearly impossible. To learn more about the policy setting, see [Allow enhanced PINs for startup](policy-settings.md?tabs=os#allow-enhanced-pins-for-startup).
For some systems, bypassing TPM-only may require opening the case, and may require soldering, but could possibly be done for a reasonable cost. Bypassing a TPM with a PIN protector would cost more, and require brute forcing the PIN. With a sophisticated enhanced PIN, it could be nearly impossible. To learn more about the policy setting, see [Allow enhanced PINs for startup](policy-settings.md?tabs=os#allow-enhanced-pins-for-startup).
For secure administrative workstations, it's recommended to:

View File

@ -5,7 +5,7 @@ metadata:
ms.collection:
- tier1
ms.topic: faq
ms.date: 09/29/2023
ms.date: 10/02/2023
title: BitLocker FAQ
summary: Learn more about BitLocker by reviewing the frequently asked questions.

View File

@ -58,3 +58,9 @@ BitLocker has the following requirements:
> [!NOTE]
> Licensing requirements for BitLocker enablement are different from the licensing requirements for BitLocker management. To learn more, see [Configure BitLocker](configure.md).
## Next steps
> [!div class="nextstepaction"]
> Learn about technologies and features to protect against attacks on the BitLocker encryption key:
> [BitLocker countermeasures >](countermeasures.md)

View File

@ -0,0 +1,211 @@
---
title: Protecting cluster shared volumes and storage area networks with BitLocker
description: This article for IT pros describes how to protect CSVs and SANs with BitLocker.
ms.topic: conceptual
ms.date: 11/08/2022
---
# Protecting cluster shared volumes and storage area networks with BitLocker
**Applies to:**
- Windows Server 2016 and above
This article describes the procedure to protect cluster shared volumes (CSVs) and storage area networks (SANs) by using BitLocker.
BitLocker protects both physical disk resources and cluster shared volumes version 2.0 (CSV2.0). BitLocker on clustered volumes provides an extra layer of protection that can be used by administrators wishing to protect sensitive, highly available data. The administrators use this extra layer of protection to increase the security to resources. Only certain user accounts provided access to unlock the BitLocker volume.
## Configuring BitLocker on Cluster Shared Volumes
### Using BitLocker with clustered volumes
Volumes within a cluster are managed with the help of BitLocker based on how the cluster service "views" the volume to be protected. The volume can be a physical disk resource such as a logical unit number (LUN) on a SAN or network attached storage (NAS).
> [!IMPORTANT]
> SANs used with BitLocker must have obtained Windows Hardware Certification. For more info, see [Windows Hardware Lab Kit](/windows-hardware/drivers/).
Instead, the volume can be a cluster-shared volume. Windows Server 2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. The volumes that are designated for a cluster must do the following tasks:
- It must turn on BitLocker—only after this task is done, can the volumes be added to the storage pool.
- It must put the resource into maintenance mode before BitLocker operations are completed.
Windows PowerShell or the `manage-bde.exe` command-line tool is the preferred method to manage BitLocker on CSV2.0 volumes. This method is recommended over the BitLocker Control Panel item because CSV2.0 volumes are mount points. Mount points are an NTFS object that is used to provide an entry point to other volumes. Mount points don't require the use of a drive letter. Volumes that lack drive letters don't appear in the BitLocker Control Panel item. Additionally, the new Active Directory-based protector option required for cluster disk resource or CSV2.0 resources isn't available in the Control Panel item.
> [!NOTE]
> Mount points can be used to support remote mount points on SMB-based network shares. This type of share is not supported for BitLocker encryption.
If there's a thinly provisioned storage, such as a dynamic virtual hard disk (VHD), BitLocker runs in **Used Disk Space Only** encryption mode. The **`manage-bde.exe -WipeFreeSpace`** command can't be used to transition the volume to full-volume encryption on thinly provisioned storage volumes. The usage of **`manage-bde.exe -WipeFreeSpace`** command is blocked to avoid expanding thinly provisioned volumes to occupy the entire backing store while wiping the unoccupied (free) space.
### Active Directory-based protector
An Active Directory Domain Services (AD DS) protector can also be used for protecting clustered volumes held within the AD DS infrastructure. The **ADAccountOrGroup** protector is a domain security identifier (SID)-based protector that can be bound to a user account, machine account, or group. When an unlock request is made for a protected volume, the following events take place:
- BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to unlock or deny the request.
- BitLocker will unlock protected volumes without user intervention by attempting protectors in the following order:
1. Clear key
2. Driver-based auto-unlock key
3. **ADAccountOrGroup** protector
a. Service context protector
b. User protector
4. Registry-based auto-unlock key
> [!NOTE]
> A Windows Server 2012 or later domain controller is required for this feature to work properly.
### Turning on BitLocker before adding disks to a cluster using Windows PowerShell
BitLocker encryption is available for disks before these disks are added to a cluster storage pool.
> [!NOTE]
> The advantage of The BitLocker encryption can even be made available for disks after they are added to a cluster storage pool.
The advantage of encrypting volumes prior to adding them to a cluster is that the disk resource need not be suspended to complete the operation.
To turn on BitLocker for a disk before adding it to a cluster:
1. Install the BitLocker Drive Encryption feature if it isn't already installed.
2. Ensure the disk is an NTFS-formatted one and has a drive letter assigned to it.
3. Identify the name of the cluster with Windows PowerShell.
```powershell
Get-Cluster
```
4. Enable BitLocker on a volume with an **ADAccountOrGroup** protector, using the cluster name. For example, use a command such as:
```powershell
Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
> [!WARNING]
> An **ADAccountOrGroup** protector must be configured using the cluster CNO for a BitLocker enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a traditional failover cluster.
5. Repeat the preceding steps for each disk in the cluster.
6. Add the volume(s) to the cluster.
### Turning on BitLocker for a clustered disk using Windows PowerShell
When the cluster service owns a disk resource already, the disk resource needs to be set into maintenance mode before BitLocker can be enabled. To turn on the BitLocker for a clustered disk using Windows PowerShell, perform the following steps:
1. Install the BitLocker drive encryption feature if it isn't already installed.
2. Check the status of the cluster disk using Windows PowerShell.
```powershell
Get-ClusterResource "Cluster Disk 1"
```
3. Put the physical disk resource into maintenance mode using Windows PowerShell.
```powershell
Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource
```
4. Identify the name of the cluster with Windows PowerShell.
```powershell
Get-Cluster
```
5. Enable BitLocker a volume with an **ADAccountOrGroup** protector, using the cluster name. For example, use a command such as:
```powershell
Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$
```
> [!WARNING]
> An **ADAccountOrGroup** protector must be configured using the cluster CNO for a BitLocker-enabled volume to either be shared in a cluster-shared Volume or to fail over properly in a traditional failover cluster.
6. Use **Resume-ClusterResource** to take back the physical disk resource out of maintenance mode:
```powershell
Get-ClusterResource "Cluster Disk 1" | Resume-ClusterResource
```
7. Repeat the preceding steps for each disk in the cluster.
### Adding BitLocker-encrypted volumes to a cluster using `manage-bde.exe`
**`Manage-bde.exe`** can also be used to enable BitLocker on clustered volumes. The steps needed to add a physical disk resource or CSV2.0 volume to an existing cluster are:
1. Verify that the BitLocker drive encryption feature is installed on the computer.
2. Ensure new storage is formatted as NTFS.
3. Encrypt the volume, add a recovery key and add the cluster administrator as a protector key using **`manage-bde.exe`** in a command prompt window. For example:
```cmd
manage-bde.exe -on -used <drive letter> -RP -sid domain\CNO$ -sync
```
1. BitLocker will check to see if the disk is already part of a cluster. If it is, administrators will encounter a hard block. Otherwise, the encryption continues.
2. Using the -sync parameter is optional. However, using the -sync parameter has the advantage of ensuring the command waits until the encryption for the volume is completed. The volume is then released for use in the cluster storage pool.
4. Open the Failover Cluster Manager snap-in or cluster PowerShell cmdlets to enable the disk to be clustered.
- Once the disk is clustered, it's enabled for CSV.
5. During the resource online operation, cluster checks whether the disk is BitLocker encrypted.
1. If the volume isn't BitLocker enabled, traditional cluster online operations occur.
2. If the volume is BitLocker enabled, BitLocker checks if the volume is **locked**. If the volume is **locked**, BitLocker impersonates the CNO and unlocks the volume using the CNO protector. If these actions by BitLocker fail, an event is logged. The logged event will state that the volume couldn't be unlocked and the online operation has failed.
6. Once the disk is online in the storage pool, it can be added to a CSV by right-clicking the disk resource, and choosing "**Add to cluster shared volumes**".
CSVs include both encrypted and unencrypted volumes. To check the status of a particular volume for BitLocker encryption run the `manage-bde.exe -status` command as an administrator with a path to the volume. The path must be one that is inside the CSV namespace. For example:
```cmd
manage-bde.exe -status "C:\ClusterStorage\volume1"
```
### Physical disk resources
Unlike CSV2.0 volumes, physical disk resources can only be accessed by one cluster node at a time. This condition means that operations such as encrypting, decrypting, locking, or unlocking volumes require a context to perform. For example, a physical disk resource can't unlock or decrypt if it isn't administering the cluster node that owns the disk resource because the disk resource isn't available.
### Restrictions on BitLocker actions with cluster volumes
The following table contains information about both physical disk resources (that is, traditional failover cluster volumes) and cluster shared volumes (CSV) and the actions that are allowed by BitLocker in each situation.
| Action | On owner node of failover volume | On Metadata Server (MDS) of CSV | On (Data Server) DS of CSV | Maintenance Mode |
|--- |--- |--- |--- |--- |
|**`Manage-bde.exe -on`**|Blocked|Blocked|Blocked|Allowed|
|**`Manage-bde.exe -off`**|Blocked|Blocked|Blocked|Allowed|
|**`Manage-bde.exe Pause/Resume`**|Blocked|Blocked**|Blocked|Allowed|
|**`Manage-bde.exe -lock`**|Blocked|Blocked|Blocked|Allowed|
|**`Manage-bde.exe -wipe`**|Blocked|Blocked|Blocked|Allowed|
|**Unlock**|Automatic via cluster service|Automatic via cluster service|Automatic via cluster service|Allowed|
|**`Manage-bde.exe -protector -add`**|Allowed|Allowed|Blocked|Allowed|
|**`Manage-bde.exe -protector -delete`**|Allowed|Allowed|Blocked|Allowed|
|**`Manage-bde.exe -autounlock`**|Allowed (not recommended)|Allowed (not recommended)|Blocked|Allowed (not recommended)|
|**`Manage-bde.exe -upgrade`**|Allowed|Allowed|Blocked|Allowed|
|**Shrink**|Allowed|Allowed|Blocked|Allowed|
|**Extend**|Allowed|Allowed|Blocked|Allowed|
> [!NOTE]
> Although the **`manage-bde.exe -pause`** command is blocked in clusters, the cluster service automatically resumes a paused encryption or decryption from the MDS node.
In the case where a physical disk resource experiences a failover event during conversion, the new owning node detects that the conversion isn't complete and completes the conversion process.
### Other considerations when using BitLocker on CSV2.0
Some other considerations to take into account for BitLocker on clustered storage include:
- BitLocker volumes have to be initialized and begin encryption before they're available to add to a CSV2.0 volume.
- If an administrator needs to decrypt a CSV volume, remove the volume from the cluster or put it into disk maintenance mode. The CSV can be added back to the cluster while waiting for decryption to complete.
- If an administrator needs to start encrypting a CSV volume, remove the volume from the cluster or put it into maintenance mode.
- If conversion is paused with encryption in progress and the CSV volume is offline from the cluster, the cluster thread (health check) automatically resumes conversion when the volume is online to the cluster.
- If conversion is paused with encryption in progress and a physical disk resource volume is offline from the cluster, the BitLocker driver automatically resumes conversion when the volume is online to the cluster.
- If conversion is paused with encryption in progress, while the CSV volume is in maintenance mode, the cluster thread (health check) automatically resumes conversion when moving the volume back from maintenance.
- If conversion is paused with encryption in progress, while the disk resource volume is in maintenance mode, the BitLocker driver automatically resumes conversion when the volume is moved back from maintenance mode.

View File

@ -1,8 +1,6 @@
items:
- name: Overview
href: index.md
- name: BitLocker device encryption
href: bitlocker-device-encryption.md
- name: BitLocker countermeasures
href: countermeasures.md
- name: Deployment guides
@ -13,6 +11,8 @@ items:
href: bitlocker-basic-deployment.md
- name: BitLocker deployment comparison
href: bitlocker-deployment-comparison.md
- name: BitLocker device encryption
href: bitlocker-device-encryption.md
- name: How-to guides
items:
- name: Manage BitLocker in your organization
@ -35,8 +35,8 @@ items:
href: policy-settings.md
- name: BCD settings
href: bcd-settings-and-bitlocker.md
- name: BitLocker frequently asked questions (FAQ)
href: faq.yml
- name: Frequently asked questions (FAQ)
href: faq.yml
- name: Troubleshooting
items:
- name: Troubleshoot BitLocker 🔗