ghost
commented
10 years ago The functional requirement for seamless switching is the strict requirement. Making that practical for clients requires some constraints on key storage and delivery, license processing, etc.
The Root/Leaf license structure can be described fairly explicitly, but everyone has been pointing out that infinite methods are possible, as long as they work with seamless switching and KID sample groups as specified in Common Encryption. ‘moof’/’pssh’ provides a DRM specific storage location for keys in each Media Segment to make they available without delivery delay for seamless presentation, but delivery of KIDs referenced by a Segment in ‘pssh’ in the movie fragment isn’t required by CENC or DASH-AVC/264.
If KID sample groups are not present, then only the default_KID in ‘tenc’ can be used to decrypt media data. If KID sample groups are present, then they override the default_KID with media keys that can change over time/samples … what we are calling “key rotation”.
The key rotation use case as practiced in broadcast provides changing keys in the broadcast stream just before they are needed, as a traditional security and conditional access (authorization) method that has been used to signal blackouts, etc. in one-way broadcasts to TVs, etc. The keys are delivered in the stream (sometimes called “control words” or Entitlement Control Messages “ECM”) and are simple to decrypt and use in realtime for receivers. A more time consuming “Entitlement Management Message” (EMM) is broadcast and processed at the start of a program or tuning operation to authenticate the receiver and authorize it to process ECMs. CSS Simulcrypt has similar functionality but different terminology, with multiple key protection/authorization systems, similar to Common Encryption.
DASH translation of broadcast key rotation allows much more flexibility, with two way internet connections with rich manifests, VOD, rights expression language in DRM licenses, etc.; but the broadcast key rotation use case can be translated to a DRM “root” license acting like an EMM, with a user or domain specific license that cryptographically authenticates a trusted Content Decryption Module, provides at least one protected key identified by default_KID; and a proprietary method of delivering the actual media keys in a ‘moof’/’pssh’ box in each Media Segment.
The practical requirement to have one set of content containing keys in Segments for all users results in the structure of shared media keys stored in Media Segments (like ECM) protected by a user/player unique license with a key to control access to the media keys (like EMM). It isn’t practical for most DRM systems to process a user-unique (“root”) license for each Media Segment in realtime. DASH allows all licenses/keys to be delivered in advance, but the traditional broadcast scenario does not (ECMs are generated roughly in realtime). If there is a different use case, such as live presentations that are stored and converted to VOD, then we should probably define them.
There has to be some constraint on presentations and clients that minimizes latency and performance so that all clients will be able to seamlessly switch with keys delivered near realtime. If we don’t specify a mechanism (like “root license” defined in a generic way) in ‘moof’/’pssh’, then we have to rely on magic; and encoders, network performance, players, and DRM companies figuring out interoperability. How much to specify depends on how much interoperability DASH IF wants.
Kilroy Hughes | Senior Digital Media Architect |Windows Azure Media Services | Microsoft Corporation [cid:image001.png@01CDABBA.71FD8800]http://www.windowsazure.com/media
From: Thomas Stockhammer [mailto:notifications@github.com] Sent: Monday, March 24, 2014 10:13 AM To: Dash-Industry-Forum/DRM Subject: [DRM] Key rotation (#14)
Sec 1.4.4 states that “To enable seamless switching, Representations of one Adaptation Set shall be protected by the same license and encrypted with the same key” – does that mean when key rotation is in use and a key is changed for one representation, all other representations in that Adaptation set also start using this new key i.e. all reps are also “key-aligned” or this is just talking about “default_KID” being the same and hence (root) license can be acquired only once in that adaptation set (with default_KID) and subsequent switches to a different rep within the adaptation set would not be disruptive. As an example say keys change every 30sec and default_KID = 0, so the client downloads the (root) license and 30sec later switches to a diff rep and now say KID = 1. It would still “combine” the earlier-downloaded (root) license with (leaf) license + KID (1) to look up the content key?
— Reply to this email directly or view it on GitHubhttps://github.com/Dash-Industry-Forum/DRM/issues/14.
haudiobe
nthorwir
Sec 1.4.4 states that “To enable seamless switching, Representations of one Adaptation Set shall be protected by the same license and encrypted with the same key” – does that mean when key rotation is in use and a key is changed for one representation, all other representations in that Adaptation set also start using this new key i.e. all reps are also “key-aligned” or this is just talking about “default_KID” being the same and hence (root) license can be acquired only once in that adaptation set (with default_KID) and subsequent switches to a different rep within the adaptation set would not be disruptive. As an example say keys change every 30sec and default_KID = 0, so the client downloads the (root) license and 30sec later switches to a diff rep and now say KID = 1. It would still “combine” the earlier-downloaded (root) license with (leaf) license + KID (1) to look up the content key?