Encrypting Windows Boot Drives

Introduction

In addition to encrypting regular Windows data partitions, you can also encrypt your Windows boot disk (C:). Note that HyTrust does not support dual booting. Encrypting the C: drive, in addition to data partitions, ensures that clear-text data never leaves the VM on its way to storage. This prevents virtualization and storage admins from being able to view the data.

The HyTrust Bootloader for Windows (the Bootloader) is a tool that is required to encrypt the Windows boot partition using keys that are retrieved, as needed, from the HyTrust KeyControl server during VM bootstrap. This means that keys are not kept with the encrypted boot partition, thus providing an extra layer of security.

There are a number of steps required to set up your Windows system for boot drive encryption. If you are running within a virtual infrastructure, we recommend that you go through this process once and set up a template VM from which new VMs can be created.

Requirements

The supported versions of Windows for the Bootloader include:

• Windows 7
• Windows 8 and 8.1
• Windows 10
• Windows 2008 R2
• Windows 2012
• Windows 2012 R2

We also require a Windows System Reserved Partition (SRP). We will create an SRP if one does not already exist.

The Windows Bootloader can only be installed on an MBR disk. GPT disks cannot be configured as encrypted boot drives.

This product will work with and without Service pack 1 installed.

The Bootloader is added as an SRP of roughly 100 MB on Windows 7, Windows 8, Windows 8.1, Windows 10, and Windows 2008 R2, and 350 MB on Windows 2012 and above. As part of the installation process, the boot drive will shrink to free up space for the Bootloader (and Windows SRP if one does not already exist). If there is insufficient space on the boot drive, the Bootloader will fail to install. This whole process is automatic.

Make sure that the Disk Defragmenter service on each client computer is enabled before installing the Policy Agent software. This is needed for compatibility with boot drive encryption. The user account used for installing the software should have the SeRestorePrivilege and the SeTakeOwnershipPrivilege for the Bootloader installation to succeed. Additionally, the SeSecurityPrivilege is required for successful installation on Windows 2008R2.

Additional notes:

• The encrypted boot partition must be on the Windows C: drive. Although Windows itself can boot from alternate drive letters, the HyTrust DataControl Policy Agent is limited to the C: drive only. Note: the boot volume can only be encrypted if it is the C: drive, or if is mapped to C:.
• The Bootloader itself will be assigned a drive letter automatically, although you can specify a drive letter during initial setup of the Bootloader.

Setup and Encryption of the Boot Partition

The installation of the components necessary to boot an encrypted version of Windows is a three-step process.

Step 1 - Install the HyTrust DataControl Policy Agent

First, you must install the HyTrust DataControl Policy Agent (the Policy Agent) software on Windows. You must reboot the Virtual Machine before the agent is activated. For installation instructions, please refer to the section on Encryption Within Windows Virtual Machines .

Be sure to check the box for HT Bootloader when you go through the installation.

Your next dialog box is for Drive and Network Configuration. This configuration is used by the Bootloader to configure its drive letter and network configuration before trying to connect to the KeyControl Server. First, you select the drive letter to be used by the Bootloader. Then, you select the network interface you want to use for the connection. By default, this dialog box presents the current DeviceID (unique integer) and ConnectionID (e.g. Local Area Connection 2) from WMI class Win32_NetworkAdapter for the selected network interface. In most cases you should be able to leave the default choices checked, including Enable DHCP for the selected network interface. Click Install.

NOTE: if a previous Bootloader partition is found, you are prompted to remove it:

We recommend that you click Yes to delete the partition and continue the installation. Next you are reminded to save your key file for possible access to the debug console.

Click OK, and you are prompted to Reboot. Click Reboot now, and then click Finish. Remember that you will have to copy the key file id_rsa to another computer after you reboot.

Note that you can manually reboot at a later time, but your Bootloader installation is not complete until you finish installation by rebooting. When you reboot, your computer will go through a scripted process that involves multiple automatic reboots, and will finally boot back into Windows.

What to do if your Bootloader Installation Fails Due to Lack of Disk Space

There is no need to uninstall the Policy Agent software. Shut down your VM, expand the disk as needed, and then follow the instructions here.

IMPORTANT: You should copy the key file id_rsa to another computer. It is located in the Agent installation directory, C:\Program Files\hcs. This is required to access the HyTrust Bootloader console using SSH, after you have encrypted the root drive of C:. Be certain that you copy the file once your computer has rebooted, and store it on another computer that you can reach via your network. You will need it if you need to troubleshoot your installation from the console.

