Understanding Microsoft Information Protection Encryption Key Types

Published 03-17-2021 09:00 AM 5,517 Views
Microsoft

“Microsoft Managed Key (MMK), Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), and Double Key Encryption (DKE)”

 

Blog Purpose

 

Enterprises often create, share, and store sensitive data on-premises, in the cloud, and across multiple clouds. Due to the nature of business and to meet regulatory requirements, sensitive data should always be securely stored and protected with solutions including strong data encryption. Enterprises are also heterogenous - one size does not fit all since they all have different business needs.

 

Microsoft Information Protection (MIP) is a built-in, intelligent, unified, and extensible solution to protect sensitive data across your enterprise – in Microsoft 365 cloud services, on-premises, third-party SaaS applications, and more. MIP provides a unified set of capabilities to know your data, protect your data, and help prevent data loss across Microsoft 365 apps (e.g., Word, PowerPoint, Excel, Outlook) and services (e.g., Teams, SharePoint, and Exchange).

 

Microsoft offers a variety of encryption keys that support various customer scenarios. While it could be a daunting task to understand various encryption key types and their applications in the context of the environment, we will describe the various Microsoft Information Protection (MIP) encryption key types through this blog. This blog expands on each key offering, highlights unique aspects, differences, benefits, challenges, typical use cases, and a high-level architectural overview of each key type. Our intent is to keep the right level of technical depth that will help readers get a good understanding of the various key options. Refer to NIST 800-57 for best practices of key management. The blog outlines key elements that enable encryption, discusses rights management services, various key types and concludes with a comparison tables that helps to choose the appropriate key types.

 

Underlying elements that enable Microsoft Encryption key types

 

Encryption Algorithms

 

  • MIP uses both symmetric encryption and public-key encryption for different processes, leveraging the best of both types of algorithms each performing a different function.
  • Symmetric AES (Advanced Encryption Standard) is used for the encryption of the plaintext in emails & files. keys are used depending on the type of content.
  • Asymmetric RSA (Rivest Shamir Adleman) algorithm with a 2048 bit ‘key’ is used to encrypt the symmetric key and thus ensure secrecy of the content.

 

Tenant Keys

 

  • A tenant key is the root encryption key tied to a tenant. In other words, content encrypted with MIP in a tenant, roots to the tenant key that was active at the time the content was protected.
  • The tenant key is used to encrypt other keys that in turn are used to supply protection to emails and files & provides access to users.
  • This tenant key is common to all emails and files protected by MIP and can be changed only by the MIP administrator for the tenant.

 

Content Keys

 

  • Content keys are symmetric keys, they are used to encrypt the content itself (the plaintext).
  • The content key is protected, together with the policy in the document that defines access to the content, with the tenant’s RSA key
  • The encrypted policy and content key are embedded into the document itself and persist through editions of the document. The document metadata is not encrypted nor protected. For more details, refer to Azure Information Protection (AIP) labeling, classification, and protection | Microsoft Docs

 

Microsoft Rights Management Services 

 

The following section provides an overview of how a client initiates the environment for users to begin protecting and consuming sensitive data[i]. This is common across all encryption key types using MSIPC clients. (Ref: How Azure RMS works - Azure Information Protection | Microsoft Docs)

 

Initializing the Environment

 

Gopal_Shankar_1-1615843468984.png

 

STEP 1: Before a user can protect content or consume protected content on a Windows computer, the user environment must be prepared on the device. This is a one-time process and happens automatically without user intervention when a user tries to protect or consume protected content.

 

The RMS client (aka MIP Client) on the computer first connects to the Rights Management service (RMS) and authenticates the user by using their Azure Active Directory account.

 

STEP 2: After the user is authenticated, the connection is automatically redirected to the organization’s MIP tenant, which issues certificates that let the user authenticate to the RMS to consume protected content, and to protect content offline.

 

One of these certificates is the rights account certificate, often abbreviated to RAC. This certificate authenticates the user to Azure Active Directory and is valid for 31 days. The certificate is automatically renewed by the RMS client, provided the user account is still in Azure Active Directory and the account is enabled. This certificate is not configurable by an administrator.

 

