Microsoft 365 – Double Key Encryption service configuration

I decided to document technical details for possible future use which helped me to understand setup and operation of Double Key Encryption in M365.

• The article is about configuration details, omitting use cases and general information of the Microsoft information and compliance solutions. Background and recommended articles section is provided to cover interests outside of the configuration details.

Backround

Microsoft 365 offers encryption solution for use- cases where compliance requirements dictate that readable data should be only allowed for the owners of the data. This kind of data could be certain regulated or customer requirement satisfying data type, where Microsoft essentially holds encrypted blobs/files of the data, but never has the possibility to decrypt the data in back-end.

”Since Microsoft can access only one of these keys, protected data remains inaccessible to Microsoft, ensuring that you have full control over your data privacy and security.” (1)

• For further background I recommend reading following docs articles for licensing deployment, and use case information:

Recommended Articles

• What is Double Key Encryption for Microsoft 365 (DKE)?
• Overview of deploying DKE
• Azure-RMSDocs/how-does-it-work.md at master · MicrosoftDocs/Azure-RMSDocs (github.com)

High Level overview of DKE client and service operation

I constructed high-level picture from App Insights logs on the DKE service side, to help understand client and services communication.

• Please not this flow picture omits individual steps and guesstimates only the use of RSA key pair in client and server side

Notes about the setup

pre-existing understanding of M365 Compliance and information protection is highly recommended.

This is a test setup, which should not be used/tested in production.

Test setup is suited for using test tenant (m365 developer tenant for example) with pre-existing test data to get feel and understanding how the solution works. (Such is data used in this demo)

Pre-reqs

• M365 Tenant with appropriate licensing
• Possibility of deploying DKE service. The service should be reachable by clients, but in the deployment phase of the label, also M365 back-end needs to reach it to add the policy (This is the last instance where I saw the two back-ends communicate with each other)
  • In my test I deployed the DKE service to Azure Web App, obviously if you wanted ensure, that a cloud service would not be able to access the data and the services for DKE you would be using an on-premise solution.

Exception notes

I followed the guide here with following exceptions to my setup:

• After deployment I noticed that appInsights was giving statusCode 404 for client requests attempting to use the sensitivity label. The reason for this is that I had mistakelny provided https://fqdn type address in label settings. This effectively omitted, the key ”friendly name identifier” (”DKE” in my case), which the client needs to know to perform operations on the data.

• Later I populated the path with Key Id from appSettings.json to sensitivity label settings

• For Key-Rollover it would be interesting to document at some point how to do roll-over?Do I add new key object to ”TestKeys” array for example?

• The deployment article shows multiple deployment options. Since the application is .NET core you should be able to deploy it for both runtime platforms (Windows and Linux)
  • In my setup I opted for Windows, as it seems that my build defaults on VScode default for Windows.
  • Windows platform also provides the possibility of using the ZIPdeployUI, which is not available with Linux plans, though its also trivial using the app service rest api with Linux Apps
  • I mostly play around with NodeJS, so if you are deploying this setup I recommend going over the solution with proper .NET developer

Authorizing users

The setting for authorized users comes into play, when user wants to perform decrypt operations on encrypted data.

User is first authenticated in Azure Ad and processed for possible user assignment/ and conditional access policies. Then user is authorized in the dke service

• When user who is not part of the AuthorizedEmailAddress key in the appSettings.json, will result to 401 in the app logs, as the authorization will fail

• Encryption will still work, as it uses public key portion to encryption (RSA), which can be only then decrypted with the private key held in the service (That’s at least the flow I assume based by judging the app insights output)

• In order to allow user access the API for DKE service, the user must be authorized under ”TestKeys” – I opted for AuthorizedEmaillAddress, as its sufficient for testing.

• Below is git diff output on changes vs the original repo regarding the authorization

Client side setting

As outlined in the docs deployment article you need to use suitable client with registry keys added for testing the solutioin

Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSIPC\flighting]
@="DoubleKeyProtection"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\flighting]
@="DoubleKeyProtection"=dword:00000001

appsettings.json and Azure AD client settings

• I opted for multi-tenant app, which was not defined in the setup guidance, but a small hint that way exists due to the usage of common endpoint (new single tenant apps cant use common endpoint)
  • I plan to test sharing scenarios at some point

{
  "AzureAd": {
    "Instance": "https://login.microsoftonline.com/",
    "ClientId": "d8f9ba46-665e-4970-be6a-3fb79aa09695",
    "TenantId": "common",
    "Authority": "https://login.microsoftonline.com/common/v2.0",
    "TokenValidationParameters": {
      "ValidIssuers": [
        "https://sts.windows.net/3d6e366f-9587-413b-ab6b-0a851b1b91ba/"
      ]
    }
  },  
  "Logging": {
    "LogLevel": {
      "Default": "Information"
    },
    "EventLog": {
      "LogLevel": {
        "Default": "Information"
      }
    }
  },
  "AllowedHosts": "*",
  "JwtAudience": "https://dkesvc.azdv.work",
  "JwtAuthorization": "https://login.windows.net/common/oauth2/authorize",
  "RoleAuthorizer": {
    "LDAPPath": "If you use role authorization (AuthorizedRoles) then this is the LDAP path."
  },
  "TestKeys": [
    { 
      "Name": "DKE",
      "Id": "1892f247-8015-422b-b1b5-7b83af4894c3",
      "AuthorizedEmailAddress": ["admin@azdv.work", "AllanD@azdv.work", "Diego@azdv.work"],
      "PublicPem" :  "",
      "PrivatePem":  ""
    }
  ]
}

• Azure AD App registration for DKE API itself does not need permissions to Azure Information protection, as the client does the communication with Azure Information Protection service.
  • The API is only updated to allow certain client apps using using delegated permissions to request tokens

• On the logs you will see authorized clients using the DKE service

• Client use of the sensitivity label to my understanding is no different from any other sensitivity label utilizing encryption. I tested with API Client

• Office Client testing was done with Insiders version

Flow pic