Insights Blog

Ask The Expert: APFS Encryption

Ask the Expert: APFS Encryption

The latest releases of macOS and iOS devices utilizes a new, complex file system called Apple File System (APFS).  Based on how APFS differs from prior Apple and Microsoft file systems, digital investigators will have to adapt their processes and examination techniques; especially with regards to APFS encryption and unallocated space. With the release of BlackBag’s solution for acquiring, decrypting, and processing APFS, our team has fielded numerous questions and received feedback from customers around the world on how to best work with this file system.
Here are our top five frequently asked questions about APFS encryption answered by Dr. Joe Sylve, one of our BlackBag forensic experts. If you need a refresher on how APFS works, please refer to Joe’s previous webinar.

1 – What are the differences between APFS Encryption using FileVault 2 and HFS+ encryption?

HFS+ has no native support for encryption.  In order to secure your data, HFS+ volumes are wrapped in a layer of encryption using CoreStorage.  CoreStorage is a logical volume management system on macOS that encrypts volume data at the block level.  When you “unlock” an encrypted volume contained in CoreStorage, a new logical device is created which contains the entire unencrypted HFS+ file system, including unallocated space as one contiguous chunk of blocks.  If you image this logical device, you are capturing all the blocks of the encrypted HFS+ Volume (including the unallocated blocks) in a decrypted state.
APFS was designed with first-class support for encryption, so it does not require the additional layer of security provided by CoreStorage.  Enabling FileVault on a volume formatted with APFS does not migrate the file system into CoreStorage as with HFS+.  It simply enables the built-in encryption support for APFS and encrypts your data at the file system level.  For this reason, “unlocking” APFS volumes does not result in a special block device that can be read to acquire an unencrypted version of an APFS volume.  Because of this, analysis tools such as BlackLight must be able to decrypt APFS file system metadata and data blocks on demand.
There are also subtle technical differences between the encryption used by CoreStorage and APFS.  While both systems encrypt data with the XTS-AES-128 cipher, APFS volumes use randomly generated secondary encryption keys, while CoreStorage uses the “logical family identifier” UUID as the secondary key.  Since theCoreStorage UUID is not random and can be identified, it is possible that APFS encryption may better withstand cryptographic attacks.

2 – Why do I have to enter a FileVault 2 password or recovery key into BlackLight if I’ve already unlocked the APFS Encryption in MacQuisition? 

Unlike HFS+ CoreStorage volumes, “unlocking” APFS volumes does not result in a logical device that can be imaged containing unencrypted data.  Although MacQuisition allows you to “unlock” APFS volumes by providing either a user’s password or the recovery key, this is only to facilitate triage and logical file acquisitions.  In these instances, MacQuisition uses the key to decrypt the data on demand and copies the logical file contents out for acquisition.
Whether or not you “unlock” an APFS volume during acquisition, physical APFS images will still contain encrypted data.  Analysis tools such as BlackLight will then need the proper user password or recovery key to decrypt this data on demand, as you are conducting an examination.  It is not technically possible to create a forensically sound physical image of an encrypted APFS volume that contains logically decrypted data.

3 – MacQuisition is giving me the option of imaging two different devices: the physical disk and the APFS container. Does imaging either one of these give me unencrypted data?

APFS is a pooled storage file system, which means storage space from one or more physical partitions can be synthesized into a single logical container.  Space in this logical container pool can then be used by one or more APFS volumes.  APFS volumes grow and shrink by allocating unused blocks from the logical container pool and returning them when files are deleted and space is freed up.  Each APFS Container only knows about the blocks used by its own active files, and unallocated space is managed within the logical container pool.
Whether you enable FileVault or not, APFS will always create an additional device for this synthesized container.  MacQuisition gives you the option to image each individual physical disk device, or this synthesized container device that can contain blocks from one or more physical disk devices.  Whichever you chose, BlackLight can process each of them.

APFS Encryption Locked APFS Container and physical disk shown in MacQuisition