A copy of this certificate is stored in Azure so that if the user moves to another device, the certificates are created by using the same keys.

 

Content Protection

 

Gopal_Shankar_0-1615843809183.png

 

STEP 1: The RMS client creates a random key (the content key) and encrypts the document using this key with the AES symmetric encryption algorithm.

 

STEP 2: The RMS client then creates a certificate that includes a policy for the document that includes the usage rights for users or groups, and other restrictions, such as an expiration date. These settings can be defined in a template that an administrator previously configured or specified at the time the content is protected (sometimes referred to as an "ad hoc policy").

 

The main Azure AD attribute used to identify the selected users and groups is the Azure AD Proxy addresses attribute, which stores all the email addresses for a user or group. However, if a user account does not have any values in the AD Proxy addresses attribute, the user's User Principal Name value is used instead.

 

The RMS client then uses the organization’s key that was obtained when the user environment was initialized and uses this key to encrypt the policy and the symmetric content key. The RMS client also signs the policy with the user’s certificate that was obtained when the user environment was initialized.

 

STEP 3: The RMS client embeds the policy into a file with the body of the document encrypted previously, which together comprise a protected document. This document can be stored anywhere or shared by using any method, and the policy always stays with the encrypted document.

 

Content Consumption

 

Gopal_Shankar_1-1615843864034.png

 

STEP 1: The authenticated user sends the document policy and the user’s certificates to the Azure Rights Management service. The service decrypts and evaluates the policy and builds a list of rights (if any) the user has for the document. To identify the user, the Azure AD Proxy addresses attribute is used for the user's account and groups to which the user is a member. For performance reasons, group membership is cached. If the user account has no values for the Azure AD Proxy addresses attribute, the value in the Azure AD User Principal Name is used instead.

 

STEP 2: The service then extracts the AES content key from the decrypted policy. This key is then encrypted with the user’s public RSA key that was obtained with the request. The re-encrypted content key is then embedded into an encrypted use license with the list of user rights, which is then returned to the RMS client.

 

STEP 3: Finally, the RMS client takes the encrypted use license and decrypts it with its own user private key. This lets the RMS client decrypt the document’s body as it is needed and render it on the screen. The client also decrypts the rights list and passes them to the application, which enforces those rights in the application’s user interface.

 

How office applications and services support Rights Management

 

End-user Office applications and Office Services also uses the Rights Management service to protect data. These office applications are Word, Excel, PowerPoint, and Outlook. The Office services are Exchange[ii] and Microsoft SharePoint[iii],[iv]. The Office configuration that supports the Rights Management service often use the term information rights management (IRM).

 

Office 365 apps, Office 2019, Office 2016, and Office 2013 versions provide built-in support for the Azure Rights Management services. No client computer configuration is required to support the IRM features for applications such as Word, Excel, PowerPoint, Outlook, and Outlook on the web. All users must do for these apps on Windows, is sign-in to their office applications with their Microsoft 365 credentials. They can protect files and emails and use files and emails that have protected by others. Users who have Office for Mac must first verify their credentials before they can protect their content.[v]  

 

To enable third party application to build native support for applying labels and protection to files refer to Microsoft Software Development Kit[vii]. Microsoft Information Protection SDK documentation | Microsoft Docs

 

Key Management Options

 

Now that we have a good understanding of encryption and how IRM client enables this functionality, let us dig deeper into the various encryption key options. Microsoft offers four encryption key management options as part of MIP offerings. Per Cloud’s shared responsibility model guidance, enterprise CISOs and Data Owners have the ultimate accountability to choose and implement the right key option that will allow their enterprise to securely create, use, share, store, archive and destroy data. Microsoft key management options are Microsoft Managed Key (MMK); Bring your own key (BYOK); Hold your own key (HYOK) and Double Key Encryption (DKE). Enterprises have the option to choose the right key solution that addresses their business scenarios to protect and secure ‘sensitive & highly sensitive’ data. All the key options are built on above key elements that are fundamentally common across the board except that the implementation varies for each key.

 

