BlackBag on APFS Encryption
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.
[…]
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.
Update (2018-05-01): See also: APFS Internals for Forensic Analysis (PDF, via Enno Rey).
1 Comment RSS · Twitter
When a file gets deleted on APFS, which is by default only running on SSD media, it should even get entirely erased, because the system will issue a TRIM command to the SSD drive, effectively zeroing the file data instantly that way.
The only way deleted files around might still be around is when a snapshot of the volume has been taken earlier. One won't see the files with normal tools (Finder, "ls" command etc.) but special tools giving access to snapshots will. Only that those are still rare (I believe CCC has added support now?)
