We have a handful of MSSQL databases encrypted using Transparent Data Encryption (TDE) without an HSM. So the current chain is:

Service Master Key (SMK) ->
Master Key (DMK) ->
Certificate encrypted by DMK ->
User Database - Data Encryption Key (DEK)

The databases are encrypted using the same certificate. Is there a possible migration path to utilizing an HSM without having to re-encrypt all of the databases?
(there is around 100TB of data, so I am trying to avoid re-encryption if at all possible)

We are implementing TDE in MS SQL SEREVR 2019 with EKM provider. We are using asymmetric key to encrypt the data at rest. Asymmetric key will be hosted in HSM appliances. I have one questions regarding that. What will be the effect if our SQL Server isn't able to connect with HSM appliances? Will the application be able to do the normal DML process on encrypted database, as database is encrypted and it’s not able to connect with HSM appliance? thanks

We are testing a particular HSM to use replace the Oracle wallet and user as a key-store for column encryption. We are using redundant HSMs so that things will continue to run even with a complete loss of one HSM. This works fine when connectivity is lost to one HSM at a time. The problem we found is that when there is a complete loss of connectivity to both devices, a restoration of connectivity is not sufficient to continue to allow decryption of encrypted columns. The only way we found to restore connectivity in this scenario is to restart the instance. The question is, which of these do our findings represent? 1. A problem with the way we have configured the HSM. 2. A limitation of this particular HSM. 3. A limitation of the way the Oracle database works with any HSM. The database is fine when this happens, only access to the encrypted columns is lost, but even when connectivity to the HSMs is restored (verified using HSM tools from the database server), the database continues to act as though the HSMs are unavailable. Everything else in the database is fine, only access to the encrypted columns is unavailable. The alert log gives no indication of any issues.

MS is clear about restoring TDE backups: Certificate has to be restored on destination OR, in case of EKM, the asymmetric key " When moving a TDE protected database, you must also move the certificate or [[asymmetric key]] that is used to open the DEK. The certificate or asymmetric key must be installed in the master database of the destination server, so that SQL Server can access the database files " Now, there is no asymmetric backup built-in SQL Server. We might assume that the EK can export it or so?? we can restore Asym keys created as strong name files but the create statement of Asym key with EKM does not look to support a source file CREATE ASYMMETRIC KEY SQL_EKM_RSA_2048_Key_TDE FROM Provider [SafeNetLunaHSM] WITH ALGORITHM = RSA_2048, PROVIDER_KEY_NAME = 'EKM_RSA_2048_Key_TDE', CREATION_DISPOSITION=CREATE_NEW I am using Safenet Luna HSM. Has anyone been in a similar situation? simply restoring a TDE backup from EKM source to Native TDE destination. Appreciate the help

So I am exploring some options about database encryption. The best options are commercial (TDE). I am looking for an open-source implementation. Recent releases of MySQL and MariaDB have data-at-rest capabilities: MariaDB https://mariadb.com/kb/en/mariadb/why-encrypt-mariadb-data/ MySQL 5.7.11 comes with InnoDB tablespace encryption https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-encryption.html What is important in this implementation (for companies) is: are these compliant with PCI-DSS / HIPAA etc? From MariaDB: >The MariaDB file_key_management plugin enables the configuration of keys in a file. The key file is read at system start and no additional access is needed during runtime. The security of the encryption depends on access restriction to the key file. The key file can itself be encrypted, providing additional layer of protection. From my point of view this will mean providing the decryption of the key during start (and OS reboot)? So whenever we (re-)boot a system does this mean we need to manually provide this key? Having this key readable on the server itself will defeat the use of data-at-rest encryption in the first place. In MySQL 5.7.11+ >The InnoDB tablespace encryption feature in non-enterprise editions of MySQL use the keyring_file plugin for encryption key management, which is not intended as a regulatory compliance solution. Security standards such as PCI, FIPS, and others require use of key management systems to secure, manage, and protect encryption keys in key vaults or hardware security modules (HSMs). > >MySQL Enterprise Edition offers the keyring_okv plugin, which includes a KMIP client (KMIP v1.2) that works with Oracle Key Vault (OKV) to provide encryption key management. A secure and robust encryption key management solution such as OKV is critical for security and for compliance with various security standards. Among other benefits, using a key vault ensures that keys are stored securely, never lost, and only known to authorized key administrators. A key vault also maintains an encryption key history. Now I am wondering, can this be made compliant with security standards? When using this data-at-rest, will root or mysql user have access to the keys since they could read encryption keys from memory?

I'm using Postgres on AWS RDS. My application is encrypting selected columns in a table using AWS KMS encryption. I tried but could not find a way to configure KMS keys and use the decrypt() in select query. For example, my app is encrypting myTable.secureColumn using KMS. Now, I'm trying to fire below query: select * from myTable where decrypt(secureColumn, 'key', 'aes') = 'data'; I didn't find how to configure KMS keys in pgCrypto and use in above query. Has anyone tried this? Thanks in advance.

We currently use an Oracle Wallet for Transparent Data Encryption of certain critical columns and are migrating to a HSM for compliance reasons. Our issue is how to handle encryption on the development systems that get refreshed frequently from the production system. These refreshes are completely automated and rely on image file backups of our production system. The development systems use the same Oracle Wallet and the refresh process handles manipulating the data in the sensitive columns so that the data does not have to be encrypted, however, we leave the columns encrypted so we can get similar behavior to production. Here are some options I am aware of. 1. Have the development systems use the same HSM Partition as production. This would be the most obvious solutions, but Oracle does not recommend it and this could potentially allow development to affect production. 2. Drop encrypted columns or drop them and add them back. - This would be relatively fast, but leaves the columns empty, preventing processes that use the data from being tested. It also changes the column order, which could be problematic. 3. Upgrade to 12c and use the reverse migrate command to move back to a wallet from an HSM. - Same problem as #1, albeit for a shorter time, but also requires an upgrade which we cannot do. As I understand it, this functionality is not available in 11g. 4. Drop/recreate the encrypted columns and populate them using queries from production as part of the data manipulation part of the refresh. 5. Drop the tables and import them from an export of production. Rather time consuming. Are there other options I am missing or things that would make one of these options more desirable?