Microsoft Double Key Encryption (DKE) Resources
Caution
This feature is a technical preview for evaluation in non-production environments. A technical preview introduces new, limited functionality for customer feedback as we work on the feature. Details and functionality are subject to change. This includes API endpoints, UI elements, and CLI commands. We cannot guarantee that data created as part of a technical preview will be retained after the feature is finalized.
After the testing is concluded, please delete the DKE resources (endpoints and authorized tenants) created during the testing on v2.16 public preview. Reusing these resources after upgrading to GA version is not supported.
Note
The Microsoft Office versions that use the MSIPC will not work with the CCKM DKE since they can not handle the optional client certificate request during the TLS connection.
The Microsoft Office versions that use the MIP SDK will work with the CCKM DKE since they can handle the optional client certificate request during the TLS connection.
Use one of the following Microsoft 365 app for enterprise versions/builds. They use MIP SDK and They work with private and public DKE preview releases.
Version Build Channel 2403 16.0.17419.20000 Beta 2403 16.0.17404.20000 Beta 2403 16.0.17330.20000 Beta 2402 16.0.17328.20000 Beta 2402 16.0.17318.20000 Beta The Microsoft Office client from Microsoft 365 app versions that use MSIPC can't handle "optional client certificate request" from CCKM and fail to establish TLS handshake. For such versions, deploy a proxy server or a load balancer to intercept and terminate DKE traffic. This will prevent the CipherTrust Manager from sending "optional client certificate request" directly to the Microsoft Office client. Make sure mutual TLS is disabled on the proxy server or load balancer.
Refer to Double Key Encryption FAQ for questions about how DKE works and supported versions.
CCKM provides support for Double Key Encryption (DKE) for Microsoft 365. With DKE, two keys are used to access content (such as files or documents) that is protected with the sensitivity labels that you apply when using any one of the supported Microsoft Office apps. You hold one key in CCKM, which you maintain full control over using the using Microsoft’s Double Key Encryption service. The other is securely stored within Microsoft Azure. To decrypt and gain access to the protected content, both keys are required. Since Microsoft holds only one of the keys, this solution ensures that Microsoft cannot independently access this content. Only your authorized users can access the protected content.
Only your highly confidential data should be protected by DKE, which is typically a small percentage of your organization’s overall data. For more information about DKE, guidance on what type of content to protect, the supported office applications, and other information, refer to Double Key Encryption.
DKE encryption workflow
User adds a DKE label to a document. The Microsoft Office client connects to Azure RMS (Protection Service).
User certificate, API templates, and Azure RMS key are sent to the Microsoft Office client.
Microsoft Office client requests CCKM for the DKE public key associated with the applied label.
CCKM verifies the request. After authorization succeeds, CCKM sends the DKE public key to the Microsoft Office client.
Microsoft Office client encrypts the document content with the content key.
Microsoft Office client encrypts the part of the metadata that controls access to the content with the DKE public key.
Microsoft Office client encrypts the encrypted metadata with the Azure RMS key.
The content is protected with the double-encrypted content key, RMS key and DKE public key. The following illustration shows the DKE encryption workflow:
DKE decryption workflow
User opens a document which has a DKE label. The Microsoft Office client first sends the double-encrypted metadata to Azure RMS (Protection Service).
Azure RMS (Protection Service) decrypts the double-encrypted metadata using the Azure RMS key and returns the simple-encrypted metadata.
Microsoft Office client sends the simple-encrypted metadata to CCKM and requests CCKM to decrypt it.
CCKM verifies the request and goes through the authorization process. When authorization passes successfully, CCKM decrypts the simple-encrypted metadata and returns the decrypted metadata to the Microsoft Office client.
Microsoft Office client uses the content key to decrypt the document. The user can view the document content.
The following illustration shows the DKE decryption workflow:
The following are the high-level steps to configure DKE within Microsoft and CipherTrust Manager/CCKM:
Prerequisites
In preparation for deploying DKE, ensure that the following prerequisites are met:
Ensure CipherTrust Manager/CCKM is installed and running. In addition, ensure to activate and install the CCKM license. Refer to the CipherTrust Manager Deployment Guide and Licensing for details.
Microsoft 365 E5 License: Windows clients must have a Microsoft 365 E5 license. Refer to information about system and licensing requirements for DKE for more information these licensing requirements.
Note
CCKM supports built-in sensitivity labeling with Office apps. CCKM does not support Azure Information Protection unified labeling client, which is to be deprecated in the future.
User Presence in Azure Directory: Users who are to create and share documents or files protected by DKE must be part of the Azure Active Directory (Azure AD) associated with the organization's tenant.
Note
DKE is not supported on applications running on mobile devices.
DKE is only tested with Windows clients. DKE is not tested with Mac, iOS, and Android clients.
To configure the B2B cross-tenant access settings, refer to Configure cross-tenant access settings for B2B collaboration.
Configure DKE on CCKM
To configure DKE on CCKM, do the following:
Install a third-party CA certificate on the web interface.
Note
We recommend obtaining a CA-signed certificate for the web interface from trusted CAs that are part of the Microsoft Trusted Root Program. For more information, refer to Microsoft Trusted Root Program participants.
From CCKM GUI or API, create a DKE endpoint. Refer to Creating Microsoft DKE Endpoints for details on how to create a DKE endpoint from CCKM GUI or Creating Microsoft DKE Endpoints using CCKM API.
Note
Only Azure AD users are currently supported. The email addresses included in the API call must be associated with a user Azure AD. The email address parameter an optional field applicable only if authorization_type is set to email.
If you specified one or more email addresses in a DKE endpoint, this field would be validated against JWT received in the decrypt operation.
A Microsoft Office 365 client user and email (if configured in CipherTrust Manager) must match.
The Issuer field must be specific to the tenant configured in the Microsoft Azure Portal.
The web interface port within CipherTrust Manager can be changed from the default port of 443 to another port. If you plan to change the default port for the CipherTrust Manager web interface, ensure to change it BEFORE configuring the Microsoft DKE service on CCKM. Also reflect this port change when creating a DKE endpoint on CCKM as part of the prerequisites for deploying DKE. Changing the default port AFTER configuring Microsoft DKE is not supported.
Register your DKE service
After creating a DKE endpoint, proceed to register your DKE service from the Microsoft Azure portal. Refer to Register your key store for details.
Note
When registering your DKE service, ensure that Application ID URI matches the FQDN of the CipherTrust Manager. In the case where you are using a load balancer in front of the CipherTrust Manager, ensure that Application ID URI matches the FQDN of the load balancer. You can only register one DKE service per one instance of CipherTrust Manager.
Also, ensure that the publisher domain on the Branding and Properties page is set to the domain in which CipherTrust Manager is deployed. For example, if CipherTrust Manager is test.thalescpl.io
, then ensure that the publisher domain includes thalescpl.io
.
Create your DKE sensitivity labels
After successfully registering your key store, you are ready to create your DKE sensitivity labels from the Microsoft Compliance portal. Refer to Create sensitivity labels using DKE for details.
When creating a sensitivity label, ensure to do the following:
- Select Apply or remove Encryption on the protection settings for labeled items page.
- Select the Use Double Key Encryption checkbox to enable DKE on the Encryption page. Enter the the value of the
key_uri
received in the API response when you created a DKE endpoint using thecreate DKE endpoint
API.
Note
After a label is published by the defining policy, it may take up to 24 hours for a label to be made available (after the label policy is published) for use in a Microsoft 365 Apps, such as Word or PowerPoint.
Note
For labels that are configured to have Offline Access set to Never, the decrypt requests will be sent to the CipherTrust Manager. Otherwise, if labels are configured to have Offline Access set to Always, the decrypt requests will not be sent to the CipherTrust Manager
You can manage the following DKE resources on CCKM.