US009313178B2
`
`US 9,313,178 B2
`(10) Patent No.:
`az) United States Patent
`Maet al.
`(45) Date of Patent:
`Apr. 12, 2016
`
`
`(54) METHOD AND SYSTEM FOR SECURE
`OVER-THE-TOP LIVE VIDEO DELIVERY
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`(71) Applicant: Ericsson AB, Stockholm (SE)
`(72)
`Inventors: Kevin J. Ma, Nashua, NH (US); Robert
`Hickey, Bedford, MA (US); Paul
`Tweedale, Andover, MA (US)
`
`005/0060316 Al*
`2007/0038857 Al
`
`3/2005 Kamath etal... 707/9
`2/2007 G
`ll
`esne
`FOREIGN PATENT DOCUMENTS
`
`9/2010
`2010108053 Al
`WO
`
`
`(73) Assignee: ERICSSON AB,Stockholm (SE) 2011020088 Al=.2/2011WO
`(*) Notice:
`Subject to any disclaimer, the term ofthis
`OTHER PUBLICATIONS
`patent is extended or adjusted. under 35
`Pantos et al, HTTP Live Streaming, downloaded from http://tools.
`U.S.C. 154(b) by 0 days.
`ietf.org/html/draft-pantos-http-live-streaming-06, published Mar.
`31, 2011.
`Microsoft Corporation, Using Silverlight DRM, Powered by
`PlayReady, with Windows Media DRM Content, downloaded from
`http://download.microsoft.com/download/7/6/D/76D540F7-A008-
`427C-8AFC-BE9E000D8435/Using_Silverlight__with__Win-
`dows_Media_DRM-Whitepaper_FINAL.doc,
`published Nov.
`2008.
`
`(21) Appl. No.: 14/266,368
`
`(22)
`
`Filed:
`
`Apr. 30, 2014
`
`(65)
`
`Prior Publication Data
`
`US 2014/0237243 Al
`
`Aug. 21, 2014
`
`* cited by examiner
`
`
`
`Primary Examiner — Brandon Hoffman
`Related U.S. Application Data
`(57)
`ABSTRACT
`(63) Continuation of application No. 13/530,997, filed on
`A methodis provided for managing keyrotation (use of series
`Jun. 22, 2012, now Pat. No. 8,751,807.
`(60) Provisional application No. 61/500,316,filed on Jun._—_OF Keys) and secure key distribution in over-the-top content
`23. 2011. delivery. The method provided supports supplyingafirst con-
`
`;
`tent encryption key to a content packaging engine for encryp-
`
`(51) tion ofafirst portion of a video stream. Oncethe first contentInt. Cl.
`HOAL 9/32
`(2006.01)
`encryption key has expired, a second content encryption key
`HOAL 29/06
`(2006.01)
`is provided to the content packaging engine for encryption of
`HOAL 9/08
`(2006.01)
`a second portion of a video stream. The method further pro-
`vides for notification of client devices of imminent key
`(52) U.S. CL
`changes, as well as support for secure retrieval ofnew keys by
`CPC wees HO4L 63/0428 (2013.01); HO4L 90891
`client devices. A system is also specified for implementing a
`(2013.01); HO4L 2209/60 (2013.01)
`client and serverinfrastructure in accordance with the provi-
`(58) Field of Classification Search
`sions of the method.
`None
`
`See application file for complete search history.
`
`20 Claims, 3 Drawing Sheets
`
`
`202
`INGESTION REQUEST RECEIVED
`WITH SECURITY POLICY SPECIFYING
`AFPIXED KEY ROTATION PERIOD.
`
`
`204 =
`PREPARATION OF SOURCE
`CONTENTISINITIATED
`(ACQUISITION, TRANSCODING, AND
`SEGMENTATION)
`
`205 —.‘ y
`WAIT FOR NEXT SEGMENT
`
`
`
`
`NEW KEY
`RECEIVED?
`
`YES
`
`*
`SELECT KEY EXPIRATION TIME
`
`206 —
`
`No
`
`208 —
`
`\
`210
`
`212
`
`
`
`
`
` i
`
`ym
`
`7 218
`
`REQUEST NEW KEY
`
`YES
`216é
`EXPIRATION
`
`IMMINENT?
`
`
`
` yo 214
`¥
`£
`ENCRYPT SEGMENT WITH CURRENT
`KEY AND UPLOAD TO CDN
`
`¥
`
`EXPIRE KEY?
`
`YES
`
`Google Exhibit 1001
`Google Exhibit 1 00 1
`Google v. Ericsson
`Google v. Ericsson
`
`

