File and Volume Encryption Flashcards
Encrypting File System (EFS):
The EFS provides a per-file encryption option, this does not include boot-up files, registry or page file
BitLocker:
The BitLocker mechanism can provide volume encryption protected by a number of key material sources including USB tokens and built-in Trusted Platform Modules
The EFS mechanism operates as a file system filter and was introduced in V3.0 of NTFS in 1999:
- Files are encrypted individually with a symmetric cipher
- This randomly generated key (File Encryption Key (FEK)) is then encrypted using a public key cryptosystem and stored alongside the encrypted file in the $EFS alternative data stream
- On reading the file, the certificate associated with the FEK is retrieved and the FEK is decrypted with the matching private key
- EFS operates on a per-file basis, but an Encryption attribute can be set on a folder level and is inherited
EFS Limitations - Key Management:
Security of EFS-encrypted files is typically not limited by the strength of the bulk cipher, but by the management of public keys including recovery keys. If a recovery agent account is compromised, this gives access to all EFS encrypted files
EFS Limitations - File System Transitions:
Copying files to non-NTFS volumes such as FAT or network file systems results in files being decrypted. Such transitions may be transparent to users, resulting in storage in plain text. File systems with links to others in them are problematic
EFS is mainly intended to protect data at rest, i.e. files on storage media during times when the operating system is not running:
- When plain-text files are encrypted, this need not happen in situ: Remnants of the original file may still be found in the file system’s data structures
- The contents of decrypted files may propagate to several unencrypted locations: Paging and printer spooling subsystem, hibernation files, but also various temporary files created by applications
Although called BitLocker Drive Encryption, Microsoft’s BitLocker is in fact a volume encryption mechanism:
- It requires the boot volume to be unencrypted
- Key material can come from a number of sources, including USB pen drives, passwords or PIN codes or a Trusted Platform Module (TPM)
A main reason for strict requirements is the possible susceptibility of mechanisms such as BitLocker to cold boot or pre-boot attacks:
For the mechanism to work, a PIN or similar mechanism is needed and the machine must support a secure hibernation mode together with UEFI Secure Boot / Windows Trusted Boot and Connected Standby
From Windows 8.1 onwards, encryption may be initiated automatically by default under the name Device Encryption:
- In this case the Master Key is not protected (anyone with access to admin account may generate a recovery key linked to the Microsoft account linked to device)
- Otherwise an Active Directory group policy must be used to store the data within the Active Directory structure
Unlike a drive encryption software, BitLocker must rely on a pre-boot environment to perform
- Such systems must encrypt the entire volume initially, but can then rely on a filter driver to encrypt and decrypt transparently
- Bootkits operate by modifying the boot loader such that malware can be injected into memory even through the actual transition to protected mode happens during the boot stage
BitLocker Vulnerability Potential - Even with a TPM, however…
Some residues of key material can persist after a re-boot