When a LUKS password is sent to the LUKS header for decryption, can it be stolen by a hacker who modified the LUKS header? Suppose my boot partition is healthy.
closed as unclear what you're asking by Rui F Ribeiro, user88036, Romeo Ninov, G-Man, Isaac Oct 14 '18 at 14:08
Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
LUKS header contains no executable code, only one or more encrypted copies of the master key of the LUKS partition. Each configured passphrase/keyfile/other access method will decrypt a copy of the master key, which is needed to access the encrypted disk. The LUKS password is not "sent to LUKS header for decryption": instead, the
cryptsetup luksOpen command reads the LUKS header, then decrypts it in memory using the password.
If a hacker has successfully modified the LUKS header, it pretty much indicates the hacker (or a hacking tool) already knew the LUKS password, as it is needed to successfully modify the LUKS header without corrupting it.
A possible scenario might be a hacker adding replacing the regular
cryptsetup command in the initramfs file of your root partition with a modified one: the modified
cryptsetup would request your LUKS password just like a normal one, but then, in addition to unlocking the disk, would re-encrypt the master key of the LUKS partition with another password that is known to the attacker, and store it in one of the free slots in the LUKS header. Alternatively, it could just store the unencrypted master key in some hidden location outside the encrypted LUKS partition. Then the modified
cryptsetup could replace the modified initramfs file on your boot partition with the original one, making it hard to detect what has really happened.
cryptsetup luksDump can be used to view the contents of the LUKS header in human-readable form. If you see more key slots in use than expected, you can use
cryptsetup luksKillSlot to disable the unauthorized key slots without knowing the password associated with them. Be careful with this command: it is possible to lock yourself out of the encrypted disk if you make mistakes with this command.