linux-kernel - Re: [RFC PATCH 7/8] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Fri, 14 May 2021 20:48:34 +0000
From:   "Bae, Chang Seok" <chang.seok.bae@...el.com>
To:     Andy Lutomirski <luto@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...nel.org>, Borislav Petkov <bp@...e.de>,
        X86 ML <x86@...nel.org>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        "Williams, Dan J" <dan.j.williams@...el.com>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "Sun, Ning" <ning.sun@...el.com>,
        "Dwarakanath, Kumar N" <kumar.n.dwarakanath@...el.com>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 7/8] crypto: x86/aes-kl - Support AES algorithm using
 Key Locker instructions

First of all, my apologies for the delay. I wish now with v2 [1] is a
momentum. 

On Dec 17, 2020, at 12:54, Andy Lutomirski <luto@...nel.org> wrote:
> 
> What does this patch *do*?

It adds a new AES implementation that can be a replacement for the AES-NI
version.

> IKL gives a few special key slots that have certain restrictions and
> certain security properties.  

I think this can be viewed as one implementation of Envelope Encryption.
Internal Wrapping Key (IWKey) on the spec is practically Key-Encryption Key.
Each CPU has one key state and it is used to encode AES keys (or Data
Encryption Key) as many as a user wants. An encoded form may convey access
restrictions.

> What can you use them for?  With this series installed, what is the
> user-visible effect?  Is there a new API?  Do you use them with the netlink
> user crypto interface?  Do you use them for encrypting disks?  Swap?  

No new API is added here.

No observable effect is expected to end-users. AES Key Locker provides the
same function of transforming data and does this for the chaining modes at the
same speed (or a bit faster).

As a replacement for AES-NI, the usage will be pretty much the same as
AES-NI’s. Admittedly, this instruction set has some limitations, e.g., with no
192-bit key support.

Since it can protect AES keys during the transformation, I think one may
consider using it for huge data. So, yes, block disk encryption for instance.
For testing purposes though, I was able to run it with dm-crypt [2].

> How?  How do you allocate, reset, and free keys?  Who has permissions to use
> them?

IWKey (or KEK) is loaded only in kernel mode. The value is randomized.

FWIW, the code intentionally sets a restriction to the encoded form. Once
encoded from an AES key, AES instructions that referencing it have to be
executed in kernel mode.

Thanks,
Chang

[1] https://lore.kernel.org/lkml/20210514201508.27967-1-chang.seok.bae@intel.com/
[2] https://gitlab.com/cryptsetup/cryptsetup/-/wikis/DMCrypt