Microsoft Purview: DKE from Zero to PoC

Double Key Encryption or DKE is a method of protecting data above anything else. As the name eludes it uses two keys together to protect the content. In the way that, one key is held by Microsoft (they protect it!) and the other is held purely by the customer (therefore by extension who are responsible to protect the key!). The mechanism of DKE piggy backs on the Azure Purview Label Set and when configured correctly allows a label to apply DKE protection to the data which it labels.

The closest analogy, imho, is the way banks provide safety deposit boxes (please refer screenshot below). In this analogy the data serves as the valuable goods within the safe deposit that the bank is encouraged (as a service provider) to protect and the customer is who’s main aim is to prevent the loss of the valuable goods.

TLDR; Two keys needed to get access to the goods! One might ask however how this does all work, simply put, exactly like the bank! So, imagine your data resides within a safe deposit at Microsoft and now they provide all the physical protection (akin to premises protection, etc.) and further provide all the infrastructure. Speaking more toward DKE, Microsoft holds one key (as does the bank!) and the customer is tasked with holding and protecting the second key. The process is like, First the sets up the means to protect and hold the second key. Using Purview the goods are then wrapped and stored, protected of course by a lock needing both the Microsoft key and the customer key to open, when needed to be accessed the goods are then begun to be withdrawn from the safe deposit hence the presence of the MS key and the Customer Key will be requested (the customer present his key through setting up the service, these deployments are further discussed in this section).  At the end of this process the goods are then successfully withdrawn and able to be accessed.

To summarize below are a few take-aways for the DKE service:

• Suitable for protecting highly sensitive data for WXP M365 Office Apps for Enterprise.
• DKE helps to meet several regulatory requirements.
• Customers have the choice to choose any location (on-premises or third-party cloud) to host their DKE service.
• Customers can share DKE encrypted across tenants if the users have access to Azure key and the required permission to access the in the DKE service.
• Data remains opaque to Microsoft under all circumstances. Only customers can decrypt the data

From a Risk standpoint, the responsibility in this scenario rests partly with both stakeholders (MS and the Customer) as the picture below depicts showing the responsibility as defined by the cloud service (see below; taken from link). Keen among you would instantly pick up on MS azure being PaaS[1] but one could also use it in different configurations.

[1] PaaS: Platform as a Service

As Microsoft[2] writes, if your organizations have any of the following requirements, you can use DKE to help secure your content:

• You want to ensure that only you can ever decrypt protected content, under any circumstances.
• You don’t want Microsoft to have access to protected data on its own.
• You have regulatory requirements to hold keys within a geographical boundary. All of the keys that you hold for data encryption and decryption are maintained in your control.

[2] As found under link.

Use Cases

Double Key Encryption (DKE) in general is only intended for the most sensitive data, data that if lost could create problems for business continuity for example, i.e. the strictest protection requirements. DKE is not ideal for all data rather only a tiny subset of data within your tenant. Prior deployment it is ideal that this data be identified so controls can be put in place leveraging the MS suite (Azure, Purview, etc.).

In the pursuit of this we have identified a few use cases where DKE could definitely be of service:

1. Generally, an information that needs to be guaranteed against unauthorized access. Information that could prove to be harmful to business continuity.
2. You are part of the Board of directors and negotiating a merger which would build significant investor value, this is in the infancy stages, hence all related information is to be kept confidential until made public.
3. Again, you are possibly under a legal tender contract as the head of an energy provider and are currently negotiating the current renewables pricing with a government and need this information to stay within two parties till it is to be made public.

As is apparent, the use of DKE is not only exclusive to theses use cases but can span the length of the subset of confidential files which could directly impact business continuity and thereby considered business critical.

Advatages and Limitations

As is with any service there exists a pro and contra, in this section we have attempted to summarize the advantages and limitations first however we shall do the contrary and look at the limitations to present a clear idea to adopters, these are:

• Customers need to deploy and manage their own DKE service.
• As of today, DKE is supported only by AIP UL Client (not Office built-in sensitivity labelling) and for documents only. 
• There are services that can’t use with DKE encrypted content (Examples: Transport rules including anti-malware and spam that require visibility into the attachment, Microsoft Delve, eDiscovery, Content search and indexing, Office Web Apps including co-authoring functionality).
• Any external application or services that are not integrated with DKE through the MIP SDK will be unable to perform actions on the encrypted data.  

For a counterbalance now we will look at the most experienced advantages of DKE:

• Customers maintain full control of their keys. Host your key and store your protected data in the location of your choice (on premises or in the clouds), it remains opaque to Microsoft.
• Manage user access to your key and content. Choose who has permission for the web service to access your key and decrypt content.
• Enjoy a consistent labeling experience. Double key encryption labels function like other sensitivity labels in the Microsoft Information Protection ecosystem, ensuring a consistent end user and admin experience.

Pre-requisites

Double Key Encryption is an included feature with the other great features in a Microsoft 365 E5 license and other licenses[3], that covers the licensing but below we will also highlight the technical prerequisites followed by a small brief about administrative cost in comparison to other key options in the Microsoft world.

DKE works with sensitivity labels and therefore requires Purview Information Protection to successfully implement. These labels are made available to end users through a sensitivity button in the AIP Unified Labeling client in Office desktop apps. Hence the AIP Client is also for the moment required. The following will be needed on the client devices:

1. Microsoft Office Apps for Enterprise version 2009 or later.
2. AIP Unified labeling client versions 2.7.93.0 or later.

