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
