LUKS (dangerous operations)
Orca, Feb. 5th, 2025
Below documents a few dangerous operations that directly deal with encryption material, you should never use them during normal operation routine. But if something is disastrously wrong and you're looking for a way to cover your ass, go ahead.
Dump volume encryption key (also known as Master Key/MK) of a LUKS encrypted volume by decrypting LUKS header
This method requires your knowledge of any password or possession of any keyfile.
cryptsetup luksDump --dump-volume-key <encrypted-device>
(--dump-master-key
is an obsolete alias of --dump-volume-key
)
Accept the warning and enter any password, cryptsetup will return a master key:
LUKS header information for <encrypted-device>
Cipher name: aes
Cipher mode: xts-plain64
Payload offset: 4096
UUID: <UUID>
MK bits: 512
MK dump: <512 bits master-key dump in hex format>
You have volume key in hex format now.
Dump volume encryption key of a LUKS encrypted volume from dmcrypt
This method is only available if the encrypted volume is in LUKS1 format, or opened with kernel keyring disabled (with option --disable-keyring
).
Use this command to extract volume encryption key from dmcrypt:
dmsetup table --target crypt --showkey /dev/mapper/<target-decrypted-volume>
0 16026704 crypt aes-xts-plain64 <master-key dump in hex format> 0 252:0 4096
You have volume key in hex format now.
Dump volume encryption key of a LUKS2 encrypted volume from kernel memory, with LiME and aeskeyfind
If the volume key is stored in kernel keyring (LUKS2 default), no userspace tool (even if running as root) can extract that from kernel memory space (due to ring3 –> ring0 security boundary) unless they use a kernel exploit (which is quite overreacting for this purpose). However we can use LiME, a memory extracating kernel module to dump kernel memory to disk.
This only works for volumes encrypted using AES encryption algorithm. During testrun, aeskeyfind failed to locate a Serpent MK that's in the memory.
(1) Install LiME on Debian
# apt install lime-forensics-dkms --install-recommends -y
...
Loading new lime-forensics-1.9.1-5 DKMS files...
Building for 6.1.0-29-amd64
Building initial module for 6.1.0-29-amd64
Done.
lime.ko:
Running module version sanity check.
- Original module
- No original module exists within this kernel
- Installation
- Installing to /lib/modules/6.1.0-29-amd64/updates/dkms/
depmod...
...
(2) Dump memory with LiME
# modprobe lime path=/root/dev_mem format=raw
...
<System freezes for some time>
...
# ls /root
dev_mem
Note: LiME creates memory dump as a regular file, it isn't a mapping of current memory, like /dev/kcore
and friends.
(3) Install aeskeyfind
, a utility to search 128-bit and 256-bit AES keys from memory dump
# apt install aeskeyfind
(4) Find AES keys in memory dump
# aeskeyfind ./dev_mem
9a4eb92cd7a4f8cd0d9492fa8d0dd8d35900f3bc4e8731127e7ecac3b068ac5b
2e6b1ed3227019d6fb43f4da4fe5ab888bc422305a1b2554b0fc206813602bbb
Keyfind progress: 100%
Note: You'll likely end up with more than one keys in result. You need to see how long the MK actually is with cryptsetup luksDump /dev/<encrypted-volume>
. If the MK is 512-bit and aeskeyfind found 2 256-bit keys then you need to stitch them together to create a 512-bit MK. Try again by putting one piece of key before the other if it didn't work the first time.
BTW, running aeskeyfind with -v
(verbose) can provide more information about these key's layout in memory:
# aeskeyfind -v ./dev_mem
FOUND POSSIBLE 256-BIT KEY AT BYTE 89671c30
KEY: 9a4eb92cd7a4f8cd0d9492fa8d0dd8d35900f3bc4e8731127e7ecac3b068ac5b
...
FOUND POSSIBLE 256-BIT KEY AT BYTE 89671e20
KEY: 2e6b1ed3227019d6fb43f4da4fe5ab888bc422305a1b2554b0fc206813602bbb
...
You can see that “2e6b...”'s location is ahead of “9a4e...” so stitching it to “2e6b...9a4b...” is more likely the correct answer than not.
(5) (ref) For reference, dump current volume key from header and compare the results.
# cryptsetup luksDump --dump-master-key <encrypted-device>
<WARNING OMITTED>
Enter passphrase for <encrypted-device>:
LUKS header information for <encrypted-device>
Cipher name: aes
Cipher mode: xts-plain64
Payload offset: 32768
UUID: <UUID>
MK bits: 512
MK dump: 2e 6b 1e d3 22 70 19 d6 fb 43 f4 da 4f e5 ab 88
8b c4 22 30 5a 1b 25 54 b0 fc 20 68 13 60 2b bb
9a 4e b9 2c d7 a4 f8 cd 0d 94 92 fa 8d 0d d8 d3
59 00 f3 bc 4e 87 31 12 7e 7e ca c3 b0 68 ac 5b
Convert hex format master key dump to binary format recognisable by cryptsetup
# apt install xxd -y
...<OMITTED>...
# echo <master key in hex format> |xxd -r -p >mk.dump
# ls -l
-rw-r--r-- 1 <user> <group> 64 <date> mk.dump
(64 bytes = 512 bits)
Or just create a binary mk dump file with any hex editor.
Decrypt a LUKS encrypted volume with master key dump
cryptsetup open --volume-key-file ./mk.dump <encrypted-device> <dm-mapped-name>
Add a new keyslot based on the master key dump
cryptsetup luksAddKey --volume-key-file ./mk.dump <encrypted-device>
(--master-key-file
is an obsolete alias of --volume-key-file
)
You'll be prompted to enter a new password to encrypt the MK.