Typically, an enterprises data landscape has the following structure. Majority of the data ~80%  are non-sensitive data not subject to compliance requirements and does not require encryption. Enterprises are most concerned about their sensitive data ~15% and highly sensitive data ~5% that they would want to protect. By using the MIP key options you can protect your data assets, additionally you can use different MIP keys to adequately protect different types of sensitive data in your digital estate.

 

Gopal_Shankar_2-1615844475287.png

 

1. Microsoft Information Protection – Microsoft Managed Keys 

Microsoft fully owns and manages the key. Microsoft offers a full key management solution that customers can use for instantiating their MIP tenant. This is the default choice if it meets the business needs and most preferable for smaller enterprises. This is also the quickest and most effective way to get started with MIP with the least number of administrative efforts and without requiring special hardware. Supports various key operations such as Rekey, Revoke, Backup, Export and Respond[viii].

 

High-level Architecture of ‘Microsoft Managed Key’:

 

Gopal_Shankar_4-1615844687754.png

 

Uniqueness:

  • Microsoft generates your tenant key and keeps the master copy.
  • Customers can export their tenant keys through Microsoft Customer Support Services.
  • RMS can use your tenant key to authorize users to open your documents.
  • RMS provides logging information to show how your protected data is used.

Benefits:

  • Key management is fully managed by Microsoft.
  • It is quick and easy to deploy with the customer.
  • Cost effective solution, no separate key management hardware/software required.
  • Least administrator efforts compared to other key solutions.
  • Customers have the choice to rekey the tenant key when a business scenario calls for it.
  • The key is automatically revoked by Microsoft when a subscription is cancelled thereby making this key unusable to protect or view data after revocation.
  • Data may be viewed after cancelling the subscription provided customer has exported the TPD.

Challenges:

  • While customers can export their tenant key, they own accountability to safeguard the exported key.
  • Rekeying may take a while to reflect across all existing clients and services used by the enterprise. This allows the client to choose a new key for protecting data. This does not re-protect existing protected content. Existing protected content can be opened if the previous key is stored in archive is available, user must unprotect with the previous keys and re-protect.
  • Customers have the responsibility of initiating the process of exporting tenant keys from Microsoft.

Use MMK when:

  • Enterprises do not have the need to manage their tenant keys.
  • You do not have to comply with stringent compliance and regulatory requirements.

How it works:

  • Upon the activation of Azure Information Protection Service Microsoft generates a tenant key
  • Microsoft manages most aspects of tenant key life cycle.
  • Azure Active Directory authenticates users.
  • RMS uses the tenant key to authorize users to open your documents.
  • RMS provides logging information to show how your protected data is used.

 

2. Microsoft Information Protection - Bring Your Own Key

Customers own and manage this key. When enterprises must comply with regulatory requirements, they have the option to bring their own keys, in other words they can generate their own keys from anywhere and bring them to Azure Key Vault.

 

High-level Architecture of ‘Bring Your Own Key’:

 

Gopal_Shankar_5-1615845171961.png

 

Uniqueness:

  • Customers generate and protect the MIP tenant key.
  • Microsoft cannot see or export customer MIP tenant key as this stay protected by HSMs.
  • It can be software or hardware based with a protected key.

Benefits:

  • Customers can use this solution if moving to cloud from On Premise (HYOK to BYOK)
  • Customer manages the MIP tenant key.
  • Customer has full control over the generated key (master copy, backup)
  • Customers can use custom specifications for the key to comply with specific regulatory needs.
  • Enables customers to meet the regulatory and compliance requirements. Customers can audit.
  • Customers can securely transfer their keys to Microsoft Hardware Security Modules (HSMs).
  • Microsoft can replicate tenant keys across a controlled set of HSMs for scale or disaster recovery.
  • Microsoft can provide log information to show how your tenant key and protected data are used.

Challenges:

  • Customers will have administrative overheads initially when setting up the solution.

Use BYOK when:

  • Use BYOK when your organization has compliance regulations for key generations, including control over all life-cycle operations. For example, when your key must be protected by a hardware security module.

How it works:

  • Customers generate their tenant key.
  • Customer securely transfer their own tenant key to Microsoft HSMs.
  • Your key stays protected by Thales or other vendor HSMs.
  • RMS can use your tenant key to authorize users to open your documents.
  • Microsoft can replicate your tenant key across a controlled set of HSMs for scale & disaster recovery but cannot export it.
  • RMS provides logging information to show how your tenant key and protected data are used.

 

