cta-wave / device-playback-task-force

9 stars 0 forks source link

TCTF request for comment on device playback testing of DRM content #27

Closed andyburras closed 5 years ago

andyburras commented 6 years ago

The following has been added to the draft TCTF Test Approach document regarding WAVE DRM and encrypted content testing. Does …. have any comments or objections to this approach?

TCTF are assuming that some aspects of DRM testing are in scope for WAVE conformance testing.

TCTF believe that testing a device’s full compliance with particular DRM schemes is not in scope. Similarly testing WAVE content is fully complaint with particular DRM schemes is not in scope. Such compliance testing is the responsibility of other bodies.

Currently the DCPTF specification contains a placeholder under Single-Track Media Playback Requirements: 8.16 Playback of Encrypted Content

And under Configurations: 16.2 Encryption A WAVE device shall support at least one of the two encryption modes: “cenc” or “cbcs”. A WAVE device should support both encryption modes: “cenc” and “cbcs”.

Note there may also be further requirements.

In the market place, the principle DRM systems currently deployed appear to be: • Apple Fairplay • Google Widevine Modular • Marlin • Microsoft PlayReady • … others?

Different browsers support different combinations of these systems. Browsers based on the same code-base may even have different support depending on whether they are built for e.g. desktop, mobile or TV/STB device.

Devices may only support one or two of the above DRM systems. Therefore, it is anticipated that the testing will need to provide an environment for all four (or more?). Furthermore, as a device is only required to support cenc OR cbcs encryption then there are additional permutations. Some permutations are unlikely in the market place, for e.g. currently ‘cenc’ mode with Fairplay. TBD which permutations should be covered.

Testing entire DRM schemes is out of scope for WAVE. However, we need to test that a device can at least successfully playback DRM protected content, and possibly other requirements that DPCTF identify.

The requirements on the testing environment are access to a license server that will provide a suitable test license(s) for:

General requirements for the DRM testing materials are a variant of media for each DRM testable requirement for each scheme/mode combination that has been identified. Each to be signed with the appropriate DRM scheme’s test license. NOTE: for their actual implementation it may be possible to combine multiple schemes within a single test media.

KilroyHughes commented 6 years ago

For content conformance, Common Encryption packaging and accurate application of the encryption scheme are the two tests needed. The first requires checking that CENC boxes and fields are valid types, ranges, self-consistent, etc. Browsers and Devices should also implement the decryption algorithm correctly, which is best determined by successful decryption of allowed features, such as full sample, NAL structured subsamples, sample groups that indicate clear and encrypted Fragments and key rotation.

The second test is best accomplished by decryption on a known-good clear key decryptor or DRM system. A tester can view decoded output of a DRM system, but a clear key decryptor can provide a decrypted compressed bitstream for binary comparison to the original bitstream before encryption.

Apps, browsers, and devices containing DRM are all involved in DRM key management, including detecting when new keys/licenses are needed, forming license request messages, passing license messages and licenses from application to CDM. The EME interface is necessary for Type 3 applications. A device installed player (Type 1) can use EME, or exchange messages directly with an Auth server via HTTPS, or other protocols (such as broadcast).

DASH IF has test cases consisting of content encrypted with test keys, and license servers that will offer test licenses for several DRM systems so key management systems can be tested.

Note that real world DRM systems start with an Authentication and Authorization process in a service provider's Auth server (to identify the content requested, and the customer requesting to determine if they have ownership, rental rights, a subscription, a location, etc. that entitles them to that content on that device or DRM domain). DRM only provides enforcement of that proprietary business logic, and it is becoming rare for service providers to host their own license servers. If a particular device and content are authorized, then a DRM license server or service can be instructed by the Auth server to generate a license with specific rights bound to a client key and containing the necessary media key(s). Devices must correctly pass Access Tokens and request redirection in some cases to perform authorization of license requests.