CPIX usage for embedding key in manifest

[kunalgoelgh]

@lpiron

This is an extension of issue #84 . Can you please help in understanding how to use CPIX for embedding key in manifest, and what role a dummy DRMId will play here.

Also, wanted to understand, if this will require changes on player\browser side? or is purely on the MPD.

Thanks for your help in advance !!

[lpiron]

If I understand correctly, you are trying to define a dummy DRM system that would provide the content key as part of the manifest, most probably in the clear. The player would just have to get it from the provided manifest. Looks like the perfect tool for content key sharing :-) CPIX is providing content key and DRM information from a key server (usually part of a DRM server) to a packager. It is in the form of a CPIX document. This document contains content keys (to be used for encrypting content) and the DRM information to be added "as is" in the manifest. Every DRM has defined its own data to be added (usually a mix of license server URLs and content key IDs but this is all opaque and proprietary). The packager then creates the MPD and copy/pastes the DRM information in the relevant place, as defined by DASH. The player extracts the DRM information and provides the DRM information to the DRM client. The DRM client can then either request a license or not (depends if it already has received what is needed) and it can then provision the descrambler with the content key. A dummy DRM client would certainly get the content key from the data received in the MPD and directly provision it in the descrambler. A you can understand, this requires writing a dummy DRM client for this and integrates with a player and app. For testing purposes, W3C Clearkey does it by providing the content key in the clear with a HTTP(S) request. Not sure one needs to do more than that in this case.

[kunalgoelgh]

@lpiron Thanks for the details.

Currently we are using ClearKey for delivering content key with a HTTP(S) request. However this requires an additional call to be made apart from fetching the MPD file.

What we are trying to understand, is if it possible for the MPD file to be self-contained. The CPIX documentation also calls out for content keys to be encrypted with Asymmetric encryption - in which case these will not be in the clear as well.

For clarification, 1) CPIX is additional data which is used by DRM to provide format in which tags are to be created, and what needs to be filled in PSSH element\tag? CPIX does not define any additional elements\encryption protocol to be used\specified outside the purview of the elements(2 kinds of elements created :- one withEncryption Scheme and default_KID, the other with urn:, where DRM specific tags are added)

2) In W3C ClearKey, as per documentation, it seems that we can only add a LaUrl tag to the ContentProtection element, which will trigger an HTTP(S) request to fetch content keys. Here, wanted to understand if there was a way to avoid this additional call, and provide content keys either in the clear OR encrypted with asymmetric encryption. (This additional call is not adding any additional security, as the Manifest fetch call can also be over HTTP(S)).

[lpiron]

CPIX provides 2 types of information to a packager, the content key and DRM data to be inserted in the MPD. The specification states that the content key should be encrypted but gives no guidance on the DRM data as it is expected the DRM will not provide the content key there. For a dummy DRM, a Key Server can create a >CPIX:ContentProtectionData> element that contains a ContentProtection element base64 encoded such as

actual value of the content key not encrypted/>

The packager will take this element and just add it to the MPD.

The player will receive the MPD, get this element, provide the data to the "DRM client" and this client just get the content key from this element, no need for a license request. There is a need for a DRM client managing this element in the player.

[lpiron]

Closing as this is not really an issue requesting changes in the document