Why AES-GCM with random nonce should be rotated every 200k writes in Kubernetes?-CodePudding

We are implementing encryption at rest in Kubernetes by this tutorial (https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/) and we are absolutely not sure why AES-GCM encryption provider requires to rotate the key every 200K writes, because of lack of knowledge about how encryption works. Also, what exactly means: "200K writes", how can we define that we should rotate the key? Thank you

CodePudding user response：

As per OpenShift docs: https://docs.openshift.com/container-platform/3.11/admin_guide/encrypting_data.html

Kubernetes has no proper nonce generator and uses a random IV as nonce for AES-GCM. Since AES-GCM requires a proper nonce to be secure, AES-GCM is not recommended. The 200,000 write limit just limits the possibility of a fatal nonce misuse to a reasonable low margin.

It's just an arbitrary number from what I can see.

CodePudding user response：

we are absolutely not sure why AES-GCM encryption provider requires to rotate

The GCM mode is basically a CTR streaming mode with built-in integrity validation (message authentication code). For this mode is very important to prevent reusing the same IV/key pair. It is advised to limit amount of the content encrypted with the same key limiting probability of the nonce-collision and options for key analysis (these is some math behind, already referred in the comments).

Yes, 200k is an arbitrary number, but someone has to state a reasonable number where nonce-collision probability is still negligible and the key is usable for significant time.

what exactly means: "200K writes",

This is usually very hard to estimate, depending what is the "write". It may be different if you use the key to encrypt other random keys (as a wrapping key) or the key is used to encrypt a lot of continuous content (e.g. a storage).

how can we define that we should rotate the key?

Let's be practical, e.g. AWS KMS provides automatic key rotation every year. Based on the question, assuming the key is used to encrypt the etcd storage (configuration), a yearly rotation can be a safe option. (I expect you don't have 200k secrets and config maps in the k8s cluster).

The key rotation process usually creates a new key (key version) and new content is encrypted using a new key. The existing content is still possible to decrypt using the older keys.

In this regard I have a little concern about how the key rotation is described in the documentation. Basically the steps 1-4 look ok, a new encryption key is defined and put in force. The step 5 and 6 are to re-encrypt all the etcd content using the new key basically limiting (if not defying) the whole purpose of the key rotation. Maybe you could pick that up with the support if you have time and patience to dig in.