Disk encryption, technical information
Full disk encryption
- ASU CISO approved full disk encryption standards
- Guidelines for other systems
- System-specific instructions
- Recommendations before starting encryption
- What disk encryption does and doesn't do for you
- Recovery keys and boot passwords
- Recommendations for departmental storage of recovery keys and boot passwords
|ASU CISO approved full disk encryption standards|
|System Type||Requirements||Standard||Key Escrow|
||Encrypt with BitLocker using TPM||Store key in AD / MBAM|
|Mac OS||OS X Lion (10.7) or later||Encrypt full partition with FileVault 2|
|Linux||Check specific distro documentation - most distros supported||Encrypt using dm-crypt/LUKS|
|Guidelines for other systems|
|Windows without TPM||Replace the system with one meeting ASU standards|
|Dual-boot system||Run a virtual instance of another OS from a fully encrypted host OS|
|Multi User Mac (Classroom & Labs only)||Encrypt if you can encrypt
If in a classroom or lab setting only
Focus on process to not allow local data storage (data security)
no persistence storage
- BitLocker System Purchasing Requirements This document describes purchasing requirements for new Windows-based systems. Specifying these requirements in new purchases will ensure that new systems can be encrypted using BitLocker.
- BitLocker procedure This document details the procedure to enable BitLocker on your computer running Windows 7. The Information Security Office recommends contacting your departmental technical support personnel for assistance.
- BitLocker FAQ This document addresses common questions and concerns about BitLocker, the encryption tool of choice for systems running Windows 7.
Trusted Platform Module
ASU systems require discrete, integrated, or firmware TPM 2.0
- Discrete TPM provides the highest level of security with complete separation from other computer hardware. The non-volatile memory is reserved solely for use by the Trusted Platform Module’s security function. Since it is independent from other functions, it maintains a high degree of tamper resistance.
- Integrated TPM provides similar levels of security. The difference being that it is integrated into another chipset and is therefore more susceptible to tampering.
- Firmware TPM runs as protected software on the CPU. The TPM functions are executed in a trusted execution environment (TEE). In addition to being more susceptible to tampering, fTPM is also dependent on the security of the TEE and operating system.
- Software TPM is an emulation of the standard TPM functions. This is not recommended for production environments but can be used in testing.
Mac OS X: FileVault 2 with full partition encryption
- System, and external storage device (including Time Machine backup target disks for Lion) encryption. Uses a Recovery HD (Partition) on the system disk
- https://support.apple.com/kb/HT4790 (OS X Lion: About FileVault 2, Instructions on Enabling)
- https://web.me.com/pondini/Time_Machine/31.html (FileVault 2 encryption for Time Machine target disk)
- https://support.apple.com/kb/HT4811 (OS X Lion: Using FileVault 2 and Lion Recovery)
- https://support.apple.com/kb/HT4718 (OS X Lion: About Lion Recovery)
- Centralized key storage with Apple is at departmental discretion
- Encrypting external SD Card, USB disks and drives: Disk Utility - select Disk (not an existing partition, otherwise the next option will not show up in the Formet list), go to Erase, then choose “Mac OS Extended ( […,] Journaled, Encrypted)”, set Erase and Security options as desired.
- See the documentation specific to your Linux distribution, some popular distros are listed below.
- General information about LVM & encryption:
- https://help.ubuntu.com/community/EncryptedFilesystemLVMHowto (Recovery / Forensics - mounting an encrypted LVM filesystem Ubuntu, varies slightly with other distributions but principle the same)
- Red Hat Enterprise Linux 6: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Security_Guide/sect-Security_Guide-LUKS_Disk_Encryption.html
- Red Hat Enterprise Linux 5: https://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Installation_Guide/Disk_Encryption_Guide.html
- Ubuntu: https://help.ubuntu.com/community/EncryptedFilesystems
- Arch Linux: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS
Recommendations before starting encryption
- If the device is in use (as opposed to a test machine), run a full backup first.
- Ensure that the device is plugged into a reliable power source.
- Anticipate leaving the device overnight to finish encrypting a full drive (Exception: Windows 7/Vista systems can be used as normally during BitLocker encryption, and BitLocker can be paused or interrupted if necessary).
- Have a USB flash drive ready to store recovery keys.
What disk encryption does and doesn't do for you
- Disk encryption protects data in physical storage. If a device is stolen, the thief may try to view files directly on the disk without logging in; e.g., by mounting it as a secondary disk in another computer system or using forensic analysis tools. This can be done if the disk is not encrypted, but can't be done if the disk is encrypted.
- Full disk encryption meets the requirements of safe harbor provisions in many data breach disclosure laws in the event of physical theft. These laws require public notification and other measures if a system containing sensitive data is lost or stolen, but often waive the requirement if the system's disk was encrypted.
- Disk encryption does not provide protection from viruses, trojans, or other malware. These threats operate while the system is running; hence, they will have the same access the system or its user has.
- Disk encryption does not provide protection from data theft via Web application hacking; e.g., SQL injection attacks. These threats operate while the system is running. Sensitive database fields should be encrypted by the application or middleware before storage in the database.
- Disk encryption does not provide protection from hardware failures. Disks can and do crash; hence, regular backups are still recommended.
- Disk encryption does not obviate the need for other defensive layers. Antivirus software, firewalls, strong passwords, and other standard security measures are still required.
- Disk encryption does not prevent theft of a computer system or disk. Physical security measures (e.g., secured rooms, case padlocks, cable locks) are appropriate measures to prevent theft of a desktop system and data resident on the system. However, the CISO recommends disk encryption even on systems that are protected physically from theft.
Recovery keys and boot passwords
- Boot passwords are required every time the computer is started. Recovery keys (e.g., for BitLocker) are required only in unusual circumstances; e.g., motherboard replacement, disk corruption, forensic analysis, or booting in safe mode.
- Recovery keys and boot passwords are only useful when combined with physical access to the system. A recovery key or boot password by itself (or even in combination with a computer name) is not considered sensitive information. To leverage a recovery key or boot password, an attacker would first have to steal the system or its disk.
- A recovery key stored on a USB flash drive or other removable media (or a written boot password) should not be kept with the encrypted system, as this would defeat the purpose of encrypting the disk.
Recommendations for departmental storage of recovery keys and boot passwords
- The CISO recommends encryption with or without university-wide centralized key storage, but recommends that departments store recovery keys and boot passwords centrally where possible so that data can be recovered in the event of a malfunction, hardware change, or forensic requirement.
- It is recommended that departments store recovery keys and boot passwords on an ITFS file share, using a file or folder naming convention that includes the encrypted system's name, service tag, property control number, or other unique system identifier. Physical locations and end users' names or ASURITE IDs may be recorded, but should not be used as key identifiers since systems may be moved or re-allocated.