`

`U.S. Patent
`
`Apr.12, 2016
`
`Sheet 1 of 3
`
`US 9,313,178 B2
`
`-— 100
`
`CONTENT
`
`WFM 102
`
` SOURCE
`PACKAGER(S) 104
`
`
`LICENSE 10
`
`CLIENT 11
`
`Fig. 1
`
`

`

`U.S. Patent
`
`Apr.12, 2016
`
`Sheet 2 of 3
`
`US 9,313,178 B2
`
`202 —.\
`
`INGESTION REQUEST RECEIVED
`WITH SECURITY POLICY SPECIFYING
`A FIXED KEY ROTATION PERIOD
`
`PREPARATION OF SOURCE
`CONTENTIS INITIATED
`(ACQUISITION, TRANSCODING, AND
`SEGMENTATION)
`
`WAIT FOR NEXT SEGMENT
`
`218
`
`REQUEST NEW KEY
`
`SELECT KEY EXPIRATION TIME
`
`IMMINENT?
`
`ENCRYPT SEGMENT WITH CURRENT
`KEY AND UPLOAD TO CDN
`
` EXPIRATION
`
`ROTATE CURRENT KEY
`
`Fig. 2
`
`

`

`U.S. Patent
`
`Apr.12, 2016
`
`Sheet 3 of 3
`
`US 9,313,178 B2
`
`302 —~
`
`INITIAL PLAYBACK REQUEST ISSUED
`
`CONTENT LOCATION AND
`ENCRYPTION INFORMATION
`RECEIVED
`
`RETRIEVE NEXT SEGMENT
`
`— 318
`
`REQUEST NEW KEY
`
`NOTIFICATION
`
`EXPIRATION
`IMMINENT?
`
`DECRYPT WITH CURRENT KEY
`
` CHECK FOR KEY CHANGE
`
`ROTATE CURRENT KEY
`
`Fig. 3
`
`

`

`US 9,313,178 B2
`
`1
`METHOD AND SYSTEM FOR SECURE
`OVER-THE-TOP LIVE VIDEO DELIVERY
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`This application claims priority to U.S. application Ser.
`No. 61/500,316, filed Jun. 23, 2011, and U.S. patent applica-
`tion Ser. No.: 13/530,997, filed on Jun. 22, 2012 now U.S. Pat.
`No. 8,751,807. The content of the above applications are
`incorporated by reference in their entirety.
`
`SUMMARY
`
`This invention relates in general to over-the-top (OTT)
`media delivery and more specifically to encryption key rota-
`tion for live streaming media.
`As content delivery models move away from streaming
`distribution over private networks to Web-based delivery of
`files over the public Internet, referred to as over-the-top
`(OTT) delivery,
`traditional content protection paradigms
`must be modified to support new delivery protocols, e.g.,
`HTTPLive Streaming. Forlive streaming content with long
`or indefinite durations, use of a single encryption key for the
`entire duration increases the probability that the key may be
`compromised. Traditional key rotation schemesused inpri-
`vate multiple system operator (MSO) and mobile network
`operator (MNO)distribution networks, where physical secu-
`rity protects the key distribution path, do not extend to use
`over the public Internet, where communications channels are
`moresusceptible to attack. Furthermore, the encryption used
`with nascent segment-based HTTP distribution protocols
`(e.g., HTTP Live Streaming, Silverlight Smooth Streaming,
`MPEG/3GP Dynamic Adaptive Streaming over HTTP
`(DASI)), etc.) also differs from traditional streaming tech-
`niques. Encryption of non-segmented content is typically
`performed using a single encryption key using a single con-
`tinuous pass over the content, from start to finish. For seg-
`ment-based formats, each segment may use the same content
`encryption key. Though the content encryption key may be
`salted with a uniqueinitialization vector (IV) for each seg-
`ment, the IV is not random andprovides only limited security.
`Methods and apparatus are disclosed for managing the
`distribution and use of a plurality of content encryption keys
`for use in the protection oflive streaming content. A disclosed
`method includes generating a series of content encryption
`keys and providing them serially to a packaging server for
`encrypting a content item, wherein each content encryption
`key is provided uponexpiration of a period ofuse ofa serially
`preceding content encryption key. The packaging server gen-
`erates packaged content for delivery to client devices via a
`content delivery network, the packaged content including or
`accompanied by key expiration information usable by the
`client devices to identify transitions between sections of the
`packaged content encrypted by different ones of the content
`encryption keys. The method further includes providing the
`content encryption keysto a license serverfor delivery to the
`client devices for use in decrypting the content item. The
`license server is operative to establish that a requesting client
`device is authorized to access the content item, and further
`operative to securely deliver the content encryption keys to a
`requesting client device whose authorization to access the
`content item has been established. Thetransitioning between
`use of different keys is also referred to herein as key “rota-
`tion”.
`A workflow management system, referred to herein as a
`workflow manager, is responsible for managing the acquisi-
`
`20
`
`30
`
`35
`
`40
`
`45
`
`55
`
`65
`
`2
`tion of source content from a content management system,
`preparation of the content,
`including, but not limited to,
`transcoding of the content into different encodings(e.g., dif+
`ferentbitrates, frame rates, resolutions, sample rates, codecs,
`etc.), storing the transcoded contentin different formats(e.g.,
`3GP, segmented 3GP, MP4, fragmented MP4, MPEG-TS,
`segmented MPEG-TS,RTP, etc.), and encrypting the differ-
`ent formats, so that the content is suitable for delivery to a
`plurality of client devices over a plurality of network infra-
`structures. The prepared content is then uploaded to a CDN
`for delivery to clients. Provisions are included for managing
`when content encryption keys expire, distributing content
`encryption keys to packaging engines, and distributing con-
`tent encryption keys toclients.
`A client device handles the secure distribution of content
`by a process including initiating a media playback request
`and receiving a playback request response, and parsing con-
`tent information from the playback request response, the con-
`tent information including content encryption keys, content
`encryption key identifiers, and content encryption key expi-
`ration times. The client device retrieves content and manifest
`
`files from a content delivery server. During ongoingretrieval
`ofcontent, the client device detects content encryption key
`rotation boundaries between periods ofuse of different con-
`tent encryption keys in decrypting retrieved content, issues
`requests to the license server ahead of a key rotation boundary
`to retrieve a second content encryption key to be usedafter a
`content encryption key rotation boundary is reached, and
`applies the second key for content decryption after the key
`rotation boundary is reached.
`In the preparation and distribution of content, specifically
`video content, modern protocols (e.g., HTTP Live Streaming,
`Silverlight Smooth Streaming, MPEG/3GP Dynamic Adap-
`tive Streaming over HTTP (DASH), etc.) employ segment-
`based rate adaptation to deal with fluctuations in bandwidth,
`whereby segment boundaries provide natural demarcation
`points for switching bitrates. Another example of a protocol
`and file format suitable for segment-based rate adaptationis
`described in PCT Application No. PCT/US2010/027893filed
`Mar. 19, 2010, and entitled, Method for Scalable Live
`Streaming Delivery for Mobile Audiences. Yet another
`example of a protocol and file format suitable for segment-
`based rate adaptation is described in PCT Application No.
`PCT/US2010/028309 filed Mar. 23, 2010, and entitled,
`Method and System for Efficient Streaming Video Dynamic
`Rate Adaptation. There are many protocols and methods for
`generating segmented content, as should be knownto those
`skilled in the art. Any of these segmentation methods are
`suitable for use in accordance with provisions of the inven-
`tion. For segment-based formats (e.g., segmented 3GP,frag-
`mented MP4, segmented MPEG-TS, etc.), each segmentis
`independently playable, and therefore needs to be indepen-
`dently encrypted and decryptable. Segments are typically ofa
`fixed duration and,in the case of video content, begin with a
`key-frame and contain no inter-segment references. Segmen-
`tation is performed on each of the different encoding gener-
`ated by the transcoder, by parsing the resultant encoding and
`determining segment boundaries. In one embodiment seg-
`ment boundaries are based on a fixed numberofbytes ofdata.
`In another embodiment segment boundaries are based on a
`fixed number of video key frames.
`Segments are encrypted on segment boundaries using the
`current content encryption key and currentinitialization vec-
`tor (IV). In one embodiment, the IV may be a simple incre-
`menting integer value. In another embodiment, the IV may be
`a pseudo-random stream of bits produced by a pseudo-ran-
`dom number generator or stream cipher. Though the IV pro-
`
`

