In anticipation of the start of a new enrollment for the course we continue to publish a series of articles about encryption in MySQL.
In the previous article in this series, we discussed . Today, based on the knowledge gained earlier, let's look at the rotation of the main keys.
Master key rotation involves generating a new master key and re-encrypting the tablespace keys (which are stored in the tablespace headers) with this new key.
Let's recall what the header of an encrypted tablespace looks like:
From the previous article, we know that the server reads the headers of all encrypted tablespaces 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 ID 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 keyring to generate a new master key with the server UUID and KEYID equal to one plus MAXKEYID. So we get master key id equal to INNODBKEY-UUID-(MAXKEYID + 1). Upon successful generation of the master key, MAX KEY ID is incremented by one (i.e. MAXKEYID=MAXKEYID + 1).
3. The server scans all tablespaces encrypted with the master key, and for each tablespace:
-
encrypts the tablespace key with the new master key;
-
updates the key id to the new MAXKEYID
-
if the UUID is different from the server UUID, then update the server UUID.
As we know, the Master Key ID used to decrypt a table consists of a UUID and a KEY ID read from the tablespace header. What we are doing now is updating this information in the tablespace encryption header so that the server receives the correct master key.
If we have tablespaces from different locations, such as different backups, then they may use different master keys. All of these master keys will need to be retrieved from the repository when the server is started. This can slow down the server startup, especially if a server-side key store is used. With master key rotation, we re-encrypt tablespace keys with a single master key that is the same for all tablespaces. The server should now receive only one master key at startup.
This, of course, is just a pleasant side effect. The main purpose of master key rotation is to make our server more secure. In the event that the master key was somehow stolen from the vault (for example, from the Vault Server), it is possible to generate a new master key and re-encrypt the tablespace keys, invalidating the stolen key. We're safe...almost.
In a previous article, I talked about how 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 get the decrypted data. As you can see, the 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 the data. Earlier I hinted that can perform true tablespace re-encryption, not just simple tablespace key re-encryption. 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.
Read more:
Source: habr.com