3.Microsoft Information Protection - Hold Your Own Key (Classic  Only)

Note: ‘Hold Your Own Key was supported with the AIP ‘classic’ client. As we announced in 2020, the AIP classic client will no longer be supported as of March 31, 2021. HYOK is included here for reference purposes only’.  

 

When enterprises want to maintain data opacity at all costs then Hold Your Own Key solution provided this functionality, however, this option will be deprecated soon in favor of Double Key Encryption that is more compatible with the overall MIP Unified Labeling story. This enables us to protect data in a way where the organization holds the key, the enterprise fully operates their own Active Directory, Rights Management Server, and Hardware Security Modules for key . HYOK-protection uses a key that is created and held by customers, in a location isolated from the clouds. Since HYOK-protection only enables access to data for on-premises applications and services, customers may also have a need for cloud-based key for managing cloud documents.

 

High-level Architecture of ‘Hold Your Own Key’:

 

Gopal_Shankar_6-1615845293559.png

Uniqueness:

  • Most suitable for cases where opaque data is required, and it comes with trade-offs.
  • Customers deploy Azure Information Protection in their organization.
  • MIP is cloud hosted, but they enable customers to operate in cloud-only, on-premises or hybrid.
  • Customers define policies using RMS for “Sensitive” data.
  • Customers define policies using Active Directory (AD) RMS for “Sensitive” data
  • Ideal for highly sensitive data that will not be shared outside of the enterprise.

Benefits:

  • Microsoft does not have access to on-premise self-hosted keys.
  • AD RMS content cannot be consumed by users from different tenants.
  • HYOK supports Documents and Email using AIP Classic Client.
  • Good for air-gapped complete control of your encryption of toxic content.

Challenges:

  • Customer owns Active Directory and AD RMS server.
  • The AD RMS server should not be published on the internet.
  • HYOK works solely with AD and AD RMS instance.
  • HYOK should be used with fully managed PCs only.
  • AD RMS content is not recognized by O365 (no search, pivoted views, eDiscovery, antispam and anti-malware).
  • Email based on AD RMS is not compatible and supported with Office 365 Message Encryption (OME).
  • Data cannot be accessed by mobile devices.
  • AIP Unified labeling does not and will not support HYOK. Works only with AIP Classic Client.
  • Extremely difficult to manage and deploy and may require specialized skills and admin overhead to use and breaks a lot of MIP functionality that the cloud has to offer.

Use HYOK when:

  • Use when documents have the highest classification in your organization, such as “Top Secret.”
  • It is restricted to just a few people.
  • Not shared outside the organization.
  • They are consumed only on internal networks.

How it works:

  • Deploy Azure Information Protection in your organization, configure labels, policies.
  • Deploy multiple RMS services within your AIP environment.
  • Configure Azure RMS protection policies for “regular” sensitive data.
  • Configure AD RMS protection policies for “sensitive” data.
  • Keep your AD RMS out of demilitarized zone (DMZ).
  • Configure RMS connector if you operate in a hybrid environment (on-premise and cloud)
  • HYOK should be used with fully managed PCs to access “sensitive” data.

 

4. Microsoft Information Protection – Double Key Encryption (AIP UL Client )

 

Double key encryption is suitable for customers with mission critical data that are most sensitive data and requires higher protection and regulatory requirement. Double key encryption uses two keys together to access protected content. Microsoft stores one key in Microsoft Azure and the customer holds the other key. Customers maintain full control of one of your keys using the Double Key Encryption service. You can apply protection using the Azure Information Protection Unified Labeling client to your highly sensitive content.

 

High Level Architecture of Double Key Encryption:

 

Gopal_Shankar_7-1615845356178.png

 

Uniqueness:

  • 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-premise 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.

Benefits:

  • 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.
  • Simplify deployment. Reference code and instructions help deploy the Double Key Encryption service used to request your key. We support the reference implementation hosted on GitHub. Any modifications to the reference implementation are at customers own risk + responsibility.   

