(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2012/0331293 A1
`Ma et al.
`(43) Pub. Date:
`Dec. 27, 2012
`
`US 20120331293A1
`
`Publication Classification
`
`(54) METHOD AND SYSTEM FOR SECURE
`OVER-THE-TOP LIVE VIDEO DELVERY
`
`(75) Inventors: Kevin J. Ma, Nashua, NH (US); Robert
`Tweedale, Andover, MA (US)
`
`Hickey, Bedford, MA (US); Paul
`
`(73) Assignee: AZUKISYSTEMS, INC., Acton, MA
`(US)
`
`(21) Appl. No.: 13/530,997
`
`(22) Filed:
`
`Jun. 22, 2012
`
`O
`O
`Related U.S. Application Data
`(60) Provisional application No. 61/500.316, filed on Jun.
`23, 2011.
`
`202 -
`
`INGESTION REQUEST RECEIVED
`WITH SECURITY POLICY SPECIFYING
`AFIXEDKEY ROTATIONPERIOD
`
`PREPARATION OF SOURCE
`CONTENTIS INITIATED
`(ACQUISITION, TRANSCODING, AND
`SEGMENTATION)
`
`WAIT FOR NEXT SEGMENT
`
`SELECT KEY EXPRATION TIME
`
`
`
`
`
`ROTATE CURRENTKEY
`
`Oa -
`
`- - -
`
`- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
`
`713/168
`
`(51) Int. Cl.
`(2006.01)
`(52) the 2
`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 b
`E. A ER is also specified for Nin
`client and server infrastructure in accordance with the provi
`sions of the method.
`
`- 200
`y
`
`- 218
`
`YES
`
`216
`
`EXPRATION
`MMINENT
`
`- 214
`ENCRYPTSEGMENT WITH CURRENT
`KEY AND UPLOAD TO CDN
`
`
`
`

`

`Patent Application Publication
`
`Dec. 27, 2012 Sheet 1 of 3
`
`US 2012/0331293 A1
`
`
`
`- 100
`
`
`
`
`
`
`
`
`
`LICENSE 106
`
`SOURCE
`CONTENT
`
`PACKAGER(S) 104
`
`CLIENT 11
`
`Fig. 1
`
`

`

`Patent Application Publication
`
`Dec. 27, 2012 Sheet 2 of 3
`
`US 2012/0331293 A1
`
`NGESTION RECUEST RECEIVED
`WITH SECURITYPOLICY SPECIFYING
`A FIXED KEY ROTATION PERIOD
`
`PREPARATION OF SOURCE
`CONTENT IS INITIATED
`(ACQUISITION, TRANSCODING, AND
`SEGMENTATION)
`
`WAIT FOR NEXT SEGMENT
`
`- 218
`
`RECQUEST NEW KEY
`
`
`
`SELECT KEY EXPRATION TIME
`
`EXPRATION
`MMINENT
`
`ENCRYPT SEGMENT WITH CURRENT
`KEY AND UPLOAD TO CDN
`
`ROTATE CURRENT KEY
`
`Fig. 2
`
`

`

`Patent Application Publication
`
`Dec. 27, 2012 Sheet 3 of 3
`
`US 2012/0331293 A1
`
`302 -
`
`INITIAL PLAYBACK REOUEST ISSUED
`
`304 -
`
`306 -
`
`CONTENT LOCATION AND
`ENCRYPTION INFORMATION
`RECEIVED
`
`RETRIEVE NEXT SEGMENT
`
`- 318
`
`RECQUEST NEW KEY
`
`308 -
`
`
`
`CHECK FOR KEY CHANGE
`NOTIFICATION
`
`EXPRATION
`MMNENT
`
`DECRYPT WITH CURRENT KEY
`
`312 -
`
`ROTATE CURRENT KEY
`
`

`

`US 2012/0331293 A1
`
`Dec. 27, 2012
`
`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 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 ofuse of a serially
`preceding content encryption key. The packaging servergen
`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 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 authorization to access the
`content item has been established. The transitioning between
`use of different keys is also referred to herein as key "rota
`tion.
`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. 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.
`0006 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
`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.
`0007. 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, /dev/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
`
`

`

`US 2012/0331293 A1
`
`Dec. 27, 2012
`
`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.
`0008. 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. In one embodiment, content encryp
`tion key identifiers 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 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 packager is responsible for providing in-band notifica
`tion 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 manifest file. In another embodiment, the
`
`manifest may be a DASHMPD 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 embodiment, the header may be a Microsoft PlayReady
`header. In another embodiment, the header may bean MPEG/
`3GPDASH header. In another embodiment, the header may
`be a proprietary segment format header.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0009. 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.
`0010 FIG. 1 is a block diagram of a content delivery
`system;
`FIG. 2 is a flow diagram showing content encryption
`0011
`and uploading using content encryption key rotation; and
`0012 FIG.3 is a flow diagram showing content download
`ing and decryption using content encryption key rotation.
`
`DETAILED DESCRIPTION
`0013. 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.
`0014. 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
`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.
`0015. 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
`
`

`

`US 2012/0331293 A1
`
`Dec. 27, 2012
`
`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.
`0016. 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. 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 segmented into
`fixed duration segment files (e.g., MPEG-TS segments, frag
`mented MP4 segments, 3GP DASH segments, etc.). In one
`embodiment, the output files, both segmented and un-seg
`mented, are encrypted using standard 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 encryption key is rotated. In another
`embodiment, IVs for the encryption protocol are not reinitial
`ized when content encryption keys are rotated. In one
`embodiment, all preparation steps are performed by a single
`content packaging server or packager 104. In another
`embodiment, individual preparation steps (e.g., transcoding,
`segmentation, encryption, etc.) may be performed across dif
`ferent 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 servers in remote data centers.
`0017. 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.
`0018. 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.
`0019 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
`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.
`(0020. 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
`
`

`

`US 2012/0331293 A1
`
`Dec. 27, 2012
`
`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.
`0021. 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).
`0022. 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 embodi
`ment, the header may be an MPEG/3GP DASH header. In
`another embodiment, the header may be a proprietary seg
`ment 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 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 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.
`0023 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.
`0024. 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.
`(0025. 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.
`0026. 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).
`0027. 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 boundary. In one embodiment, the lifespan of
`the new content encryption key is set to the remainder of the
`lifespan of the current content encryption key. In another
`embodiment, the lifespan of the new content encryption key is
`rounded up to the remainder of the lifespan of the current
`content encryption key plus one fixed key rotation period
`duration. Once the content encryption key expirations have
`been set, processing proceeds to step 210.
`(0028. In step 210, executed after step 208 or after step 206
`when no new content encryption key is received, the packager
`104 checks the expiration of current content key to see if a
`new key should be applied. If the current content encryption
`key has not yet expired or if a replacement content encryption
`key has not yet been obtained, processing proceeds to step
`214. If the current content encryption key needs to be expired
`and a replacement content encryption key is available, pro
`cessing proceeds to step 212 where the current content
`encryption key is expired and replaced with the pending con
`tent encryption key. The key expiration time from the WFM
`102 may be viewed as a