Start the HyTrust GUI

Once you have copied the id_rsa file, click Start and then click HyTrust GUI, as shown below.

Step 2 - Register the Policy Agent

The HyTrust GUI starts, and presents a Registration screen. Fill in the KeyControl Name or IP address, the Username and Password, and the Cloud VM Set into which you will place this Policy Agent. Then click Register.

When registration is complete, your user interface in the HyTrust GUI will change to show Connected.

Note that you can see the distinction between the Windows boot partition and the root partition by running the Windows diskmgr utility. For example:

The small boot partition is listed as System Reserved, and the HyTrust Bootloader appears as HTBOOTLDR. No part of the Windows root C: is ever decrypted on disk and the boot partition, added during the installation process, contains only a small part of the bootstrap process.

Step 3 - Encrypt the Windows Boot Partition

Next you need to encrypt the Windows root C: drive. Here is the sequence of events that happen:

• Run the HyTrust GUI, as shown below, and select your boot drive. Be aware that larger disks can take a while to encrypt, but the Status column shows you the percentage complete. However, even if the encryption process is not complete, you can continue to use the computer while the encryption process progresses. If you choose to shut down prior to full encryption, you can resume it, using the CLI command: hcl encrypt c:. All interrupted rekey/encryption operations will resume automatically when the VM is rebooted.

When encrypting the C: drive, the process will be displayed in the HyTrust GUI. When complete, the status will change to Attached and will show the algorithm used for the encryption, as shown below. Note that the default boot drive encryption algorithm is AES-XTS-512. If you have virtual machines encrypted prior to the 3.0 release, they will continue to use the AES-256 cipher.

At that point, the encryption process is complete and the VM can be safely shut down or rebooted, as you wish. Bear in mind that your boot-encrypted disk relies upon access to the KeyControl node to validate your access to the boot drive. This is described in the following sections.

The Boot Process

The Bootloader uses a small pre-boot environment to retrieve encryption keys for the boot device each time the system starts up. The system is reconfigured to boot the Bootloader before booting Windows. Here are the steps:

1. You reboot a computer that has an encrypted boot drive.
2. The Bootloader intercepts the boot request, and sends a request to the KeyControl node to retrieve your encryption key for the C: drive.
3. The Bootloader retrieves the key from the KeyControl node and then supplies it to the secondary boot stage which will boot Windows.
4. Windows boots normally.

NOTE: Keys for the C: drive are never stored persistently on the VM, and are only stored on the remote KeyControl node. The following topics describe some of the possible outcomes in the boot process.

Normal Bootstrap

In the following screenshot, you can see the operation of the Bootloader. It indicates that it has successfully contacted the KeyControl node, presented credentials that allow it to retrieve the boot partition encryption key, and retrieved the key. When complete, it will once again reboot, this time into Windows.

Failure to Retrieve Keys When Booting

Since encryption keys are never stored locally, a VM will require access to a KeyControl node when booting. Failure to contact a KeyControl node will prevent the system from booting. If a KeyControl node is not available when the system is booted, it will repeatedly attempt to contact it for 30 seconds, at which time it presents a console menu which allows a number of options. If you are unable to view the console directly, for example in environments such as Amazon AWS, you can access the console using an SSH client. This will require the id_rsa key file that you copied earlier. You can use the following command to access the console menu to copy the id_rsa file:

# ssh -i id_rsa <root@server.ip.addr>

The console menu options are:

1. Reauthenticate. If the credentials of the VM become stale, then it must be re-authenticated to the KeyControl node in much the same way as a running VM would have to do. The most likely reason for this might include the grace period expiring. Another possibility is that your boot drive's IP address is configured via DHCP, which means it may have changed. We recommend static IPs for boot drives, or disabling the IP address check feature in your KeyControl. Choosing this option allows you to re-enter the credentials, using your id_rsa key file. Key retrieval will proceed after this.
2. Update network settings. This takes you back to the network settings screen so that you can update the settings.
3. Update Certificate. This allows updating the VM certificate if it has expired.
4. Drop to shell. Provides a simple recovery shell. Use the command exit to leave the recovery shell. This is primarily for use by HyTrust Support. We recommend against customers using this option.
5. Update NTP settings. This allows the user to update the NTP server address.
6. Clone. This allows us to clone a VM with an encrypted boot drive. This is similar to ‘hcl register -c’ while cloning a non-boot-encrypted VM.
7. Boot Windows with clearkey. This option instructs the Bootloader to boot without an encryption key, and is done automatically if we detect that the boot partition is not encrypted.
8. Restart network. This option instructs the VM to re-attempt to contact the KeyControl server and once again retrieve the encryption key. If no selection is made in this menu after 30 seconds, then this option will be taken automatically. You can see this in the first example, below.
9. Poweroff. Power down the computer.