Challenges:

  • 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 – but this may change in the future. 
  • 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 coauthoring functionality). (Double Key Encryption (DKE) - Microsoft 365 Compliance | Microsoft Docs)
  • 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.    

Use a DKE when:

  • Double key encryption is intended for your most sensitive data that is subject to the strictest protection requirements.
  • Customers want to ensure that only they can ever decrypt protected content, under all circumstances.
  • Enterprise does not want Microsoft to have access to protected data on its own.
  • It has regulatory requirements to hold keys within a geographical boundary. With DKE, customers can choose to host their DKE service and keys in the location of their choosing.

How it works:

  • If you have not already set up the Azure Information Protection service using MMK or BYOK
  • Deploy Double Key Encryption Service at your preferred location i.e., on-premise or cloud.
  • Microsoft Office client + AIP Unified labeling client bootstraps to the AIP Service.
  • AIP service sends the customer’s public key to the Office client which gets cached for 30 days.
  • Microsoft Office + AIP Unified Label client requests customer-controlled public from DKE service
  • The document metadata controlling access to the document is encrypted with the key from DKE.
  • The encrypted part of the metadata is further encrypted with AIP, thus double encrypting the document.

 

Synopsis

*With AIP Classic client deprecation HYOK is not relevant anymore. Documented for reference purposes only.

The table below shows a high-level comparison between the various MIP key options. IT admins can assess the various aspects to select the most suitable option that meets their business scenario.   

 

Table 1: Key options and key actions

 

Action

MMK

BYOK

HYOK*

DKE

Revoke a tenant key.

Gopal_Shankar_20-1615868910271.png

 

Gopal_Shankar_21-1615868910272.png

 

Gopal_Shankar_22-1615868910272.png

 

Gopal_Shankar_23-1615868910273.png

 

Re-key your tenant key.

Gopal_Shankar_24-1615868910273.png

 

Gopal_Shankar_25-1615868910273.png

 

Gopal_Shankar_26-1615868910273.png

 

Gopal_Shankar_27-1615868910273.png

 

Backup & recover your tenant key.

Gopal_Shankar_28-1615868910273.png

 

Gopal_Shankar_29-1615868910274.png

 

Gopal_Shankar_30-1615868910274.png

 

Gopal_Shankar_31-1615868910274.png

 

Customers can export tenant keys.

Gopal_Shankar_32-1615868910274.png

 

Gopal_Shankar_33-1615868910274.png

 

Gopal_Shankar_34-1615868910274.png

 

Gopal_Shankar_35-1615868910275.png

 

Microsoft can export tenant keys.

Gopal_Shankar_32-1615868910274.png

 

Gopal_Shankar_38-1615868910275.png

 

Gopal_Shankar_38-1615868910275.png

 

Gopal_Shankar_39-1615868910275.png

 

 

 

Table 2: Key options and administrative efforts:

 

Administrative Effort

MMK

BYOK

HYOK*

DKE

Low

Gopal_Shankar_40-1615869105578.png

 

-

-

-

Moderate

-

Gopal_Shankar_41-1615869105580.png

 

-

-

High

-

-

Gopal_Shankar_42-1615869105580.png

 

Gopal_Shankar_43-1615869105580.png

 

 

Table 3: Key options and licensing requirements:

 

License

MMK

BYOK

HYOK*

DKE

AIP P1

Gopal_Shankar_44-1615869163747.png

 

Gopal_Shankar_45-1615869163747.png

 

Gopal_Shankar_46-1615869163747.png

 

Gopal_Shankar_47-1615869163748.png

 

AIP P2

Gopal_Shankar_48-1615869163748.png

 

Gopal_Shankar_49-1615869163748.png

 

Gopal_Shankar_50-1615869163748.png

 

Gopal_Shankar_51-1615869163748.png

 

M365 E3

Gopal_Shankar_52-1615869163749.png

 

Gopal_Shankar_53-1615869163749.png

 

Gopal_Shankar_54-1615869163749.png

 

Gopal_Shankar_55-1615869163749.png

 

M365 E5

Gopal_Shankar_56-1615869163749.png

 

