Good practices for AES key derivation and management

Question

I'm developping a device based on STM32L4x6. It is connected through BLE to a smartphone and it exchanges encrypted data with it. Data consists of health data of patients.

Encryption is AES-GCM 256 bits and I'm using the reference implementation provided by STMicro.

I have implemented a classical shared secret exchange mechanism using Diffie-Helman protocol on Curve25519. Right now I am using this shared secret directly as the AES key.

I know that I need to derive a "cryptographycally good" AES key from this shared secret.

I was planning to use HKDF-SHA512 for that, because it seems to be a widely used algorithm and also because a reference implementation is also provided by STMicro. Is it a good choice ?

I'm confused about the size and the nature of the salt to derive the key. Do you have any advice for that ?

From what I understood one can use HKDF-SHA512 to generate a key of 256 bits, do you confirm ?

Also regarding the derivation frequency : at what frequency should I derive a new key ?

Thank you

Answer 1

I know that I need to derive a "cryptographycally good" AES key from this shared secret... I was planning to use HKDF-SHA512 for that, because it seems to be a widely used algorithm and also because a reference implementation is also provided by STMicro. Is it a good choice?

Yes, it is. HKDF is standardized and well regarded.

I'm confused about the size and the nature of the salt to derive the key. Do you have any advice for that?

If a random is already provided within the protocol you may want to use that. A random of 64 to 128 bits should be plenty. Anything over 256 bits is madness. Note that the salt is complementary; a salt of any size is better than nothing.

The salt must of course be known at both sides, so it will complicate the protocol somewhat if it isn't available yet.

From what I understood one can use HKDF-SHA512 to generate a key of 256 bits, do you confirm?

Sure thing, you can just take the leftmost 256 bits. You could use 96 bits of the remaining bits for the IV.

Also regarding the derivation frequency : at what frequency should I derive a new key?

That depends on the use case. For smart cards you may just derive the key once at the start of the protocol and simply halt if too much data is being processed, as smart cards are not meant to be continuously available. But if your secure channel of your transport protocol is just established once then you may want to reestablish after a certain amount of messages.

Hints on how to make sure that the keys are fresh are in chapter 8 of the GCM specification by NIST, specifically chapter 8.3 which specifies how GCM is to be used.

---

Beware that there are many pitfalls in creating a transport protocol; you may want to have a look at TLS 1.3 or even implement it directly. TLS 1.3 also is able to use GCM as well as HKDF.