[TUC] Encryption related issues

[haudiobe]

We welcome experts feedback on whether we should recommend:
a) indicating that use of ‘seig’ is not permitted under the ‘cmfc’ and ‘cmf2’ brands (and that a 3rd brand should be introduced if needed);
b) and documenting that mixed clear/protected samples is supported, but only at the CMAF Chunk (or Fragment?) granularity (all samples clear or all samples encrypted) and by using multiple sample description entries (one clear and one encrypted).

[haudiobe]

Feedback from CTA WAVE:

We have identified that the two common use cases for the deployment of media with seig boxes are:

• Mixture of clear and protected samples.
• Rotation of sample encryption keys.

While we do observe active deployments using seig boxes, we note the following consistent comment from deployment experience:

• Key rotation via seig boxes works on a large set of media engines, but there is set of devices from around 2015/2016 with large user bases that will reject segments containing sbgp and sgpd boxes. These devices instead require new initialization segments to be passed with the updated default_KID value.

From these observations, there appears to be a clear desire to use seig boxes, but there are practical deployment restrictions in doing so. We encourage the group to further explore how seig should work with the CMAF defined brands to provide further clarification to content authors and media implementors.

We additionally concur that the mixture of clear and protected samples is currently intended to be supported and welcome clarifications in the text as this is a recognized point of confusion among implementors. Based on our research, we believe the current text allows for mixture at the granularity of a CMAF Fragment but would note that we restricted this to the granularity of CMAF Segments to enable functional interoperability between DASH manifests and HLS playlists.

In addition to the stated encryption issues, we would suggest adding text to clarify the requirement of 16- byte IVs for the cbcs encryption scheme. This suggestion is based on two observations:

• The common encryption specification does not explicitly state that the cbcs scheme requires 16- byte IVs, but the requirement of constants IVs for cbcs and the definition of zero padding applied only to 8-byte per sample IVs result in this being necessary.
• Deployed decryption implementations have divergent handling of 8-byte IVs for the cbcs scheme, sometimes rejecting the IV and sometimes padding the IV to 16-bytes resulting in content that is not interoperable.

[RufaelDev]

From discussions I had with some of the experts on the topic of clear to protected transitions, we would consider that clear - protected transitions in CMAF can be achieved at segment boundary using multiple sample entries. Seig and sample groups support is not consistent, excluding it in CMAF makes sense to me.

[haudiobe]

This issue is complex and suggested to be consolidated. I will check with DASH-IF Content Protection and Security TF

[RufaelDev]

@haudiobe I think this is a good suggestion, but if we can get some input from MPEG it is also helpful, as stated we prefer option B using multiple sample entries for this but if seig is rolled out already it should be studied as excluding it in that case may then not be desirable.

[ZmGorynych]

One additional constraint we may consider is requiring at most 9 subsamples.
The reason is legacy Android implementation of Common Encryption which has a hardcoded limit on the number of slices (as low as 10 on some versions).

[cconcolato]

@ZmGorynych Any pointer to a (public) document mentioning these limits?

[ZmGorynych]

We ran into this in the field when an encoder was misconfigured and was outputting 16-19 slices per picture, and this was what we discovered. Unsure about a reference.

…

On Thu, Jul 13, 2023, 11:10 Cyril Concolato ***@***.***> wrote: @ZmGorynych <https://github.com/ZmGorynych> Any pointer to a (public) document mentioning these limits? — Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGEYZPLEAT2HGUU4JBSO63XQAFVVANCNFSM5MM572CQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[AUGxhub]

As cmaf spec(ISO/IEC 23000-19) is following CENC (ISO/IEC 23001-7) ， so , cmaf should allow using `seig (define at ISO/IEC 23001-7)

Or make it clear than forbidden using key rotation and sample level encrypted/clean mixed contents

[cconcolato]

We welcome contributions with proposed text update for the CMAF specification.

[krasimirkolarov]

From BoG at MPEG146: The File Format group is working on identifying brands for encryption tooling requirements. We still need particular contribution text for CMAF for key rotation, mix mode, etc.

[krasimirkolarov]

File Format is revisiting the topic of Common Encryption and will start a new amendment soon. We will keep this open in the meantime, however we still invite contributions on the CMAF specific issues above