Note: The first four options appear on all platforms, including Amazon Web Services. The last two appear only in a CLI environment. The screenshot below shows what a failure to retrieve keys and accompanying "Restart Network" looks like:

Key Management

One of the important features offered by this system is the ability to control remote access to the encrypted data from the KeyControl. HyTrust boot encryption also offers this feature. The C: drive is presented in the KeyControl GUI as simply another disk to be managed. Keys can be revoked and access granted in the same manner as non-root disks.

If access to the encrypted C: drive is revoked, the Policy Agent, upon the next heartbeat, will immediately present the BSOD (”Blue Screen Of Death”). The BSOD status code will be set to the value “DEADDEAD” so that it can be quickly determined that a key revocation is the reason for the BSOD.

The BSOD will eventually result in the VM attempting to reboot. Of course, at this time, the key is no longer available, since access has been revoked. Key retrieval will fail, and the boot will fail. In the following screenshot you can see that the Bootloader was unable to fetch keys.

Windows will now fail to boot, because the encryption key cannot be retrieved. Thus, when it attempts to boot, it will fail with the status code 0xC00000f, indicating a failure to read the disk. This is shown in the screenshot below. Subsequent boot attempts after the key access is granted will not result in this error.

Attempts to boot the fail will fail until the VM is granted access to the encryption key. Once the key has been provided, restarting the VM will once again proceed normally. The encryption key will be retrieved and passed to the Windows Bootloader, allowing the VM to operate normally. Here is a normal boot process, once the encryption key has been retrieved:

Installing the Bootloader at a Later Time

powershell -ExecutionPolicy Unrestricted -File 
  "C:\Program Files\hcs\bin\InstallHTBootloader.ps1"  

Example of a Successful Installation

The PowerShell script should return an exit code of zero. Any other exit code indicates an error, which will print in the log. The log appears in C:\Program Files\hcs\InstallhtBootloader.log. An example of a successful execution appears below:

PS C:\users\administrator\desktop> powershell -ExecutionPolicy

Unrestricted -File "C:\Program Files\hcs\bin\InstallHTBootloader.ps1”

This system already has a separate System volume and Boot volume.

Creating new primary partition 1 of 1

Failed, trying to free up space

Shrinking C: by 360 MB, this may take some time

DiskPart successfully shrunk the volume by: 360 MB

Trying to create partition again

Successfully created primary Partition 3 on Disk 0

Formatting

DiskPart successfully formatted the volume.

DiskPart successfully assigned the drive letter or mount point.

Creating SRP

Boot files successfully created.

Successfully created SRP on Partition 3 Disk 0

Copying bootloader files

Updating bootloader configuration

Adding boot menu entries

Marking new SRP active

Winldr serial: 40604346 , Bootldr serial: 1155100468

Please reboot for changes to take effect.

If you have executed this script from Power Shell directly, please

execute SetupHTBootloaderNetwork.ps1 before rebooting

Modifying Bootloader Network Settings

Bootloader network settings can be changed by running a different PowerShell script, SetupHTBootloaderNetwork.ps1, which is located in your default installation directory (<installation_dir>/bin). The script is interactive, and requires user input. It is shown below:

powershell -ExecutionPolicy Unrestricted -File
  "C:\Program Files\hcs\bin\SetupHTBootloaderNetwork.ps1"

These settings can also be changed using the Update network settings choice on the rescue menu. Note that if you change your static IP configuration in Windows, you must update your Bootloader with this script to reflect those changes.

Note that you can also set the drive letter for the Bootloader by using the -drive parameter. In the following example, the Bootloader is set to drive P:

powershell -ExecutionPolicy Unrestricted -File \
 "C:\Program Files\hcs\bin\InstallHTBootloader.ps1" -drive P:

Examples of Successful Installations

