Skip to content

Commit 113ff17

Browse files
authored
Merge pull request #107923 from Juliako/patch-6
Update media-services-content-protection-overview.md
2 parents d1a97b3 + 2621872 commit 113ff17

File tree

1 file changed

+16
-0
lines changed

1 file changed

+16
-0
lines changed

articles/media-services/previous/media-services-content-protection-overview.md

Lines changed: 16 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -49,6 +49,9 @@ Customers often wonder whether they should use AES encryption or a DRM system. T
4949

5050
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. DRM is recommended for use cases where the viewer might not be a trusted party and you require the highest level of security.
5151

52+
> [!NOTE]
53+
> If content is encrypted with a clear key and it is sent over HTTPS, the content is not in clear until it reaches the client.
54+
5255
## Storage encryption
5356
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.
5457

@@ -71,6 +74,19 @@ With a token-restricted authorization policy, the content key is sent only to a
7174

7275
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.
7376

77+
### Token replay prevention
78+
79+
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](https://github.com/Azure-Samples/media-services-v3-dotnet-tutorials/blob/master/AMSV3Tutorials/EncryptWithDRM/Program.cs#L601).
80+
81+
#### Considerations
82+
83+
* Customers must have control over token generation. The claim needs to be placed in the token itself.
84+
* 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.
85+
* 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.
86+
* Playback fails if the token has exceeded the `maxuses` value set by the customer.
87+
* This feature can be used for all existing protected content (only the token issued needs to be changed).
88+
* This feature works with both JWT and SWT.
89+
7490
## Streaming URLs
7591
If your asset was encrypted with more than one DRM, use an encryption tag in the streaming URL: (format='m3u8-aapl', encryption='xxx').
7692

0 commit comments

Comments
 (0)