key rotation support where PSSH exists also in the MPD

[meladc]

• Shaka version used - 2.2.5, on Chrome, Windows 7/10

• When playing DASH live streaming with key rotation, where PSSHs exist in the MPD, shaka player ignores PSSH signaling in the media segments, and does not raise license requests upon key change.
  When manually removing the PSSH from the MPD - Shaka raise the license requests properly.

• This issue is opened based on feedback from the CWIP discussion group and confirmation from Shaka dev team that Shaka player indeed ignores PSSH information from media segments when PSSH info is included in the MPD..

• The issue relies upon the following resources:
  Quote from the DASH spec - ISO/IEC 23001-7:2016, section 11.3.3 :
  "An MPD will normally be processed before Media Segments are downloaded, so license acquisition information in an MPD will normally take precedence over information stored in ‘pssh’ boxes."

• In addition, DASH-IF-IOP-V4.0 (http://dashif.org/wp-content/uploads/2016/12/DASH-IF-IOP-v4.0-clean.pdf), section 7.5.3.1 recommends to include first key rotation PSSHs in the manifest in a way that implies that both MPD and media segments PSSHs can be processed in the same playback session.

• The expected behavior is that Shaka will use both PSSH info from the MPD and from the media segments, despite the somewhat confusing language of the DASH spec.

[joeyparrish]

Is there any guidance in the DASH spec or IOP on signalling key rotation? If so, we can use that signal to make sure we listen for media PSSHs.

Otherwise, there's no clear way for us to do what you're asking and still do the right thing on VOD content.

[sandersaares]

DASH-IF IOP states that a change in content key requires a new period to be created, enabling you to provide any new initialization data in the MPD. I believe the current interpretation is smeared across different points but there is a change enqueued for vNext to be even more explicit about this.

One exception is when hierarchical keys are used - the leaf keys may be changed within a period, although a new root key will still require a new period to be created. Presumably, for leaf key rotation there would be PSSHs in the media segments which the CDM would use for obtaining the input data for leaf key rotation. This must all be invisble to the player (the DASH layer just deals with the root keys in hierarchical key scenarios and any activity with leaf keys is purely in the domain of the CDM).

As implementations of hierarchical keys are sparse and the relevant sections in IOP have not had as many eyes on them as the others, the wording in IOP with regard to them could probably benefit from clarification. I believe EME interactions in a hierarchical key scenario are also not well explored (naively, I would expect each PSSH in a media segment to raise encrypted and the player to thereby feed this PSSH to generateRequest() and for this all to not result in any license request but just the CDM internally rotating the leaf key).

Is the context here regular key rotation or leaf key rotation in a hierarchical key scenario?

[meladc]

@sandersaares – the context is standard key rotation and not an hierarchical one.
DASH-IF IOP v4.0 refers to it as periodic re-authorization (section 7.5) and describes multiple implementation options, one of which (7.5.3.2) is to use a DASH period as the minimum period for key duration. This is not to say that key rotation must use a new period, as another described option talks about providing future keys in PSSH without relation to periods (7.5.3.3). Key hierarchy is mentioned as a third implementation option, but there might be more options, for example – if the license server has the logic to know what keys to return regardless of the PSSH info, etc.

@joeyparrish – I’m not sure that I understand the question.
If I understand Shaka’s current implementation, then it looks for a PSSH in the MPD, and

• if found - does not listen to the PSSH events coming from media segments.
• If there is no PSSH in the MPD, then Shaka listens to PSSH events from the media segments while filtering duplicated PSSHs based on binary/string comparison.

What I would suggest is to always listen to PSSH events from the media segments, but to keep filtering them if the PSSH is identical to the one from the MPD. DASH CENC spec notes that cenc:pssh element in the MPD needs to have identical structure to the one in the media segments, so such filtering can take place.

As VOD is less subject to key rotation, and as all content (including required keys) can be assumed known in advance, Shaka may choose to apply an optimization for VOD, taking into account only the PSSH information from the MPD. This optimization may raise issues if assumptions don’t hold.

[sandersaares]

The option of providing future keys described by DASH-IF IOP does not eliminate the need to signal those future key changes in the way documented in IOP. It is an additional feature on top of the regular DRM interactions, to help players retrieve keys in advance, and does not replace the more basic use cases nor remove the need for any signaling that would otherwise be present.

if the license server has the logic to know what keys to return regardless of the PSSH info, etc.

All required content keys (root keys in case of hierarchical keys) must be signaled in the manifest for the content to conform to DASH-IF IOP. If there is some hidden logic that drives the license server to send some keys that were not signaled in the manifest then that is not an ineroperable scenario. See IOP 4.1 section 7.7.9, where the basic expectations are outlined (basically, the default_KID is the focus of all key management interactions on the DASH layer).

I agree with your statement that PSSHs in the media segments ought to be passed to EME but this is would be to serve hierarchical key scenarios, not as a replacement for regular key rotation signaling (at least as far as compatibility with DASH-IF IOP is desired). I imagine there are also browser compatibility concerns there (hierarchical keys are not (yet?) used much in practice, so it is likely an area with plenty of unresolved issues). After all, I assume there are good reasons this is not done currently (or at least, is done with some filtering logic).

To emphasize the keyid-period relationship, I would also direct you to IOP 4.1 7.7.6 which says:

If a new license is needed and cenc:default_KID is to be changed, it SHALL be at the beginning of a Period

[meladc]

So if I understand correctly, what you say is -

1. PSSH events in the stream are only meant for hierarchical key scenarios.
2. They must be related to already pre-fetched root licenses, and
3. They should not trigger a license request in no circumstances (as the PSSH from the MPD will trigger it).

Maybe this is not the right forum to ask, but I am wondering if this is the common understanding of how DASH/CENC should work.

[sandersaares]

Yes, I would say those three points accurately describe my interpretation of IOP guidelines.

Similar questions used to come up in DASH-IF context more often a few years back when there were not many companies implementing IOP. This has changed and IOP tends to be quite popular these days, as it has become obvious that following IOP helps keep development costs down. I have noticed a decrease in the amount of such DRM related questions, so presumably this means that there is something of a common understanding in place by now.

As with any voluntary guidelines, it always depends on how much product authors care about IOP. Certainly, DASH allows all sorts of mechanisms that are outside the scope of things allowed by IOP. This is pretty much the reason IOP was created - to create some common interpretation of a reasonable feature set that can serve common needs in a generic way.

[TheModMaker]

@kqyang @joeyparrish

This seems to be against how standard Widevine key rotation works. IIRC, Shaka Packager sets the default_KID and the tenc box to all 0's and uses the per-frame key ID property to signal what key to use to decrypt. The content is in a single Period, but different frames may be encrypted using different keys. Then each media segment contains a pssh box to signal which keys are needed for that segment. Does this mean this kind of key rotation is against the IOP guidelines? Would non-hierarchical key rotation require using multiple Periods?

Widevine has a separate concept of a content ID and a key ID. A single piece of content has a single content ID, but it may have different key IDs (e.g. key rotation or for SD/HD). These are not really hierarchical, but the license server can derive the keys from the content ID (but the client can't). Would this kind of key rotation be inline with the IOP since the content ID doesn't change?

@meladc There is a configuration manifest.dash.ignoreDrmInfo which will tell Shaka Player to ignore the data in the manifest and force us to make requests based on the media. Will this work for you?

[kqyang]

+@tinskip

cenc:default_KID maps to the default_KID field in tenc box, which is carried in the initialization segment.

I think there are two ways of indicating key rotation for regular (non-hierarchical) key rotation.

1. Use the same initialization segment throughout. The initialization segment, including cenc:default_KID stays the same even if key rotates. Use sbgp sgpd with seig in media segments to indicate the key id (See DASH-IF-IOP v4.1 7.4.1). There is no need to use separate periods when key rotates as neither initialization segment nor cenc:default_KID changes.

2. Update cenc:default_KID and thus initialization segment whenever key rotates. A separate period needs to be created when key rotates. default_KID indicates the KID in the representations contained in the period.

I don't think either option is against the spec or IOP. Option 1 is probably preferred as initialization segment does not change, although it loses KID indication capability in the manifest.

[sandersaares]

As I understand it, option 1 above refers to the situation where the samples are signaled as encrypted with key Y whereas the manifest (default_KID) and init segment (tenc box) signal key X.

In this scenario, I see an IOP violation in the aspect that the CDM is only informed to acquire key X and it it is never informed about the need to acquire key Y (until it encounters samples encrypted that key Y). This seems contrary to 7.7.9 and 7.7.6 of IOP which tie the acquisition of keys to default_KID and to periods, respectively. There appears to be no IOP-compatible scenario wherein scenario 1 ensures that the CDM has key Y available for use.

Do you see flaws in this logic?

[meladc]

I must admit this thread makes me go back to thoroughly read the IOP and the spec. Interesting though.
@TheModMaker Your suggestion seems perfect. I'll give it a go and report back.
@kqyang Thanks for describing the two options. I guess that in the first option PSSH boxes are signaled in the media segments and trigger license request upon key rotation, right? I assume in the second option PSSH can be signaled either in the MPD, init segment or media segments.

[kqyang]

@sandersaares Agree that option 1 is not compliant to 7.7.9, which seems to be added in IOP v4.1 - I don't see it in v4.0. It does not seem right to me to require different initialization segments for different key rotation periods. I filed an issue to DASH-IF-IOP: Dash-Industry-Forum/DASH-IF-IOP#159.

@meladc Correct.

[meladc]

@TheModMaker - checked this configuration (manifest.dash.ignoreDrmInfo) and it works.
I'm just wondering if it is really necessary to choose either signaling from the MPD or from the media, and not be able to use both (with same filtering algorithm to ignore duplicated PSSH boxes).

[TheModMaker]

The filtering logic only works if the PSSH data is exactly the same. If they are different, even if they result in the same license request, we may send duplicate requests, since we don't parse the PSSH data. Also, it is possible for the media to contain extra or incorrect PSSH data that should be ignored. When on embedded platforms, there is usually a limit on the number of active sessions. So making duplicate requests can be bad.

For example, if the media contains PSSH data for and old license server, but the manifest is updated to a new one. The old data may result in errors from the server, or may result in extra sessions being created, or could mess with logging on the license server proxy.

We might be able to parse v1 PSSH boxes, which contain the key IDs that the data represents. This could allow us to filter by key ID like we do for the manifest. But this will only work for v1 PSSH data, there is a lot of legacy content out there where the media uses v0 PSSH data.

[meladc]

If I understand correctly, your reference use case is that the MPD PSSH is intentionally used to replace PSSH in the stream, and therefore the two should not be combined.
My reference use case was that with live key rotation, the MPD periodically gets updated with PSSH for current key(s). This PSSH is identical to the one in the stream, but allows license acquistion before media segments are accessed. This use case does need future PSSH key rotation signaling from the media (in addition to the first from the MPD).

Would it be reasonable and possible to distinguish between the two cases based on the MPD type (Static or Dynamic) assuming the first use case is mainly used for VOD, and the second for live?
Alternatively, configuration can be enhanced to allow for PSSHs based on 3 options: MPD only, Media only, both MPD and Media.

[jsvictor]

From the above discussion:
"PSSH events in the stream are only meant for hierarchical key scenarios.
They must be related to already pre-fetched root licenses"

Could someone please elaborate the relation of keys to pre-fetched root licenses. Does this mean that the root license is used to decrypt the content encryption keys received for content decryption?

Also, can Widevine client player log/ record the keys which have been used for content decryption. I would like to view the logs to be able to identify till where the content was viewed.

[sandersaares]

With a hierarchical key scenario, you have two types of keys:

• the sample encryption keys; these are embedded into PSSH boxes in each media sample in a protected form; these keys are sometimes called leaf keys
• to unlock their protected form, another key is needed; this is sometimes called the root key

What exactly this "protection" is depends on the DRM system. In the simplest case, the sample keys are just encrypted with the root key.

In a hierachical scenario, the player deals only with root keys - the leaf keys are loaded from PSSH by the CDM and the player does not need to deal with them. Root keys look just like regular keys to the player. They are delivered in regular (to the player) licenses.

Sometimes licenses carrying root keys are called root licenses. Sometimes the data structures within the PSSHs that carry leaf keys are called leaf licenses.

Does this explain some?

[jsvictor]

Thank you for your detailed response. Can Content Decryption Module (CDM) keep a track of which leaf keys have been used to decrypt content (or even a track of which leaf keys have been decrypted using the root key).
This kind of information could be useful in scenarios such as monetization, or simply the provider to know to what extent the content has been viewed by the consumer, etc.

[TheModMaker]

@jsvictor The CDM definitely does track that info to handle expirations. The real question would be whether you could get that info from it. From EME (in JavaScript) there is no way to get that info. Some key systems may be able to expose this in some implementation-specific way. For example, Widevine uses renewals to handle this case. The license is only valid for a few minutes and the client needs to update the license every few minutes to continue playing. This tells you they are still watching the video.

But you'd need to discuss this with a specific key system provider on how to get that info.

@meladc Sorry for not noticing your reply earlier. I think the correct behavior would be to always track pssh data from the media to support both kinds of key rotation. To support the old behavior of overriding the media, we will add a configuration parameter to ignore the pssh data in the media.

[TheModMaker]

An update: after #1360 we support the MPD adding new Periods with new PSSH data in it. So we now support the MPD-based key rotation. We still have the behavior of ignoring the PSSH in the media if the manifest has PSSH data in it.

So what we need to do now is add a flag for whether to ignore PSSH data in the media when the manifest also has PSSH data.

[avelad]

In more than 5 years no one has asked for this configuration, so I am going to close the issue. If anyone wants this configuration please leave a comment. Thanks!