Gopal_Shankar_57-1615869163749.png

 

Gopal_Shankar_58-1615869163750.png

 

Gopal_Shankar_59-1615869163750.png

 

 

Table 4: Applications Supported:

 

Applications Supported

MMK

BYOK

HYOK*

DKE

One Drive

Gopal_Shankar_60-1615869252098.png

 

Gopal_Shankar_61-1615869252100.png

 

Gopal_Shankar_62-1615869252101.png

 

Gopal_Shankar_63-1615869252102.png

 

SharePoint Online

Gopal_Shankar_64-1615869252102.png

 

Gopal_Shankar_65-1615869252103.png

 

Gopal_Shankar_66-1615869252103.png

 

Gopal_Shankar_67-1615869252104.png

 

Exchange Online

Gopal_Shankar_68-1615869252105.png

 

Gopal_Shankar_69-1615869252105.png

 

Gopal_Shankar_70-1615869252105.png

 

Gopal_Shankar_71-1615869252106.png

 

Microsoft 365 (Office 365 Word, Excel, PowerPoint)

Gopal_Shankar_72-1615869252106.png

 

Gopal_Shankar_73-1615869252106.png

 

Gopal_Shankar_74-1615869252107.png

 

Gopal_Shankar_75-1615869252107.png

 

Microsoft 365 (Office 365 - Email)

Gopal_Shankar_76-1615869252108.png

 

Gopal_Shankar_77-1615869252108.png

 

Gopal_Shankar_78-1615869252108.png

 

Gopal_Shankar_79-1615869252108.png

 

On-Premise Exchange

Gopal_Shankar_80-1615869252109.png

 

Gopal_Shankar_81-1615869252109.png

 

Gopal_Shankar_82-1615869252109.png

 

Gopal_Shankar_83-1615869252110.png

 

On-Premise SharePoint

Gopal_Shankar_84-1615869252110.png

 

Gopal_Shankar_85-1615869252110.png

 

Gopal_Shankar_86-1615869252110.png

 

Gopal_Shankar_87-1615869252110.png

 

Teams

Gopal_Shankar_88-1615869252111.png

 

Gopal_Shankar_89-1615869252111.png

 

Gopal_Shankar_90-1615869252111.png

 

Gopal_Shankar_91-1615869252111.png

 

 

Table 5: Applications Supported:

 

Platform

MMK

BYOK

HYOK*

DKE

Windows

Gopal_Shankar_92-1615869410524.png

 

Gopal_Shankar_93-1615869410526.png

 

Gopal_Shankar_94-1615869410526.png

 

Gopal_Shankar_95-1615869410526.png

 

iOS

Gopal_Shankar_96-1615869410526.png

 

Gopal_Shankar_97-1615869410527.png

 

Gopal_Shankar_98-1615869410527.png

 

Gopal_Shankar_99-1615869410527.png

 

Android

Gopal_Shankar_100-1615869410527.png

 

Gopal_Shankar_101-1615869410527.png

 

Gopal_Shankar_102-1615869410528.png

 

Gopal_Shankar_103-1615869410528.png

 

 

 

Frequently asked questions

 

How to renew symmetric keys

https://docs.microsoft.com/en-us/azure/information-protection/develop/how-to-renew-symmetric-key

How to export tenant keys for MMKs:

https://docs.microsoft.com/en-us/azure/information-protection/operations-microsoft-managed-tenant-ke...

What are DKE License requirements?

https://docs.microsoft.com/en-us/office365/servicedescriptions/microsoft-365-service-descriptions/mi...

How to configure DKE

https://docs.microsoft.com/en-us/microsoft-365/compliance/double-key-encryption?view=o365-worldwide

 

References

 

[i] How Azure RMS works - Azure Information Protection | Microsoft Docs

[ii] How Office apps & services support Azure RMS from AIP | Microsoft Docs

[iii] How Office apps & services support Azure RMS from AIP | Microsoft Docs

[iv] Enable sensitivity labels for Office files in SharePoint and OneDrive - Microsoft 365 Compliance | M...

[v] Configuration for clients to use Office apps with Azure RMS from AIP | Microsoft Docs

