Architecture Note: Using SQL Server Always Encrypted with Secure Enclaves for In‑Place Computations

Requirements

To use Always Encrypted with secure enclaves you need:

• SQL Server 2019 Enterprise edition or later (the enclave feature is Enterprise‑only).
• A column‑level encryption key stored in a key store that supports enclave attestation – Azure Key Vault or an HSM that exposes the required attestation endpoint.
• The client application must use a driver that understands enclave attestation, for example .NET SqlClient 4.6+ or the ODBC driver with the Column Encryption Setting enabled.
• The host operating system must have Virtualization‑Based Security (VBS) enabled; without VBS the enclave runs in software‑only mode and you lose the performance and isolation benefits.

Smallest Suitable Design

Encrypt a single sensitive column that only needs equality or deterministic comparisons, keep all other columns in plaintext, and enable enclave computations for that column. This minimizes management overhead while still demonstrating the core benefit: the database can perform joins or filters on the encrypted data without ever seeing the plaintext.

Example – encrypting a credit‑card number in a Customers table:

ALTER TABLE dbo.Customers
ALTER COLUMN CreditCardNumber ADD ENCRYPTED WITH
(
    COLUMN_ENCRYPTION_KEY = MyCEK,
    ENCRYPTION_TYPE = RANDOMIZED,
    ENCLAVE_COMPUTATIONS = ON
);

The application connection string must enable column encryption and point to the attestation URL:

Server=mySqlServer;Database=Sales;Column Encryption Setting=Enabled;
Enclave Attestation URL=https://mykeyvault.azure.net/attest;Trust Server Certificate=no;

Trust and Data Boundaries

The SQL Server engine never receives the plaintext value of the encrypted column. When a query references the column, the driver:

1. Performs attestation with the key store to prove the enclave is genuine.
2. Sends the encrypted ciphertext to the server.
3. The server routes the ciphertext into a secure enclave that runs inside the SQL Server process but is isolated by VBS.
4. Inside the enclave, the column encryption key is used to decrypt the value, the requested operation (e.g., equality join) is performed, and the result is re‑encrypted before leaving the enclave.

Thus the trust boundary is: client application ↔ key store (for attestation and key access) ↔ secure enclave ↔ SQL Server engine (which only sees ciphertext). The database administrator can manage the encrypted column but cannot view its data without the client‑side key.

Operational Checks

After deployment, verify that the column is correctly configured and that the enclave is being used:

SELECT column_name, encryption_state, enclave_enabled
FROM sys.dm_database_encryption_columns
WHERE object_id = OBJECT_ID('dbo.Customers');

Expected result: encryption_state = 3 (encrypted) and enclave_enabled = 1.

To see the enclave in action, capture an actual execution plan for a simple query:

SELECT * FROM dbo.Customers WHERE CreditCardNumber = @encryptedValue;

In the plan look for an operator named Enclave Scan or Enclave Hash Match – its presence indicates the enclave performed the comparison.

Monitor enclave CPU usage via the dynamic management view or Performance Monitor:

SELECT * FROM sys.dm_os_enclave_stats;

Non‑zero values for enclave_cpu_usage_ms during workload confirm that the enclave is active.

Failure Modes

• Enclave initialization failure – If VBS is disabled or the hypervisor cannot launch the enclave, the driver falls back to client‑side decryption. Queries will succeed but performance drops and the security guarantee is lost. Check the SQL Server error log for messages like Enclave initialization failed.
• Key store inaccessibility – If the attestation endpoint or the key vault cannot be reached, the driver returns an error and the query fails. Implement connection pooling and retry logic to handle transient network issues.
• Side‑channel exposure – While enclaves mitigate many attacks, they rely on the host OS being patched. Missing VBS or hypervisor updates can increase risk; apply OS security updates promptly.

Conditions That Would Change the Design

If the application later needs range scans, pattern matching (LIKE), or non‑deterministic comparisons on the encrypted column, the enclave‑enabled random encryption will not suffice. In that case you would either:

• Remove enclave use and switch to deterministic encryption (which still allows equality joins but not range queries), or
• Redesign the data model – move the sensitive data to a separate table that can be decrypted client‑side, or use a different protection technology such as dynamic data masking for non‑searchable fields.

Upgrading to SQL Server 2022 introduces immutable enclave images, which reduces the attestation overhead on subsequent connections because the enclave identity is fixed after the first successful attestation. If you are on 2022, you can consider caching the attestation result longer to lower latency.