Generate A Test Key From Playready Test Server

admin
Generate A Test Key From Playready Test Server
  1. Legacy Syntax Documentation. Parameters are entered in the query string, separated by semi-colons and ampersand characters. This syntax was introduced in 2008 for PlayReady 1.0, extended in 2010 for PlayReady 2.0, extended in 2015 for PlayReady 3.0, and supports only a sub-set of the PlayReady.
  2. Licensing Options Microsoft offers a flexible business model that supports a variety of scenarios regardless of whether you are shipping devices, offering live TV to end customers, operating a back-end service, or manufacturing a PlayReady-enabled silicon solution for devices.
  3. In order to be able to use PlayReady Hardware DRM (the com.microsoft.playready.hardware key system), you have to use the latest Windows 10 and your hardware must have a Trusted Platform Module (TPM) 2.0. Both Edge and Internet Explorer support this key system. You can use the Hardware DRM test page in order to check whether your system supports.
  4. Azure Media Services Java SDK adds support for Content Protection feature Tuesday, August 25, 2015. We are pleased to announce a new update including new features allowing you to easily configure AES and PlayReady dynamic encryption for VOD or Live with Java SDK.
  5. PlayReady 3.X Test Content This section contains a collection of test content that can be used to validate some PlayReady 3.X scenarios, for example using the WRMHEADER v4.2 and with audio and video tracks protected with different content keys.

Azure Media Services Test Content. This section contains some test content encoded and packaged with Microsoft Azure Media Services. You can also easily create your own test content with Azure Media Services.

-->

Every media file protected by PlayReady has a PlayReady Object (PRO), which contains several pieces of information that PlayReady needs. This is located in the file's content header which, for example, might also contain metadata for the video and audio tracks.

Within each PRO is a PlayReady Header, which gives a client the information needed to locate or acquire a license for the piece of content in which it's stored. The PlayReady Header looks something like this:

The part that interests us is the <KIDS> element, which contains one or more <KID> elements. A KID (Key ID) contains a globally unique identifier (GUID) that the client uses to ask the Server for a corresponding key, and an ALGID, which is then used to decrypt the file. The KID is public, since it's contained in the PRO, but the key itself is a secret to the service, and the relationship between key and KID is known only to the service.

Generate a key and encrypt the content

Content encryption keys in PlayReady systems are AES-128 CTR and AES-128 CBC keys. The service that encrypts the content generates a new KID and a new content key. The KID is inserted into the PRO, and the video and audio frames of the content are encrypted with the content key. The following image shows how a key is generated, and then used to encrypt content.

There are two ways to generate a KID and key, including:

  • Using a Key Management System (KMS), where the service randomly generates each KID and key value and stores them, and can simply look up the key value that corresponds to the KID provided by the client.
  • Using the PlayReady Key Seed mechanism. With this mechanism, the service determines a constant value called the key seed (a 30-byte random value), and for each piece of content that requires a key, generates a random KID. Using the Server SDK, you can generate a key by providing the 128 bits of the key, or the key seed and KID. The key will be inferred by a PlayReady algorithm specified here.

No matter how you generate the key, you must be able to verify that it corresponds to the correct KID and then encrypt the content.

Deliver a license for the content

When a client makes a license request, it sends the content's PlayReady Header to the license issuer. The license issuer extracts the KID and determines the corresponding key value, using one of the methods described above—if it uses the key seed mechanism, it just regenerates the key based on the KID and key seed. Then it generates a license including this key, which it sends back to the client in a license response.

For example, let's say you have a video file. The packager for this content generates a random KID 123, which it inserts into the file's PlayReady Header. The packager also generates a random key value ABC to correspond with the KID 123, and stores them both in the KMS. The packager asks the KMS for the correct key to encrypt the file with, and encrypts the file with the key ABC. When the customer tries to play the file, the client asks the license issuer for a license that corresponds to the KID 123. The license issuer looks up the KID in the KMS, and responds with a license including the key ABC, which allows the client to unlock the file, and the customer to watch it.

Note

