Robust cryptosystem for files/chunks protection? I'm not a cryptographic expert by far but I do understand that when it comes to cryptography it's best to stick with established standards.

I have to ensure confidentiality and integrity of a bunch of files (chunks of these files actually).

Getting inspiration from "serious" people, AES-GCM with distinct IVs and keys for each chunk seems the way to go since it provides both confidentiality and integrity, and is good performance-wise.
It also seems a good practice to encrypt each chunk key with a Key Encryption Key that has to be renewed on a regular basis.

Here are my questions:


Did I get it right up to this point?
Are there specific ciphers for encrypting each chunk key with the KEK? Does it require to use an IV since there shouldn't be two identical chunk keys?
What are the good practice/standards to protect the KEK on a server without dedicated hardware such as an HSM?


PS: I'd be glad to take a look at any ressource available and accessible to non-experts on that topic.
I'm looking at a very similar thing, where I need to encrypt data at rest, and the existing file structure that I'm trying to add encryption to is randomly accessed chunks / blocks of binary records.

The file IO I'm working with is performance sensitive, and the binary structure caters for allocating and freeing record space within these chunks.  It is in an embedded environment, so the desktop storage encryption solutions can't be applied.

I looked at AES-GCM after seeing many recommendations for it.  But the NIST guidelines for its use, which require unique IVs for a given key, make it challenging for storage encryption.  Somewhere I read that AES-GCM is better suited to transport encryption.

I'm currently heading down the path of AES-CBC + AES-CMAC, due to less stringent requirements around key and IV re-use.  Having a file key and chunk IVs from a CRNG seems to be acceptable.  Again, I'm new to this as well, so I'm happy to be told otherwise.  I'm just on here researching the process of deriving keys for encryption vs MAC generation from a common key.

I was tempted by OpenSSL's EVP_aes_256_cbc_hmac_sha256, but then the docs have a warning that it was only intended to be used internally by OpenSSL's SSL/TLS.  It would be nice to find the "shrink wrapped" answer to take care of all this.

Key storage without an HSM can be challenging, especially if there is no user involved.  In a desktop environment, a key derived from a passphrase (KDF) is the traditional solution.  A "logon secured" encryption scheme can also be used (e.g. Microsoft's DSAPI). Without that, I think it becomes a chain of "where to keep the key that encrypts the key...", which I haven't yet seen a good answer for.

Securing keys with another layer of encryption is called key wrapping.  I've seen code that uses AES to encrypt one key with another as a simplified version of this.