SQL Key Management and Database Encryption: Where the Master Key Lives

Database encryption key management is the question of who holds the key that protects the database's own encryption keys, and whether the database engine ever sees plaintext. Turning on Transparent Data Encryption does not answer it. TDE encrypts files and backups. If the master key sits in a wallet or certificate on the same host, anyone who takes that host takes the key with the data.

DuoKey's database integrations all do the same job in the engine's own protocol: the database, or its client driver, fetches a wrapping key from a tenant vault instead of storing that key locally. The engines differ in whether the database itself encrypts, or the client does. (DuoKey docs: Database encryption)

---

Table of Contents

1. Two models
2. SQL key management: TDE with EKM, and Always Encrypted
3. Oracle TDE
4. Engines that talk KMIP
5. Client-side field encryption
6. What to ask before you pick one
7. FAQ

---

Two models

DuoKey does not see table data in the TDE model. It sees key operations. In the client-side model it never sees the field values either. (DuoKey docs: Database encryption)

---

SQL key management: TDE with EKM, and Always Encrypted

"SQL key management" usually means one of two Microsoft features. They get mixed up because both can use a key outside the server.

TDE with Extensible Key Management (EKM). SQL Server encrypts data and log files, and backups, with a database encryption key. An EKM provider holds the asymmetric key that wraps that DEK. With DuoKey, the RSA master key stays in the vault you selected for the SQL EKM app: a software vault, an MPC-based backend, or a supported third-party HSM. The provider runs on SQL Server 2016 or later, Enterprise or Developer edition, on Windows. Express, LocalDB, Azure SQL Managed Instance and SQL Server on Linux cannot load that Windows provider. (SQL Server TDE and Always Encrypted guide)

Always Encrypted. The driver encrypts columns. SQL Server stores ciphertext. DuoKey holds the column master key. The database never holds that key in plaintext. This is a separate integration from SQL EKM. (DuoKey docs: SQL Always Encrypted)

The rule from the SQL guide: if the database administrator must not be able to read the column, you need Always Encrypted. If files and backups must be encrypted with a key held outside the server, you need TDE with EKM. Product page: SQL encryption.

---

Oracle TDE

Oracle TDE uses a master encryption key to wrap tablespace and table keys. The default store is a software wallet on the database host. An external keystore moves that master key off the host. Oracle reaches it over PKCS#11.

DuoKey's PKCS#11 library is that keystore. Oracle sees an HSM-type wallet (WRL_TYPE = HSM). The library holds no keys and does no cryptography locally. It sends master-key operations to DuoKey Cockpit, which runs them against the tenant vault or an HSM. Master-key bytes are not returned to Oracle. Hardware custody uses Securosys. (Oracle TDE external keystore guide)

The setup, rekey and the usual ORA- errors are in that guide. Product page: Oracle TDE.

---

Engines that talk KMIP

The Key Management Interoperability Protocol is how several engines already expect to fetch a key. DuoKey Cockpit exposes a KMIP server on port 5696 (the IANA port), binary TTLV over TLS, negotiating KMIP 1.0 through 2.1. It generates symmetric keys (AES, default 256-bit, and HMAC). It does not generate RSA or EC key pairs. (DuoKey docs: KMIP)

Keys created through this KMIP server are encrypted at rest with AES-256-GCM under the platform encryption key. That path is envelope encryption. It is not the MPC custody used for other DuoKey flows, such as Microsoft 365 Double Key Encryption. (DuoKey docs: KMIP)

These are Apps in DuoKey Cockpit. The database still does the bulk encryption. DuoKey is the external key custodian. Each engine's page is under Database encryption.

---

Client-side field encryption

The driver unwraps data keys with the master key DuoKey holds. The database stores ciphertext. Query limits depend on the engine: randomized ciphertext in SQL Server Always Encrypted cannot be searched without a secure enclave, and deterministic ciphertext can. The SQL guide covers that split. MongoDB's two modes are separate docs: CSFLE and Queryable Encryption.

---

What to ask before you pick one

1. Must a database administrator running a query see plaintext? If no, you need a client-side mode, not TDE.
2. Must stolen files and backups be useless without a key that was not on the server? That is TDE with an external master key.
3. Which protocol does this engine already speak? SQL Server EKM and Oracle PKCS#11 are not the KMIP apps. Pointing a KMIP client at the SQL EKM provider will not work.
4. For a KMIP engine, is envelope encryption under the platform key enough, or does the standard require an HSM or MPC for that key? Say which. The KMIP server path documented above is the platform envelope.

---

FAQ

What is SQL key management?

For SQL Server, it is where the key that protects the database encryption key lives (TDE with EKM), or where the column master key lives (Always Encrypted). DuoKey can be the external store for either. They are different products and different threat models. (SQL guide)

What is database encryption key management?

The lifecycle of the keys that wrap a database's own encryption keys: where they are generated, who can use them, how they rotate, and how a backup is restored when the key is not on the database host.

Does TDE stop a DBA from reading the data?

No. The engine decrypts pages to answer queries. TDE protects files and backups. Column or field encryption in the client is what keeps plaintext out of the engine.

Is the KMIP key an MPC key?

No. DuoKey's KMIP server protects generated keys with envelope encryption under the platform key. MPC applies to other DuoKey key flows, not to this KMIP backend. (DuoKey docs: KMIP)

Which page do I use for SQL Server step by step?

SQL Server TDE with EKM vs Always Encrypted. For Oracle, Oracle TDE with an external keystore.