`

`US 9,313,178 B2
`
`3
`vides some additional cryptographic strength,it is not ran-
`dom. The generation ofnew strongly random valuesfor use as
`content encryption keys and the rotation of content encryp-
`tion keys provides protection from content encryption keys
`being compromised in long lived streams. In one embodi-
`ment, IVsare reinitialized whenever a content encryption key
`is rotated. In another embodiment, IVs are not reinitialized
`when content encryption keysare rotated.
`In one embodiment the workflow manager generates con-
`tent encryption keys with a fixed duration lifespan on a fixed
`periodic basis. In one embodiment, the content encryption
`keys may be generated using weak sources of entropy(e.g.,
`processoror wall clock time, /dev/urandom,etc.). In another
`embodiment, the content encryption keys may be generated
`using strong sources ofentropy(e.g., hardware sources which
`rely on electrical static or radioactive decay, /dev/random/,
`etc.). There are many ways to generate random numbers, as
`should be knownto those skilled in the art. Any method for
`generating random numbers may beused in accordance with
`provisions of this method. The workflow managerdistributes
`the content encryption keys and content encryption key
`lifespan to both a license server and content packaging
`engine, referred to herein as a packager. The fixed duration
`lifespan is directly correlated to a fixed period of the live
`content. The changing of content encryption keys based on
`the fixed period of the live content is referred to herein as
`rotation. A history of individual content encryption keys and
`the order in which they were generated is maintained. Each
`content encryption key in the history is assigned a unique
`identifier which is referred to herein as the content encryption
`key identifier. In one embodiment, the content encryption key
`identifiers are selected based on the wall clock time offset
`
`from the beginning of the live stream. In another embodi-
`ment,
`the content encryption key identifiers are selected
`based on a segment numberof the prepared content. In one
`embodiment the segment boundaries are based on a fixed
`numberof bytes of data. In another embodimentthe segment
`boundaries are based on a fixed numberof video key frames.
`The content packaging engine is responsible for encrypting
`the associated content using the content encryption key. In
`one embodiment, the packager recognizes the imminent end
`to the fixed duration lifespan and requests a new content
`encryption key from the workflow manager. The license
`server is responsible for distributing content encryption keys
`to clients. In one embodiment,the license serveralso distrib-
`utes fixed duration lifespan information to clients. In one
`embodiment, wheninitiating playback of the stream, the cli-
`ent requests the current content encryption key, the next
`future content encryption key, andthe fixed duration lifespan
`of the keys. The client uses the content encryption keys to
`decrypt the associated content.
`In one embodiment, the workflow manager may initiate
`content encryption key rotation at any time, outside of the
`fixed duration lifespan of the existing key. The workflow
`manageris responsible for notifying the packager of the key
`rotation request. The packager is responsible for selecting
`when the new keyshall be applied and notifying the workflow
`manager. In one embodiment, the point at which the key is
`applied is based on the wall clock time offset from the begin-
`ning of the live stream. In another embodiment, the point at
`whichthe key is applied is based on a segment numberofthe
`prepared content. In one embodimentthe segment boundaries
`are based on a fixed number of bytes of data. In another
`embodiment the segment boundaries are based on a fixed
`number of video key frames. The workflow manageris then
`responsible for notifying the license serverofthe new content
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`encryption key, the content encryption key identifier of the
`new content encryption key, and the lifespan of the new
`content encryption key.
`In one embodiment, content encryption key identifiers are
`selected based on the fixed period ofthelive content. In one
`embodiment,
`the content encryption key identifiers are
`selected based on the wall clock time offset from the begin-
`ning ofthelive stream. In another embodiment, the content
`encryption key identifiers are selected based on a segment
`numberof the prepared content. In one embodimentthe seg-
`ment boundaries are based on a fixed numberofbytes ofdata.
`Tn another embodiment the segment boundaries are based on
`a fixed numberof video key frames. The packageris respon-
`sible for providing in-bandnotification to the client for the
`key change. In one embodiment,the notification is embedded
`in a manifest file that describes the encrypted content. In one
`embodiment, the manifest may be an m3u8file. In another
`embodiment, the manifest may be a Smooth Streaming mani-
`fest file. In another embodiment, the manifest may be a
`DASH MPDfile. In another embodiment, the notification is
`embeddedin the segmentfile name of the encrypted content.
`In another embodiment, the notification is embedded in a
`header prepended to the encrypted content. In one embodi-
`ment, the header may be a Microsoft PlayReady header. In
`another embodiment, the header may be an MPEG/3GP
`DASHheader. In another embodiment, the header may be a
`proprietary segment format header.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The foregoing and other objects, features and advantages
`will be apparent from the following description of particular
`embodiments of the invention,as illustrated in the accompa-
`nying drawings in whichlike reference charactersrefer to the
`same parts throughout the different views. The drawingsare
`not necessarily to scale, emphasis instead being placed upon
`illustrating the principles of various embodiments of the
`invention.
`
`FIG.1 is a block diagram of a content delivery system;
`FIG.2 is a flow diagram showing content encryption and
`uploading using content encryption key rotation; and
`FIG.3 is a flow diagram showing content downloading and
`decryption using content encryption key rotation.
`
`DETAILED DESCRIPTION
`
`In the description herein for embodiments of the present
`invention, numerous specific details are provided, such as
`examples of components and/or methods, to provide a thor-
`ough understanding of embodimentsofthe present invention.
`Oneskilled in the relevant art will recognize, however, that an
`embodimentof the invention can be practiced without one or
`moreofthe specific details, or with other apparatus, systems,
`assemblies, methods, components, materials, parts, and/or
`the like. In other instances, well-knownstructures, materials,
`or operationsare not specifically shownor describedin detail
`to avoid obscuring aspects of embodiments of the present
`invention.
`In this description the term “server” refers to a general-
`purpose or special-purpose computer, generally including
`memory, input/output circuitry, and instruction processing
`logic along with interconnections such as one or more high-
`speed data buses connecting those components together.
`Manyaspectsofthe disclosed techniques can be embodied as
`one or more server computers executing software. Similarly,
`a “client” herein is a computerized device (also including the
`above components and executing software) capable ofreceiv-
`
`

`

`US 9,313,178 B2
`
`5
`ing content from a network connection and decoding and
`rendering the content on a display or similar output device.
`So-called smartphones are specifically included within the
`definition of client as used herein.
`
`In FIG. 1 is a block diagram of a system 100 for one
`embodimentofthe present invention. As shown,it includes a
`workflow manager (WFM)102, one or more packagingserv-
`ers or “packager(s)” 104, a license server 106, a content
`delivery network (CDN) 108, client devices or “clients” 110,
`and a content management system (CMS) 112. Generally in
`operation, the packager(s) 104 receive source content and
`process or “package” the source content so that it may be
`delivered to the clients 110 via the CDN 108. Specifically, the
`packager(s) 104 perform content encryption using a series of
`content encryption keys as described below. The CMS 112
`provides high-level control over content ingestion, packaging
`and delivery, while the WFM 102 performs more detailed
`control operations. The license server 106 is responsible for
`storing encryption keys and providing them to the clients 110
`for use during playback, as described in more detail below.
`The workflow manager (WFM)102 is responsible for ini-
`tiating ingestion and preparation of live content. In one
`embodiment, preparation includes transcoding audio and
`video into a plurality of encodings using different codecs,
`bitrates, frame rates, sample rates, and resolutions.
`The transcoded content is then written into a plurality of
`output files. In one embodiment, a plurality of output files
`contain the same transcoded content encapsulated in different
`container formats (e.g., 3GP, MP4, MPEG-TS, WMV, MOV,
`etc.). In one embodiment, the prepared output files are seg-
`mented into fixed duration segmentfiles (e.g., MPEG-TS
`segments, fragmented MP4 segments, 3GP DASH segments,
`etc.). In one embodiment, the output files, both segmented
`and un-segmented, are encrypted using standard encryption
`protocols (e.g., AUS-128,
`IIC-128, RC4, etc.).
`In one
`embodiment, IVs for the encryption protocolare reinitialized
`by the packager 104 whenever a content encryption key is
`rotated. In another embodiment, IVs for the encryption pro-
`tocol are not reinitialized when content encryption keys are
`rotated. In one embodiment, all preparation steps are per-
`formedby a single content packaging server or packager 104.
`In another embodiment, individual preparation steps (e.g.,
`transcoding, segmentation, encryption, etc.) may be per-
`formedacross different physical packaging servers 104. The
`packager 104 which performs encryption acquires content
`encryption keys from the workflow manger 102. In one
`embodiment the WFM 102 and packager 104 reside in the
`same physicalserver. In another embodiment, the WFM 102
`and packager 104 reside in different physical servers in the
`same data center. In another embodiment, the WFM 102 and
`packager 104 reside in different physical servers in remote
`data centers.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`6
`initial content encryption key identifier was generated. In
`another embodiment, the content encryption key identifiers
`are based off of segment numbers, as produced by the pack-
`ager 104 during segmentation. In one embodiment the seg-
`ment boundaries are based on a fixed numberofbytes ofdata.
`Tn another embodiment the segment boundaries are based on
`a fixed numberofvideo key frames.
`The WFM 102then initiates content preparation by assign-
`ing a packager 104 to begin acquiring the source content and
`performing transcoding and segmentation as required. The
`WFM 102 provides the initial content encryption key and
`lifespan of the key to the packager 104 responsible for
`encryption of the prepared outputs. The packager 104
`encrypts the content using the initial content encryption key
`until it expires. In one embodiment, the expiration timeis
`based on a relative wall clock time offset to the time prepa-
`ration was started.
`In another embodiment,
`the content
`encryption key identifiers are based off of segment numbers,
`as produced by the packager 104 during segmentation. Seg-
`mentation detects segment boundaries and assigns a fixed
`amount of data to each individual segment. In one embodi-
`ment the segment boundaries are based on a fixed number of
`bytes ofdata. In another embodiment the segment boundaries
`are based on a fixed number of video “key frames”(e.g.,
`I-Frames in MPEGencoding). In one embodiment, before the
`content encryption key expires, the packager 104 requests a
`new key from the WFM 102. In one embodiment, the new
`content encryption key has the samelifespan as the previous
`content encryption key. The new content encryption key is
`made available by the WFM 102 to the packager 104 before
`the previous content encryption key has expired to allow for
`uninterrupted encryption. In one embodiment,ifthe packager
`104 is unable to obtain a new content encryption key from the
`WFM 102 prior to the expiration of the current content
`encryption key, the packager 104 will continue to use the
`current content encryption key until such timeasit is able to
`obtain a new key from the WFM 102.
`Encrypted content is uploaded by the packager 104 to a
`content delivery network (CDN) 108, from which it may be
`retrieved by clients 110. In one embodiment, manifestfiles
`are also uploaded by the packager 104 to the CDN 108. The
`clients 110 mustfirst obtain the content encryption keys from
`the license server 106, before they may decrypt and render
`encrypted content. In one embodiment, clients 110 retrieve
`content encryption keys using HTTPS. Generally, the license
`server 106 is responsible for ensuring that a client device 110
`is authorized to access any protected content before providing
`the encryption keys for such content to a requesting client
`110. In one embodiment, clients 110 are verified by the
`license server 106 using client certificate verification. In
`another embodiment, clients 110 are verified using login cre-
`dentials. The license server 106 is notified of new content
`
`55
`
`encryption keys by the WFM 102 asthey are generated. In one
`The WFM 102 receives an ingestion request from the con-
`embodiment,the license server 106 stores the content encryp-
`tent management system (CMS) 112. The request specifies a
`tion key, content encryption key identifier, content encryption
`security profile. In one embodiment, the security profile
`key lifespan (or expiration), and the location of the encrypted
`includes content encryption information, including cipher
`content. In one embodiment, the information is stored as an
`specification and content encryption key expiration policies.
`encrypted token in a database. In one embodiment the WFM
`The WFM 102 generates aninitial content encryption key and
`102 and license server 106 reside in the same physical server.
`assigns it a content encryption key identifier. In one embodi-
`In another embodiment, the WFM 102 andlicense server 106
`ment, the content encryption key identifier is initially set to
`zero and all future content encryption key identifiers are
`reside in different physical servers in the same data center.In
`another embodiment, the WFM 102 andlicense server 106
`based onarelative offset to the initial content encryption key
`identifier. In one embodiment, the content encryption key
`reside in different physical servers in different data centers. In
`identifiers are based off a next sequential integer value,offset
`one embodiment,
`the license server 106 registers client
`from the previous content encryption key identifier.
`In
`devices 110 and verifies the right of each client device 110 to
`another embodiment, the content encryption key identifiers
`view the content. If the client 110 has the right to view the
`are based off the wall clock time offset from the time the
`content, the license server 106 provides the content encryp-
`
`60
`
`65
`
`

