Request to detect PlayReady Hardware DRM

[avelad]

This is a enhancement request for detect PlayReady Hardware DRM. According to: http://playready.azurewebsites.net/Home/Hwdrm

PlayReady hardware DRM can also be leveraged in HTML5 MSE/EME web apps. To use PlayReady Hardware DRM, your JavaScript web app should query requestMediaKeySystemAccess new unprefixed EME method, or use isTypeSupported legacy prefixed EME method, both with a key system identifier of com.microsoft.playready.hardware to query for PlayReady hardware DRM support from the browse

[joeyparrish]

@avelad, can you help us understand more specifically what you want in terms of behavior?

Do you want us to add the .hardware variant to probeSupport()?

Do you want us to try .hardware in DrmEngine before trying without? (I recently heard from Microsoft that .hardware should not always be preferred, since some hardware implementations have a smaller feature set than software implementations.)

Do you want some configuration for this?

[avelad]

Yes, I want that you add com.microsoft.playready.hardware to probeSupport().With this I can set one or other url to the player (eg: 720p url or 2K/4K url). Add this to probeSupport should be easy, can you add it to 2.1.2 or 2.2.0?

I think that second option it's better but it's require more work. In this case it's necessary active this with a parameter on the config.

[joeyparrish]

I will experiment with this a little and let you know what we can do. Adding to probeSupport() is trivial, but may not be sufficient to make this variant of the key system ID usable.

[joeyparrish]

Here's one possible solution:

To request that we use com.microsoft.playready.hardware specifically, use that instead of com.microsoft.playready in your DRM config when you specify a license server. We will fail to play if that is not available.

A better solution would be to use robustness settings in the advanced DRM config. But I am not familiar with the specific robustness values Microsoft Edge supports. I will experiment with this a little.

[joeyparrish]

Edge does not seem to support robustness correctly. I filed a bug about this: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/12133118/

We could work around that bug, though.

The bigger issue with using robustness is that I am unable to guess which robustness strings are valid for Edge/PlayReady. I tried these with no luck: 1000, 2000, 3000, SL1000, SL2000, SL3000.

@avelad, do you know what Microsoft considers valid robustness values? I asked in the bug I filed, but it may be some time before I get a reply.

[avelad]

I do not know what values are possible, in the past I could not find any value that works, and the documentation is not clear.

I'm sure that Netflix knows the solution for this, because they have been implemented logic for 4K with high level of protection only on Edge, but I do not know the logic.

I thought a possible solution was to use probeSupport() and check if there are compability with hvc1 and com.microsoft.playready.hardware. With this, we load a stream that use com.microsoft.playready

[vladimir-kazakov]

I would like to request this feature as well, because the usage of PlayReady Hardware DRM is required for higher value content. It seems to me that there's no work happening on this feature, because there's no clear understanding how it must work. I'll try to clarify it.

PlayReady Hardware DRM is another key system that Shaka Player must support, which is com.microsoft.playready.hardware. It must be possible to specify this key system in the DRM configuration. For example:

player.configure({
  drm: {
    servers: {
      'com.microsoft.playready.hardware': 'https://drm-playready-licensing.axtest.net/AcquireLicense'
    }
  }
});

Currently, it doesn't work. I get the following error in the console:

