Re: [PATCH v4 11/13] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions

[Bae, Chang Seok]

On Dec 24, 2021, at 09:42, Andy Lutomirski <luto@xxxxxxxxxx> wrote:
> 
> I find it a bit bizarre that this tries to be a drop-in replacement for normal
> AES.  Is this actually what we want, or do we want users to opt in to the KL
> implementation?
> 
> It seems like it might make more sense for tools like cryptsetup (or dm-crypt
> -- the actual layer is subject to some degree of debate) to explicitly create
> a key handle and then ask the kernel to use that key handle, not for the
> kernel to do this by magic.

Yeah, it is ideal to encode a key early but it was considered less significant
in terms of key protection versus doing it via setkey().

This opt-in looks to be the --cipher option specific and cryptsetup even
allows users to directly choose kernel’s crypto API via “capi:”.

I suspect in case a user wants to pick a specific crypto implementation via
“capi:”, one should have studied it.

But indeed, such question deserves more discussion here.

> What happens when someone applies your patches and runs dmsetup table
> --showkeys?

"dmsetup table --showkeys" [1] shows UUID that could be found when dumping the
master key by giving the passphrase, like [2]. The volume key in LUKS header
is under the user key.

> Why should the use of keylocker be part of the luksFormat operation? Surely a
> non-KL machine should still be able to decrypt a nominally KL-using volume in
> a pinch, for recovery purposes if nothing else.

I was trying to directly update cipher information in LUKS. But it was not
that smooth. But if it is possible in an acceptable way, decoding KL-volume
with a generic AES (or vice versa) should work. 

They both are AES data transformations so compatible with each other. This was
also tested by setting the default AES cipher in the LUKS then switching each
other by tweaking the priority.

On the bottom, the "reencrypt" option [3] allows updating a cipher in the LUKS
format. But maybe a better option like the above is possible.

Thanks,
Chang

[1]
$ sudo dmsetup table --showkeys /dev/mapper/volume
0 491520 crypt capi:xts-aes-aeskl-plain64 :32:logon:cryptsetup:8c12bfda-3570-406a-b4fe-5ecf1e91eecd-d0 0 7:17 32768

[2] 
$ sudo cryptsetup luksDump  --dump-master-key ./test

WARNING!
========
Header dump with volume key is sensitive information
which allows access to encrypted partition without passphrase.
This dump should be always stored encrypted on safe place.

Are you sure? (Type uppercase yes): YES
Enter passphrase for ./test:
LUKS header information for ./test
Cipher name:    capi:xts
Cipher mode:    aes-aeskl-plain64
Payload offset: 32768
UUID:           8c12bfda-3570-406a-b4fe-5ecf1e91eecd
MK bits:        256
MK dump:        3a 51 37 60 37 d2 58 9f 48 a7 ce 44 f7 ff de 34
               4d b9 6f eb f2 e7 d6 bc e0 c9 76 b6 3d b1 e6 24

[3] https://man7.org/linux/man-pages/man8/cryptsetup-reencrypt.8.html