`

`US 9,313,178 B2
`
`7
`tion key, content encryption key lifespan (or expiration), and
`the location of the encrypted content.
`Tn one embodiment, the WFM 102 mayissue a new unso-
`licited content encryption key to the packager 104. In one
`embodiment, the WFM 102 pushes the new content encryp-
`tion key to the packager 104 whenthe current content encryp-
`tion key is nearing the endofits lifespan. In one embodiment,
`the new content encryption key is pushed aheadofthe current
`content key expiration, and the packager 104 waits until the
`current content encryption key has expired before applying
`the new content encryption key. In another embodiment, the
`newcontent encryption key is pushed ahead of the current
`content key expiration with explicit instructions to apply the
`key as soon aspossible, in which case the packager 104 does
`not wait until the current content encryption key has expired
`before applying the new content encryption key.
`In one embodiment, the WFM 102 pushesthe new content
`encryption key to the packager 104 when the current content
`encryption key is deemedto be no longersecure (e.g., if the
`content encryption key has been compromised). The pack-
`ager 104 waits until the next available encryption boundary
`before applying the new content encryption key, and then
`notifies the WFM 102 ofthe exact boundary at which it
`expired the previous content encryption key. In one embodi-
`ment, the encryption boundary is a segment boundary.In one
`embodiment the segment boundaries are based on a fixed
`numberof bytes of data. In another embodimentthe segment
`boundaries are based on a fixed numberof video key frames.
`The lifespan of the new content encryption key may be
`aligned to the periodic use period boundaries of the previous
`content encryption keys. In one embodiment, the expiration
`ofthe new content encryption keyis set to the expiration time
`of the previous content encryption key. Thus if the new con-
`tent encryption key was applied when the previous content
`encryption key had 10 minutes left
`in its lifespan,
`for
`example, then the lifespan of the new content encryption key
`is set to 10 minutes. In another embodiment,the expiration of
`the new content encryption key is set to the next periodic
`expiration time whichis greater than halfthe fixed expiration
`period duration. Thus, if the lifespan of content encryption
`keys is 60 minutes and the previous content encryption key
`had 10 minutes left in its lifespan, for example, then the
`lifespan ofthe new content encryption key is set to 70 minutes
`(10+60) because the remaining time of 10 minutes1s less than
`half the fixed expiration period duration (60/2=30). In one
`embodiment, the packager 104notifies the client 110 ofa key
`change by prepending a header to the encrypted content
`which contains a flag that describes the expiration of the
`previous key. In one embodiment,
`the header may be a
`Microsoft PlayReady header. In another embodiment, the
`header may be an MPEG/3GP DASH header. In another
`embodiment, the header may be a proprietary segment format
`header. In another embodiment, the packager 104 notifies the
`client 110 of the key change by updating a manifestfile that
`describes the encrypted content with a flag that describes the
`expiration of the previous key. In one embodiment, the mani-
`fest may be an m3u8file. In another embodiment, the mani-
`fest may be a Smooth Streaming manifest file. In another
`embodiment, the manifest may be a DASH MPDfile. In
`another embodiment, the packager 104 notifies the client 110
`ofthe key changein thefile nameof the encrypted content by
`appendinga flag that describes the expiration of the previous
`key.
`FIG.2 is a flow chart 200 describing a process for obtaining
`and rotating content encryption keys in a packager 104. In
`step 202, the WFM 102 receives an ingestion request from a
`CMS112. In one embodiment, the request is an HTTP POST
`
`30
`
`35
`
`40
`
`45
`
`8
`of XMLdata containing information including, but not lim-
`ited to,
`transcode parameters, segmentation parameters,
`encryption parameters, source content location, and CDN
`parameters. In one embodiment, the WFM 102 may have
`predefined profiles for media preparation, content encryption,
`and CDN upload which are referenced in the ingestion
`request.
`In one embodiment
`the encryption parameters
`include a fixed period duration for key rotation.
`It should be noted that the fixed period duration for key
`rotation may be viewedasa “target” period, as the packager
`104 may not expire a key on the exact boundary. Generally,
`the packager 104 will not expire a key earlier than the end of
`a target period.
`In step 204, the WFM 102 instructs the packager 104 to
`begin preparation of the content. A packager 104 begins
`acquiring the source content, transcoding the source content
`and segmenting the source content. As each segmentis pro-
`duced, it is delivered to the packager 104 responsible for
`encrypting the prepared content.
`In step 205, the packager 104 responsible for encryption
`waits for new segments to becomeavailable. Once a new
`segment becomesavailable, processing proceeds to step 206
`where this packager 104 checks to see if a new content
`encryption key has been received from the WFM 102. The
`content encryption key may be an initial content encryption
`key provided by the WFM 102 with theinitial content prepa-
`ration request. The content encryption key maybe received in
`response to a content encryption key request from the pack-
`ager 104 (originating from step 218). The content encryption
`key maybe received via a proactive push from the WFM 102
`in anticipationof a periodic content encryption key expiration
`event. The content encryption key may be an unsolicited
`content encryption key pushed by the WFM 102as a security
`precaution necessitated by security policies (e.g., the current
`content encryption key was compromisedor the current con-
`tent encryption was foundto be not sufficiently random).
`If a new content encryption key was received, processing
`proceeds to step 208 where the expiration times for the cur-
`rent content encryption key and the new