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

From: Milan Broz <gmazyland@gmail.com>
To: Sven Eschenberg <sven@eschenberg.eu>, dm-crypt@saout.de
Subject: Re: [dm-crypt] LUKS header recovery attempt, bruteforce detection of AF-keyslot bit errors
Date: Tue, 25 Apr 2017 18:30:00 +0200	[thread overview]
Message-ID: <c036836b-2fec-e974-2ba2-63309e92bfe4@gmail.com> (raw)
In-Reply-To: <8434a425-d7dc-b3d6-9a7e-a93fa9d5037f@eschenberg.eu>

On 04/25/2017 06:16 PM, Sven Eschenberg wrote:
> 
> 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 ;-).

Crypto API stores the key in memory as well (even the round keys etc), obviously.

We have already support for kernel keyring in dm-crypt (so the key will
not be directly visible in dmsetup table), this will be supported in next major
version of cryptsetup/LUKS.

But as you said, if you have access to the kernel memory, it is there anyway...

Milan