“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
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)
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.
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.
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.
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].
Uniqueness:
Benefits:
Challenges:
Use MMK when:
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.
Uniqueness:
Benefits:
Challenges:
Use BYOK when:
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.
Uniqueness:
Benefits:
Challenges:
Use HYOK when:
How it works:
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.
Uniqueness:
Benefits:
Challenges:
Use a DKE when:
How it works:
Synopsis
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. |
|
|
|
|
Re-key your tenant key. |
|
|
|
|
Backup & recover your tenant key. |
|
|
|
|
Customers can export tenant keys. |
|
|
|
|
Microsoft can export tenant keys. |
|
|
|
|
Administrative Effort |
MMK |
BYOK |
HYOK* |
DKE |
Low |
|
- |
- |
- |
Moderate |
- |
|
- |
- |
High |
- |
- |
|
|
Table 3: Key options and licensing requirements:
License |
MMK |
BYOK |
HYOK* |
DKE |
AIP P1 |
|
|
|
|
AIP P2 |
|
|
|
|
M365 E3 |
|
|
|
|
M365 E5 |
|
|
|
|
Table 4: Applications Supported:
Applications Supported |
MMK |
BYOK |
HYOK* |
DKE |
One Drive |
|
|
|
|
SharePoint Online |
|
|
|
|
Exchange Online |
|
|
|
|
Microsoft 365 (Office 365 Word, Excel, PowerPoint) |
|
|
|
|
Microsoft 365 (Office 365 - Email) |
|
|
|
|
On-Premise Exchange |
|
|
|
|
On-Premise SharePoint |
|
|
|
|
Teams |
|
|
|
|
Table 5: Applications Supported:
Platform |
MMK |
BYOK |
HYOK* |
DKE |
Windows |
|
|
|
|
iOS |
|
|
|
|
Android |
|
|
|
|
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:
What are DKE License requirements?
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
[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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.