Disk encryption (FVE)#
Dissect has support for transparent disk encryption. This means that, for supported disk encryption implementations, all Dissect tools will be able to work transparently on the source data, without having to wait on a “decrypted copy” of the source data.
At this time, no implementations are made available open-source.
Because Dissect is designed to work on multiple targets, we need a way to specify one or more encryption keys for one or more targets. Dissect uses the concept of a keychain CSV file for this.
A valid keychain CSV file contains four columns, namely
Optional, can be left blank. The encryption provider ID. E.g.
Required. The key type for this entry. One of
Optional, can be left blank. The UUID of the volume or data that corresponds to this key.
Required. The key value. E.g. a user passphrase, Bitlocker recovery key or path to BEK file.
identifier value is specified, decryption will be attempted by brute forcing using the
provided keys. This can be extremely slow, depending on the implementation, so it’s recommended to enter as much
information in this file as you know.
For example, we may receive a Bitlocker recovery key but don’t know the UUID that it corresponds to. We can run
a Dissect tool with
INFO logging (
-v) to learn if decryption succeeded and what the corresponding UUID is.
With this new knowledge, we can update the keychain file so that future invocations are faster.
--keychain-file can be used with most Dissect tools to specify a keychain CSV
file. Alternatively, if you’re only dealing with a single target or just want to quickly inspect something,
--keychain-value argument can be used to easily specify a key passphrase, recovery key or a
key file on the command line without having to create a keychain CSV file.