(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2014/0237243 A1
`(43) Pub. Date:
`Aug. 21, 2014
`Ma et al.
`
`US 20140237243A1
`
`(54)
`
`(71)
`(72)
`
`METHOD AND SYSTEM FOR SECURE
`OVER-THE-TOP LIVE VIDEO DELVERY
`
`Applicant: Azuki Systems, Inc., Acton, MA (US)
`
`Inventors: Kevin J. Ma, Nashua, NH (US); Robert
`Hickey, Bedford, MA (US); Paul
`Tweedale, Andover, MA (US)
`
`(73)
`
`Assignee: Azuki Systems, Inc., Acton, MA (US)
`
`(21)
`
`Appl. No.: 14/266,368
`
`(22)
`
`Filed:
`
`Apr. 30, 2014
`
`(63)
`
`(60)
`
`Related U.S. Application Data
`Continuation of application No. 13/530.997, filed on
`Jun. 22, 2012, now Pat. No. 8,751,807.
`Provisional application No. 61/500,316, filed on Jun.
`23, 2011.
`
`Publication Classification
`
`(51) Int. Cl.
`H04L 29/06
`(52) U.S. Cl.
`CPC .................................. H04L 63/0428 (2013.01)
`USPC .......................................................... 713/168
`
`(2006.01)
`
`ABSTRACT
`(57)
`A method is provided for managing key rotation (use of series
`of keys) and secure key distribution in over-the-top content
`delivery. The method provided supports Supplying a first con
`tent encryption key to a content packaging engine for encryp
`tion of a first portion of a video stream. Once the first content
`encryption key has expired, a second content encryption key
`is provided to the content packaging engine for encryption of
`a second portion of a video stream. The method further pro
`vides for notification of client devices of imminent key
`changes, as well as Support for secure retrieval of new keys by
`client devices. A system is also specified for implementing a
`client and server infrastructure in accordance with the provi
`sions of the method.
`
`202 —
`
`NGESTION REOUEST RECEIVED
`WITH SECURITYPOLICY SPECIFYING
`AFIXEDKEY ROTATIONPERIOD
`204 -
`
`PREPARATION OF SOURCE
`CONTENTIS INITIATED
`(ACQUISITION, TRANSCODING, AND
`SEGMENTATION)
`
`205 —
`
`
`
`WAIT FOR NEXT SEGMENT
`
`- 200
`
`218
`
`REGUEST NEW KEY
`
`SELECT KEY EXPRATION TIME
`
`EXPRATION
`MMINENT
`
`ENCRYPT SEGMENT WITH CURRENT
`KEY AND UPLOAD TO CON
`
`ROTATE CURRENTKEY
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Aug. 21, 2014 Sheet 1 of 3
`
`US 2014/0237243 A1
`
`
`
`
`
`
`
`
`
`SOURCE
`CONTENT
`
`LICENSE 106
`
`CLIENT 11
`
`Fig. 1
`
`

`

`Patent Application Publication
`
`Aug. 21, 2014 Sheet 2 of 3
`
`US 2014/0237243 A1
`
`202 —
`
`INGESTION REOUEST RECEIVED
`WITH SECURITYPOLICY SPECIFYING
`AFIXEDKEY ROTATION PERIOD
`
`PREPARATION OF SOURCE
`CONTENT IS INITIATED
`(ACQUISITION, TRANSCODING, AND
`SEGMENTATION)
`
`WAIT FOR NEXT SEGMENT
`
`- 218
`
`REGUEST NEW KEY
`
`
`
`SELECT KEY EXPRATION TIME
`
`EXPRATION
`MMINENT
`
`ENCRYPT SEGMENT WITH CURRENT
`KEY AND UPLOAD TO CON
`
`ROTATE CURRENT KEY
`
`Fig. 2
`
`

`

`Patent Application Publication
`
`Aug. 21, 2014 Sheet 3 of 3
`
`US 2014/0237243 A1
`
`302 —-
`V
`
`INITIAL PLAYBACK REOUEST ISSUED
`
`CONTENT LOCATION AND
`ENCRYPTION INFORMATION
`RECEIVED
`
`RETRIEVE NEXT SEGMENT
`
`-— 318
`
`REGUEST NEW KEY
`
`
`
`CHECK FOR KEY CHANGE
`NOTIFICATION
`
`EXPIRATION
`MMNENT
`
`ROTATE CURRENT KEY
`
`

`

`US 2014/0237243 A1
`
`Aug. 21, 2014
`
`METHOD AND SYSTEM FOR SECURE
`OVER-THE-TOP LIVE VIDEO DELIVERY
`
`SUMMARY
`0001. This invention relates in general to over-the-top
`(OTT) media delivery and more specifically to encryption key
`rotation for live streaming media.
`0002. 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 para
`digms must be modified to Support new delivery protocols,
`e.g., HTTP Live Streaming. For live 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 schemes used in
`private 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
`more Susceptible 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
`(DASH), 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 unique initialization vector (IV) for each seg
`ment, the IV is not random and provides only limited security.
`0003 Methods and apparatus are disclosed for managing
`the distribution and use of a plurality of content encryption
`keys for use in the protection of live 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 upon expiration of a period of use
`of a serially preceding content encryption key. The packaging
`server generates 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 keys to a license server for
`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 authori
`zation to access the content item has been established. The
`transitioning between use of different keys is also referred to
`herein as key "rotation'.
`0004. A workflow management system, referred to herein
`as a workflow manager, is responsible for managing the
`acquisition 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.,
`different bitrates, frame rates, resolutions, sample rates,
`codecs, etc.), storing the transcoded content in different for
`mats (e.g., 3GP, segmented 3GP, MP4, fragmented MP4,
`MPEG-TS, segmented MPEG-TS, RTP, etc.), and encrypting
`
`the different formats, so that the content is suitable for deliv
`ery to a plurality of client devices over a plurality of network
`infrastructures. The prepared content is then uploaded to a
`CDN for delivery to clients. Provisions are included for man
`aging when content encryption keys expire, distributing con
`tent encryption keys to packaging engines, and distributing
`content encryption keys to clients.
`0005. 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 pars
`ing content information from the playback request response,
`the content information including content encryption keys,
`content encryption key identifiers, and content encryption
`key expiration times. The client device retrieves content and
`manifest files from a content delivery server. During ongoing
`retrieval of content, the client device detects content encryp
`tion key rotation boundaries between periods of use of differ
`ent content 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
`used after a content encryption key rotation boundary is
`reached, and applies the second key for content decryption
`after the key rotation boundary is reached.
`0006. In the preparation and distribution of content, spe
`cifically video content, modern protocols (e.g., HTTP Live
`Streaming, Silverlight Smooth Streaming, MPEG/3GP
`Dynamic Adaptive Streaming over HTTP (DASH), etc.)
`employ segment-based rate adaptation to deal with fluctua
`tions 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 adaptation is described in PCT Application No.
`PCT/US2010/027893 filed 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 Stream
`ing Video Dynamic Rate Adaptation. There are many proto
`cols and methods for generating segmented content, as should
`be known to those skilled in the art. Any of these segmenta
`tion methods are Suitable for use in accordance with provi
`sions of the invention. For segment-based formats (e.g., seg
`mented 3GP, fragmented MP4, segmented MPEG-TS, etc.),
`each segment is independently playable, and therefore needs
`to be independently encrypted and decryptable. Segments are
`typically of a fixed duration and, in the case of video content,
`begin with a key-frame and contain no inter-segment refer
`ences. Segmentation is performed on each of the different
`encoding generated by the transcoder, by parsing the resultant
`encoding and determining segment boundaries. In one
`embodiment segment boundaries are based on a fixed number
`of bytes of data. In another embodiment segment boundaries
`are based on a fixed number of video key frames.
`0007 Segments are encrypted on segment boundaries
`using the current content encryption key and current initial
`ization vector (IV). In one embodiment, the IV may be a
`simple incrementing integer value. In another embodiment,
`the IV may be a pseudo-random stream of bits produced by a
`pseudo-random number generator or stream cipher. Though
`the IV provides some additional cryptographic strength, it is
`not random. The generation of new strongly random values
`for use as content encryption keys and the rotation of content
`encryption keys provides protection from content encryption
`
`

`

`US 2014/0237243 A1
`
`Aug. 21, 2014
`
`keys being compromised in long lived streams. In one
`embodiment, IVs are reinitialized whenever a content
`encryption key is rotated. In another embodiment, IVs are not
`reinitialized when content encryption keys are rotated.
`0008. In one embodiment the workflow manager gener
`ates content 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., processor or wall clock time, /dev/urandom,
`etc.). In another embodiment, the content encryption keys
`may be generated using strong Sources of entropy (e.g., hard
`ware sources which rely on electrical static or radioactive
`decay, ?cleV/random/, etc.). There are many ways to generate
`random numbers, as should be known to those skilled in the
`art. Any method for generating random numbers may be used
`in accordance with provisions of this method. The workflow
`manager distributes 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 number of the prepared content. In one
`embodiment the 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 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 server also distrib
`utes fixed duration lifespan information to clients. In one
`embodiment, when initiating playback of the stream, the cli
`ent requests the current content encryption key, the next
`future content encryption key, and the fixed duration lifespan
`of the keys. The client uses the content encryption keys to
`decrypt the associated content.
`0009. 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
`manager is responsible for notifying the packager of the key
`rotation request. The packager is responsible for selecting
`when the new key shall 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
`which the key is applied is based on a segment number of the
`prepared content. In one embodiment the 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 manager is then
`responsible for notifying the license server of the new content
`
`encryption key, the content encryption key identifier of the
`new content encryption key, and the lifespan of the new
`content encryption key.
`0010. In one embodiment, content encryption key identi
`fiers are selected based on the fixed period of the live content.
`In one embodiment, the content encryption key identifiers are
`selected based on the wall clock time offset from the begin
`ning of the live stream. In another embodiment, the content
`encryption key identifiers are selected based on a segment
`number of the prepared content. In one embodiment the seg
`ment 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 packager is respon
`sible for providing in-band notification 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 m3u8 file. In another
`embodiment, the manifest may be a Smooth Streaming mani
`fest file. In another embodiment, the manifest may be a
`DASH MPD file. In another embodiment, the notification is
`embedded in the segment file 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
`DASH header. In another embodiment, the header may be a
`proprietary segment format header.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0011. 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
`accompanying drawings in which like reference characters
`refer to the same parts throughout the different views. The
`drawings are not necessarily to scale, emphasis instead being
`placed upon illustrating the principles of various embodi
`ments of the invention.
`0012 FIG. 1 is a block diagram of a content delivery
`system;
`0013 FIG. 2 is a flow diagram showing content encryption
`and uploading using content encryption key rotation; and
`0014 FIG.3 is a flow diagram showing content download
`ing and decryption using content encryption key rotation.
`
`DETAILED DESCRIPTION
`0015. 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 thorough understanding of embodiments of the present
`invention. One skilled in the relevant art will recognize, how
`ever, that an embodiment of the invention can be practiced
`without one or more of the specific details, or with other
`apparatus, systems, assemblies, methods, components, mate
`rials, parts, and/or the like. In other instances, well-known
`structures, materials, or operations are not specifically shown
`or described in detail to avoid obscuring aspects of embodi
`ments of the present invention.
`0016. In this description the term “server” refers to agen
`eral-purpose or special-purpose computer, generally includ
`ing memory, input/output circuitry, and instruction process
`ing logic along with interconnections such as one or more
`high-speed data buses connecting those components together.
`Many aspects of the disclosed techniques can be embodied as
`
`

`

`US 2014/0237243 A1
`
`Aug. 21, 2014
`
`one or more server computers executing Software. Similarly,
`a “client herein is a computerized device (also including the
`above components and executing software) capable of receiv
`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.
`0017. In FIG. 1 is a block diagram of a system 100 for one
`embodiment of the present invention. As shown, it includes a
`workflow manager (WFM) 102, one or more packaging serv
`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 contentingestion, 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.
`0018. The workflow manager (WFM) 102 is responsible
`for initiating 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.
`0019. The transcoded content is then written into a plural
`ity 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 segmented into fixed duration segment files (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 stan
`dard encryption protocols (e.g., AES-128, HC-128, RC4.
`etc.). In one embodiment, IVs for the encryption protocol are
`reinitialized by the packager 104 whenever a content encryp
`tion key is rotated. In another embodiment, IVs for the
`encryption protocol are not reinitialized when content
`encryption keys are rotated. In one embodiment, all prepara
`tion steps are performed by a single content packaging server
`or packager 104. In another embodiment, individual prepa
`ration steps (e.g., transcoding, segmentation, encryption,
`etc.) may be performed across 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 physical server. 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 serv
`ers in remote data centers.
`0020. The WFM 102 receives an ingestion request from
`the content management system (CMS) 112. The request
`specifies a security profile. In one embodiment, the security
`profile includes content encryption information, including
`cipher specification and content encryption key expiration
`policies. The WFM 102 generates an initial content encryp
`tion key and assigns it a content encryption key identifier. In
`one embodiment, the content encryption key identifier is ini
`tially set to Zero and all future content encryption key identi
`
`fiers are based on a relative offset to the initial content encryp
`tion key identifier. In one embodiment, the content encryption
`key identifiers are based off a next sequential integer value,
`offset from the previous content encryption key identifier. In
`another embodiment, the content encryption key identifiers
`are based off the wall clock time offset from the time the
`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 number of bytes of data.
`In another embodiment the segment boundaries are based on
`a fixed number of video key frames.
`(0021. The WFM 102 then initiates content preparation by
`assigning a packager 104 to begin acquiring the source con
`tent and performing transcoding and segmentation as
`required. The WFM 102 provides the initial content encryp
`tion key and lifespan of the key to the packager 104 respon
`sible 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 time is
`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 of data. In another embodiment the segment boundaries
`are based on a fixed number of video “key frames' (e.g.,
`I-Frames in MPEG encoding). 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 same lifespan 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, if the 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 time as it is able to
`obtain a new key from the WFM 102.
`0022. 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, manifest files
`are also uploaded by the packager 104 to the CDN 108. The
`clients 110 must first 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
`encryption keys by the WFM102 as they are generated. In one
`embodiment, the license server 106 stores the content encryp
`tion key, content encryption key identifier, content encryption
`key lifespan (or expiration), and the location of the encrypted
`content. In one embodiment, the information is stored as an
`encrypted token in a database. In one embodiment the WFM
`
`

`

`US 2014/0237243 A1
`
`Aug. 21, 2014
`
`102 and license server 106 reside in the same physical server.
`In another embodiment, the WFM 102 and license server 106
`reside in different physical servers in the same data center. In
`another embodiment, the WFM 102 and license server 106
`reside in different physical servers in different data centers. In
`one embodiment, the license server 106 registers client
`devices 110 and verifies the right of each client device 110 to
`view the content. If the client 110 has the right to view the
`content, the license server 106 provides the content encryp
`tion key, content encryption key lifespan (or expiration), and
`the location of the encrypted content.
`0023. In one embodiment, the WFM 102 may issue a new
`unsolicited content encryption key to the packager 104. In
`one embodiment, the WFM 102 pushes the new content
`encryption key to the packager 104 when the current content
`encryption key is nearing the end of its lifespan. In one
`embodiment, the new content encryption key is pushed ahead
`of the 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 new content encryption key is pushed ahead
`of the current content key expiration with explicit instructions
`to apply the key as soon as possible, in which case the pack
`ager 104 does not wait until the current content encryption
`key has expired before applying the new content encryption
`key.
`0024. In one embodiment, the WFM 102 pushes the new
`content encryption key to the packager 104 when the current
`content encryption key is deemed to be no longer secure (e.g.,
`if the content encryption key has been compromised). The
`packager 104 waits until the next available encryption bound
`ary before applying the new content encryption key, and then
`notifies the WFM 102 of the 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
`number of bytes of data. In another embodiment the segment
`boundaries are based on a fixed number of 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
`of the new content encryption key is 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 which is greater than half the 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 of the new content encryption key is set to 70 minutes
`(10+60) because the remaining time of 10 minutes is less than
`half the fixed expiration period duration (60/2=30). In one
`embodiment, the packager 104 notifies the client 110 of a 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 manifest file 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 m3u8 file. In another embodiment, the mani
`fest may be a Smooth Streaming manifest file. In another
`embodiment, the manifest may be a DASH MPD file. In
`another embodiment, the packager 104 notifies the client 110
`of the key change in the file name of the encrypted content by
`appending a flag that describes the expiration of the previous
`key.
`(0025 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 CMS 112. In one embodiment, the request is an HTTP
`POST of XML data containing information including, but not
`limited to, transcode parameters, segmentation parameters,
`encryption parameters, Source content location, and CDN
`parameters. In one embodiment, the WFM 102 may have
`predefined profiles formedia 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.
`0026. It should be noted that the fixed period duration for
`key rotation may be viewed as a “target period, as the pack
`ager 104 may not expire a key on the exact boundary. Gener
`ally, the packager 104 will not expire a key earlier than the end
`of a target period.
`(0027. 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 segment
`is produced, it is delivered to the packager 104 responsible for
`encrypting the prepared content.
`0028. In step 205, the packager 104 responsible for
`encryption waits for new segments to become available. Once
`a new segment becomes available, 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 encryp
`tion key provided by the WFM 102 with the initial content
`preparation request. The content encryption key may be
`received in response to a content encryption key request from
`the packager 104 (originating from step 218). The content
`encryption key may be received via a proactive push from the
`WFM 102 in anticipation of a periodic content encryption key
`expiration event. The content encryption key may be an unso
`licited content encryption key pushed by the WFM 102 as a
`security precaution necessitated by security policies (e.g., the
`current content encryption key was compromised or the cur
`rent content encryption was found to be not sufficiently ran
`dom).
`0029. If a new content encryption key was received, pro
`cessing proceeds to step 208 where the expiration times for
`the current content encryption key and the new content
`encryption key are determined. If the new content encryption
`key is an initial content encryption key or a regularly sched
`uled update in advance of a periodic content encryption key
`expiration (either requested by the packager 104, or pushed
`proactively by the WFM 102), the lifespan is set to the fixed
`period duration. If the new content encryption key is not a
`regularly scheduled update and must be applied as soon as
`possible, the expiration of the current content encryption key
`and the new content encryption key are calculated. In one
`embodiment, the new content encryption key is applied at the
`next segment bound