[vi] Licenses and Certificates, and how AD RMS protects and consumes documents

[vii] Microsoft Information Protection SDK documentation | Microsoft Docs

[viii] Microsoft-managed - AIP tenant key life cycle operations | Microsoft Docs

[ix] Customer-managed - AIP tenant key life cycle operations | Microsoft Docs

[x] How to prepare an Azure Information Protection “Cloud Exit” plan

[xi] Bring Your Own Key (BYOK) details - Azure Information Protection | Microsoft Docs

[xii] How to generate & transfer HSM-protected keys – BYOK – Azure Key Vault | Microsoft Docs

[xiii] Bring Your Own Key (BYOK) details - Azure Information Protection | Microsoft Docs

[xiv] Operations for your Azure Information Protection tenant key

[xv] Host DKE on IIS, using an on-premises server - Microsoft Tech Community

[xvi] Implement DKE B2B scenarios - Microsoft Tech Community

 

 

 

 

 

10 Comments
Senior Member

Hi,

in the table about what application supports which Encryption Type I'm not sure if that is correct. From that table I read OneDrive and DKE is not supported but on the DKE page I find that this is supported: https://docs.microsoft.com/en-us/microsoft-365/compliance/double-key-encryption?view=o365-worldwide#...

 

Can you check this against the DKE article? Which information is now correct?

Occasional Contributor

Hello @Gopal_Shankar 

 

Thanks a lot for this post.

 

I would be delighted if you could make a follow-up article on the impact of the different encryption option of Defender capacity as well as on DLP/Sensitive Information Type

 

Best Regards

Christophe

Microsoft

@Peter Forster Thank you for reviewing the post. The table in the blog is accurate, you can’t apply DKE labels in those applications. Thanks for pointing out the DKE docs reference. I'll work with the content owner to update.  

Microsoft

@ChristopheHumbert Hello Christopher - Thank you for reviewing the post. I really appreciate your input. I will relay this back to the respective teams. 

Microsoft

Also worth mentioning that DKE breaks quite a few services in the Microsoft cloud according to this documentation.

 

Double Key Encryption (DKE) - Microsoft 365 Compliance | Microsoft Docs

 

Things that don't work with DKE:

  • Transport rules including anti-malware and spam that require visibility into the attachment
  • Microsoft Delve
  • eDiscovery
  • Content search and indexing
  • Office Web Apps including coauthoring functionality
New Contributor

HI, I spent lot of time gathering the information about the DKE, here are few things that are not clear in this article: 

 

  • DKE content can be stored everywhere - even on SharePoint/Teams/OD4B. The post means that M365 services cannot read, preview nor index the content. Microsoft does not have the key to be able to look into the documents. Therefore there is trade off - the disadvantages are clearly documented in Microsoft article (eDiscovery, Delve, etc.) @Peter Forster 
  • The label using DKE must be set from Microsoft Desktop client on Windows with UL client installed (forget iOS, web, mobile, etc.)
  • Even Outlook can use the same labeling system - but again, only Microsoft Outlook can use that label containing DKE. And for external recipient to be able to decrypt content, the special requirements for having access to DKE are in place.
  • Configuring label advanced settings for Outlook you can apply S/MIME protection instead for DKE for the emails, even when using label configured with DKE. But you have to have working S/MIME deployment. 
  • DKE Service must be built by a customer or purchased from some vendor (they are coming). The provided reference is just sample how it can be used, but the sample it GIT repository is not enterprise ready!
  • If you built you own DKE Service, you are responsible for its High Availability!
  • You also need to have a Key store (HW - HSM or SW - e.g., Azure Ket Vault)
  • If you want to be 100% sure, you probably want to have HSM in On Premises with your own Highly Available DKE Service (running either in cloud or On Premises). 
New Contributor

BTW two vendors are active in this area, check it - Thales and Entrust

 

Microsoft

@PaulEdlund Thank you for highlighting DKE challenges. I'll include these in the blog. 

Microsoft

@Jakub Urban Thank you for adding some comments. I have also included two other blogs in the reference section.   

Occasional Contributor
Co-Authors
Version history
Last update:
‎Mar 22 2021 02:16 PM
Updated by: