Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20713

Implement key rotation for file_key_management plugin

Details

    Description

      Some users are requesting that we implement key rotation for file_key_management plugin.

      I'm not sure that it's practical. How would key rotation work in file_key_management plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation. Some open questions are listed below.

      Generation of New Key Versions

      How would new key versions be generated?

      The file_key_management plugin currently doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it either.

      With file_key_management plugin, any encryption keys currently need to be generated by the user with external tools, such as openssl. For example:

      -- Generate a new 256-bit key
      openssl rand -hex 32
      

      And then the keys currently need to be manually saved to the key file.

      See here:

      https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

      Some possibilities:

      • Would the user still have to manually generate the new key versions, and then manually save them to the key file?
      • Would we implement a UDF in the file_key_management plugin that can be used to generate random keys, and a UDF that can save a key version to a key file? For example:

      -- Generate a new 256-bit key
      SELECT file_key_management_generate_key(256);
       
      -- Write key to key file as key_version 2 of key ID 1
      SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
      

      Format of Key File

      How would the format of the key file change to allow different key versions of the same key ID?

      The format of file_key_management plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format.

      <encryption_key_id1>;<hex-encoded_encryption_key1>
      <encryption_key_id2>;<hex-encoded_encryption_key2>
      

      For example, if we had two keys with key ID 1 and 2, then the key file could look like this:

      1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
      2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
      

      This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

      It's possible that we could extend the format, but it could get very ugly. For example:

      <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
      <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
      ...
      <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
      <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
      <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
      ...
      <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
      

      For example, if we had two key versions of two different keys with key ID 1 and 2, then the key file could look like this:

      1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
      1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
      2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
      2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
      

      Reloading Key Versions

      If we decide that new key versions need to be manually generated, then how would the file_key_management plugin reload the new key versions?

      Some possibilities:

      • file_key_management plugin currently only parses the key file at startup. Would we still want to require a server restart to reload keys?
      • Would we want to implement some FLUSH command? For example:

      FLUSH ENCRYPTION KEYS;
      

      • Would we want to implement some UDF? For example:

      SELECT file_key_management_reload_keys();
      

      Similar functionality in other databases?

      Is there similar functionality in other databases that we could use as inspiration?

      Users migrating from Oracle might have used Oracle Wallet:

      https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbimi/using-oracle-wallet-manager.html

      Attachments

        Issue Links

          Activity

            GeoffMontee Geoff Montee (Inactive) created issue -
            GeoffMontee Geoff Montee (Inactive) made changes -
            Field Original Value New Value
            GeoffMontee Geoff Montee (Inactive) made changes -
            Description Some users are requesting that we implement key rotation for {{file_key_management}} plugin.

            I'm not sure that it's practical. There are some open questions:

            How would key rotation work in {{file_key_management}} plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation, such as:

            h2. Generation of New Key Versions

            The {{file_key_management}} plugin doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it. With {{file_key_management}} plugin, any encryption keys need to be generated by the user by using external tools. See here:

            https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

            Some possibilities:

            * Would the user still have to manually generate the new key versions, and then manually save them to the key file?

            * Would we implement a UDF in the {{file_key_management}} plugin that can be used to generate random keys, and a UDF that can save a key version to a key file?

            {code}
            -- Generate a 256-bit AES key
            SELECT file_key_management_generate_key(256);

            -- Write key to key file as key_version 2 of key ID 1
            SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
            {code}

            h2. Format of Key File

            The format of {{file_key_management}} plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format:

            {noformat}
            <encryption_key_id1>;<hex-encoded_encryption_key1>
            <encryption_key_id2>;<hex-encoded_encryption_key2>
            {noformat}

            So having two keys with key ID 1 and 2 could look like this:

            {noformat}
            1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            {noformat}

            This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

            It's possible that we could extend the format, but it could get very ugly. i.e.:

            {noformat}
            <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
            <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
            ...
            <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
            <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
            <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
            ...
            <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
            {noformat}

            So having two versions of key ID 1 and 2 could look like this:

            {noformat}
            1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
            2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
            {noformat}

            h2. Reloading Key Versions

            If we decide that new key versions need to be manually generated, then how would the {{file_key_management}} plugin learn about the new key versions?

            Some possibilities:

            * Would we want it to require a server restart?

            * Would we want to implement some {{FLUSH}} command? i.e.:

            {code}
            FLUSH ENCRYPTION KEYS;
            {code}

            * Would we want to implement some UDF? i.e.:

            {code}
            SELECT file_key_management_reload_keys();
            {code}

            h2. Similar functionality in other databases?

            Is there similar functionality in other databases that we could use as inspiration?

            Oracle uses might be used to Oracle Wallet:

            https://docs.oracle.com/cd/B28359_01/network.111/b28530/asowalet.htm#i1010609
            Some users are requesting that we implement key rotation for {{file_key_management}} plugin.

            I'm not sure that it's practical. How would key rotation work in {{file_key_management}} plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation. Some open questions are listed below.

            h2. Generation of New Key Versions

            How would new key versions be generated?

            The {{file_key_management}} plugin currently doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it either.

            With {{file_key_management}} plugin, any encryption keys currently need to be generated by the user with external tools, such as {{openssl}}. i.e.:

            {code}
            -- Generate a new 256-bit key
            openssl rand -hex 32
            {code}

            And then the keys currently need to be manually saved to the key file.

            See here:

            https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

            Some possibilities:

            * Would the user still have to manually generate the new key versions, and then manually save them to the key file?

            * Would we implement a UDF in the {{file_key_management}} plugin that can be used to generate random keys, and a UDF that can save a key version to a key file?

            {code}
            -- Generate a new 256-bit key
            SELECT file_key_management_generate_key(256);

            -- Write key to key file as key_version 2 of key ID 1
            SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
            {code}

            h2. Format of Key File

            The format of {{file_key_management}} plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format:

            {noformat}
            <encryption_key_id1>;<hex-encoded_encryption_key1>
            <encryption_key_id2>;<hex-encoded_encryption_key2>
            {noformat}

            So having two keys with key ID 1 and 2 could look like this:

            {noformat}
            1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            {noformat}

            This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

            It's possible that we could extend the format, but it could get very ugly. i.e.:

            {noformat}
            <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
            <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
            ...
            <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
            <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
            <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
            ...
            <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
            {noformat}

            So having two versions of key ID 1 and 2 could look like this:

            {noformat}
            1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
            2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
            {noformat}

            h2. Reloading Key Versions

            If we decide that new key versions need to be manually generated, then how would the {{file_key_management}} plugin learn about the new key versions?

            Some possibilities:

            * Would we want it to require a server restart?

            * Would we want to implement some {{FLUSH}} command? i.e.:

            {code}
            FLUSH ENCRYPTION KEYS;
            {code}

            * Would we want to implement some UDF? i.e.:

            {code}
            SELECT file_key_management_reload_keys();
            {code}

            h2. Similar functionality in other databases?

            Is there similar functionality in other databases that we could use as inspiration?

            Oracle uses might be used to Oracle Wallet:

            https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbimi/using-oracle-wallet-manager.html
            GeoffMontee Geoff Montee (Inactive) made changes -
            Description Some users are requesting that we implement key rotation for {{file_key_management}} plugin.

            I'm not sure that it's practical. How would key rotation work in {{file_key_management}} plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation. Some open questions are listed below.

            h2. Generation of New Key Versions

            How would new key versions be generated?

            The {{file_key_management}} plugin currently doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it either.

            With {{file_key_management}} plugin, any encryption keys currently need to be generated by the user with external tools, such as {{openssl}}. i.e.:

            {code}
            -- Generate a new 256-bit key
            openssl rand -hex 32
            {code}

            And then the keys currently need to be manually saved to the key file.

            See here:

            https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

            Some possibilities:

            * Would the user still have to manually generate the new key versions, and then manually save them to the key file?

            * Would we implement a UDF in the {{file_key_management}} plugin that can be used to generate random keys, and a UDF that can save a key version to a key file?

            {code}
            -- Generate a new 256-bit key
            SELECT file_key_management_generate_key(256);

            -- Write key to key file as key_version 2 of key ID 1
            SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
            {code}

            h2. Format of Key File

            The format of {{file_key_management}} plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format:

            {noformat}
            <encryption_key_id1>;<hex-encoded_encryption_key1>
            <encryption_key_id2>;<hex-encoded_encryption_key2>
            {noformat}

            So having two keys with key ID 1 and 2 could look like this:

            {noformat}
            1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            {noformat}

            This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

            It's possible that we could extend the format, but it could get very ugly. i.e.:

            {noformat}
            <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
            <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
            ...
            <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
            <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
            <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
            ...
            <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
            {noformat}

            So having two versions of key ID 1 and 2 could look like this:

            {noformat}
            1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
            2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
            {noformat}

            h2. Reloading Key Versions

            If we decide that new key versions need to be manually generated, then how would the {{file_key_management}} plugin learn about the new key versions?

            Some possibilities:

            * Would we want it to require a server restart?

            * Would we want to implement some {{FLUSH}} command? i.e.:

            {code}
            FLUSH ENCRYPTION KEYS;
            {code}

            * Would we want to implement some UDF? i.e.:

            {code}
            SELECT file_key_management_reload_keys();
            {code}

            h2. Similar functionality in other databases?

            Is there similar functionality in other databases that we could use as inspiration?

            Oracle uses might be used to Oracle Wallet:

            https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbimi/using-oracle-wallet-manager.html
            Some users are requesting that we implement key rotation for {{file_key_management}} plugin.

            I'm not sure that it's practical. How would key rotation work in {{file_key_management}} plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation. Some open questions are listed below.

            h2. Generation of New Key Versions

            How would new key versions be generated?

            The {{file_key_management}} plugin currently doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it either.

            With {{file_key_management}} plugin, any encryption keys currently need to be generated by the user with external tools, such as {{openssl}}. i.e.:

            {code}
            -- Generate a new 256-bit key
            openssl rand -hex 32
            {code}

            And then the keys currently need to be manually saved to the key file.

            See here:

            https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

            Some possibilities:

            * Would the user still have to manually generate the new key versions, and then manually save them to the key file?

            * Would we implement a UDF in the {{file_key_management}} plugin that can be used to generate random keys, and a UDF that can save a key version to a key file?

            {code}
            -- Generate a new 256-bit key
            SELECT file_key_management_generate_key(256);

            -- Write key to key file as key_version 2 of key ID 1
            SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
            {code}

            h2. Format of Key File

            How would the format of the key file change to allow different key versions of the same key ID?

            The format of {{file_key_management}} plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format:

            {noformat}
            <encryption_key_id1>;<hex-encoded_encryption_key1>
            <encryption_key_id2>;<hex-encoded_encryption_key2>
            {noformat}

            So having two keys with key ID 1 and 2 could look like this:

            {noformat}
            1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            {noformat}

            This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

            It's possible that we could extend the format, but it could get very ugly. i.e.:

            {noformat}
            <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
            <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
            ...
            <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
            <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
            <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
            ...
            <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
            {noformat}

            So having two versions of key ID 1 and 2 could look like this:

            {noformat}
            1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
            2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
            {noformat}

            h2. Reloading Key Versions

            If we decide that new key versions need to be manually generated, then how would the {{file_key_management}} plugin reload the new key versions?

            Some possibilities:

            * {{file_key_management}} plugin currently only parses the key file at startup. Would we still want to require a server restart to reload keys?

            * Would we want to implement some {{FLUSH}} command? i.e.:

            {code}
            FLUSH ENCRYPTION KEYS;
            {code}

            * Would we want to implement some UDF? i.e.:

            {code}
            SELECT file_key_management_reload_keys();
            {code}

            h2. Similar functionality in other databases?

            Is there similar functionality in other databases that we could use as inspiration?

            Oracle uses might be used to Oracle Wallet:

            https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbimi/using-oracle-wallet-manager.html
            GeoffMontee Geoff Montee (Inactive) made changes -
            Description Some users are requesting that we implement key rotation for {{file_key_management}} plugin.

            I'm not sure that it's practical. How would key rotation work in {{file_key_management}} plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation. Some open questions are listed below.

            h2. Generation of New Key Versions

            How would new key versions be generated?

            The {{file_key_management}} plugin currently doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it either.

            With {{file_key_management}} plugin, any encryption keys currently need to be generated by the user with external tools, such as {{openssl}}. i.e.:

            {code}
            -- Generate a new 256-bit key
            openssl rand -hex 32
            {code}

            And then the keys currently need to be manually saved to the key file.

            See here:

            https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

            Some possibilities:

            * Would the user still have to manually generate the new key versions, and then manually save them to the key file?

            * Would we implement a UDF in the {{file_key_management}} plugin that can be used to generate random keys, and a UDF that can save a key version to a key file?

            {code}
            -- Generate a new 256-bit key
            SELECT file_key_management_generate_key(256);

            -- Write key to key file as key_version 2 of key ID 1
            SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
            {code}

            h2. Format of Key File

            How would the format of the key file change to allow different key versions of the same key ID?

            The format of {{file_key_management}} plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format:

            {noformat}
            <encryption_key_id1>;<hex-encoded_encryption_key1>
            <encryption_key_id2>;<hex-encoded_encryption_key2>
            {noformat}

            So having two keys with key ID 1 and 2 could look like this:

            {noformat}
            1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            {noformat}

            This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

            It's possible that we could extend the format, but it could get very ugly. i.e.:

            {noformat}
            <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
            <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
            ...
            <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
            <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
            <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
            ...
            <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
            {noformat}

            So having two versions of key ID 1 and 2 could look like this:

            {noformat}
            1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
            2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
            {noformat}

            h2. Reloading Key Versions

            If we decide that new key versions need to be manually generated, then how would the {{file_key_management}} plugin reload the new key versions?

            Some possibilities:

            * {{file_key_management}} plugin currently only parses the key file at startup. Would we still want to require a server restart to reload keys?

            * Would we want to implement some {{FLUSH}} command? i.e.:

            {code}
            FLUSH ENCRYPTION KEYS;
            {code}

            * Would we want to implement some UDF? i.e.:

            {code}
            SELECT file_key_management_reload_keys();
            {code}

            h2. Similar functionality in other databases?

            Is there similar functionality in other databases that we could use as inspiration?

            Oracle uses might be used to Oracle Wallet:

            https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbimi/using-oracle-wallet-manager.html
            Some users are requesting that we implement key rotation for {{file_key_management}} plugin.

            I'm not sure that it's practical. How would key rotation work in {{file_key_management}} plugin? The plugin has some serious limitations that would likely make it impractical to implement key rotation. Some open questions are listed below.

            h2. Generation of New Key Versions

            How would new key versions be generated?

            The {{file_key_management}} plugin currently doesn't generate any encryption keys itself, and it doesn't even have a backend KMS to generate encryption keys for it either.

            With {{file_key_management}} plugin, any encryption keys currently need to be generated by the user with external tools, such as {{openssl}}. For example:

            {code}
            -- Generate a new 256-bit key
            openssl rand -hex 32
            {code}

            And then the keys currently need to be manually saved to the key file.

            See here:

            https://mariadb.com/kb/en/library/file-key-management-encryption-plugin/#creating-the-key-file

            Some possibilities:

            * Would the user still have to manually generate the new key versions, and then manually save them to the key file?

            * Would we implement a UDF in the {{file_key_management}} plugin that can be used to generate random keys, and a UDF that can save a key version to a key file? For example:

            {code}
            -- Generate a new 256-bit key
            SELECT file_key_management_generate_key(256);

            -- Write key to key file as key_version 2 of key ID 1
            SELECT file_key_management_save_key_version(1, 2, '8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e');
            {code}

            h2. Format of Key File

            How would the format of the key file change to allow different key versions of the same key ID?

            The format of {{file_key_management}} plugin's key file is pretty simplistic. It simply stores encryption keys in a plain-text file that uses the format.

            {noformat}
            <encryption_key_id1>;<hex-encoded_encryption_key1>
            <encryption_key_id2>;<hex-encoded_encryption_key2>
            {noformat}

            For example, if we had two keys with key ID 1 and 2, then the key file could look like this:

            {noformat}
            1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            2;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            {noformat}

            This format currently has no way to store different versions of the same encryption key. However, this is something that it would need to support in order to support key rotation.

            It's possible that we could extend the format, but it could get very ugly. For example:

            {noformat}
            <encryption_key_id1>;<encryption_key_id1_version1>;<hex-encoded_encryption_key1_version1>
            <encryption_key_id1>;<encryption_key_id1_version2>;<hex-encoded_encryption_key1_version2>
            ...
            <encryption_key_id1>;<encryption_key_id1_versionN>;<hex-encoded_encryption_key1_versionN>
            <encryption_key_id2>;<encryption_key_id2_version1>;<hex-encoded_encryption_key2_version1>
            <encryption_key_id2>;<encryption_key_id2_version2>;<hex-encoded_encryption_key2_version2>
            ...
            <encryption_key_id2>;<encryption_key_id2_versionN>;<hex-encoded_encryption_key2_versionN>
            {noformat}

            For example, if we had two key versions of two different keys with key ID 1 and 2, then the key file could look like this:

            {noformat}
            1;1;5d5f14b7262b8281e7d8bf17e53079c77f943b0a777659e14f368820975f4f34
            1;2;8ceb3336fa2a4bfacced7ea5dae17f246d93da44890386e2ce178453c4e9ba9e
            2;1;c3ff5b5d1ae78a7898539db984df20b43d13bfb4de11a80cd0d1082845209222
            2;2;f737cf391194d68c1a9c96b3d340e0b07464889171c061dd9cb95d3d61c765f2
            {noformat}

            h2. Reloading Key Versions

            If we decide that new key versions need to be manually generated, then how would the {{file_key_management}} plugin reload the new key versions?

            Some possibilities:

            * {{file_key_management}} plugin currently only parses the key file at startup. Would we still want to require a server restart to reload keys?

            * Would we want to implement some {{FLUSH}} command? For example:

            {code}
            FLUSH ENCRYPTION KEYS;
            {code}

            * Would we want to implement some UDF? For example:

            {code}
            SELECT file_key_management_reload_keys();
            {code}

            h2. Similar functionality in other databases?

            Is there similar functionality in other databases that we could use as inspiration?

            Users migrating from Oracle might have used Oracle Wallet:

            https://docs.oracle.com/en/database/oracle/oracle-database/12.2/dbimi/using-oracle-wallet-manager.html
            julien.fritsch Julien Fritsch made changes -
            Assignee Sergei Golubchik [ serg ] Ralf Gebhardt [ ralf.gebhardt@mariadb.com ]
            julien.fritsch Julien Fritsch made changes -
            Assignee Ralf Gebhardt [ ralf.gebhardt@mariadb.com ]
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 100100 ] MariaDB v4 [ 131161 ]
            mariadb-jira-automation Jira Automation (IT) made changes -
            Zendesk Related Tickets 179092
            ralf.gebhardt Ralf Gebhardt made changes -
            Component/s Plugin - File Key Management [ 20227 ]
            Component/s Plugins [ 10118 ]
            julien.fritsch Julien Fritsch made changes -
            Issue Type Task [ 3 ] New Feature [ 2 ]
            julien.fritsch Julien Fritsch made changes -
            Assignee Ralf Gebhardt [ ralf.gebhardt@mariadb.com ]

            People

              ralf.gebhardt Ralf Gebhardt
              GeoffMontee Geoff Montee (Inactive)
              Votes:
              1 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.