Customer Key and Double Key Encryption

Posted by

Reading time: 5 minutes

Encryption in Microsoft 365

Customer key and Double Key Encryption are both options that allow an organization to have and keep control over the encryption keys for Microsoft 365. But do these allow confirmation to regulations and what are the differences?

During my session for CollabDaysBE in Brussels in October 2022, I had a small discussion on encryption. The session was about Microsoft Purview Information Protection. And this platform utilizes encryption to protect specific labeled items. So it was no surprise to me to be discussing this function in some more detail.

The main reason for discussing encryption was not the encryption standards used or the reason for using encryption. It was about key management as related to (inter)national regulations in particular.

Let me explain

Like most or all countries, here in The Netherlands, we have specific regulations for information governance and information protection. Governmental organizations are bound to (at least) the Baseline Informatiebeveiliging Overheid [BIO – Information protection baseline for the government]. And this baseline does address the encryption of sensitive information.

In the baseline itself this is addressed in article 10 (see below). But there is additional information provided in an add-on to this baseline.

BIO V1.04

Simply stated, or in my own words, (highly) confidential information that is allowed to be stored in the cloud, needs to be encrypted. But also: the organization needs to be in control of the keys used.

Control of encryption keys

In this blog, I’m not going into the baseline itself or the add-ons in particular. But the way I read these regulations, is this; An organization needs processes and technology in place to manage and use cryptographic functions. Especially for highly confidential information. And this can be very complex when using cloud platforms. But here is where concepts like “Bring Your Own Key” [BYOK] and “Hold Your Own Key ” [HYOK] come in…

Microsoft Learn information

Options offered by Microsoft

In the standard or default tenant configurations, encryption of data uses Microsoft managed keys. These keys are used on many different levels, for instance on the storage locations using Bitlocker.

Within Microsoft 365 the common workloads themselves (Exchange Online, SharePoint Online/OneDrive, and all others like Microsoft Purview Information Protection) use so-called Data Encryption Policies. And this is where BYOK comes in.

Microsoft Purview Information Protection also offers an additional option, called Double Key Encryption or DKE. But this is more widely known as HYOK.

Let’s take a look at these options and how they relate to regulations.

DEP and Customer Key

Any DEP by default uses Microsoft encryption keys. Let’s say your organization has the requirement to manage encryption keys used for information protection. In this case, the DEP for the Microsoft Purview Information Protection workload can be configured to use an organizational managed key. This concept is called “Customer Key” and requires an additional E5 license. By the way: this workload also includes other functions like Teams conversations, for example.

The key the organization provides is stored using Azure Key Vault and there are many requirements and steps to complete:

Do note that Microsoft recommends the use of Hardware Security Modules [HSMs] to protect the Key Vault(s). But this is a Premium feature – and highly recommended.

Using the DEP and Customer Key allows you to encrypt the information (at rest) for a specific workload. It also allows this workload to function as designed. And this requires some explanation.

The use of a Customer Key does not mean that Microsoft (technology/people) cannot access the information stored on the Microsoft 365 platform. This access is simply required in order to have functions like search, eDiscovery, co-authoring, Delve and more to work. The encrypted data needs to be accessed by the service for this.

This is a common misunderstanding. You provide and manage your own keys, in order for the platform to continue to work. Microsoft itself is clear about this, although you do need to find this on Microsoft Learn.

And, again, this makes sense. And where regulations are concerned: you are able to create, manage, and rotate your organizational encryption keys. Which makes this a solution to consider. Please remember: Customer Key is used to encrypt an entire workload.

But there’s still data that might require even stricter encryption when this is allowed to be stored in the (Microsoft) cloud. And that’s where Double Key Encryption comes in.

Double Key Encryption

To start: Double Key Encryption [DKE] can only be used within a sensitivity label in Microsoft Purview Information Protection. It is not a solution to encrypt data from an entire workload. But instead, it is document based. It is also an option that can only be used for Office documents and it requires the so-called Unified Labeling client within Office.

Sensitivity Label configuration

From a confidentiality perspective, DKE offers the best solution. When protecting an Office document, the document is encrypted using both the Microsoft managed key and your own on-premises managed key. Only these two keys combined can be used to decrypt the document.

Because your own key is managed entirely on-premises, the encrypted data is very secure. Even Microsoft cannot access this. But there is a very important “snag” to this. Because of the high level of encryption and the use of an on-premises key, specific Microsoft 365 functions will seize to work on this data.

Working together on documents (co-authoring), search/indexing of information, and eDiscovery solutions will not be possible because the platforms cannot decrypt the document. The same goes for anti-malware and anti-spam functions that require access to the information for their scans.

The eDiscovery part is important because this also means that you cannot use these functions to adhere to the Freedom of Information Act (or Wet Open Overheid).

From a technology perspective, this makes sense. But do take this into consideration, especially from the users-perspective. Also, note that this function (at this moment) only works with this Unified Labeling client. A client that has been in maintenance mode for some time and will not receive any feature enhancements.

Wrapping up

Okay – where does this leave us? In general, Microsoft offers options for an organization to be in control of its encryption keys and processes. But this does not automatically imply that your data by default cannot be read by other platforms or Microsoft personnel. But this is working as designed.

In short:

Customer Key is useful for entire workloads. No functions are impaired and you have control over your keys. Microsoft platform and personnel can have access (if needed!!!). An additional safeguard for this is Customer Lockbox. As this is also an E5 function, why not combine the two?

Double Key Encryption can be useful for very specific Office documents. It only works with Microsoft Purview Information Protection. Some (important) Microsoft 365/Purview functions are impaired and an installable client is required. Microsoft Platform and personnel do not have access. But: if you have a problem with your key(s), then you have a very significant problem with the data that’s encrypted using this key. A problem with which Microsoft itself cannot help. So please beware!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s