Note – When booted to MacQuisition on non-fusion Mac computers, the physical disk device is generally disk0 and the synthesized APFS container is generally disk1.

In the common case where an APFS container is backed by a single physical partition, we recommend imaging the physical device because the resulting image will contain all the physical partitions on the disk as well as the partition that backs the APFS container.
While Apple doesn’t automatically upgrade HFS+ formatted fusion drives to APFS, you may come across a fusion drive that has been manually formatted with APFS.  In this case, the APFS logical container pool may consist of blocks that span across multiple physical volumes.  In this instance, we recommend imaging the synthesized logical container device so that you have a single image containing all of the data needed to successfully analyze the APFS volumes with BlackLight.
As indicated above, “unlocking” APFS volumes does not result in a decrypted logical device, so neither of these methods will result in acquiring a decrypted image.

4 – Why can’t I carve for files from an APFS encrypted image, even though I have the File Vault 2 password?

APFS encrypts data blocks using the XTS-AES-128 cipher.  In order to decrypt data, several pieces of information are required:

  • The encrypted data
  • 128-bit Volume Encryption Key
  • 128-bit Secondary Encryption Key
  • The original “block number” of the file

Each volume in an APFS container uses unique volume and secondary encryption keys.  When a file is deleted, its data blocks are released to the container pool.  At that point it is not possible to map an unallocated data block back to its original volume.  We therefore do not know which encryption keys to use to correctly decrypt the data.  This process is further complicated due to the fact that encrypted blocks can be relocated on disk.  When this happens, the data is not re-encrypted, and the original block number must be known to decrypt the data.  This information is generally lost when a file is deleted.
Since unallocated blocks remain encrypted inside the logical container pool, carving for data that was associated with an encrypted volume will be ineffective because there are no known signatures to look for in the header.  If carving is run, returned data will likely be a false positive or a file fragment that was created prior to the volume being encrypted.
BlackBag is currently researching methods of brute-forcing the requisite information needed to decrypt encrypted blocks during carving.  Unfortunately, this process may be very time consuming as it is difficult to determine whether a block has been successfully decrypted before carving.

5 – I’ve disabled File Vault 2 on a High Sierra Mac, but I still can’t carve for deleted files. Why?

In APFS, disabling FileVault encryption will decrypt the file system metadata and the blocks of allocated files (active files) in a volume.  The unallocated blocks that have already been released to the container pool will not be decrypted, as they are no longer associated to the volume that encrypted them.  Therefore, as explained above, carving the unallocated space would not be effective because any data remaining in those blocks would still be encrypted.  In contrast, CoreStorage encrypted HFS+ volumes are encrypted at the block level (every block of the volume is encrypted) rather than the file system level, so disabling FileVault in these cases results in all data being decrypted, including unallocated space.  Please note that files that are deleted after FileVault has been disabled from an APFS volume, can potentially be carved because the data would never have been encrypted.
We hope this post answered your questions on APFS encryption.  For more information about APFS, BlackBag has added the latest research and discoveries in both Essential Forensics Techniques Courses. We encourage examiners to attend at least one of these courses to better understand Apple’s latest file system. 

For details on how to use BlackBag’s End-To-End APFS solution, including APFS encryption, visit our previous post.

Dr. Joe T. Sylve is the Director of Research and Development at BlackBag Technologies, Inc and an Adjunct Professor of Computer Science at the University of New Orleans. His interests are in Memory Analysis, Reverse Engineering, Digital Forensics, Computer Security, Incident Response, and Operating System Internals. He is the author of several open source digital forensic tools such as LiME Forensics, the first tool set that allows full physical memory acquisition from Android devices. He is the co-organizer of both NOLASec, a monthly security meetup, and BSidesNOLA, an annual security conference, and is devoted to promoting computer security and digital forensics awareness, education, and jobs in his home city of New Orleans. Dr. Sylve is a GIAC Certified Forensic Analyst and received his Ph.D. in 2017 from the University of New Orleans. He has published several peer-reviewed publications on digital forensics.

Ashley Hernandez