Chapter 23 SECURITY ANALYSIS AND DECRYPTION OF FILEVAULT 2 Omar Choudary, Felix Grobert and Joachim Metz Abstract This paper describes the first security evaluation of FileVault 2, a vol- ume encryption mechanism that was introduced in Mac OS X 10.7 (Lion). The evaluation results include the identification of the algo- rithms and data structures needed to successfully read an encrypted volume. Based on the analysis, an open-source tool named libfvde was developed to decrypt and mount volumes encrypted with FileVault 2. The tool can be used to perform forensic investigations on FileVault 2 encrypted volumes. Additionally, the evaluation discovered that part of the user data was left unencrypted; this was subsequently fixed in the CVE-2011-3212 operating system update. Keywords: Volume encryption, full disk encryption, FileVault 2 1. Introduction The FileVault 2 volume encryption software was first included in Mac OS X version 10.7 (Lion). While the earlier version of FileVault (intro- duced in Mac OS X 10.3) only encrypts the home folder, FileVault 2 can encrypt the entire volume containing the operating system – referred to as “full disk encryption.” This has two major implications. The first is that there is a new functional layer between the encrypted volume and the original filesystem (typically a version of HFS Plus). This new functional layer is actually a full volume manager, which Apple calls CoreStorage. Although the full volume manager could be used for more than volume encryption (e.g., mirroring, snapshots and online storage migration), we do not know of any other applications. Therefore, in the rest of this paper we use the term CoreStorage to refer to the com- bination of the encrypted volume and the functional layer that links the volume to the HFS Plus filesystem. The second implication is that G. Peterson and S. Shenoi (Eds.): Advances in Digital Forensics IX, IFIP AICT 410, pp. 349–363, 2013. c IFIP International Federation for Information Processing 2013 350 ADVANCES IN DIGITAL FORENSICS IX the boot process is modified because the user password or some other recovery token must be retrieved before the operating system can be decrypted. Mac OS X volume encryption is similar to other volume encryption so- lutions. These include PGP Whole Disk Encryption [22], TrueCrypt [23], Sophos SafeGuard [21], Credant [6], WinMagic SecureDoc [24] and Check Point FDE [4]. This paper presents a detailed analysis of the FileVault 2 full disk encryption architecture, including the key derivation mechanisms and the data structures needed for decryption. Based on the analysis, an open source cross-platform library named libfvde was developed to decrypt and mount CoreStorage volumes. The library and the detailed documentation of the data structures used by FileVault 2 are available online [5]. The library can be used to analyze the contents of a particular file or block in an encrypted volume without having to use Mac OS and even without gaining physical access to the Apple computer in question (e.g., by booting from a Linux live CD and connecting to the machine via the Internet). 1.1 Motivation Our main goal was to determine how FileVault 2 operates. This task involved finding how and where the encrypted volume master key is stored, how the key can be obtained from the user password or token, what other data (metadata) is available and how is used, and finally, how disk encryption and decryption are performed. We were motivated by two factors. First, we needed a tool for digital forensic investigations. When a computer is suspected of having malware or having been the target of malicious access, it is necessary to obtain certain files from the disk. If the computer is at a distant location, it may not be feasible or convenient to transport the computer or disk to a forensic laboratory for analysis (it is not easy to remove the disk from a MacBook Air). Even if physical access is available to the computer, the native operating system cannot be trusted to extract the necessary files because of the presence of malware. Furthermore, although it is possible to access a FileVault 2 encrypted volume using another Mac computer connected via FireWire, this is a very limiting context. Our open source library (libfvde) does not have any of these limitations. Our second motivation was to have a security evaluation of the system. Since FileVault 2 could be used on sensitive corporate machines, it is necessary to verify that no serious vulnerabilities exist. Choudary, Grobert & Metz 351 2. Background A hard disk is generally organized in multiple sections called partitions or volumes. These volumes are often structured according to a filesystem format (e.g., NTFS, FAT or HFS). It is possible to have a single disk with three volumes, where the first volume is formatted with NTFS and contains a Windows operating system, the second volume is formatted with EXT3 and contains an installation of a Linux distribution, and the third volume is formatted with FAT and only contains data (no operating system). Interested readers are referred to [3] for details about this topic. Volume encryption is a mechanism used to encrypt the contents of an entire volume. This is sometimes incorrectly referred to as “full disk encryption.” We will use the term “volume encryption” in this paper to refer to the encryption performed by FileVault 2. One of the main problems with volume encryption is that the oper- ating system data is also encrypted, so there is no code left to boot the system. Therefore, the minimum code required to decrypt the operating system (or enough to initialize the filesystem and decrypt the rest of the operating system) must reside elsewhere. This is a problem that is tackled differently by the various volume encryption solutions. Another important aspect of volume encryption is key derivation. The volume is generally encrypted using an algorithm that relies on AES or other symmetric cipher (asymmetric cryptography would have too much of an impact on read/write performance). Therefore, there must be a key that can unlock the encrypted volume. FileVault 2 uses 128-bit AES keys and has a layered architecture that allows multiple users to decrypt the same volume master key. The next important aspect of volume encryption is the encryption op- eration itself. This operation must be carefully designed because there are several problems that can make a straightforward implementation in- secure [11]. Also, the nature of disk encryption has special requirements with regard to speed (encryption should not introduce noticeable delays) and size (individual fixed-size sectors must be encrypted individually so they can be accessed independently). The last important problem deals with the storage of the volume master key during the system operation and sleep modes. During the boot process, the volume master key is derived from the user password or token. After this key is derived, the operating system stores it in memory in order to read and write blocks efficiently without having to derive the key on every disk access. Halderman, et al. [13] have shown that an attacker with temporary access to a running system can scan the memory to retrieve the volume master key and then decrypt 352 ADVANCES IN DIGITAL FORENSICS IX Figure 1. Recovery password shown when FileVault 2 is enabled. the disk contents. This is still a general problem, but it is possible to use proprietary methods such as on-board tamper resistant memory to mitigate these attacks. 3. FileVault 2 Architecture This section describes the architecture and key features of FileVault 2. 3.1 Enabling FileVault 2 After FileVault 2 is enabled, a series of events take place. First, the user is presented with a 24-character recovery password (see Figure 1) that can be used to access the encrypted volume, even if the user pass- word is lost. Next, the filesystem in the main volume is converted from the na- tive HFS Plus type to CoreStorage (encrypted). During this opera- tion, the user can still use the system and the ConversionStatus field in the EncryptedRoot.plist file (details are provided below) contains the string “Converting.” After the encryption process is complete, the string is changed to “Complete.” At this time, we do not know how the operating system keeps track of the encrypted blocks during the conver- sion process, so our tool cannot correctly mount volumes that are in the Converting state. We are continuing to investigate this situation. In addition to the encryption itself, a new volume called Recovery HD appears alongside the main Macintosh HD volume. This new partition contains the encrypted volume master key. Running the command diskutil list on a Mac OS installation with FileVault 2 enabled yields an output similar to that shown in Figure 2. The output contains the encrypted volume (disk0s2), Recovery HD volume (disk0s3), original unmodified EFI volume (disk0s1)andalso the unlocked (unencrypted) version of the main volume (disk1). There Choudary, Grobert & Metz 353 Figure 2. Output of diskutil list run on a Mac Book Air with FileVault 2 enabled. is also an additional partition (disk0s4), which we created only for testing purposes. The Recovery HD volume contains a series of new files, including new EFI boot code to deal with the encrypted volume. Among all the files available in the new volume, the most important for FileVault 2 operation is the EncryptedRoot.plist.wipekey file, which is found at: com.apple.boot.X/System/Library/Caches/com.apple.corestorage where X changes between R, S and P . This file contains all the information needed to extract the volume master key from the user password or recovery token. The EncryptedRoot.plist.wipekey file is encrypted using AES-XTS with an all-zeros “tweak key,” but the encryption key is easily available in the header (first block) of the CoreStorage volume.