MySQL Encryption: Master Key Rotation

In anticipation of the start of a new recruitment for the course “Database” We continue to publish a series of articles about encryption in MySQL.

In the previous article in this series, we discussed How does Master Key encryption work?… Today, based on the knowledge gained earlier, let’s look at the rotation of the master keys.

Master key rotation consists in generating a new master key and re-encrypting the table space keys (which are stored in the table space headers) with this new key.

Let’s remember what the header of an encrypted tablespace looks like:

We know from the previous article that the server reads the headers of all encrypted table spaces at startup and remembers the largest KEY ID. For example, if we have three tables with KEYID = 3 and one table with KEYID = 4, then the maximum key identifier will be 4. Let’s call this KEY ID – MAX KEY ID.

How master key rotation works

1. The user executes ALTER INNODB MASTER KEY.

2. The server requests the generation of a new master key from the server UUID and KEY in the keyringID equal to MAX increased by oneKEYID. Thus, we get the master key ID equal to INNODBKEY-UUID- (MAXKEYID + 1). Upon successful generation of the master key, the MAX KEY ID is increased by one (i.e. MAXKEYID = MAXKEYID + 1).

3. The server looks at all tablespaces encrypted with the master key and for each tablespace:

encrypts the tablespace key with the new master key;
updates key id to new MAXKEYID;
if the UUID is different from the server’s UUID, it updates the server’s UUID.

As we know, the Master Key ID used to decrypt the table consists of the UUID and KEY ID read from the tablespace header. What we’re doing now is updating this information in the tablespace encryption header so that the server gets the correct master key.

If we have tablespaces obtained from different places, for example, from different backups, then they can use different master keys. All of these master keys will need to be retrieved from the repository when the server starts. This can slow down server startup, especially if a server-side keystore is being used. By rotating the master key, we re-encrypt the tablespace keys with a single master key that is the same for all tablespaces. Now the server should receive only one master key at startup.

This is, of course, just a pleasant side effect. The main purpose of the master key rotation is to make our server more secure. If the master key was somehow stolen from the vault (for example, from the Vault Server), then you can generate a new master key and re-encrypt the table space keys, making the stolen key invalid. We’re safe … almost.

In the previous article, I talked about the fact that once a tablespace key is stolen, a third party can use it to decrypt the data. Provided that there is access to our disk. If the master key is stolen and you have access to the encrypted data, you can use the stolen master key to decrypt the tablespace key and retrieve the decrypted data. As you can see, rotation of the master key does not help in this case. We re-encrypt the tablespace key with the new master key, but the actual key used to encrypt / decrypt the data remains the same. Therefore, the “hacker” can continue to use it to decrypt data. Earlier, I hinted that Percona Server for MySQL can do true re-encryption of table spaces, not just simple re-encryption of the table space key. This feature is called encryption threads. However, this functionality is still experimental at the moment.

Master key rotation is useful when the master key is stolen, but there is no way for an attacker to use it and decrypt the tablespace keys.

Sign up for a free demo lesson.