47 min read

> Where you are: Part V, Chapter 29 of 40. Parts II and III taught you to pull data back from the dead and to find evidence in the living structures of a disk — but every one of those techniques assumed you could read the bytes. Chapter 4 warned...

In This Chapter

Exercises Quiz Case Study 01 Case Study 02 Key Takeaways Further Reading

Chapter 29: Encrypted Device Forensics — BitLocker, FileVault, LUKS, VeraCrypt, and the Encryption Challenge

Where you are: Part V, Chapter 29 of 40. Parts II and III taught you to pull data back from the dead and to find evidence in the living structures of a disk — but every one of those techniques assumed you could read the bytes. Chapter 4 warned that encryption ends file-system analysis; Chapter 6 noted recovery from an encrypted volume without credentials is generally not feasible; Chapter 15 made the agonizing live-response decision turn on whether a BitLocker volume was unlocked. This chapter is where all of those threads meet the wall head-on. It is the chapter that takes the book's fifth theme — know your limitations — most seriously, because full-disk encryption is the one place where correctly applied technology can defeat both disciplines completely and permanently.

Learning paths: This matters to all four tracks, but it lands hardest on 🔍 Forensic Examiner and 📜 Legal/eDiscovery — the technical question ("can I read it?") and the legal question ("can a court make the suspect give me the password?") are inseparable here. 🛡️ Incident Response practitioners live the time-critical version of this problem (capture the key from RAM before the power dies). 💾 Data Recovery technicians meet its gentler-but-no-less-final form: the client who encrypted their own backup, lost the recovery key, and now wants you to perform a miracle you cannot perform.

The wall at the end of the investigation

You did everything right. You isolated the device, you wrote down the make and model and serial, you imaged it through a hardware write-blocker, you computed MD5 and SHA-256, the source and image hashes matched, and the chain of custody has no gaps. You have a perfect, court-defensible, bit-for-bit copy of the suspect's drive. You open it in your forensic suite to begin analysis, and you find this:

$ xxd -l 256 -s 0x100000 suspect-disk.dd
00100000: 7f3a c41e 9b62 d508 11ac 7e93 4f20 e6bb  .:...b....~.O ..
00100010: 2d91 88f0 6a47 cc15 3e7a b209 d6e4 1c83  -...jG..>z......
00100020: 5b08 a3fd 70e2 4419 cf86 0b57 9d31 ea64  [...p.D....W.1.d
00100030: 12bf 6cd0 87a5 3e29 4f1b c8e7 60d4 9a32  ..l...>)O...`..2
   ...           every sector to the end of the volume looks like this:
   ...           no NTFS "$MFT", no ext4 superblock, no recognizable
   ...           file header, no zeros, no structure — just uniform,
   ...           high-entropy noise that is statistically indistinguishable
   ...           from random data.

That is what a strongly encrypted volume looks like to a forensic tool. There is no Master File Table to parse, no inode to follow, no JPEG header to carve, no deleted resignation letter waiting in unallocated space. The book's foundational theme — deleted ≠ destroyed, the data persists until overwritten — is still technically true: every byte the suspect ever wrote is sitting right there on the platters. But it has been transformed by a mathematical function into ciphertext, and without the key, "the data is still there" buys you exactly nothing. This is the rare place where the entire toolkit of the first twenty-eight chapters comes to a stop, and where your professionalism is measured not by what you can recover but by how clearly you understand why you can't, and what — legally and technically — might still open the door.

The honest framing of this chapter is the framing the field uses with itself: full-disk encryption, implemented correctly and used correctly, is unbreakable in any timeframe that matters. There is no secret government backdoor into properly configured AES-256, no clever carving trick, no tool you can buy that "decrypts any drive." What there is — and what makes this a rich forensic subject rather than a one-line dead end — is a set of perfectly legitimate ways the key can come into your hands when you have authorization: it was escrowed somewhere you can reach; it is sitting in the RAM of a machine that is still running; it leaked into a hibernation file or a memory dump; the encryption was suspended or misconfigured; the passphrase was weak enough to guess; or a court ordered the holder to produce it. Knowing which of those doors is open — and recognizing instantly when none of them is — is the skill this chapter teaches.

Why This Matters. Encryption inverts the central assumption of both trades. Everywhere else in this book, the original is sacred because the data is there to be read; here, the original is sacred and the data is there and you still cannot read it. An examiner who does not understand encryption will either give up too early on a drive that has an escrowed recovery key sitting in Active Directory, or — far worse — promise a court, a client, or an employer a decryption that the mathematics will never deliver. Both errors are career-defining. The cure for both is to understand exactly how these systems work.

How full-disk encryption works

Before you can reason about getting in, you have to understand what "encrypted" actually means at the level of bits and keys. Full-disk encryption (FDE), more precisely called full-volume encryption in most implementations, transforms every sector of a volume so that the bytes on the media are ciphertext and the bytes the operating system sees are plaintext, with the translation happening transparently in a driver as data moves between RAM and disk. Three ideas make the whole edifice work: the cipher (AES), the way that cipher is applied to a disk (a length-preserving sector mode), and — the part that trips up most newcomers — the key hierarchy that sits between your password and the actual encryption key.

AES and how a cipher is applied to a disk

Every system in this chapter is built on the Advanced Encryption Standard (AES) — the block cipher (originally the Rijndael algorithm) selected by NIST in 2001 and now the de facto worldwide standard, approved by the U.S. government for classified information up to TOP SECRET at the 256-bit key length. AES operates on fixed 128-bit (16-byte) blocks and supports key sizes of 128, 192, or 256 bits. Its security rests on the fact that, for a properly chosen random key, the only known approach to recovering the plaintext is to try keys until one works — and the keyspace is so vast that this is infeasible. A 128-bit key has 2^128 ≈ 3.4 × 10^38 possibilities; a 256-bit key has 2^256 ≈ 1.2 × 10^77. To put 2^128 in perspective: if every one of the roughly 8 billion people on Earth ran a billion modern machines, each testing a billion AES keys per second, exhausting the 128-bit keyspace would still take far longer than the current age of the universe. This is the number that makes brute-forcing the encryption key itself a non-starter, and it is why every realistic attack in this chapter targets the password, the key hierarchy, or the key in memory — never the AES key directly.

Applying a block cipher to a disk introduces a wrinkle. A disk is a fixed-size array of sectors, and an encrypted disk must be the same size as an unencrypted one — sector 4,194,304 must still hold exactly 4,096 bytes after encryption, with nowhere to store an extra nonce or authentication tag. So disk encryption uses a length-preserving mode keyed to each sector's position. The modern standard is XTS-AES (XEX-based tweaked-codebook mode with ciphertext stealing, standardized as IEEE 1619 and NIST SP 800-38E), which uses the sector number as a "tweak" so that the same plaintext written to two different sectors produces different ciphertext — defeating the pattern-leakage that plagued the older CBC (cipher-block-chaining) mode. When you read that "BitLocker uses XTS-AES-128" or "LUKS defaults to aes-xts-plain64," that is what it means: AES, in XTS mode, with the sector offset folded in. The practical forensic consequence is that there is no structure to exploit — no repeated blocks, no recognizable boundaries — which is exactly why the hex dump above looks like pure noise.

The key hierarchy: why your password is not the key

Here is the single most important idea in the chapter, the one that explains both how these systems are usable and where they are vulnerable. Your password does not encrypt the disk. The disk is encrypted with a large, random, machine-generated key — call it the media key or full-volume encryption key — that no human ever sees or types. Your password (or PIN, or the TPM, or a recovery key) protects an intermediate key, which in turn protects the media key. The data is encrypted once, with the media key; everything else is a chain of wrapping around that key.

   THE KEY HIERARCHY  (names differ per system; the shape is universal)

   ┌─────────────────────────────────────────────────────────────────┐
   │  WHAT THE USER SUPPLIES  →  WRAPS  →  ... →  WHAT ENCRYPTS DATA   │
   └─────────────────────────────────────────────────────────────────┘

     Password / PIN ──KDF──▶ ┐
     Recovery key ──────────▶ ├─encrypts─▶  Volume Master Key (VMK) ─┐
     TPM (sealed to boot) ──▶ │             [the "intermediate" key]  │
     Startup key (USB .bek)─▶ ┘                                       │
                                                                      │ encrypts
                                                                      ▼
                                              Full-Volume Encryption Key (FVEK)
                                                                      │
                                                                      │ AES-XTS,
                                                                      ▼ per sector
                                                  ░░░  every sector of the disk  ░░░

This two-level (sometimes three-level) design is not bureaucratic over-engineering; it is what makes the system practical, and understanding why tells you where to look. Because the data is encrypted with the media key and only the wrapping depends on your password, you can change your password without re-encrypting the entire disk — the system just decrypts the media key with the old wrapping and re-wraps it with the new one, a millisecond operation instead of an hours-long rewrite of a terabyte. For the same reason, a single disk can have many independent ways in: a password and a recovery key and a TPM and a corporate escrow key can each wrap its own copy of the same intermediate key, any one of which unlocks the volume. BitLocker calls these wrappings key protectors; LUKS calls them key slots; FileVault speaks of the user password and recovery keys. They are the same idea, and they are the reason "do you have any of the keys?" is the first and most productive question an authorized examiner asks.

Recovery vs. Forensics. The key hierarchy is where the two disciplines first diverge on encryption — and they diverge politely, toward the same door. In data recovery, an encrypted volume is a problem only because the rightful owner has lost one wrapping (forgot the password) but you hope another exists (a recovery key they printed, an escrow at their employer, the key still resident because the machine never powered off). Your job is to find the surviving protector and restore the owner's access. In digital forensics, the encrypted volume is evidence, and you are looking for a protector you are lawfully authorized to use — an escrowed corporate recovery key, a key recovered from RAM under warrant, a passphrase the court has compelled. The technical move is identical: enumerate the protectors, use the one available to you. The difference is entirely in the authority under which you use it — and that difference is the whole second half of this chapter.

Key protectors and the TPM

The protectors that wrap the intermediate key fall into a few families, and each behaves differently under examination:

  • Something you know — a password, passphrase, or PIN. Run through a deliberately slow key derivation function (KDF) — PBKDF2, Argon2, scrypt, or bcrypt — that stretches the secret into a wrapping key while imposing a heavy per-guess cost. The KDF is the only thing standing between a weak password and an attacker, which is why its parameters (iteration count, memory cost) matter enormously, as we will see.
  • Something you have — a USB startup key (BitLocker's .bek file), a smart card, a YubiKey, or a recovery key printed on paper or escrowed in a directory.
  • Something the platform proves — the Trusted Platform Module (TPM), a dedicated security chip (discrete on the motherboard, or firmware-based inside the CPU) present in TPM 1.2 or 2.0 form on virtually every business-class machine made since roughly 2016. The TPM can seal a key to a set of Platform Configuration Registers (PCRs) — measurements of the firmware, boot loader, and boot configuration taken during startup. The TPM will release (unseal) the sealed key only if the measurements match, meaning the machine boots into the same trusted state it was sealed under. This is what lets a BitLocker laptop boot straight to the Windows login screen with no pre-boot password: the TPM silently hands the OS the key because the boot chain is unmodified.

The TPM is a double-edged artifact for the examiner. On one hand, it is a genuine security control: tamper with the boot chain and the key is never released. On the other, in its most common consumer configuration — TPM-only, with no PIN — the key is released automatically at every boot, with no human secret involved. That convenience is precisely the weakness: if the only thing standing between an attacker and the unsealed key is "boot the machine normally," then physical access to the machine becomes physical access to a key-release oracle, and (as we will see under implementation weaknesses) the unsealed key can sometimes be intercepted on the wire between the TPM and the CPU. Adding a PIN — TPM+PIN — closes this by requiring a human secret before the TPM will unseal, and is the configuration security-conscious organizations mandate.

Why This Matters. Notice the recurring shape: the strength of the whole system is the strength of its weakest enabled protector. A disk encrypted with flawless AES-256 and an unguessable 40-character passphrase is still trivially openable if it also has a TPM-only protector that releases the key at boot, or a recovery key escrowed in a directory you can query, or a four-digit PIN. As an examiner you are never attacking "the encryption." You are enumerating the protectors and finding the weakest one you are authorized to use. As a defender, you are making sure no weak protector is enabled. Same map, opposite goals.

The four systems up close

The principles above are universal; the implementations differ in ways you must recognize on sight, because identifying which system you are facing tells you immediately which key sources to pursue. Four dominate the field: BitLocker (Windows), FileVault (macOS), LUKS (Linux), and VeraCrypt (cross-platform).

BitLocker (Windows)

BitLocker Drive Encryption is Microsoft's FDE, built into Windows Pro, Enterprise, and Education editions since Windows Vista, and increasingly enabled by default on modern Windows 11 installations signed in with a Microsoft account. It encrypts with AES in XTS mode (XTS-AES-128 by default since Windows 10 version 1511; XTS-AES-256 optionally), having used AES-CBC with an "Elephant diffuser" in earlier releases. Its hierarchy is the textbook one: the Full-Volume Encryption Key (FVEK) encrypts the sectors; the FVEK is wrapped by the Volume Master Key (VMK); and the VMK is wrapped, independently, by every enabled key protector — TPM, TPM+PIN, TPM+startup key, password, recovery password, startup key, or a Data Recovery Agent certificate.

A BitLocker volume announces itself. Where an NTFS volume begins with the OEM identifier NTFS (4E 54 46 53 20 20 20 20) at offset 3 of its boot sector, a BitLocker-encrypted volume begins with a jump instruction and the signature -FVE-FS-:

$ xxd -l 16 bitlocker-volume.dd
00000000: eb58 902d 4656 452d 4653 2d00 0200 0800  .X.-FVE-FS-.....
          │  │  │ └──────────────────┘
          │  │  │  "-FVE-FS-" (2D 46 56 45 2D 46 53 2D) ← BitLocker signature
          │  │  └─ NOP (90)
          └──┴──── JMP short (EB 58) — boot jump

The volume also carries three redundant copies of an FVE metadata block, each holding the wrapped VMK for every protector and the VMK-wrapped FVEK. The forensic reading of this structure: the door is locked in several ways at once, and you need only one matching key.

The protector that most often saves an authorized examiner is the recovery password — a 48-digit numerical key, displayed as eight groups of six digits, each group divisible by 11 (a built-in checksum) and identified by a Recovery Key ID (a GUID). Critically for forensics, in managed environments this key is escrowed: pushed into Active Directory (stored on the computer object as msFVE-RecoveryInformation child objects, in the msFVE-RecoveryPassword and msFVE-RecoveryGuid attributes), into Azure AD / Microsoft Entra ID and Intune, or into the user's personal Microsoft account at aka.ms/myrecoverykey. You enumerate and use protectors with the built-in tools:

# Inspect BitLocker status and the protectors present on a volume
manage-bde -status C:
manage-bde -protectors -get C:        # lists protector types and the Recovery Key ID(s)

# PowerShell equivalent
Get-BitLockerVolume -MountPoint C: | Select-Object MountPoint,VolumeStatus,EncryptionMethod,KeyProtector

# Unlock a volume with a 48-digit recovery password (authorized use only)
manage-bde -unlock D: -RecoveryPassword 123456-654321-...-...-...-...-...-......

# Retrieve an escrowed recovery password from Active Directory (RSAT / domain admin)
Get-ADObject -Filter 'objectClass -eq "msFVE-RecoveryInformation"' `
    -SearchBase (Get-ADComputer LAPTOP-7F2X9Q3).DistinguishedName `
    -Properties msFVE-RecoveryPassword | Select-Object msFVE-RecoveryPassword

Two BitLocker quirks have outsized forensic value. First, when a user suspends BitLocker (to apply a firmware update, for instance), Windows writes the VMK into the metadata as a clear key — an unprotected protector sitting in plaintext on the disk — so a suspended BitLocker volume is effectively not protected at all, and tools will mount it without any secret. Second, BitLocker offers auto-unlock for non-system (data) volumes, storing that volume's key wrapped under the system volume's key; if you can unlock C:, the auto-unlocked D: comes with it. Both are reminders of theme three — every action leaves a trace — applied to convenience features: each shortcut a user enables is a door an examiner can later walk through.

FileVault (macOS)

FileVault 2 is Apple's FDE, standard since OS X 10.7 Lion and on by default during setup on modern Macs. On Intel Macs it originally encrypted a CoreStorage volume with AES-128 in XTS; on APFS (the default file system since macOS 10.13 High Sierra) it uses APFS native encryption, AES-XTS. The hierarchy mirrors the others: a per-volume Volume Encryption Key (VEK) encrypts the data and is wrapped by a Key Encryption Key (KEK), which is unlocked by an authorized user's login password or by a recovery key.

The decisive variable on modern Macs is hardware. Macs with the Apple T2 Security Chip (2018–2020 Intel models) and all Apple Silicon Macs (M1 and later) have a Secure Enclave — an isolated coprocessor that generates and stores keys that never leave the chip in plaintext. On these machines the internal SSD is always hardware-encrypted at the controller level regardless of FileVault; turning FileVault "on" really means requiring the user's password to release the keys at boot rather than releasing them automatically. The practical forensic consequence is stark: you cannot remove the SSD from a T2 or Apple Silicon Mac and read it in another machine — the keys are bound to that specific Secure Enclave. There is no chip-off, no transplant; the data is meaningful only on its original logosboard, unlocked by its credential. This is hardware enforcing the key hierarchy.

When you are authorized and have a credential, the path is straightforward, and recovery keys come in two flavors that map directly to the personal/corporate divide:

# List FileVault status and enabled users
fdesetup status
fdesetup list

# Unlock / mount an encrypted APFS volume with a password or recovery key
diskutil apfs listCryptoUsers /dev/disk2s1
diskutil apfs unlockVolume /dev/disk2s1 -user <UUID> -passphrase <password-or-recovery-key>

# (Older CoreStorage volumes)
diskutil coreStorage unlockVolume <UUID> -passphrase <password>

A personal recovery key is a 24-character alphanumeric string (shown in groups, e.g. XXXX-XXXX-XXXX-XXXX-XXXX-XXXX) generated when the user enables FileVault and optionally escrowed with Apple via iCloud. An institutional recovery key is deployed by organizations as a FileVaultMaster.keychain containing a certificate and private key, allowing IT to unlock any managed Mac — the macOS analog of BitLocker's Active Directory escrow, and the reason a corporate Mac in a lawful internal investigation is usually openable while a stranger's personal MacBook is usually not.

LUKS (Linux)

LUKS — the Linux Unified Key Setup — is the standard for disk encryption on Linux, layered over the kernel's dm-crypt. It is the most transparent of the four to an examiner, because its on-disk header is documented and readable (the header, not the data). A LUKS partition begins with a recognizable magic value:

$ xxd -l 16 luks-partition.dd
00000000: 4c55 4b53 babe 0002 0000 0000 0000 0000  LUKS............
          └───────┘ └──┘ └──┘
          "LUKS"    BABE  version (00 02 = LUKS2; 00 01 = LUKS1)

LUKS embodies the key-slot model explicitly. The randomly generated master key (the media key) is stored, encrypted, in one or more key slots — up to 8 in LUKS1, up to 32 in LUKS2 — each slot holding the master key wrapped by a key derived from a different passphrase. Any single valid passphrase unlocks the volume. This is exactly the multi-protector idea made visible, and it has direct investigative meaning: several people may each hold a different passphrase to the same disk, a slot can be added for a new custodian without disturbing existing access, and deleting a slot does not destroy the data as long as another slot's passphrase is known. You read the header without ever touching the encrypted data:

# Dump the LUKS header: cipher, KDF, and which key slots are populated
cryptsetup luksDump /dev/sdb1

# Back up the header BEFORE any operation — it is small, vital, and easily corrupted
cryptsetup luksHeaderBackup /dev/sdb1 --header-backup-file case-2026-0142-luks.hdr

# Unlock with an authorized passphrase, mounting the decrypted mapping read-only
cryptsetup --readonly luksOpen /dev/sdb1 evidence_decrypted
mount -o ro /dev/mapper/evidence_decrypted /mnt/case

A representative luksDump tells you the cipher, the KDF, and — the part you care about — which slots are live:

LUKS header information
Version:        2
Epoch:          5
Cipher name:    aes
Cipher mode:    xts-plain64
Hash:           sha256
Keyslots:
  0: luks2
        Key:        512 bits
        PBKDF:      argon2id          ← LUKS2 default; memory-hard, brute-force-resistant
        Time cost:  6
        Memory:     1048576           (1 GiB per guess — deliberately expensive)
  1: luks2  (ENABLED)                 ← a SECOND passphrase exists
  2-31: (unbound)

The KDF line is the whole story for a brute-force assessment. LUKS1 used PBKDF2; LUKS2 defaults to Argon2id, a memory-hard function that requires (here) a gibibyte of RAM per guess — turning a GPU brute-force farm's millions-of-guesses-per-second into a crawl. Against a strong passphrase and Argon2id, brute force is hopeless; against a weak one, the dump tells you precisely what you are up against.

VeraCrypt (cross-platform)

VeraCrypt — the open-source successor to the discontinued TrueCrypt — is the one designed specifically to frustrate examiners, and it is the most important of the four to understand for exactly that reason. It encrypts containers (files), partitions, or whole system drives, with AES, Serpent, Twofish, or cascades of them (e.g., AES-Twofish-Serpent, three ciphers in series), and KDFs (PBKDF2 with SHA-512, SHA-256, Whirlpool, or Streebog) hardened by a high default iteration count and an optional user PIM (Personal Iterations Multiplier) that drives the cost even higher.

Its defining forensic property is the absence of any signature. Where BitLocker shows -FVE-FS- and LUKS shows LUKS\xBA\xBE, a VeraCrypt volume has no identifiable header. The first 64 bytes are a random salt; the rest of the header is itself encrypted; and the entire volume — header and data alike — is statistically indistinguishable from random noise. There is nothing to find:

   A VeraCrypt volume on disk — the "looks like nothing" by design:

   offset 0x000  ┌───────────────────────────┐
                 │ 64 bytes: random SALT      │  ← no magic, no version, no clue
   offset 0x040  ├───────────────────────────┤
                 │ encrypted header           │  ← decrypts to ASCII "VERA" at
                 │ (keys, size, flags)        │     rel. offset 0x40 IF the
   offset 0x200  ├───────────────────────────┤     password+PIM are correct
                 │                            │
                 │   encrypted data area      │  ← uniform high entropy,
                 │   (every sector random)    │     no file-system structure
                 └───────────────────────────┘

VeraCrypt verifies a password by deriving a key from the salt and the candidate passphrase, decrypting the header, and checking whether bytes 64–67 of the decrypted header equal the ASCII magic VERA (56 45 52 41; TrueCrypt used TRUE). No password, no magic, no way to even confirm you are looking at a VeraCrypt volume rather than wiped free space, a corrupted partition, or a swap area. That ambiguity is the feature. It enables hidden volumes — a second, secret volume tucked inside the apparent free space of an outer "decoy" volume, with its own header at a fixed offset (e.g., 0x10000) — so that a holder compelled to reveal a password can surrender the decoy while the hidden volume's existence remains unprovable. This is plausible deniability, and it is engineered precisely to defeat the legal compulsion we will discuss later: you cannot prove a hidden volume exists, so a court cannot find that someone is concealing one.

Tool Tip — recognizing an encrypted volume when there's no signature. When a region has no file-system structure, no recognizable headers, and no long runs of zeros, measure its entropy. Compressed and encrypted data both approach the theoretical maximum of 8.0 bits per byte; ordinary files, file systems, and slack do not. A large region (sized as a clean multiple of 512 bytes) of near-maximal entropy with no decompressible structure is a strong candidate for an encrypted container — though, by VeraCrypt's design, you can rarely prove it. A small Python entropy scan flags candidates fast:

#!/usr/bin/env python3
"""Estimate Shannon entropy of a file/region to flag candidate encrypted volumes.
Illustrative and READ-ONLY: opens the target for reading only; never writes."""
import math, sys, collections

def shannon_entropy(data: bytes) -> float:
    if not data:
        return 0.0
    counts = collections.Counter(data)
    n = len(data)
    return -sum((c / n) * math.log2(c / n) for c in counts.values())

def scan(path: str, block: int = 1 << 20) -> None:
    with open(path, "rb") as f:                 # read-only handle on the evidence
        offset = 0
        while True:
            chunk = f.read(block)
            if not chunk:
                break
            h = shannon_entropy(chunk)
            flag = "  <-- HIGH (encrypted/compressed?)" if h > 7.90 else ""
            print(f"0x{offset:012x}  entropy={h:5.3f}{flag}")
            offset += len(chunk)

if __name__ == "__main__":
    scan(sys.argv[1])

Try This. On a test machine you own, create a small VeraCrypt container and a LUKS partition, then run the scanner above against each, against a normal NTFS image, and against a ZIP archive. You will see the encrypted volumes and the ZIP all sit at ~7.99 while the NTFS image varies wildly and dips to near 0 over its zeroed regions. Then cryptsetup luksDump your LUKS test volume to read its header in the clear, and confirm with xxd that the VeraCrypt container shows no signature at all. Feeling the difference on data you own is worth more than reading about it.

When you have authorization: the key-source playbook

Identification done, the operative question becomes: given lawful authority, where might a usable key come from? There are four broad sources, in rough order of how often they actually pay off. None of them breaks AES; all of them route around it.

Source 1 — Recovery keys and escrow (the common, quiet win)

The overwhelming majority of successful authorized decryptions never involve a clever attack at all. They involve finding the recovery key that an organization, a cloud provider, or the user themselves already stored. This is mundane and it is the right first move every time:

  • BitLocker → Active Directory / Entra / Microsoft account. In a managed enterprise, the 48-digit recovery password is escrowed automatically. A domain investigator queries the computer object's msFVE-RecoveryInformation (via the BitLocker Recovery Password Viewer RSAT feature or the Get-ADObject query shown earlier), matches the Recovery Key ID printed by manage-bde -protectors -get, and unlocks the drive. For a personal Windows machine, the key may be in the user's Microsoft account.
  • FileVault → institutional key or iCloud escrow. A corporate Mac unlocks with the FileVaultMaster.keychain institutional key; a personal one may have its recovery key escrowed with Apple (released only via legal process to Apple).
  • LUKS → an added key slot. Organizations that manage Linux endpoints frequently provision a second key slot holding an admin/escrow passphrase precisely so authorized recovery is possible; the luksDump shows whether such a slot exists.

This is exactly where anchor case two — the employee who covered their tracks — resolves almost anticlimactically on the encryption front. The departing engineer's laptop is a corporate asset with BitLocker managed by Group Policy, so its recovery password sits in Active Directory the whole time. The internal investigation, conducted under the company's authority over its own device, simply retrieves the escrowed key, unlocks the image, and proceeds to the registry, $FILE_NAME timestamps, and USB history that prove the theft (the work of Chapter 16 and Chapter 21). The lesson generalizes: in the enterprise, encryption is rarely the barrier — escrow is the friend of the authorized examiner and the bane of the careless insider.

Chain of Custody. A recovery key is itself evidence, and where it came from matters as much as the data it opens. Document the key's provenance precisely: "Recovery password for Key ID {GUID} retrieved 2026-06-26 from Active Directory object CN=LAPTOP-7F2X9Q3 by [name], under [authority]." Record that you unlocked the working image, not the original; that you mounted the decrypted volume read-only; and the hashes of both the encrypted image (unchanged) and the decrypted volume you analyzed. The defense will ask how you got in and whether unlocking altered the evidence. "We used a lawfully obtained escrow key to unlock a verified copy, mounted read-only, with hashes recorded throughout" is the answer that holds.

Source 2 — Keys in memory (live, cold-boot, and DMA)

When a volume is mounted, its FVEK/master key must exist in plaintext in RAM — the CPU needs it to decrypt sectors on the fly. That single fact is the most important offensive opportunity in the whole subject, and it is why Chapter 15 made the live-response decision turn on encryption. If you can capture the RAM of a running, unlocked machine, you very likely capture the key. This is the legitimate, lawful core of memory-based decryption, and it has three modes:

  • Live capture. The machine is on and the volume mounted; you image RAM with a forensic memory acquirer (winpmem, Magnet RAM Capture, f-response, LiME on Linux) before anything powers off. Recall WEB-07 from Chapter 15: the responder retained WEB07-mem.raw precisely so the BitLocker key could be recovered later even if a dead-box image were taken. The key was in that 16 GiB the entire time.
  • Cold-boot attack. DRAM does not lose its contents instantly when power is cut — it decays over seconds, and far more slowly when cold. The 2008 Princeton "Lest We Remember" research (Halderman et al.) showed that chilling memory chips with inverted canned air (to roughly −50 °C) extends remanence to minutes, long enough to cut power, reboot into a tiny RAM-dumping tool, or even transplant the DIMMs into another machine, and recover keys that were live at the moment of power-off. F-Secure demonstrated in 2018 that many modern sleep-state protections could still be bypassed this way.
   DRAM REMANENCE — why a just-powered-off machine still holds the key

   power cut ──▶ time ──────────────────────────────────────────────▶
   room temp:   [████ readable ███▒▒░░ fades in seconds .......... gone]
   chilled ~−50C:[████████ readable for minutes ████████▒▒░░░░ ...... ]
                  ▲ reboot to a RAM imager here, or transplant the DIMMs
  • DMA attack. Direct Memory Access ports — FireWire/IEEE-1394, Thunderbolt, and exposed PCIe — let an attached device read system RAM directly, bypassing the CPU and OS. Tools such as Inception (FireWire) and PCILeech (PCIe/Thunderbolt, by Ulf Frisk) can dump memory from a locked-but-running machine through such a port. The Thunderspy research (Ruytenberg, 2020) extended this to Thunderbolt 3. Mitigations are now common — an IOMMU (Intel VT-d / AMD-Vi), Windows Kernel DMA Protection (Windows 10 1803+), and "block new DMA devices when locked" — so this works mainly against older or unhardened hardware, but it remains a live avenue at a scene where the machine is on.

Limitation. Every memory-based avenue requires the machine to be running with the volume unlocked at the moment of capture. Power the box off — or let its battery die, or let it re-lock on sleep — and the plaintext key in RAM is gone, decayed beyond recovery within seconds at room temperature. This is the entire reason the Chapter 15 decision exists: an unlocked encrypted system is a closing window, and "pull the plug" can be the single most expensive reflex in modern forensics.

Source 3 — Extracting the key from a captured image

A memory image (or, often, a hibernation file hiberfil.sys, page/swap file, or crash dump MEMORY.DMP — all of which are reservoirs of once-resident RAM and may contain a key) does not hand you the key on a labeled platter; you must find it among gigabytes of noise. The classic, tool-agnostic technique exploits a structural fact: an AES key in use is not stored bare but as an expanded key schedule (the round keys derived from it), and a valid key schedule is internally self-consistent in a way random data is not. aeskeyfind (from the cold-boot researchers) scans a raw memory image for byte sequences that form a valid AES-128 or AES-256 key schedule and prints the candidate keys; bulk_extractor does the same via its aes scanner:

# Find candidate AES keys by validating key schedules in a RAM image
aeskeyfind WEB07-mem.raw
#   FOUND POSSIBLE KEYS:
#   a3f1c08e9b...   (256-bit)
#   1d77b4e2...     (128-bit)

# bulk_extractor's AES scanner over the same image
bulk_extractor -E aes -o be_out/ WEB07-mem.raw
cat be_out/aes_keys.txt

[aeskeyfind output — illustrative]
Keyfind progress: 100%
FOUND POSSIBLE KEYS:
  d4 1c 6b 9e a7 03 5f 82 11 c0 4e 9d 36 a8 7b f5   (AES-256 candidate)
  e7 22 90 ab 5c 1f 84 d9                            (AES-128 candidate)

Purpose-built forensic products turn those raw key candidates into a mounted volume automatically. Elcomsoft Forensic Disk Decryptor and Passware Kit Forensic both ingest a memory dump, hiberfil.sys, or page file, locate the FVEK/VMK for BitLocker, FileVault 2, TrueCrypt/VeraCrypt, LUKS, or PGP, and then unlock or decrypt the corresponding image — no passphrase required, because they extracted the media key itself. Volatility (the memory-analysis framework that Chapter 22 covers in depth) is the open-source companion for locating the encryption-related structures and the surrounding process context; community plugins exist to carve BitLocker keys from a Windows memory image, and you corroborate everything against the running state. Whatever the tool, the principle is constant — find the plaintext key the live system was forced to keep in RAM — and it is why the memory image from a lawful live capture is often worth more than the disk image it unlocks.

Source 4 — Exploiting implementation weaknesses (narrow, but real)

When there is no escrow and no live memory, a handful of implementation (not algorithm) weaknesses sometimes apply. They are situational and you should never assume one will work, but they are part of a complete examiner's mental map:

  • TPM bus sniffing (TPM-only mode). In TPM-only BitLocker, the TPM unseals the VMK at boot and transmits it to the CPU over a physical bus — the LPC bus on older systems, SPI on newer ones — and on a discrete TPM that traffic is, by default, unencrypted. An attacker with physical access can attach a logic analyzer (researchers have done it with a sub-$10 Raspberry Pi Pico) to the bus, capture the VMK in the clear during a normal boot, and unlock the drive. This is a real, demonstrated attack against laptops in TPM-only configuration — and it is exactly why TPM+PIN (which gates unsealing on a human secret), a firmware TPM (where the key never crosses an external bus), or TPM 2.0 encrypted bus sessions are the recommended hardening.
  • Suspended encryption / clear keys. As noted, a suspended BitLocker volume stores its VMK as a clear key; tools mount it with no secret. Always check encryption state, not just presence.
  • Weak passphrases + the KDF reality. If a human chose the password and chose poorly, an offline guessing attack on a non-escrowed volume becomes viable. You extract a crackable representation with the John the Ripper "2john" helpers — bitlocker2john, luks2john, veracrypt2john — and run a GPU attack with Hashcat (BitLocker is mode -m 22100; LUKS1 is -m 14600; VeraCrypt and newer LUKS2 have their own modes). But respect the arithmetic: these KDFs are engineered to be slow. Argon2id with a gigabyte memory cost, or PBKDF2 with a high iteration count and a VeraCrypt PIM, can drop your throughput to a handful of guesses per second — so a strong passphrase defeats this utterly, and only weak, short, or reused human-chosen secrets fall. The KDF is the deliberate tax that makes "guess the password" hopeless against a careful user and feasible only against a careless one.

War Story. A unit seized a desktop in a fraud case. The system drive was VeraCrypt-encrypted with a cascade cipher; the machine was powered off when officers arrived. There was no escrow (it was a personal machine), no memory to capture (off for hours), no recovery key, and the suspect, on counsel's advice, said nothing. The lab tried a months-long dictionary-and-rules attack against the extracted header; the passphrase was a long, random phrase the suspect had memorized, and the cascade plus a high PIM made each guess agonizingly expensive. After eight months of GPU time the attack was abandoned. The drive was never opened. The case proceeded on other evidence — bank records and a co-conspirator's testimony — and the encrypted drive was reported, accurately and without apology, as acquired, verified, and inaccessible. Sometimes the honest finding is the only finding, and a strong passphrase used correctly is simply a wall.

When the mathematics wins

It is worth stating plainly, because examiners under pressure (and the attorneys who employ them) sometimes refuse to believe it: there are drives you will never read, no matter your budget, tools, or skill. When all four of these conditions hold at once, the volume is, for practical purposes, permanently inaccessible:

  1. The cipher and mode are sound (AES in XTS — i.e., not a broken or homebrew scheme), so there is no cryptographic shortcut.
  2. The protector is only a strong, high-entropy, human-memorized passphrase run through a modern KDF — no TPM-only auto-release, no weak PIN.
  3. The key is not escrowed anywhere you can lawfully reach — no AD, no cloud, no printed copy, no second key slot.
  4. There is no plaintext key in memory to capture — the machine is powered off (or was, long enough for DRAM to decay), with no hibernation file or page file you can read containing a key.

Under those conditions the only remaining attack is to guess the passphrase, and against genuine entropy the keyspace defeats you exactly as the AES keyspace would. A truly random 12-character passphrase from a 95-character set is ~2^78 possibilities; a six-word diceware phrase is ~2^77 — both, multiplied by a deliberately slow KDF, are beyond any feasible attack. This is not a failure of your method; it is encryption working as designed. The mature examiner internalizes this and refuses to promise otherwise. Deleted ≠ destroyed met its one true exception: with a strong key gone, the data is destroyed in the only sense that matters — it cannot be made to mean anything ever again. (And note the mirror image in Chapter 12: ransomware is hostile encryption that weaponizes this same permanence against a victim — which is exactly why backups, not decryption, are the answer there.)

Recovery vs. Forensics. This wall hits both disciplines, and the human cost differs in tone but not in weight. For the forensic examiner, an unbreakable drive means an investigation that must proceed on other evidence — frustrating, occasionally decisive for a guilty party who encrypted well, but a known professional outcome you document and move past. For the recovery technician, it is anchor case one's darkest variant: a client who encrypted their own backup drive — the only copy of a decade of family photographs, a late parent's letters, a business's records — and lost the only passphrase, with no recovery key ever saved. There is no client more desperate and no answer more final. You did not lose their data; their own encryption did, exactly as it was built to. Saying so kindly, and refusing to sell them a false hope or a fraudulent "we can crack anything" service, is the job. Encryption protects everyone equally, including from themselves.

When the technical doors are all closed, one door remains that is not technical at all: the law. If the only thing standing between investigators and the evidence is a passphrase locked in a suspect's memory, can the state compel them to reveal it? This is one of the most contested questions in digital-evidence law, it is unsettled in the United States, and it varies enormously by country. The detailed framework belongs to Chapter 25 (and Appendix E); what follows is the encryption-specific core every examiner must understand, because you are the one who will tell counsel "the only way in is the suspect's passphrase."

The Fifth Amendment and the act of production (United States)

The U.S. Fifth Amendment protects against being "compelled in any criminal case to be a witness against himself." The privilege protects testimonial communications — revealing the contents of one's mind — but not the production of physical things. Courts have long held the state can compel you to provide a blood sample, a handwriting exemplar, or the key to a strongbox, but not the combination to a safe, because the combination exists only in your mind and stating it is testimonial. A memorized passphrase is the digital combination, and that analogy has driven the case law.

The pivotal doctrine is the "foregone conclusion" exception, from Fisher v. United States (1976). The act of producing something can have testimonial aspects — producing a document implicitly testifies that it exists, that you possess it, and that it is authentic. But if the government already independently knows those facts — the existence, your control, and the authenticity of what it seeks — then your production "adds little or nothing" to the government's information and is treated as non-testimonial, and may be compelled. Applied to decryption, the fight is over whether the government already knows enough about what is on the drive (and that the suspect can decrypt it) for production to be a foregone conclusion. The results are genuinely split:

  • In re Boucher (D. Vt. 2009) and United States v. Fricosu (D. Colo. 2012): decryption compelled, because the government had already seen specific incriminating files or otherwise established the foregone conclusion.
  • United States v. Doe (11th Cir. 2012): decryption could not be compelled — the government could not show it knew what, if anything, was on the encrypted drives, so the foregone-conclusion exception did not apply.
  • Commonwealth v. Davis (Pa. 2019): the Pennsylvania Supreme Court held that compelling a passcode violates the Fifth Amendment, treating the passcode itself as testimonial and rejecting the foregone-conclusion theory for the password.
  • State v. Andrews (N.J. 2020): the New Jersey Supreme Court reached the opposite result, compelling disclosure of phone passcodes under the foregone-conclusion doctrine.

The split runs state-to-state and circuit-to-circuit with no Supreme Court resolution. A separate, equally live distinction concerns biometrics versus passcodes: several courts treat compelling a fingerprint or face-scan to unlock a device as non-testimonial (a physical characteristic, like the strongbox key), while a memorized passcode is testimonial (the combination) — though other courts have rejected even biometric compulsion. (Layered atop all of this, Riley v. California (2014) requires a warrant to search a phone's contents at all.) The upshot for the examiner is concrete and tactical: biometric unlock may be compellable where a passphrase is not, which is why responders increasingly try to seize a phone unlocked, or while a registered finger/face can still be compelled, before it falls back to requiring the passcode.

Key-disclosure laws abroad

Other democracies have legislated where the U.S. has litigated, and several do compel disclosure, with criminal penalties for refusal:

  • United Kingdom — RIPA 2000, Part III. Section 49 lets authorities serve a notice compelling disclosure of a key or putting material into intelligible form; section 53 makes failure to comply a criminal offense — up to two years' imprisonment, or five in national-security or indecent-images cases. People have been jailed in the UK purely for refusing to surrender passwords.
  • France — Penal Code Article 434-15-2 criminalizes refusing to hand over decryption keys to material used in a crime.
  • Australia — the Assistance and Access Act 2018 created compulsory assistance powers (including for individuals) and controversial provisions aimed at providers.
  • India — Information Technology Act, Section 69 empowers authorities to compel decryption assistance, with penalties for non-compliance.

The contrast is stark and matters for cross-border cases (and for Chapter 31's jurisdictional tangles): conduct that is a constitutionally protected refusal in one U.S. courtroom is a prosecutable offense in London. An examiner working international matters must know which regime applies before advising on the "just compel the password" option.

Legal Note. Two practical cautions sit on top of all this case law. First, VeraCrypt hidden volumes are engineered to defeat compulsion itself: even a holder ordered to "produce the password" can surrender the decoy volume's password truthfully, and because the hidden volume's existence is mathematically unprovable, no court can find they withheld anything. Second, the law here is genuinely unsettled and jurisdiction-specific — never advise an attorney or investigator on compulsion from memory or from this chapter alone. Your role as the technical witness is to state precisely what is technically required ("the data is recoverable only with the user's passphrase or a key we do not possess") and let counsel and the court fight the constitutional question. Document that statement carefully; it is often the hinge on which a motion turns. The full legal treatment, with citations, is Chapter 25 and Appendix E.

Ethics Note. Encryption is where the recovery technician's duty to refuse work surfaces most sharply. A stranger who brings you a locked drive "that's definitely mine" and asks you to "get past the password" may be the rightful owner — or a thief, an abusive ex, or someone bypassing a lawful seizure. You are not a court, and a service that "cracks any drive, no questions asked" is a service that launders unauthorized access. Verify ownership and authority before you touch a single protector; decline when you cannot; and remember Chapter 28's framing — the same skill that reunites a grieving family with their photos can, misapplied, breach the most private region of someone's life. The key hierarchy does not know whose finger is on the keyboard; you are the control that does.

Worked example: three encrypted drives, three outcomes

Nothing fixes this chapter like watching the same problem — "the volume is encrypted" — resolve three completely different ways depending on the protectors and the state of the machine. Three items arrive at the lab in three unrelated matters.

Item A — the corporate laptop (anchor case two). A departing engineer's company-issued Windows laptop, seized under the employer's authority over its own device. You image it through a write-blocker per Chapter 14; the system volume shows the -FVE-FS- signature. manage-bde -protectors -get (run against the mounted image in a controlled environment) reports a TPM protector and a numerical-password protector with Recovery Key ID {6f1a…}. Because the device is domain-joined, that recovery password is escrowed in Active Directory. You retrieve it from the computer object's msFVE-RecoveryInformation, unlock a working copy of the image, mount the decrypted volume read-only, and record the provenance of the key and the hashes of both the encrypted and decrypted images. Encryption added perhaps an hour to the case. From here the investigation is ordinary Windows forensics — and the $FILE_NAME timestamps and USB history do the rest.

DECRYPTION RECORD — Case 2026-0142, Item A
  Volume:        \\?\Volume{...}  (BitLocker, XTS-AES-128, "-FVE-FS-")
  Protectors:    TPM ; NumericalPassword (Recovery Key ID 6f1a... )
  Key source:    AD escrow — CN=LAPTOP-7F2X9Q3, msFVE-RecoveryPassword
                 retrieved 2026-06-26 14:02 by J. Okafor, GCFA (domain admin, authorized)
  Action:        unlocked WORKING COPY; mounted READ-ONLY
  Integrity:     encrypted image SHA-256 = 7f3a...  (unchanged)
                 decrypted volume SHA-256 = 2c84...  (recorded for the analyzed copy)

Item B — the powered-off laptop (anchor case four, clinically). The laptop from the child-exploitation matter (introduced in Chapter 5, acquired in Chapter 14) is, in this variant, protected by BitLocker in TPM+PIN mode with a strong PIN, on a personal machine with no escrow, and it was seized powered off. Walk the playbook: no AD/Entra escrow (personal device); no live memory (off at seizure, DRAM long decayed); no hibernation-file key you can read (it is inside the encrypted volume); TPM+PIN means no auto-release to sniff and no clear key; the PIN gates unsealing and the holder has not provided it. Every technical door is shut. The remaining question is legal — whether a court will compel the PIN — and that turns on the foregone-conclusion analysis above and is counsel's fight, not yours. Your report states the matter exactly and without overreach: the volume was acquired and verified; it is BitLocker-protected in TPM+PIN mode with no accessible key; absent the user's PIN, an escrowed key, or a court-ordered disclosure, the contents are not technically recoverable. That sentence — clinical, precise, honest about the limit — is the professional product. The dignity of any victims and the rights of the accused both depend on you not pretending to a capability you do not have. (The mandatory-reporting duties under 18 U.S.C. §2258A and the examiner-well-being concerns, should the drive ever be opened, are Chapter 28's subject; the report itself is Chapter 26.)

Item C — the running desktop. Officers, briefed on encryption, photograph a suspect's desktop while it is on and logged in and call you before touching it. A VeraCrypt volume is mounted as drive V:. This is the closing window of Chapter 15 made real. You capture RAM first (DESK-mem.raw, hashed immediately), then — recognizing the mounted volume will vanish on power-off — you make a reasoned, documented decision to live-image the decrypted V: while it is accessible, and you retain the memory image as the key reservoir. Back in the lab, aeskeyfind DESK-mem.raw (corroborated by Passware against the same dump) yields the volume's master key; you confirm it mounts the encrypted image read-only to identical plaintext, giving you a clean, repeatable path to the data and a key whose provenance you can defend.

$ aeskeyfind DESK-mem.raw
FOUND POSSIBLE KEYS:
  9b 2e f0 a4 ... (AES-256 candidate)   <-- mounts encrypted image V: read-only

The contrast writes itself: had officers reflexively shut the machine down, Item C would have become Item B — a powered-off VeraCrypt volume with no signature, no escrow, no memory, and (given VeraCrypt's deniable design) not even a provable existence — i.e., the unbreakable wall of the war story above. One trained decision at the scene was the entire difference between a solved case and a permanent dead end.

Common mistakes

  • Giving up before checking for escrow. The most common waste of an openable drive. In any managed environment, BitLocker keys live in Active Directory/Entra, FileVault has an institutional key, and LUKS may have an admin slot. Query the escrow first; the clever attacks are for when escrow fails, not before.
  • Pulling the plug on a running, unlocked encrypted machine. The most common waste of an unbreakable-once-off drive. The plaintext key is in RAM right now and gone seconds after power-off. Capture memory (and consider a live image) before anyone touches the power — the single most expensive reflex in modern forensics.
  • Promising a decryption the math will never deliver. Telling a court, client, or boss "we'll get in" on a strong-passphrase, no-escrow, powered-off volume. You won't. Overpromising here destroys credibility and, in court, your standing as an expert.
  • Mistaking suspended for protected (and vice versa). A suspended BitLocker volume has a clear key and mounts with no secret; check the encryption state, not just the -FVE-FS- signature, before concluding a drive is locked — or that it is safely encrypted.
  • Treating the recovered key as un-evidence. A key from RAM, escrow, or the suspect is itself evidence with provenance and chain-of-custody obligations. Document where every key came from and that you applied it to a read-only copy.
  • Working decryption on the original. Unlock and mount the working image, read-only, never the original evidence drive. The original is sacred even when it is ciphertext.
  • Assuming you can read a T2/Apple-Silicon SSD elsewhere. The keys are bound to that Mac's Secure Enclave; the removed chip is meaningless. Plan acquisition around the live, authenticated machine.
  • Forgetting biometrics-vs-passcode timing. A locked phone may be compellable by fingerprint/face but not by passcode in some jurisdictions, and biometric unlock expires after reboots/timeouts. Coordinate with counsel fast; the legal window can close as quickly as the technical one.
  • Ignoring hidden-volume deniability. Surrendering "the" VeraCrypt password may reveal only a decoy. You generally cannot prove a hidden volume exists — say so rather than implying you have everything.

Limitations: knowing when to stop

This chapter is, in a sense, the book's limitations chapter — encryption is where theme five stops being a caution and becomes a hard physical boundary. State the limits as plainly as you would any finding:

  • Strong, correctly used encryption is unbreakable. Sound AES-XTS + a high-entropy, KDF-stretched, memorized passphrase + no escrow + no resident key = a volume no tool, budget, or technique will open. "Brute force" against genuine entropy fails for the same reason brute-forcing AES does. This is not a skills gap; it is mathematics.
  • The key sources are conditional, not guaranteed. Escrow exists only if someone configured it. A key in RAM exists only while the machine runs unlocked. Implementation weaknesses (TPM-only sniffing, suspended clear keys, weak passwords) apply only when present. None is a method you can count on; each is an opportunity you check for.
  • Some hardware forecloses options entirely. T2/Apple-Silicon Secure Enclaves bind keys to one machine — no chip-off, no transplant. Modern IOMMU/Kernel DMA Protection neutralizes DMA attacks. The avenues that exist on old hardware may simply not exist on new hardware.
  • Deniable encryption can defeat even legal compulsion. VeraCrypt hidden volumes are designed so that compelling "the" password proves nothing about what else may exist. You cannot report the absence of what you cannot detect.
  • The honest finding is a complete finding. "Acquired, verified, and inaccessible — encrypted with no available key" is not a failure to investigate; it is the result of investigating. Pair it, where relevant, with the legal path (a compulsion motion) and stop. Overreaching past this line is where examiners lose cases and credibility.

Progressive project: the encryption question for your case file

Your Forensic Case File now confronts the question every modern investigation must answer before analysis can proceed: is anything encrypted, and if so, can I lawfully get in? Add an encryption assessment to your case file.

Do this:

  1. Detect. Run the entropy scanner above (or your tool's encryption detection) across your acquired image. Flag any high-entropy regions and identify volumes by signature: -FVE-FS- (BitLocker), LUKS\xBA\xBE (LUKS), the FileVault/APFS encryption flag, or no signature (a VeraCrypt candidate). Record offsets and sizes.
  2. Identify the protectors. For each encrypted volume, document the system and, where readable, its protectors/key slots/KDF (manage-bde -protectors -get, cryptsetup luksDump, fdesetup status). This is your map of possible doors.
  3. Enumerate lawful key sources. For this case's authority, list which sources are available: escrow (AD/Entra/institutional/key-slot), a memory image (did you capture RAM while it was unlocked?), a hibernation/page file, a suspended/clear-key state, a weak-password attack, or a legal-compulsion path. Note which are present and which are absent.
  4. Act on the best available source, on a copy. If you have a lawful key, unlock a working copy, mount read-only, and record the key's provenance and both images' hashes. If you do not, say so.
  5. Write the finding. Draft the one-paragraph encryption finding for your report — either "decrypted via [source], analysis proceeds" with full provenance, or the clinical "acquired, verified, and inaccessible; recoverable only via [PIN/escrow/court order]" statement.

Add to your case file: the entropy/signature scan output, the protector inventory, the lawful-key-source enumeration, the decryption record (or the inaccessibility finding), and updated hashes for any decrypted working copy. You now treat encryption the way a professional does — as a question to be assessed and answered, not a panic to be improvised.

Summary

Encryption is where the toolkit of the first twenty-eight chapters meets its limit, and this chapter taught you to work that limit precisely rather than fear it. Full-disk encryption applies AES in a length-preserving sector mode (XTS) so that every sector becomes high-entropy noise with no structure to carve or parse — deleted ≠ destroyed finally meeting its one true exception. But the password is never the key: a key hierarchy wraps a large random media key (FVEK) inside an intermediate key (VMK) inside one or more protectors — a password through a KDF, a recovery key, a TPM sealed to boot measurements, a startup key — and the strength of the whole is the strength of the weakest enabled protector. You learned to recognize the four systems on sight: BitLocker by its -FVE-FS- signature, 48-digit recovery password, and Active Directory/Entra escrow (with suspended-clear-key and auto-unlock quirks); FileVault by its APFS encryption and T2/Apple-Silicon Secure Enclave that binds keys to one machine; LUKS by its readable LUKS\xBA\xBE header and explicit key slots; and VeraCrypt by its deliberate absence of any signature, enabling hidden volumes and plausible deniability. Given authorization, you pursue keys in order: escrow first (the quiet, common win, and why anchor case two's corporate laptop opens in an hour); then keys in memory from a live capture, cold boot, or DMA attack (the closing window that makes the Chapter 15 "don't pull the plug" decision life-or-death for the evidence); then extracting that key from a RAM image, hiberfil, or page file with aeskeyfind, bulk_extractor, Elcomsoft, or Passware; and finally implementation weaknesses — TPM-only bus sniffing, clear keys, and weak-passphrase attacks throttled by deliberately slow KDFs. And you learned the wall: sound cipher + strong memorized passphrase + no escrow + no resident key = a drive no one will ever open, where the honest finding "acquired, verified, and inaccessible" is the complete and professional result. Wrapped around all of it is the law — the unsettled U.S. Fifth Amendment fight over compelling a passphrase, governed by the foregone-conclusion doctrine and split court-by-court, the biometrics-versus-passcode distinction, and foreign key-disclosure laws that jail those who refuse — because when every technical door is shut, the last door is legal, and you are the one who must tell counsel, precisely and without overreach, exactly what the technology does and does not permit.

You can now: - Explain how full-disk encryption works at the level of AES, XTS sector mode, and the key hierarchy (media key → intermediate key → protectors), and why changing a password never re-encrypts the disk. - Identify BitLocker, FileVault, LUKS, and VeraCrypt volumes by their on-disk signatures (or deliberate lack of one) and enumerate their protectors, key slots, and KDFs. - Pursue a lawful key in the right order — escrow, memory capture, key extraction, implementation weaknesses — and apply it to a read-only working copy with documented provenance. - Recognize instantly when a volume is genuinely unbreakable and write the clinical "acquired, verified, and inaccessible" finding instead of overpromising. - Explain the Fifth Amendment foregone-conclusion debate, the biometrics-vs-passcode distinction, and foreign key-disclosure laws — and advise counsel on what is technically required without overstepping the legal question. - Capture the encryption key from a running, unlocked machine before power-off destroys it — and explain why that single decision can decide a case.

What's next. Chapter 30 — Anti-Forensics (and detecting it) — turns from suspects who encrypt to suspects who try to erase, hide, and falsify the traces of what they did. You will see how wiping tools, timestomping, log deletion, and steganography work — and, in keeping with theme three, how each of them leaves its own tell-tale trace for the examiner who knows where to look.

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.