Re: [dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors

[Sven Eschenberg <sven@eschenberg.eu>]

Am 25.04.2017 um 15:44 schrieb Dominic Raferd:
>
>
> On 25 April 2017 at 14:14, Robert Nichols <rnicholsNOSPAM@comcast.net
> <mailto:rnicholsNOSPAM@comcast.net>> wrote:
>
>     On 04/24/2017 06:49 PM, protagonist wrote:
>
>         However, I assume it is likely that a determined attacker running as
>         root might be able to extract the master key from RAM if the
>         encrypted
>         volume in question is still open at the time of attack, so
>         technically,
>         there would be a way to do this without the password.
>
>
>     It's trivial. Just run "dmsetup table --showkeys" on the device.
>
>
> Wowzer. 'cryptsetup luksDump <device> --dump-master-key' can also
> provide this info but it requires a passphrase, which 'dmsetup table
> --showkeys' does not. So must we assume that anyone who has ever had
> root access while the encrypted device is mounted can thereafter ​break
> through the encryption regardless of passphrases? At least until
> cryptsetup-reencrypt is run on the device, which is a big step.
>

Furthermore, everyone who had access to /dev/mem and was able to locate 
the keys knows, them. On second thought, this holds certainly true for 
the 'new central kernel key storage' (Forgot the name), depending on the 
allover kernel configuration and userspace, that is.

At the end of the day dm-crypt (etc.) needs to store the key somewhere, 
where it can be accessed at all times when an IO-Request comes in. There 
is not that many options for that ;-).