load() failed: shaka.util.Error { "severity": 2, "category": 6, "code": 6012, "data": [], "handled": false, "message": "Shaka Error DRM.NO_LICENSE_SERVER_GIVEN ()", "stack": "Error: Shaka Error DRM.NO_LICENSE_SERVER_GIVEN ()\n at shaka.util.Error (https://example/shaka/2.3.3/js/shaka-player.compiled.debug.js:43:480)\n at Anonymous function (https://example/shaka/2.3.3/js/shaka-player.compiled.debug.js:119:320)" } Shaka Error DRM.NO_LICENSE_SERVER_GIVEN () Error: Shaka Error DRM.NO_LICENSE_SERVER_GIVEN () at shaka.util.Error (https://example/shaka/2.3.3/js/shaka-player.compiled.debug.js:43:480) at Anonymous function (https://example/shaka/2.3.3/js/shaka-player.compiled.debug.js:119:320)

Error code 6012 object shaka.util.Error { "severity": 2, "category": 6, "code": 6012, "data": [], "handled": false, "message": "Shaka Error DRM.NO_LICENSE_SERVER_GIVEN ()", "stack": "Error: Shaka Error DRM.NO_LICENSE_SERVER_GIVEN ()\n at shaka.util.Error (https://example/shaka/2.3.3/js/shaka-player.compiled.debug.js:43:480)\n at Anonymous function (https://example/shaka/2.3.3/js/shaka-player.compiled.debug.js:119:320)" }

I guess it happens because Shaka Player doesn't know anything about the com.microsoft.playready.hardware key system.

Robustness values in the advanced DRM configuration is not an option, because PlayReady doesn't use such concept. PlayReady clients have a security level property. Currently, there are 3 security levels defined: 150 (test clients), 2000 (clients that use software-based security; Software DRM) and 3000 (clients that use hardware-based security; Hardware DRM). It's possible to use security levels 150 and 2000 with the com.microsoft.playready key system, but 3000 is only available when using the com.microsoft.playready.hardware key system. The security level is a property of a PlayReady client, which depends on a key system that is being used. It's not possible to change the security level manually.

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 Hardware DRM. It's also important to mention that Hardware DRM doesn't work in virtual machines or when a remote desktop session is active.

In order to acquire a license, the client sends a license request to a license server. The client mentions its security level in the license request, so the security level is available to the license server. The license server uses this info to generate a license. The license has a "minimum security level" policy, which means that the client may use a license only if its security level is equal or higher than the minimum security level specified in the license. For example, if the license says that only clients with security level 2000 are allowed to use the license, then clients with security level 150 won't be able to use the license. In fact, the license server will even refuse to give such license to the client, because the client's security level is lower than what's required.

This all means that since Shaka Player doesn't support the com.microsoft.playready.hardware key system, it's impossible to acquire a license with a minimum security level 3000, which is a license that can only be used by highly-secure clients that use hardware-based security. Axinom's PlayReady license server allows requesting the minimum security level through the DRM message. You may try it by using the following info:

• Media: https://media.axprod.net/TestVectors/v7-MultiDRM-SingleKey/Manifest_1080p.mpd
• License server: https://drm-playready-licensing.axtest.net/AcquireLicense
• DRM message, specified in the X-AxDRM-Message HTTP header, that requests a license with a minimum security level 3000: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ2ZXJzaW9uIjoxLCJjb21fa2V5X2lkIjoiYjMzNjRlYjUtNTFmNi00YWUzLThjOTgtMzNjZWQ1ZTMxYzc4IiwibWVzc2FnZSI6eyJ0eXBlIjoiZW50aXRsZW1lbnRfbWVzc2FnZSIsImtleXMiOlt7ImlkIjoiOWViNDA1MGQtZTQ0Yi00ODAyLTkzMmUtMjdkNzUwODNlMjY2IiwiZW5jcnlwdGVkX2tleSI6ImxLM09qSExZVzI0Y3Iya3RSNzRmbnc9PSJ9XSwicGxheXJlYWR5Ijp7Im1pbl9hcHBfc2VjdXJpdHlfbGV2ZWwiOjMwMDB9fX0.KmKYAEpixHf6J_On65Q5w-Lkn6HkfwVFE-z5oJygssY

Sending a license request from a PlayReady client that has security level 2000 will result in the following error:

Status code: HTTP 500
Response body: License denied. Your DRM client's security level is 2000, but the entitlement message requires 3000 or higher.

Sending a license request from a client that has security level 3000 should result in a license response.

That's a lot of reading, but hopefully it clarifies how things are expected to work. I guess, for Shaka Player all these details are not very important, and it all boils down to simply adding support for another key system, which is com.microsoft.playready.hardware.

More info about PlayReady and EME can be found here.

It's also worth mentioning that supporting PlayReady Hardware DRM is important not only because of movie studio requirements, but also because Hardware DRM is required in order to use licenses with AES CBC keys. Microsoft is going to add support for cbc1 and cbcs protection schemes, defined in the CENC standard, to their PlayReady clients, and licenses with CBC keys can only be requested by clients that use Hardware DRM (their security level is 3000).

[avelad]

@joeyparrish is it possible add support to com.microsoft.playready.hardware key system?

[joeyparrish]

We will consider this in our next round of planning. Right now, v2.5 is quite full, and we will likely have to cut some features from that list to make our deadlines.

[joeyparrish]

In the mean time, we are happy to have someone in the community look into it and provide some suggestions on how it could be achieved, then work on a PR to that end. Thanks!

[swenkeratmicrosoft]

FYI: When using the com.microsoft.playready.recommendation key system string, you can explicitly request hardware DRM by setting the MediaKeySystemMediaCapability's "robustness" string to "3000" for the corresponding contentType. Of note, only certain contentType values support Hardware DRM - e.g. hardware DRM is never supported for any audio content; hardware DRM is only supported for HEVC content when the corresponding hardware, codec, and drivers are available; etc. When "3000" is specified for the "robustness" string and Hardware DRM is not supported for the given contentType, requestMediaKeySystemAccess will behave as defined by the W3C Recommendation 18 September 2017 specification as linked here:
http://www.w3.org/TR/2017/REC-encrypted-media-20170918/#navigator-extension:-requestmediakeysystemaccess()

Here is an example javascript code snippit that explicitly requests Hardware DRM for AVC1 video content. Only Software DRM is supported for audio streams, so the "robustness" string is not specified for the audio codec. (Obviously, because this code snippit only specifies a single MediaKeySystemConfiguration, the promise will be rejected if Hardware DRM is unavailable as per the EME specification.)

    navigator.requestMediaKeySystemAccess("com.microsoft.playready.recommendation", [
        {
            initDataTypes: ["cenc"],
            audioCapabilities: [
                {
                    contentType: "audio/mp4; codecs='mp4a'"
                }
            ],
            videoCapabilities: [
                {
                    contentType: "video/mp4; codecs='avc1'", robustness: "3000"
                }
            ],
            distinctiveIdentifier: "required",
            persistentState: "required"
        }
    ]).then( ...

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team

[avelad]

I think that the issue can be closed and follow up #1495

[GouravSna]

Hi,

Any help here is appreciable. Is there any way to detect playready hardware DRM ?
@avelad Did you find any solution ?

[swenkeratmicrosoft]

Using com.microsoft.playready.recommendation is strongly recommended. To request Hardware DRM, use the robustness string as indicated in my July 17, 2018 comment.

While com.microsoft.playready.hardware will technically request hardware DRM, it will also use the legacy EME implementation. That implementation is deprecated, and there are no plans to update it with bugfixes or feature improvements.

I hope this helps,
-Sam Wenker with the Microsoft PlayReady team