The license sent by the license issuer to the client (in our example, the license containing the key ABC) is encrypted; an attacker can't intercept the key value.

The key used to protect the media file and the key in the license are the same; therefore, the content packager and the license issuer must both be able to retrieve or generate the exact same key for a specified media file. To accomplish this, if you're using a key seed to generate keys, you must share it between the content packager and the license issuer.

Sharing keys between files or tracks

Just as a real key can unlock more than one door, it is technically possible to use one PlayReady key to unlock multiple tracks in one file, or even multiple files in a collection of assets. During the packaging process, the content packager can specify the same key identifier for multiple tracks or multiple media files, and the same key is used for them all.

For example, with a multi-quality video asset with 4K, HD, and SD video tracks and several audio tracks, the encryptor has the flexibility to define one key per track, or one key for all the tracks.

Clients will need a license for each of the keys that they have the right to decrypt. Note that delivering multiple licenses can be done by a License Server in a single license response.

In a single asset with multiple tracks, the decision between one key for all tracks or a key for each track is done by the service managing the content, and based on the following criteria:

  • More keys brings more complexity but allows you to specify at license delivery time what tracks the service wants to allow a particular client to decrypt.
  • Less keys is less complex but does not allow you to specify at license delivery time what tracks the service wants to allow a particular client to decrypt.
  • Some clients may have the limitation that they do not support multiple keys for a single asset.

Note

While PlayReady keys can unlock more than one digital media file, Microsoft is strongly against this. /passport-photo-maker-key-generator.html. Using unique keys across all files provides greater security than protecting files with the same key.

Stacking licenses in a license response

Generate A Test Key From Playready Test Server Ip

A single license response can also carry multiple licenses and thus multiple keys to unlock multiple files or tracks in one transaction. This is more efficient than creating multiple responses for multiple licenses, since it only involves one transaction. This can be useful for different scenarios:

  • One media file is encrypted using multiple keys. For example, the video track is encrypted using Key1, and the audio track is encrypted using Key2. When a client requests a license for KID1, the License Server issues a license response including licenses for KID1 and KID2, so the client has all the keys to decrypt the video and audio tracks of the file.
  • Each song on an album is encrypted using a different key, but a customer has acquired the rights for all of them. When the customer starts playing the first song, the License Server issues a license response including one license for each song on the album, so the client has all the keys needed to play the entire album seamlessly.
  • The key for a channel on live TV is expected to change every 24 hours. When playback starts, the Server sends a license response including the license for the current key, but also a license with the next key, so when the key changes, the client will already have the next key and the change happens seamlessly.

See also

License Server


The PlayReady Public Test Server available http://test.playready.microsoft.com/service/rightsmanager.asmx unconditionally delivers to clients licenses with customizable rights and right restrictions, by providing parameters as arguments to the license request.The client can specify the rights requested in the returned license(s) by providing a set of parameters in the query string, or in the request headers.The PlayReady Public Test Server now supports multiple syntaxes to provide these parameters so testers can chose the one most appropriate to their case.

The recommended syntax is the Query String Syntax.

Reference for the rights and right restrictions

