Always Encrypted vs Always Encrypted with secure enclaves

This post has been republished via RSS; it originally appeared at: Microsoft Tech Community - Latest Blogs - .

Introduction

Encryption is a vital technique for protecting sensitive data from unauthorized access or modification. SQL Server and Azure SQL Database offer two encryption technologies that allow you to encrypt data in use: Always Encrypted and Always Encrypted with secure enclaves. In this blog post, we will compare these two technologies and highlight their benefits and limitations.

 

What is Always Encrypted?

We began our journey towards the confidential computing vision in 2015 and we introduced the first version of Always Encrypted in SQL Server 2016 and Azure SQL Database. Always Encrypted is a client-side encryption technology where the client driver transparently encrypts query parameters and decrypts encrypted results. The data gets encrypted on the client side (inside the client driver) before being stored in the database. The data is never decrypted inside the database. The encryption keys are never exposed to the database engine, ensuring that the data stays secure even if the database is breached.

 

Always Encrypted provides strong encryption, but computations on protected data is limited to just one operation – equality comparison, which is supported via deterministic encryption. All other operations, including cryptographic operations (initial data encryption or key rotation) and richer queries (for example, pattern matching) aren't supported inside the database. Users need to move their data outside of the database to perform these operations on the client-side.

 

PieterVanhove_1-1717491640962.png

 

What is Always Encrypted with secure enclaves?

Always Encrypted with secure enclaves is an enhancement of Always Encrypted that enables rich computations on encrypted data. When processing SQL queries, the database engine delegates computations on encrypted data to a secure enclave. The enclave decrypts the data and performs computations on plaintext. This can be done safely, because the enclave is a black box to the containing database engine process and the OS, so DBAs or machine admins cannot see the data inside the enclave.

 

PieterVanhove_2-1717491701454.png

 

Always Encrypted supports the following enclave technologies (or enclave types):

 

What are the differences between Always Encrypted and Always Encrypted with secure enclaves?

 

  Always Encrypted Always Encrypted with secure enclaves
Version Introduced in SQL Server 2016 and Azure SQL Database in 2015. Also available in Azure SQL Managed Instance and CosmosDB Available from SQL Server 2019 and later, as well as in Azure SQL Database
Trusted Execution Environment Ensures data confidentiality by encrypting it on the client side. Utilizes a secure enclave. which is a trusted execution environment that can safely access cryptographic keys and sensitive data in plaintext without compromising confidentiality.
Initial Encryption and key rotation Encrypts data on the client side Cryptographic operations on database columns inside the secure enclave on the server side. The data can stay inside the database.
Confidential Queries Limits queries to equality comparisons only (only available with deterministic encryption) Allows richer confidential queries, including pattern matching, range comparisons, and sorting.

 

In essence, Always Encrypted with secure enclaves provides more flexibility and functionality for querying and managing encrypted data while maintaining a high level of security. It leverages secure enclave technology to allow certain computations to be performed on encrypted columns directly inside the database, without exposing sensitive data outside of the enclave.

 

Why do people still use Always Encrypted instead of Always Encrypted with secure enclaves?

 

I noticed that many customers are still creating new databases without using an enclave, even though we have learned that Always Encrypted with secure enclaves offers you more flexibility and functionality. So, what is the explanation for this? I contacted many of these customers and the main reasons are the following:

  • They are not aware of Always Encrypted with secure enclaves.
  • They don't need the functionality. They only need to encrypt PII information but there is no need to use it for filtering or in a where-clause.
  • Their application already works with Always Encrypted and they don't have resources, time or budget to migrate to Always Encrypted with secure enclaves.

So, I'm interested in your opinion. Are you using Always Encrypted? Or are you planning to use it? What is the reason why you're not using it with enclaves? Please let me know on this form. It would be great to get some more insights.

 

Learn more

 

Leave a Reply

Your email address will not be published. Required fields are marked *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.