KYOS

What is Double Key Encryption (DKE)?

Thibaud Merlin

Thibaud Merlin

Cloud Security Architect

Illustration de double key encryption

1. Introduction

What is DKE?

DKE – or Double Key Encryption– is a new option offered by Microsoft Information Protection (MIP), a cloud-based data classification and protection software.

Given that many customers are worried to start their journey to the cloud because of data protection concerns, Microsoft implemented a new option to protect unstructured data (documents, files) against unauthorized access, wherever the document or file is stored AND against the cloud provider itself.

What is MIP?

Using MIP files are encrypted and protected against unauthorized access, not only in your internal perimeter but in every location.

Documents are encrypted, and the encryption key is encrypted too. To protect this key, MIP uses by default a master key in the Azure Key Vault (either in an HSM or software-protected): the master key is accessible to service accounts to be able to use standard cloud features (like eDiscovery).

With DKE file encryption keys are protected by two master keys: the first is still in the Azure Key Vault, while the second could be either with a second cloud provider (e.g., cloud HSM) or on an on-premises server (backed with an HSM/KMS). This means you can have full control of who access the key and when. ISP service accounts are not able to decrypt DKE encrypted files, thus making them available only to those who are authorized on your own system.

Currently DKE allows two ways to authorize users and both require LDAP access to Active Directory:

Microsoft publishes the source code of the internal server, you will be able to develop additional features for new authorization methods.

At this point, DKE uses the credentials entered the Office Client to authenticate the user on the DKE server.  

All this is pretty cool, isn’t it?

Indeed, it is. However, you must keep the following in mind: since ISP service accounts are not able to access DKE protected files, you will be not able to use some cool cloud features – in fact all features which need access to the contents of the protected documents (like SharePoint Online Co-Authoring, Office Web App, eDiscovery)

DKE is the new AD RMS, with one more foot in the Cloud Door.

“As” in the sense of “when”? Is it already published?

Table of Contents
    Add a header to begin generating the table of contents
    Scroll to Top

    How does it work

    Can I use DKE to share documents with external users?

    The answer is yes, but with some caveats:

    • An external user must be authorized on your AzureAD (Guest user, B2B, etc…) and on your on-premises DKE server/HSM/KMS (AD groups membership OR emails list).
    Can I use different DKE keys for different labels?

    Yes, you can use one key per label, and you are able to rotate keys.

    Which kind of files can I protect?

    For now, only Office documents. There is no possibility yet to encrypt emails.

    The prerequisites to use DKE:
    What comes next?

    2 Solutions :

    Thales EKMS plugin

    DuoKey SaaS solution

    Schema DKE solutions Thales EKMS and DuoKey Saas

    Thales will release a new product, end of Q1 2021, to connect Thales HSM/KMS (Luna HSM, CCKM KMS, Data Protection on Demand PaaS) to DKE API.

    2. Technical Overview

    How does the demo server work?

    Microsoft published the source code of a C#/.NET 3.1 demo server here: https://github.com/Azure-Samples/DoubleKeyEncryptionService/tree/main

    How does the authentication/authorization work?

    The server uses OpenIDConnect to authenticate against Azure AD (and also cookies).

    				
    					using Microsoft.AspNetCore.Authentication.Cookies;
        using Microsoft.AspNetCore.Authentication.JwtBearer;
        using Microsoft.AspNetCore.Authentication.OpenIdConnect;
    
    				
    			

    And the server uses JWT to grant authorization.

    You must register an enterprise app on your AzureAD to integrate your DKE server to the tenant.

    double-key-encryption-dke-server-tenant

    To authorize a user to access the on-premises key, the source code uses 2 methods:

    Provide the LDAP path to the server and the group names, and the DKE server will be able to search if a user is a member of the allowed group.

    				
    					{
    "AllowedHosts": "*",
    "JwtAudience": "https://aadrm.com",
    "JwtAuthorization": "https://login.windows.net/common/oauth2/authorize",
    "RoleAuthorizer": {
      "LDAPPath": "If you use role authorization (AuthorizedRoles) then this is the LDAP path."
    },
    "TestKeys": [
      { 
        "Name": "YourTestKeyName",
        "Id": "GUID",
        "AuthorizedRoles": ["On premises Active Directory groups that you want to have access to this key. If you provide a value for AuthorizedRoles, then remove the line that starts with AuthorizedEmailAddress."],
        "AuthorizedEmailAddress": ["Email addresses of users that have access to this key. If you provide a value for AuthorizedEmailAddress, then remove the line that starts with AuthorizedRoles."],
        "PublicPem" :  "The public key in PEM format.  Do not include the BEGIN and END lines",
        "PrivatePem":  "The private key in PEM format.  Do not include the BEGIN and END lines"
      }
    
    				
    			

    Each key has a separate configuration for authorization, thus you can have different authorization for different labels.

    In MIP, for each DKE protected label, you must specify the path to the Key:

    https://your.dkeserver.com/YourKey

    dsk-server-yourkey

    How are the keys handled in the server?

    In this demo server, a simple public/private key in the app settings:

    				
    					"TestKeys": [
      { 
        "Name": "YourTestKeyName",
        "Id": "GUID",
        "AuthorizedRoles": ["On premises Active Directory groups that you want to have access to this key. If you provide a value for AuthorizedRoles, then remove the line that starts with AuthorizedEmailAddress."],
        "AuthorizedEmailAddress": ["Email addresses of users that have access to this key. If you provide a value for AuthorizedEmailAddress, then remove the line that starts with AuthorizedRoles."],
        "PublicPem" :  "The public key in PEM format.  Do not include the BEGIN and END lines",
        "PrivatePem":  "The private key in PEM format.  Do not include the BEGIN and END lines"
      }
    ]
    
    				
    			

    And the server uses this key to encrypt/decrypt:

    				
    					services.AddSingleton<ippw.IKeyStore, ippw.TestKeyStore>();
    				
    			

    Note: At this moment, this method is only for demo purposes, do not use it in production!

    Which kind of Key Type is used?

    				
    					    public class TestKeyStore : IKeyStore
        {
            private const string KeyType = "RSA";
            private const string Algorithm = "RS256";
    
    				
    			

    This demo server can be tuned to be used in a production environment, or third-party product like the new Thales one can be used as an appliance to interface with the new MIP DKE API:

    https://github.com/thalescpl-io/ms-dke-api

    3. Conclusion

    Microsoft has published the API for using DKE, and it has made available a sample source code to make a DKE server. This server is not usable “as-is” for a production environment, however editors with experience in Key Management such as Thales are already preparing the missing components that will soon enable the use of this option.

    DKE provides an answer to customers’ concerns about service provider access to data protected by a system like MIP/AIP, however it should be noted that this mechanism prevents the use of some important features of SaaS platforms that would need to access the data (such as eDiscovery, etc…).

    More information on this subject?

    We are at your disposal!