File and Disk Encryption
Windows has two built-in methods for encrypting data on a disk: Encrypting File System (EFS) and BitLocker Drive Encryption.
Encrypting File System (EFS)
File encryption on NTFS volumes is made possible by Encrypting File System (EFS). Files encrypted with EFS can be opened only by the holder of an encryption key, which is stored in a digital certificate. You can encrypt files or entire folders by simply setting or clearing the encryp- tion attribute in the file or folder’s properties.
Steps to encrypt by EFS:
1. Right-click the file or folder and click Properties.
2. In the General tab of the Properties dialog box, click the Advanced button.
3. In the Advanced Attributes dialog box, click the “Encrypt contents to secure data” check box.
4. Click OK twice. If you’re encrypting a single file, you have the option to encrypt only the file or encrypt the file and parent folder. If you’re encrypting a folder, you have the option to encrypt its contents.
5. To decrypt a file or folder, clear the “Encrypt contents to secure data” check box.
Another method of encrypting and decrypting files and folders is the cipher.exe command. To encrypt a file or folder, enter
cipher /e filename at a command prompt. To decrypt a file or folder, enter
cipher /d filename.
After a file is encrypted, a user can open it by using the normal means for the file type, such as double-clicking the file in File Explorer to open it in the associated application. The data in the file is decrypted automatically before it’s loaded in the application, but the data remains encrypted on the disk.
You can set the encryption attribute on a file or folder but not on a volume.
When a user encrypts a file by setting its encryption attribute or by creating a file in or moving a file to an encrypted folder, the following takes place:
1. The file is encrypted by using a symmetric key called a file encryption key (FEK).
2. The public key in the user’s digital certificate is used to encrypt the FEK. If the user doesn’t have a digital certificate, one is created automatically and stored on the system.
3. The encrypted FEK is stored with the encrypted file.
When a user attempts to open the encrypted file, the following takes place:
1. The encrypted FEK stored with the file is decrypted by using the user’s private key, which is associated with the user’s logon account. (The FEK was encrypted by using the user’s public key.)
2. The file is decrypted by using the decrypted FEK.
Who can open the encrypted file:
Encrypted files can usually be opened only by the user account that encrypted the file because the user’s private key is used in the process. However, the user can designate other accounts that are allowed to access the file.
In addition, in a domain environment, the domain administrator account is designated as a Recovery agent, which can open all encrypted files. Recovery agents are used, for example, if the user account that encrypted the file can no longer access it. This can happen if an administrator resets a user’s password, the user account is deleted, or the user leaves the company.
A user must have a valid EFS certificate to be added to an encrypted file’s access list. EFS is set up to issue an EFS certificate automatically to any user who encrypts a file. Users can also be issued a certificate from a certificate server.
When working with EFS, keep the following points in mind:
• EFS is supported only on NTFS volumes.
• Encrypted files that are copied or moved always stay encrypted, regardless of the destination folder’s encryption attribute. The exception is if the file is copied or moved to a FAT or ReFS volume, in which case the file is decrypted because neither FAT nor ReFS support encryption.
• Unencrypted files that are moved or copied to a folder with the encryption attribute set are always encrypted.
• Encrypted files are unencrypted when they’re transferred across a network and remain unencrypted on the destination server unless they’re saved to an encrypted folder.
• If a user’s private key is corrupted or damaged, the user can’t decrypt files. For this reason, the user’s EFS certificate and private key should be archived so that they can be imported later to recover files.
• EFS keys are associated with a user’s logon account. Anyone with access to a user’s logon ID and password can decrypt files this user has encrypted.
• Instead of encrypting files, it’s better to set the encryption attribute on folders and place files that should be encrypted in these folders.
EFS Recovery Agent
A recovery agent is a user account with a recovery agent certificate. Recovery agents can open all encrypted files for which they’re the designated recovery agent. In a domain, the Administrator account is the default recovery agent and can open and decrypt all encrypted files created by domain users. Additional Recovery agent can be created by group policy.
On a workgroup computer, there’s no default recovery agent, but you can create one with the Local Security Policy console. Recovery agents on a workgroup computer can open and decrypt files only on that computer.
To be added as a recovery agent, the user account must have a recovery agent certificate issued by a certification authority. Configuring a certification authority is beyond the scope of this chapter, but assuming there are one or more user accounts that have a recovery agent certificate, follow these steps to add an account as a recovery agent for the domain:
1. Open the Default Domain Policy in the Group Policy Management Editor.
2. Navigate to Computer Configuration, Policies, Windows Settings, Security Settings, and Public Key Policies.
3. Right-click Encrypting File System and click Add Data Recovery Agent. Follow the instructions in the Add Recovery Agent Wizard. Any recovery agent certificates that were published in Active Directory are listed in the Select Recovery Agents window. Otherwise, you can browse to a folder where the certificate is stored.
If you have encrypted files, you should back up your EFS certificate and private key in case they’re damaged or lost. The EFS certificate can be lost if a user account is deleted or if a user’s profile on the computer is deleted or corrupted. Ideally, the certificate should be backed up on removable storage, such as a flash drive. Certificates for recovery agents should also be backed up.
Steps to back up an EFS certificate:
1. Open the Certificates snap-in by adding it to an MMC or by entering certmgr.msc at a command prompt or in the Run dialog box.
2. In the left pane, click to expand Personal, and then click Certificates . The Administrator account has both an EFS certificate and a File Recovery certificate.
3. Right-click the certificate and click All Tasks, and then click Export to start the Certificate Export Wizard. In the welcome window, click Next.
4. In the Export Private Key window, you’re asked whether you want to export the private key. If you’re exporting the certificate to recover from a lost private key, click “Yes, export the private key,” and then click Next.
5. In the Export File Format window, accept the default options, and then click Next.
6. In the Security window, click Password, and then type a password and confirm it. The password is needed if you want to import the certificate with the private key later. Click Next.
7. In the File to Export window, browse to the location where you want to export the certificate, and enter a filename for the certificate, such as EFScert. Click Save, and then click Next.
8. Review the settings in the final window, and then click Finish. Click OK in the message indicating that the export was successful.
To restore a certificate and private key, use a similar procedure, but right-click Certificates, click Import, click All Tasks, and then follow the Certificate Import Wizard. You’re prompted for the password you entered when you exported the certificate.
BitLocker Drive Encryption
BitLocker Drive Encryption, as the name implies, encrypts entire drives or volumes. It encrypts the entire volume on which it’s enabled and can be used to encrypt the Windows boot volume in addition to other volumes. BitLocker mitigates the risk of a lost or stolen computer and is useful when decommissioning computers because data on the disk remains encrypted even if the disk is removed and placed in another system.
To secure the Windows boot volume (the volume where the \Windows folder is installed) with BitLocker, you must make sure your system meets these requirements:
• The Windows boot volume and the Windows system volume (the active partition containing the files needed for the computer’s BIOS to start Windows) must be on separate partitions. The system volume must remain unencrypted so that the BIOS can read it.
• The computer must have a Trusted Platform Module (TPM), or a USB flash drive must be accessible during system boot. The TPM module or USB flash drive stores the encryption key.
To secure a drive that doesn’t hold the Windows OS, there are no special requirements. After the drive is encrypted with BitLocker, you have the option to unlock it with a password or smart card or unlock it automatically when you log on to the system. You select the method when you first encrypt the drive.
Trusted Platform Module
A Trusted Platform Module (TPM) is a microchip built into some computer motherboards that’s used to create and store cryptographic information for the purposes of securing a computer against unauthorized use. Used with BitLocker on a Windows system, it can prevent the system from booting without authentication. Even if the Windows boot volume is removed from the computer, it can’t be used on another computer because the TPM holds the encryption keys needed to decrypt the volume.
If your system doesn’t have a TPM, you need to take another step before you can configure BitLocker on the volume containing Windows: configuring the “Require additional authentica- tion at startup” policy. You can set this policy in a GPO linked to an OU containing the relevant computer accounts. The policy is at “Computer Configuration, Policies, Administrative Templates, Windows Components, BitLocker Drive Encryption, Operating System Drives.”
During BitLocker configuration on a volume with the Windows OS, you have the following options for unlocking the drive to allow the system to boot:
• TPM-only—In this mode, the system boots normally, with no special user interaction. If the drive is removed from the system or the TPM detects changes to OS files, the system enters recovery mode, which requires a recovery password.
• TPM with PIN—The user must enter a personal identification number (PIN) to boot the system.
• TPM with startup key—A startup key stored on a USB drive must be available for the system to boot.
• TPM with startup key and PIN—This option uses multifactor authentication, meaning two authentication methods are required: a USB drive with startup key and a PIN.
• Startup key only—If the system doesn’t have a TPM, this option can be used if the right policy is configured.
Installing and Configuring BitLocker with PowerShell
The following PowerShell cmdlets are available for installing and configuring BitLocker:
• Install-WindowsFeature BitLocker -IncludeManagementTools—Installs the BitLocker Drive Encryption feature.
• Enable-BitLocker -MountPoint DriveLetter—Enables BitLocker on a volume.
• Disable-BitLocker -MountPoint DriveLetter—Disables BitLocker on a volume.
• Enable-BitLockerAutoUnlock -MountPoint DriveLetter—Enables the automatic unlocking feature on a non-Windows volume.
Configuring Bitlocker with Group Policies
You might want to use BitLocker Drive Encryption throughout your organization or for only selected parts of it. There are dozens of BitLocker-related policies you can configure in Group Policy (by navigating to Computer Configuration, Policies, Administrative Templates, Windows Components, BitLocker Drive Encryption). After you configure the policies you need, you can link the GPO to the domain to configure all computers or to selected OUs to configure certain computers in the domain. Browse through the policies with the Group Policy Management Editor and read the descriptions to see the available settings.
Using Network Unlock
Network Unlock is a new feature in Windows Server 2012/R2 that makes it easier to manage BitLocker on OS volumes in a domain environment. With the Network Unlock feature enabled, OS volumes are unlocked automatically when they’re connected to the network, so users don’t need to supply a PIN or startup key each time their system boots. If their system becomes disconnected from the network, they need to supply the PIN or startup key. To use Network Unlock, first install the BitLocker Network Unlock feature by using the Add Roles and Features Wizard or PowerShell.
Additional requirements include the following:
• A Windows 8/8.1 or Windows Server 2012/R2 computer with a NIC that has a Universal Extensible Firmware Interface (UEFI)–compatible DHCP driver
• A Windows Server 2012/R2 computer running WDS
• A DHCP server on a separate server from the one running WDS
• A Network Unlock certificate for the WDS server and each client computer
• Network Unlock settings configured in Group Policy
Note, The Network Unlock feature requires clients to be connected via a wired network interface; wireless networks aren’t supported.
Steps to configure Network Unlock:
1. Install the Windows Deployment Services role.
2. Install the BitLocker Network Unlock feature.
3. Create a Network Unlock certificate on the WDS server from an existing certification authority or use a self-signed certificate.
4. Deploy the certificate and private key to the WDS server.
5. Configure Network Unlock settings in Group Policy by going to this node: Computer Configuration, Policies, Administrative Templates, Windows Components, BitLocker Drive Encryption, Operating System Drives.