Now as promised we have summarized the administrative effort in this table below and as you can see amongst other offering that Microsoft has for Keys DKE would be considered the one with the highest administrative effort to setup, stemming from the fact that it requires a certain know-how to put together, specifically in areas (again depending on use case) of web applications, dotnet, etc along with the security know how to secure this customer-end key store service (the purse that holds your key to present to the bank).

[3] Please refer link for a summary of license requirements link.

Possible Deployments

It could be useful for you as an organization to evaluate if Double Key Encryption (DKE) is the right solution for you, to this end the following are some ways DKE can be evaluated in a PoC (Proof of Concept) environment. Each solution presented depicts scenarios encountered in the field and can be modified depending on use case. For the deployment scenarios there are most commonly one of three to pick from as explained in the following.

From an ease of implementation point of view please find below a table that has the implementation effort for each PoC type in the following sections (refer screenshot below). To clarify, when we say implementation effort, we mean the technical and administrative overhead required to successfully implement the use of the PoC for testing.

Cloud Only PoC

The easiest, or otherwise least intensive and quickest way to spool up a PoC is in our opinion the Cloud only PoC. The logic for that being, all you would need is a valid tenant with the prerequisite licenses and an internet access. The cloud only PoC emphasizes the ease of implementation by intent by Microsoft. It showcases the major deployment steps needed to successfully implement DKE with the added advantage of it being cloud based and the advantages that come along with that (Availability, reduced risk, geographical control, etc.). The mechanism serves well as an overview to progressively implement more complex scenarios.

Instead of talking about specific implementation steps (as it has been well documented by Microsoft link), we will rather take on the PoC implementation approach. In the Cloud only PoC approach (refer screenshot above) we would require the use of one tenant and therefore minimum complexity (in essence one digital location, one plug). As an overview once the pre-requisites are fulfilled, we could do the following in the written sequence:

1. Setup an Azure VM
2. Clone the DKE repository and make the necessary changes (inserting generated keys, etc.) using VS code then build and publish the project.
3. Use ZipDeployUI to upload the published project into an Azure App Service (this now serves as the customer keystore).
4. Register the application to make it accessible to the users in the tenant.
5. Insert the URI from the App to the intended Purview DKE label.

To reinforce, what we have just done is created or rather implemented the customer end of the responsibility table i.e., created a way to store, secure and present the customer key to the bank at time of withdrawal of the goods. Therefore, this fulfils the customer side requirements. This is also most akin to the analogy presented above of the banks as in this scenario too the infrastructure is completely provided, controlled, and hence protected by the bank (service provider, MS).

On-Prem PoC

There could exist situations wherein we would require the key and the store be hosted within the customer environment i.e., on premises, so the customer has full control and by extension responsibility to store and protect the key, also make it presentable, within their own infrastructure. To reiterate this approach to a PoC is required only when within the strictest requirements, either by regulatory authorities or internal practices.

Instead of talking about specific implementation steps (as it has been well documented by Microsoft link), we will rather take on the PoC implementation approach. In the On Prem PoC approach (refer screenshot above) we prioritize location of the customer key over complexity due to regulatory reasons, hence there is a need for additional infrastructure and administrative overhead at the customer end. As an overview once the pre-requisites are fulfilled, we could do the following in the written sequence:

1. Set up the on-prem machine (IIS, etc.).
2. Clone the DKE repository and make the necessary changes (inserting generated keys, etc.) using VS code then build and publish the project.
3. Run the project on the on-prem machine.
4. Register the application to make it accessible to the users in the tenant.
5. Insert the URI from the App to the intended Purview DKE label.

To reinforce, in this PoC scenario what we have just done in essence is to claim to the bank that we as the customer want to hold the key, following through with the analogy, and therefore just installed a safe in the house to store the key hence again fulfilling the customer end of the responsibility.

Multi-Cloud PoC

This scenario is also rather interesting, there could exists situations wherein as an organization you would have to share information deemed DKE worthy with other sister organizations or partners in this situation the Multi-cloud PoC (or rather to be clearer I suppose; multi-Tenant PoC). To follow the analogy, and we are going to try hard on this one, we essentially are in a matter of speaking putting the customers key to the safe deposit at bank A into another safe deposit at bank B! In the screenshot presented below we take this situation and use a parallel of a Test and Productive tenant by a customer.

Instead of talking about specific implementation steps (as it has been well documented by Microsoft link), we will rather take on the PoC implementation approach. In the Multi Cloud PoC approach essentially in technical terms we tell the system that two tenants are allowed to issue valid identities to use the key store i.e., we say that we trust two different banks to hold the goods together (following the analogy!). As an overview once the pre-requisites are fulfilled, we could do the following in the written sequence:

1. Setup an Azure VM in the Test tenant.
2. Clone the DKE repository and make the necessary changes (inserting generated keys, etc.) using VS code then build and publish the project.
3. Use ZipDeployUI to upload the published project into an Azure App Service (this now serves as the customer keystore) in the Test tenant.
4. Register the application to make it accessible to the users in both tenants but in the Productive tenant.
5. Insert the URI from the App to the intended Purview DKE label in productive and/or test tenant.

If set up correctly what is interesting the DKE service can be used by both parties, installed within both Purview label implementations.

Summary

Depending on the organization structure and specific needs, an appropriate PoC implementation for testing can be implemented. Further depending on complexity of internal architecture the PoC implementation can be further tweaked to successfully test DKE and leverage Purview for the most sensitive data within your environment.

According to MS[1] and its cybersecurity bell curve (see image below), data protection completes your basic security hygiene and therefore provides upto 98% protection i.e. at the end of the day that covers most requirements for things like compliance and certifications. More importantly atleast in most eyes would be the peace in the fact that we are secured (almost !).

[1] See the full MS Cybersecurity Report ’21 Link