Re: [RFC PATCH v2 10/11] crypto: x86/aes-kl - Support AES algorithm using Key Locker instructions

[Andy Lutomirski <luto@kernel.org>]

On 5/14/21 1:15 PM, Chang S. Bae wrote:
> Key Locker (KL) is Intel's new security feature that protects the AES key
> at the time of data transformation. New AES SIMD instructions -- as a
> successor of Intel's AES-NI -- are provided to encode an AES key and
> reference it for the AES algorithm.
> 
> New instructions support 128/256-bit keys. While it is not desirable to
> receive any 192-bit key, AES-NI instructions are taken to serve this size.
> 
> New instructions are operational in both 32-/64-bit modes.
> 
> Included are methods for ECB, CBC, CTR, and XTS modes. They are not
> compatible with other implementations as referencing an encrypted form
> only.

This entire concept is severely problematic.  The nineties are over --
in 2021, a responsible author of a crypto library will understand,
document, and preferably prove what security properties it is supposed
to have.

Even assuming that Key Locker is used properly and that the wrapping key
is never compromised, the security properties of Key Locker-ified
AES-CTR are weak at best.  In particular, all the usual caveats of CTR
apply, and KL does nothing to mitigate it.  Any attacker who recovers,
directly or by capture of a plaintext-ciphertext pair, enc_k(0),
enc_k(1), etc can encrypt and forge any message involving those counter
values.

In-kernel support for an AES Key Locker mode needs to document precisely
what that mode accomplishes and when it should and should not be used.

At least AES-XTS *probably* has the property that at attacker who gets
the contents of main memory once can't decrypt future disk images
encrypted against the same key.  AES-CTR can't even achieve that.

So far, the only compelling use case for KL that I've seen is full disk
encryption.  I think it would be nice for the entire process of doing
that to be worked out.

--Andy