The full description of the rights and right restrictions is published in the [PlayReady Compliance and Robustness Rules](http://www.microsoft.com/playReady/licensing/compliance).
### Test Key Seed - common to all syntaxesUnless the LA URL includes a custom Key Seed to be used (e.g. by using the parameter `keyseed:VB8xp/ZsROLmaEu3Zyug4DH0r0MmA/tTcmFMBEqL`), the key seed used is the Test Key Seed given below:

/rainbow-six-siege-pc-cd-key-generator.html. Test Key Seed (bytes) = { 0x5D, 0x50, 0x68, 0xBE, 0xC9, 0xB3, 0x84, 0xFF, 0x60, 0x44, 0x86, 0x71, 0x59, 0xF1, 0x6D, 0x6B, 0x75, 0x55, 0x44, 0xFC, 0xD5, 0x11, 0x69, 0x89, 0xB1, 0xAC, 0xC4, 0x27, 0x8E, 0x88 };

Test Key Seed (bytes Base64) = 'XVBovsmzhP9gRIZxWfFta3VVRPzVEWmJsazEJ46I'

Query String Syntax

Examples:

http://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(begindate:20151201,expiration:20171230)

http://test.playready.microsoft.com/service/rightsmanager.asmx?cfg=(kid:B6E39626-1CFB-4AA1-BCBD-4EF1ABA7843A,sl:3000),(kid:7C9484BA-C238-467A-869C-CDD8C7167712,sl:2000)

Parameters are entered in the query string, separated by commas and brackets. This syntax was introduced in 2017 to fully support PlayReady 3 functionalities:

  • Similar to a JSON syntax (not real JSON though)
  • Easy to read and edit
  • Does not include unsafe characters (like ampersand) and should not require escaping any of them
  • Note: the query string must not include any space characters (' ')
  • Note: '+' characters are acceptable in the base64 encoded arguments
  • Allows to requests for multiple licenses in one licnese response, and set parameters for each of them.
  • Example: video track encrypted with one key set at SL3000, and audio track encrypted with another key set at SL2000.
  • New date time format yyyymmdd (example: 20171231) and allows set hours, minutes and seconds: yyyymmdd[hhmmss] (example: 20171231235959)

See the full documentation here.

CustomData JSON Syntax

Example: http://test.playready.microsoft.com/service/rightsmanager.asmx

with CustomData = 'json=[{'kid':'B6E39626-1CFB-4AA1-BCBD-4EF1ABA7843A','sl':'3000'},{'kid':'7C9484BA-C238-467A-869C-CDD8C7167712','sl':'2000'}]'

Parameters are entered in a JSON blob added to the LicenseRequest.CustomData node:

  • Pure JSON syntax
  • Allows to requests for multiple licenses in one license response, and set parameters for each of them.
  • Allow all sorts of properties and combinations of rights and right restrictions
  • Require the client to be able to insert data in LicenseRequest.CustomData

See the full documentation here.

Base64 JSON Syntax

Example: http://test.playready.microsoft.com/service/rightsmanager.asmx?cfg64=W3sna2lkJzonQjZFMzk2MjYtMUNGQi00QUExLUJDQkQtNEVGMUFCQTc4NDNBJywnc2wnOiczMDAwJ30seydraWQnOic3Qzk0ODRCQS1DMjM4LTQ2N0EtODY5Qy1DREQ4QzcxNjc3MTInLCdzbCc6JzIwMDAnfV0=

Parameters are entered in a JSON blob which is base64 encoded and provided in the query string:

  • Pure JSON syntax
  • Not that easy to read and edit though
  • Does not include unsafe characters and should not require escaping any of them
  • Allows to requests for multiple licenses in one license response, and set parameters for each of them.
  • Allow all sorts of properties and combinations of rights and right restrictions
  • Allows to insert customdata values in the query string
  • Does not require the client to be able to insert data in LicenseRequest.CustomData
  • Note: '+' characters are acceptable in the base64 encoded string

See the full documentation here.

Legacy Syntax - inherited from `http://playready.directtaps.net/`

Playready Test Site

Example: http://test.playready.microsoft.com/service/rightsmanager.asmx?PlayRight=1&FirstPlayExpiration=60&UncompressedDigitalVideoOPL=270

Parameters are entered in the query string, separated by semi-colons and ampersand characters. This syntax was introduced in 2008 for PlayReady 1.0, extended in 2010 for PlayReady 2.0, and supports only a sub-set of the PlayReady 3.X features:

  • Inherited from and compatible with the previous test server hosted on http://playready.directtaps.net/rightsmanager.asmx
  • The '&' character in the LA URL isn't well supported by XML parser, so for inclusion as a LA_URL value in a WRMHEADER (media file header or media stream header), you have to escape this character
  • Example: http://test.playready.microsoft.com/service/rightsmanager.asmx?PlayRight=1&amp;UseSimpleNonPersistentLicense=1
  • Limited possibilities (one license only)
  • 'US' date format: mm/dd/yyyy (example: 12/31/2017)

See the full documentation here.

Playready Test Page