AES Ciphertext as key to another AES operation

Chris Liaw

6/14/24, 6:11 AM

I've this requirement to 'derive' a session key from an AES key that is stored inside a HSM. I don't want to mention which HSM since what I intended to do is to make the system HSM neutral.

The initial idea is to use any existing KDF algorithms but since the AES key is in hardware, the KDF is only possible if the HSM supports it. But again I don't want to tie down to particular HSM.

Therefore the idea to use the AES key inside the HSM to encrypt a known random string for each session, using the most common mode such as CBC and use the ciphertext as 'derived' value for a subsequent AES operation which happened outside of the HSM.

Is there any concern of this design?

0 + 7

aes

Sacha Servan-Schreiber

6/14/24, 8:42 AM

If it's helpful, an AES ciphertext can be used as a key for another AES operation. In the context of one-way compression functions, this is known to be secure: see [Matyas–Meyer–Oseas](https://en.wikipedia.org/wiki/One-way_compression_function#Matyas%E2%80%93Meyer%E2%80%93Oseas). I'm not sure if this would be secure as a KDF, however.

Marc Ilunga

6/14/24, 9:55 AM

Assuming the key in the HSM was randomly and securely generated, it is possible to use another key for KDF. In general, a new key can be computed using a PRF keyed with the original key and taking as input some value. Note that the value does not need to be random or secret, just unique per application/context. For AES based method, the CMAC mode is a good PRF. Other alternatives are HMAC.

Chris Liaw

6/14/24, 11:29 AM

@MarcIlunga using CMAC mode I assume requires HSM to support it?

Chris Liaw

6/14/24, 11:31 AM

@SachaServan-Schreiber Then I would think if use the HSM key ciphertext as input to a KDF before it becomes an input of the subsequent AES would be much better in that case.

poncho

6/14/24, 12:24 PM

The problem with CBC mode encryption is that the HSM might insist on selecting a random IV each time; that might not be a problem unless you need to derive the same key twice (e.g. once by the encryptor, once by the decryptor)

Chris Liaw

6/14/24, 12:54 PM

@poncho Yeah you're correct unless the HSM allow IV to be set from application

poncho

6/14/24, 1:11 PM

One obvious alternative is to use CBC mode *decryption* - the cavaet there is if the HSM insists on removing "padding" (and will return an error if the padding is bad). One work around for that would be to use a padding attack to find a ciphertext with a valid padding - if this is needed, this would require 128 decryptions on average, 256 worse case - obviously, not great, however, it would be possible on just about any HSM...

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: AES Ciphertext as key to another AES operation

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.