Content protection overview
Update your Azure Media Services REST API and SDKs to v3 by 29 February 2024. Version 3 of Azure Media Services REST API and client SDKs for .NET and Java offers more capabilities than version 2. We’re retiring version 2 of the Azure Media Services REST API and client SDKs for .NET and Java.
Action Required: To minimize disruption to your workloads, review the migration guide to transition your code from the version 2 API and SDKs to version 3 API and SDK before February 29th, 2024. After February 29th, 2024, Azure Media Services will no longer accept traffic on the version 2 REST API, the ARM account management API version 2015-10-01, or from the version 2 .NET client SDKs. This includes any 3rd party open-source client SDKS that may call the version 2 API. Learn about the latest version, starting with the Media Services v3 Overview.
You can use Azure Media Services to secure your media from the time it leaves your computer through storage, processing, and delivery. With Media Services, you can deliver your live and on-demand content encrypted dynamically with Advanced Encryption Standard (AES-128) or any of the three major digital rights management (DRM) systems: Microsoft PlayReady, Google Widevine, and Apple FairPlay. Media Services also provides a service for delivering AES keys and DRM (PlayReady, Widevine, and FairPlay) licenses to authorized clients.
The following image illustrates the Media Services content protection workflow:
This article explains concepts and terminology relevant to understanding content protection with Media Services. The article also provides links to articles that discuss how to protect content.
You can use Media Services to deliver your content encrypted dynamically with AES clear key or DRM encryption by using PlayReady, Widevine, or FairPlay. If content is encrypted with an AES clear key and is sent over HTTPS, it is not in clear until it reaches the client.
Each encryption method supports the following streaming protocols:
- AES: MPEG-DASH, Smooth Streaming, and HLS
- PlayReady: MPEG-DASH, Smooth Streaming, and HLS
- Widevine: MPEG-DASH
- FairPlay: HLS
Encryption on progressive downloads is not supported.
To encrypt an asset, you need to associate an encryption content key with your asset and also configure an authorization policy for the key. Content keys can be specified or automatically generated by Media Services.
You also need to configure the asset's delivery policy. If you want to stream a storage-encrypted asset, make sure to specify how you want to deliver it by configuring the asset delivery policy.
When a stream is requested by a player, Media Services uses the specified key to dynamically encrypt your content by using AES clear key or DRM encryption. To decrypt the stream, the player requests the key from Media Services key delivery service. To decide whether or not the user is authorized to get the key, the service evaluates the authorization policies that you specified for the key.
AES-128 clear key vs. DRM
Customers often wonder whether they should use AES encryption or a DRM system. The primary difference between the two systems is that with AES encryption the content key is transmitted to the client in an unencrypted format ("in the clear"). As a result, the key used to encrypt the content can be viewed in a network trace on the client in plain text. AES-128 clear key encryption is suitable for use cases where the viewer is a trusted party (for example, encrypting corporate videos distributed within a company to be viewed by employees).
PlayReady, Widevine, and FairPlay all provide a higher level of encryption compared to AES-128 clear key encryption. The content key is transmitted in an encrypted format. Additionally, decryption is handled in a secure environment at the operating system level, where it's more difficult for a malicious user to attack. You should use DRM when the viewer might not be a trusted party and you require the highest level of security.
You can use storage encryption to encrypt your clear content locally by using AES 256-bit encryption. You then can upload it to Azure Storage, where it's stored encrypted at rest. Assets protected with storage encryption are automatically unencrypted and placed in an encrypted file system prior to encoding. The assets are optionally re-encrypted prior to uploading back as a new output asset. The primary use case for storage encryption is when you want to secure your high-quality input media files with strong encryption at rest on disk.
To deliver a storage-encrypted asset, you must configure the asset's delivery policy so that Media Services knows how you want to deliver your content. Before your asset can be streamed, the streaming server decrypts and streams your content by using the specified delivery policy (for example, AES, common encryption, or no encryption).
Types of encryption
PlayReady and Widevine utilize common encryption (AES CTR mode). FairPlay utilizes AES CBC-mode encryption. AES-128 clear key encryption utilizes envelope encryption.
Licenses and keys delivery service
Media Services provides a key delivery service for delivering DRM (PlayReady, Widevine, FairPlay) licenses and AES keys to authorized clients. You can use the Azure portal, the REST API, or the Media Services SDK for .NET to configure authorization and authentication policies for your licenses and keys.
Control content access
You can control who has access to your content by configuring the content key authorization policy. The content key authorization policy supports either open or token restriction.
With an open authorization policy, the content key is sent to any client (no restriction).
With a token-restricted authorization policy, the content key is sent only to a client that presents a valid JSON Web Token (JWT) or simple web token (SWT) in the key/license request. This token must be issued by a security token service (STS). You can use Azure Active Directory as an STS or deploy a custom STS. The STS must be configured to create a token signed with the specified key and issue claims that you specified in the token restriction configuration. The Media Services key delivery service returns the requested key/license to the client if the token is valid and the claims in the token match those configured for the key/license.
When you configure the token restricted policy, you must specify the primary verification key, issuer, and audience parameters. The primary verification key contains the key that the token was signed with. The issuer is the secure token service that issues the token. The audience, sometimes called scope, describes the intent of the token or the resource the token authorizes access to. The Media Services key delivery service validates that these values in the token match the values in the template.
Token replay prevention
The Token Replay Prevention feature allows Media Services customers to set a limit on how many times the same token can be used to request a key or a license. The customer can add a claim of type
urn:microsoft:azure:mediaservices:maxuses in the token, where the value is the number of times the token can be used to acquire a license or key. All subsequent requests with the same token to Key Delivery will return an unauthorized response. See how to add the claim in the DRM sample.
- Customers must have control over token generation. The claim needs to be placed in the token itself.
- When using this feature, requests with tokens whose expiry time is more than one hour away from the time the request is received are rejected with an unauthorized response.
- Tokens are uniquely identified by their signature. Any change to the payload (for example, update to the expiry time or the claim) changes the signature of the token and it will count as a new token that Key Delivery hasn't come across before.
- Playback fails if the token has exceeded the
maxusesvalue set by the customer.
- This feature can be used for all existing protected content (only the token issued needs to be changed).
- This feature works with both JWT and SWT.
If your asset was encrypted with more than one DRM, use an encryption tag in the streaming URL: (format='m3u8-aapl', encryption='xxx').
The following considerations apply:
No more than one encryption type can be specified.
Encryption type doesn't have to be specified in the URL if only one encryption was applied to the asset.
Encryption type is case insensitive.
The following encryption types can be specified:
- cenc: For PlayReady or Widevine (common encryption)
- cbcs-aapl: For FairPlay (AES CBC encryption)
- cbc: For AES envelope encryption