The PowerShell script should return an exit code of zero. Any other exit code indicates an error, which will print in the log. The log appears in C:\Program Files\hcs\SetupHTBootloaderNetwork.log. Several examples of a successful execution appear below, with user input in bold type:

Example 1, Using DHCP:

PS C:\users\administrator\desktop> powershell -ExecutionPolicy \

  Unrestricted -File "C:\Program Files\hcs\bin\SetupHTBootloaderNetwork.ps1"

Configuring HT Bootloader Network:

----------------------------------

Following network interfaces are available:

  1) Intel(R) PRO/1000 MT Network Connection 00:0C:29:45:59:93

  2) RAS Async Adapter 20:41:53:59:4E:FF

Select the primary interface by number or press Q to quit:   1

DHCP is currently enabled for the selected network interface.

Use DHCP during boot? [y/n] :   y

Successfully updated HT Bootloader network configuration

Example 2, Using Current Settings for Static IP Configuration

PS C:\users\administrator\desktop> powershell -ExecutionPolicy \

  Unrestricted -File "C:\Program Files\hcs\bin\SetupHTBootloaderNetwork.ps1"

Configuring HT Bootloader Network:

----------------------------------

Following network interfaces are available:

  1) Intel(R) PRO/1000 MT Network Connection 00:0C:29:45:59:93

  2) RAS Async Adapter 20:41:53:59:4E:FF

Select the primary interface by number or press Q to quit: 1

DHCP is currently enabled for the selected network interface.

Use DHCP during boot? [y/n] : n

Setting up static IP for use during boot

Current configuration:

Network parameters provided:

IP address 		: 172.16.14.222

Gateway address 	: 172.16.14.2

Netmask 		: 255.255.255.0

DNS server address 	: 172.16.14.2

Host Name 		: WINQ2FCCC3ALIH

DNS Domain 		: localdomain

Is this correct? [y/n] 	: y

Successfully updated HT Bootloader network configuration

Example 3, Using Custom Settings for Static IP Configuration

PS C:\users\administrator\desktop> powershell -ExecutionPolicy \

  Unrestricted -File "C:\Program Files\hcs\bin\SetupHTBootloaderNetwork.ps1"

Configuring HT Bootloader Network:

----------------------------------

Following network interfaces are available:

  1) Intel(R) PRO/1000 MT Network Connection 00:0C:29:45:59:93

  2) RAS Async Adapter 20:41:53:59:4E:FF

Select the primary interface by number or press Q to quit: 1

DHCP is currently enabled for the selected network interface.

Use DHCP during boot? [y/n] : n

Setting up static IP for use during boot

Current configuration:

Network parameters provided:

IP address 		: 172.16.14.222

Gateway address 	: 172.16.14.2

Netmask 		: 255.255.255.0

DNS server address 	: 172.16.14.2

Host Name 		: WINQ2FCCC3ALIH

DNS Domain 		: localdomain

Is this correct? [y/n] 	: n

Please provide network parameters:

IP address 		: 172.16.14.22

Netmask 		: 172.16.14.2

Gateway address 	: 255.255.255.0

DNS server address 	: 172.16.14.3

Host Name 		: MYPC

DNS Domain 		: localdomain

Network parameters provided:

IP address 		: 172.16.14.22

Netmask 		: 172.16.14.2

Gateway address 	: 255.255.255.0

DNS server address 	: 172.16.14.3

Host Name 		: MYPC

DNS Domain 		: localdomain

Is this correct? [y/n] 	:   y

Successfully updated HT Bootloader network configuration

Automated Solutions for Bootloader Installation

The SetupHTBootloaderNetwork.ps1 script has been enhanced to support automation. In keeping with the GUI installer, when used in interactive mode, this script displays the ConnectionIdand DeviceIDof the network adapter identification instead of just the hardware description.

The DeviceID displayed is the value of the DeviceID property of the Win32_NetworkAdapter WMI class. Note that value of DeviceID is same as the Index property of the Win32_NetworkAdapterConfiguration class.

To use this script in interactive mode, do not use the -silent flag. In interactive mode, any parameters supplied to the script will be ignored.

When used in non interactive mode, using the -silent flag, the network adapter to be configured is specified through the -deviceid parameter (similar to /NET in the silent installer). The script will detect current settings of the specified network adapter and use them if they are not overridden by any of the following optional parameters:

• -dhcp: Use -dhcp for configuring the adapter. This choice overrides all other settings .
• -ip: IP address
• -netmask: Netmask
• -gw: Gateway IP address
• -dns: IP address of one or more DHCP servers, separated by commas
• -hostname: Hostname
• -domain: Domain

If the -silent flag is used without the -deviceid parameter, the script will try to detect the preferred network adapter, that is, the one used to connect to the KeyControl, and configure it.

For the purpose of automation, available network adapters can be listed by using the -listadapters parameter. The output is printed on the console. This flag overrides any other parameter.

Automation Examples

PS C:\users\administrator\desktop>SetupHTBootloaderNetwork.ps1 -listadapters

DeviceID|Description|IPAddress|MACAddress|DhcpEnabled|ConnectionID|Preferred

7|Intel(R) PRO/1000 MT Network Connection|172.16.14.222|00:0C:29:45:59:93|True|Local Area Connection|False

10|Intel(R) PRO/1000 MT Network Connection #2|192.168.100.34|00:0C:29:45:59:9D|False|Connection 2|False

PS C:\users\administrator\desktop>SetupHTBootloaderNetwork.ps1 -deviceid 10

Successfully updated HT Bootloader network configuration

PS C:\users\administrator\desktop> cat T:\hcs\etc\ipconfig

DHCP=false

IP="192.168.100.34"

NETMASK="255.255.255.0"

GATEWAY=""

IPV4DNS0=""

DNSDOMAIN=""

PS C:\users\administrator\desktop>SetupHTBootloaderNetwork.ps1 -silent -deviceid 10 /

  -gw 192.168.100.1 -dns 192.168.100.1,192.168.1.1

Successfully updated HT Bootloader network configuration

PS C:\users\administrator\desktop> cat T:\hcs\etc\ipconfig

DHCP=false

IP="192.168.100.34"

NETMASK="255.255.255.0"

GATEWAY="192.168.100.1"

IPV4DNS0="192.168.100.1 192.168.1.1"

DNSDOMAIN=""

Bootloader Issues, Solutions, and Diagnostics

There are other potential issues with Bootloader installation. They are less likely to be found:

ISSUE: Your certificates don't match, and the diagnostic reports that the time on the Bootloader system clock is wrong.

Cause: The Bootloader is based on Linux, which initializes its clock during boot from the RTC/hardware clock. During this initialization the RTC time is assumed to be UTC. However this is not true because Windows by default syncs the RTC clock with local time.

Solution: There are two approaches that can be used to solve this problem: 1) Change the system time on the Bootloader by taking the time zone being used by Windows into account. We can do this by simply storing the difference in local time and UTC time on the Bootloader and applying the difference to the system time during boot. 2) Change the system time using a Network Time Protocol (NTP) client to fetch the correct time from an NTP server.

How it works: We now store two more bits of information in the Bootloader: hcs/etc/tzdiff - the time difference between local time and UTC hcs/etc/ntpsrv - a comma-separated list of NTP servers

Two new powershell scripts have been added: SetHTBootloaderTzDiff.ps1, which accepts no parameters and creates hcs/etc/tzdiff on the Bootloader drive.

UpdateHTBootloaderNtpServers.ps1, which is used to create hcs/etc/ntpsrv, meant for automation.

Usage: UpdateHTBootloaderNtpServers.ps1 [-ntpsrv <server list>] [-default] ntpsrv - list of comma-separated NTP servers in quotes. The default - use NTP server settings from the host system, which overrides the ntpsrv parameter.

Bootloader Diagnostics

The final state of installation can be inferred from four empty files created by the installer in the same directory as the installer executable:

• HTDone This indicates that the installation ended. You should poll for creation of this file to ensure that the installer process finished. If no other file is created, it means that a successful installation completed.
  • NOTE: Boot drive encryption is not available until AFTER a successful installation and reboot.
• HTError: The installation failed. This file contains the error string.
• HTBLError: HyTrust Windows Bootloader installation failed, but the rest of the installation succeeded. This file contains the error string.
• HTRetryOnReboot: If this file is present, the installation was not a failure, but it needs a reboot. To complete the installation, reboot and run the installer again

Configuration Tools

We provide tools for defining the Bootloader drive and network configuration. They include:

Executable: htblconf.exe

This executable provides a user interface for updating the Bootloader drive and network configuration after installation has been completed. This is based on the installer and presents the same drive and network configuration options as are presented during the Bootloader installation.

Setting the Preferred Network Adaptor