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 talked about keystores. In this article, we'll look at how the master key is used and discuss the advantages and disadvantages of envelope encryption.
The idea behind envelope encryption is that the keys used for encryption (tablespace keys) are encrypted with another key (the master key). Tablespace keys are actually used to encrypt data. Graphically, this can be represented as follows:
The master key is in the keystore, and the tablespace keys are in the encrypted tablespace headers (on page 0 of the tablespace).
In the picture above:
Table A is encrypted with key 1 (Key 1). Key 1 is encrypted using the master key and stored encrypted in the header of table A.
Table B is encrypted with key 2 (Key 2). Key 2 is encrypted using the masker key and stored encrypted in the header of table B.
And so on.
When the server needs to decrypt table A, it gets the master key from the store, reads encrypted key 1 from the header of table A, and decrypts key 1. The decrypted key 1 is cached in the server's memory and used to decrypt table A.
InnoDB
In InnoDB, the actual encryption and decryption is done at the I/O level. That is, the page is encrypted just before it is flushed to disk and decrypted immediately after being read from disk.
In InnoDB, encryption only works at the tablespace level. And by default all tables are created in separate tablespaces (). In other words, a tablespace is created that can contain only one table. Although you can create tables in the main tablespace as well (). But in any case, the table is always in some tablespace. And since encryption is done at the tablespace level, it is either fully encrypted or not. That is, you cannot encrypt only part of the tables in the main table space.
If for some reason you have file-per-table disabled, then all tables are created inside the system tablespace. IN you can encrypt the system tablespace using the innodb variablesystablespaceencrypt or using encryption threads, but this is still an experimental feature. MySQL does not have this.
Before moving on, we need to consider the structure of the master key ID. It consists of UUID, KEYID and prefix "INNODBKey". It looks like this: INNODBKey-UUID-KEYID.
The UUID is the uuid of the server with the encrypted tablespace. keyID is just an ever-increasing value. When you first create a master key KEYID is 1. During key rotation, when a new master key is created, KEYID = 2 and so on. We'll talk more about master key rotation in later articles in this series.
Now that we know what the master key identifier looks like, let's look at the header of the encrypted tablespace. When a tablespace is encrypted, the encryption information is added to the header. It looks like this:
KEYID is KEYThe ID from the master key ID we've already discussed. The UUID is the uuid of the server and is also used in the master key identifier. TABLESPACE KEY - table space key, which consists of 256 bits, randomly generated by the server. The initialization vector (IV, initialization vector) also consists of 256 randomly generated bits (although it should be 128 bits). IV is used to initialize AES encryption and decryption (out of 256 bits, only 128 are used). At the end there is a CRC32 checksum for TABLESPACE KEY and IV.
All this time I've been simplifying a bit by saying that there is an encrypted tablespace key in the header. In fact, the tablespace key and the initialization vector are stored and encrypted together using the master key. Remember that before the tablespace key and initialization vector are encrypted, CRC32 is calculated for them.
Why is CRC32 needed?
In a nutshell, in order to verify the validity of the main key. After decrypting the tablespace key and initialization vector, a checksum is calculated and compared with the CRC32 stored in the header. If the checksums match, then we have the correct master key and tablespace key. Otherwise, the tablespace is marked as missing (we still can't decrypt it).
You may ask: at what point is the verification of keys performed? The answer is when the server starts. Server with encrypted tables / tablespaces reads UUID, KEY at startupID from the header and generates a master key ID. It then obtains the required master key from the keyring, decrypts the tablespace key, and verifies the checksum. Once again, if the checksum matches, then everything is in order, no - the tablespace is marked as missing.
If you read the last article in this series (), then perhaps remember that when using a server key store, the server only receives a list of key identifiers at startup, more precisely, key id and user id, since this pair uniquely identifies the key. What I'm saying now is that the server, at startup, gets all the keys it needs to check that the tablespace keys can be decrypted. So why, when initializing, in the case of server storage, only key is loadedid and userid and not all keys? Because you may not need all the keys. This is mainly due to the rotation of the master key. When a master key is rotated in the vault, a new master key is created, but the old keys are not deleted. Thus, you may have many keys in the server's keystore that are not needed by the server and therefore not retrieved when the server starts.
It's time to talk a little about the advantages and disadvantages of encryption using a master key. The biggest advantage is that you only need one encryption key (the master key), which will be kept separate from your encrypted data. This makes server startup fast and storage small, making it easy to manage. And also the only master key is easy to regenerate.
However, master key encryption has one big drawback: once a tablespace is encrypted with tablespace_key, it always remains encrypted with the same key. Master key rotation does not help here. Why is this a disadvantage? We know that MySQL has bugs that can cause it to crash and create a core file. Since the core file contains a server memory dump, it can happen that the dump contains the decrypted tablespace key. Even worse, the decrypted tablespace keys are stored in memory, which can be swapped to disk. You can tell that this is not a disadvantage since you need root permissions to access these files and the swap partition. Yes. But root is needed only for a while. Once someone has access to the decrypted tablespace key, he/she can continue to use it to decrypt data, even without root access. In addition, the disk can be stolen, and the swap / core files can be read using third-party tools. The goal of TDE is to make it unreadable even if the disk is stolen. IN it is possible to re-encrypt the tablespace with newly generated keys. This feature is called encryption threads and is still experimental at the time of this writing.
Read more:
Source: habr.com
