As we approach the start of a new course enrollment we continue to publish a series of articles on encryption in MySQL.
In the previous article of this series, we discussed, Today, based on the knowledge gained earlier, we will look at the rotation of master keys.
Master key rotation involves generating a new master key, which is then used to re-encrypt the keys of the tablespaces (stored in the headers of the tablespaces).
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 highest KEY ID. For instance, if we have three tables with KEYID = 3 and one table with KEYID = 4, then the maximum key identifier will be 4. Let's refer to this KEY ID as MAX KEY ID.
How master key rotation works
1. The user executes ALTER INNODB MASTER KEY.
2. The server requests the key storage (keyring) to generate a new master key with the server's UUID and KEYID, which is equal to MAXKEYID increased by one. Thus, we get the master key identifier equal to INNODBKEY-UUID- (MAXKEYID + 1). Upon successful generation of the master key, MAX KEY ID is increased 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 identifier to the new MAXKEYID;
if the UUID differs from the server’s UUID, it updates the server’s UUID.
As we know, the master key identifier (Master Key ID) used to decrypt the table consists of a UUID and KEY ID read from the header of the tablespace. 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 obtained from different locations, such as different backups, they may use different master keys. All these master keys will need to be retrieved from the storage when starting the server. This can slow down the server startup, especially if a keystore is being used. By rotating the master key, we re-encrypt the keys of the tablespaces with a single master key that is the same for all tablespaces. Now, upon startup, the server only needs to retrieve one master key.
This is, of course, just a nice side effect. The main goal of master key rotation is to make our server more secure. In the event that the master key has been somehow stolen from the storage (for example, from the Vault Server), a new master key can be generated, and the keys of the tablespaces can be re-encrypted, rendering the stolen key invalid. We are safe… almost.
In the previous article, I mentioned that after the theft of a tablespace key, a third party could use it to decrypt data, provided they have access to our disk. In the event of a master key theft and access to encrypted data, the stolen master key can be used to decrypt the tablespace key and obtain the decrypted data. As we see, master key rotation does not help in this case. We re-encrypt the tablespace key with a 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. Previously, I hinted that it can perform true re-encryption of tablespaces, not just simple re-encryption of the tablespace key. This feature is called encryption threads. However, at this time, this functionality is still experimental.
Master key rotation is useful when the master key is stolen, but the attacker does not have the ability to use it and decrypt the tablespace keys.
Read more:
Source: habr.com
