Microsoft Purview Information Protection
Microsoft Purview Information Protection
Understanding the foundation of DKE encryption and decryption
Foundation: MPIP / Azure RMS
Understanding the standard MPIP/Azure RMS workflow is essential before diving into DKE specifics, as DKE builds upon this foundation.
Core Functionality
MPIP is fundamentally a client-side encryption technology that automates key management for end-users, simplifying protection compared to traditional PKI. It relies heavily on Microsoft Entra ID for user identity (using email addresses or User Principal Names) to control authorization.
Beyond encryption, it enforces usage restrictions (rights) – like preventing printing, restricting editing, or setting expiry dates – defined by the author or central policies (e.g., sensitivity labels).
Key Concept: These rights travel with the encrypted file.
Key Concepts & Components
| Component | Description |
|---|---|
| Microsoft Entra ID | Provides identity services and tenant isolation. User/group identities control authorization. |
| Purview Information Protection Service | Cloud service for managing sensitivity labels and protection settings |
| Azure Rights Management (Azure RMS) | Core cloud service holding the tenant's cryptographic keys and processing requests |
| Clients | Applications on user devices or authorized cloud service instances that interact with protected content |
| DKE Web Service | Customer-controlled component for Double Key Encryption (discussed separately) |
Standard Encryption Process (MPIP/Azure RMS)
This describes how content is protected without DKE, using only the Microsoft-managed key:
Label Application
A user applies a sensitivity label configured for encryption in an RMS-aware application (e.g., Word).
Content Key Generation
The application generates a unique symmetric AES key (Content Key) in memory for this specific document (tied to its documentID).
File Encryption
The application encrypts the document content stream using this unique Content Key.
Publishing License (PL) Creation
The application creates a Publishing License (PL). This XML structure contains the Content Key, the usage rights/permissions defined by the label or author, and other metadata.
PL Encryption & Embedding
The application encrypts the sensitive parts of the PL (most importantly, the Content Key) using the Azure RMS tenant's public key (retrieved and cached from the Azure RMS service). The encrypted PL is then embedded within the document file structure.
Steps 2-4 occur locally within the application's memory.
Some metadata within the PL, like the URL of the tenant's Azure RMS service, remains unencrypted to allow clients to find the correct service.
Standard Decryption Process (MPIP/Azure RMS)
This describes how authorized users or services access content protected without DKE:
Open Attempt & Service Discovery
A user opens the protected document in an RMS-aware application. The application reads the Azure RMS service URL from the unencrypted part of the PL.
Authentication & GIC
The user authenticates to the Azure RMS service via Microsoft Entra ID. If it's the user's first interaction with RMS, the service provisions a user-specific RSA key pair (Global Identity Certificate (GIC)). The GIC private key is stored securely in the user's local profile; the public key is known to RMS.
License Request
The application sends the encrypted PL (not the full file) and proof of the user's identity (including their GIC public key) to the Azure RMS service identified in step 1.
Authorization Check
Azure RMS validates the user's identity against the permissions defined in the PL, potentially checking Microsoft Entra ID group memberships or other attributes. It determines the user's effective rights for this specific document (permissions are additive if granted via multiple groups).
Use License (UL/EUL) Issuance
If authorized, Azure RMS uses its tenant private key to decrypt the Content Key from the PL. It then creates an End User License (EUL), also known as a Use License. The EUL contains the decrypted Content Key and the user's specific effective permissions. This EUL is then encrypted using the user's public GIC key.
Content Decryption & Enforcement
The application receives the encrypted EUL. It uses the user's private GIC key (stored locally) to decrypt the EUL, thereby retrieving the Content Key. The application then uses the Content Key to decrypt the actual document content and simultaneously enforces the permissions specified in the EUL (e.g., allowing viewing but disabling printing or copying).
Note on Service Access
Authorized Cloud Services
This RMS flow isn't limited to end-user applications. Authorized cloud services can also act as RMS clients:
Exchange Online
Transport rules
DLP Services
Data Loss Prevention
eDiscovery
Microsoft Purview
Microsoft Copilot
AI services
They authenticate to Azure RMS, obtain a Use License if permitted, and decrypt content to perform their functions on the clear text data.
Important — this does not apply to DKE-protected content. Because DKE requires the customer-held second key, Microsoft cloud services (including Copilot, content search, eDiscovery and Office web apps) cannot decrypt or access DKE-protected content. The behavior above applies to standard Azure RMS / sensitivity-label content only.