US008196214B2
`
`(12) United States Patent
`US 8,196,214 B2
`(45) Date of Patent:
`Jun. 5, 2012
`Farrugia et al.
`
`(10) Patent No.:
`
`(54) METHOD AND APPARATUS FOR SECURING
`CONTENT USING ENCRYPTION WITH
`EMBEDDED KEY IN CONTENT
`
`(75)
`
`-
`.
`.
`.
`Inventors. Augustin J. Farrugla, Cupertlno, CA
`(US); Gianpaolo Fasoli, Palo Alto, CA
`(US); Mathieu Ciet, Paris (FR);
`Bertrand Mollinier Toublet, Los Gatos,
`CA (US)
`
`(73) Assignee: Apple Inc., Cupertino, CA (US)
`
`*
`
`Notice:
`
`J
`y
`Sub'ect to an disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 941 days.
`
`(21) Appl. No.: 12/002,098
`
`CA
`DE
`EP
`EP
`EP
`
`FOREIGN PATENT DOCUMENTS
`2 649 402 A1
`11/2007
`10 2006 18 645 A1
`10/2007
`1 041 823 A2
`10/2000
`1 041 823 A3
`10/2000
`1 041 823 B1
`10/2000
`OTHER PUBLICATIONS
`
`Extended European Search Report mailed on Apr. 6, 2009, for EP
`Application 081714016, filed on Dec. 11, 2008, 5 pages.
`International Search Report mailed on Jul. 10, 2009, for PCT Appli-
`cation No. PCT/US08/l2902, filed on Nov. 18, 2008, 1 page.
`Written Opinion of the International Searching Authority mailed on
`Jul. 10, 2009, for PCT Application No. PCT/US08/l2902, filed on
`Nov. 18, 2008, 5 pages.
`
`* cited by examiner
`
`Primary Examiner 7 Nasser Goodarzi
`Assistant Examiner 7 Lisa Lewis
`
`(22)
`
`Filed:
`
`Dec. 14: 2007
`
`(74) Attorney, Agent, or Firm 7 Morrison & Foerster LLP
`
`(65)
`
`Prior Publication Data
`
`(57)
`
`ABSTRACT
`
`US 2009/0154704 A1
`
`Jun. 18, 2009
`
`(51)
`
`Int. Cl.
`(2006.01)
`G06F 21/00
`(52) us. Cl.
`......................................................... 726/30
`(58) Field of Classification Search ..................... 726/30
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`7,184,550 B2 *
`7,233,668 B2
`7,477,749 B2 *
`2003/0185397 A1
`2004/0139027 A1
`2005/0039022 A1
`2006/0177094 A1
`2007/0033419 A1
`2009/0319770 A1
`
`2/2007 Graunke ......................... 380/42
`6/2007 Weinstein et a1.
`1/2009 Pippuri
`......................... 380/284
`10/2003 Ishiguro
`7/2004 Molaro
`2/2005 Venkatesan et al.
`8/2006 Smith
`2/2007 Kocher et al.
`12/2009 Thiruvengadam
`
`Method and apparatus enabled by computer (or equivalent)
`hardware and software for protection of content such as audio
`and Video to be downloaded or streamed over a computer
`network such as the Internet. The content is provided to the
`user via streaming or downloads in encrypted form. The
`encryption is such that the content key decryption informa-
`tion is transmitted so that it itself is encrypted to be both
`device and session unique. That is, the key information can be
`used only to extract the content decryption key for a particular
`session and for a particular client device such as an audio or
`video consumer playing device. This prevents any fiuther use
`or copying ofthe content other than in that session and for that
`.
`~
`.
`.
`.
`.
`.
`particular client. The spe01fi01ty IS accompllshed by usmg a
`device unique identifier and antireplay information which is
`session specific for encrypting the content key. A typical
`application is Internet streaming of audio or video to consum-
`er5'
`
`18 Claims, 5 Drawing Sheets
`
`
`
`5<3
`.5N
`t
`.5a)
`5a:
`aw0
`UIto
`orat
`u-m
`cuto
`m4»
`ma
`ua
`a.m
`
`1‘
`
`Client SelectsAsset from Store
`
`Gateway Sends Client the URL ofArray
`Gateway RequestsAsset from Content Provider
`Content Provider Streams Asset to Client
`Client Receives Stream
`Client Extracts Dki from Stream
`
`Client Assembles its Playback Request and Sends it
`Gateway Verifies Dki
`Gateway Opens Dki
`Gateway Repeckages Dki» D'kt
`Sends D'ki to Client
`Client Verifies D'ki
`
`Client Extracts Content Key from D'ki
`Client DecryptsAsset
`Client Plays Asset
`
`
`
`Apple Exhibit 4247
`
`Apple V. SightSound Technologies
`CBM2013-00020
`
`Page 00001
`
`Apple Exhibit 4247
`Apple v. SightSound Technologies
`CBM2013-00020
`Page 00001
`
`

`

`U.S. Patent
`
`Jun. 5, 2012
`
`Sheet 1 of 5
`
`US 8,196,214 B2
`
`coszavE.
`
`>=._:omw
`
`Eb.29em:“82
`
`vwfibocw
`
`3:30me
`
`.5.me
`
`>m>>2m0
`
`52mm
`
`A999
`
`EczemwwHmwm<EEO
`
`coszhouE.
`
`
`
`“$2#952
`
`22w2¢
`
` RE28$
`Emzu
`
`om.
`
`_..9".
`
`
`
`NV5.25525:50
`
`Uwuqbocm
`
`6mm<
`
`3052531
`
`StowBmwm<
`
`azoa
`
`.w_m_9mEEoO
`
`Page 00002
`
`Page 00002
`
`
`
`
`
`
`
`

`

`US. Patent
`
`Jun. 5, 2012
`
`Sheet 2 015
`
`US 8,196,214 132
`
`.b O
`
`4sN
`
`Client Selects Asset from Store
`
`Gateway Sends Client the URL of Array
`
`|#|
`
`A
`
`Gateway Requests Asset from Content Provider
`
`4: 0)
`
`A 00
`
`U101
`
`01 0)
`
`01 00
`
`CD[\J
`
`O).b
`
`0) CD
`
`\l 0
`
`\l N
`
`\l.1}.
`
`Content Provider Streams Asset to Client
`
`Client Receives Stream
`
`Client Extracts Dki from Stream
`
`Client Assembles its Playback Request and Sends it
`
`Gateway Verifies Dki
`
`Gateway Opens Dki
`
`Gateway Repackages Dki —-> D'ki
`
`Sends D'ki to Client
`
`Client Verifies D'ki
`
`Client Extracts Content Key from D'ki
`
`Client Decrypts Asset
`
`Client Plays Asset
`
`FIG. 2
`
`Page 00003
`
`Page 00003
`
`

`

`US. Patent
`
`Jun. 5, 2012
`
`Sheet 3 015
`
`US 8,196,214 132
`
`(ID00#|.
`
`Assets in Storage
`
`Content Provider Receives Asset Request
`
`CD 0)
`
`CD CO
`
`(0 0
`
`(0.b
`
`(O 6
`
`100
`
`102
`
`_l 04
`
`_s O m
`
`Verify Gateway MAC
`
`Send Encryption Request to Gateway
`witrh Certificate and AR
`
`Gateway Verifies Certificate
`
`Gateway Generates Content Key, Eki, Dki
`
`Send Eki, Dki to Content Provider
`and Response Integrity
`
`Content Provider Inserts Dki into Header
`
`Encrypt Asset Using Eki
`
`Post Encrypted Asset
`
`Stream Encrypted Asset to Client with Header
`
`FIG. 3
`
`Page 00004
`
`Page 00004
`
`

`

`US. Patent
`
`Jun. 5, 2012
`
`Sheet 4 015
`
`US 8,196,214 132
`
`30'\‘
`
`12
`
`
`
`122
`
`Processor
`
`Decryption
`Information
`Memory (Dki)
`
`130
`
` Content
`
`
`
`
`Memory
`
`(Encrypted)
`
`
`
`
`
`
`
`
`
`
`Content
`Decrypted
`
`Content
`
`
`
`Playback portion
`(Decompress, Decode)
`
`Decryptor
`
`Content key
`
`132
`
`
`
`Audio
`Output
`
`Video
`Output
`
`FIG. 4
`
`Page 00005
`
`Page 00005
`
`

`

`US. Patent
`
`Jun. 5, 2012
`
`Sheet 5 015
`
`US 8,196,214 132
`
`34\‘
`
`12
`
`Menu
`Memory Store
`
`142
`
`
`Content
`Provider
`
`Verification
`
`150
`
`Generator of
`Eki,Dki,D'ki
`
` 144
`
`
`
`
`
`
`154
`
`Gateway Key
`Store
`
`
`
`FIG. 5
`
`Page 00006
`
`Page 00006
`
`

`

`US 8,196,214 B2
`
`1
`METHOD AND APPARATUS FOR SECURING
`CONTENT USING ENCRYPTION WITH
`EMBEDDED KEY IN CONTENT
`
`FIELD OF THE INVENTION
`
`This invention relates generally to copy protection of digi-
`tal files and more specifically to protecting digital files using
`encryption, and to key management for that encryption.
`
`BACKGROUND
`
`Systems such as “Apple TV” are well known. Apple TV is
`a digital media receiver designed and sold by Apple, Inc. It is
`a networked device intended to play digital content such as
`audio and/or Video provided from any associated Macintosh
`or Windows client type computer. Typically the client com-
`puter is one executing the “iTunes” client. The Apple TV
`connects to the client computer (which is connected to the
`Internet for receipt of the video) and stores and plays the
`video, for instance, on an enhanced definition or high defini-
`tion television. The Apple TV device stores content which are
`the audio or video files on an internal hard disk drive. The
`
`Apple TV device connects to a television or other video
`equipment, for instance, through high definition multimedia
`interface (HDMI) or component video connections. The
`Apple TV is somewhat similar to the Apple iPod. It is paired
`with an iTunes library on the client computer and can syn-
`chronize with that library, copying content to its own hard
`disk drive. Thus Apple TV and similar products allow one to
`obtain, for instance, video materials such as television pro-
`grams or movies, from an online “store” such as the iTunes
`Store operated by Apple, Inc. Other such stores also exist. The
`material provided may be in the form of a download or
`streaming video or audio. Typically the connection with the
`store is via the Internet. Of course, other similar products are
`available which may be integrated with a computer, or are
`dedicated devices not requiring a general purpose computer
`but providing the same functionality of obtaining video and
`audio content via the Internet such as the Apple Inc. “iPhone.”
`Typically the content provided is protected against misuse.
`A typical means of this protection is encryption. That is,
`material as provided to the Apple TV or similar client device
`is encrypted. A decryption key is conventionally provided so
`that the material may be decrypted. Managing the keys is a
`significant technical problem. Obviously if all instances of
`the downloaded or streamed material have the same key for
`all users, this is not secure enough since the key could be
`publicly available. Thus some form of key management is
`typically provided.
`However, satisfactory forms of key management are prob-
`lematic especially given a large number of users and hence a
`large number of keys being required. While encryption secu-
`rity in this context need not be airtight, a certain degree of
`security is necessary since audio and video content have to be
`protected against hacking.
`
`SUMMARY
`
`In accordance with this disclosure, downloaded or stream-
`ing video or audio content is provided in encrypted form to a
`user via a client device. The material is provided to the device
`in encrypted form. The associated decryption is such that the
`decryption (key) information is both unique to the particular
`device and also to a particular session or connection time.
`Thus the material as streamed or downloaded to the particular
`user is not usable, that is, cannot be decrypted, at another time
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`even on the same client device and cannot be used even at the
`
`same time on another client device due to the encryption. The
`copy protection using the encryption is thereby unique in
`terms of the client and the session. This is especially advan-
`tageous for use in the streaming video situation.
`As well known, streaming video or streaming multimedia
`is continuously received by and normally displayed at an end
`user (client) while it is being delivered by the provider. Typi-
`cally streaming media is delivered over a telecommunications
`network such as the Internet. There are well known protocols
`for streaming media such as real time streaming protocol, real
`time transfer protocol and real time transport control protocol
`intended to stream media over networks. These are “on top”
`of the well known UDP which sends the media stream as a
`
`series of small packets. Typically streaming video and audio
`is compressed using well known compression techniques.
`The present system is compatible with these protocols but not
`so limited.
`
`The present system is intended to ensure that if a streaming
`video, for instance, is recorded, that is, stored by the client, the
`stored material is as of no use because it cannot be decrypted
`due to the key management in accordance with this disclo-
`sure. Misuse is a well known problem with streaming video
`since typically the supplier (content provider) intends to pre-
`vent recordation or reuse by the original client or by another
`client. It is well known to make it inconvenient to record a
`
`stream by using unpublished data formats or by encrypting
`the stream.
`
`Note that often in the present commercial environment,
`downloaded videos such as those sold through the iTunes or
`other online media stores are made available for storage and
`replay, at least by a single client. In contrast, other types of
`videos are typically intended only for streaming purposes and
`immediate single viewing such as current television pro-
`grams. One reason for this is that the streaming television
`programs are provided with advertising commercials, often
`on a no charge basis, and the content provider expects the
`viewer to be watching the commercials. Hence the present
`system is especially suitable for this sort of streaming video or
`audio situation where portions of the material may be of little
`or no interest to the user but it is important to the content
`provider that the user be forced to encounter them. By pre-
`venting the user from recording and later viewing the content,
`that is making the streaming session unique, the problem of
`commercial skipping is prevented. However, the present sys-
`tem is also applicable to downloads.
`Briefly, the present system in one embodiment operates in
`the context of conventional streaming video over the Internet.
`A particular audio or video (“asset”) such as a television
`program or movie is compressed using a well known format
`and then encrypted using a content key as is conventional. The
`encrypted asset is then posted to a server accessible by users
`(via the Internet) and downloaded in conventional streaming
`fashion over the Internet to a client device in which is resident
`
`suitable client software. A typical client device is the Apple
`TV product. Also involved is a gateway server also referred to
`as an online store as described above which acts as a com-
`
`mercial intermediary between the client and the content pro-
`vider. However, there is no requirement that any money actu-
`ally be paid by the user. In some cases the gateway server in
`this case only has control function and security functions
`rather than acting as a revenue collection entity.
`In any case, rather than simply encrypting the asset with a
`content key which is provided to the client and which is not
`very secure, instead the key management is made more com-
`plex so that the required key information is both session and
`client unique. This is done using a combination ofkey encryp-
`
`Page 00007
`
`Page 00007
`
`

`

`US 8,196,214 B2
`
`3
`tion, key decryption, antireplay mechanisms, and altering the
`key information so that the key needed to decrypt the key
`itself includes both antireplay information and a identifier
`unique to each client device. Thereby the streamed material
`can be successfully decrypted only by a particular client for a
`particular session. A recorded version of the streaming Video
`would not be decryptable by any other client or even at a later
`time by the original client. This meets the goal of requiring
`each individual that wishes to watch a particular streaming
`Video to uniquely stream it from the content provider. This 10
`also meets the goal that commercials or other material asso-
`ciated with the streaming material and of little (or less) inter-
`est to the client user must be encountered by the client user
`while he views the streaming material itself. Hence this copy
`protection is especially useful in the environment of, for
`instance, television programs or movies with associated com-
`mercial messages.
`
`15
`
`5
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`20
`
`FIG. 1 shows a system in which the present method can be
`carried out with the associated computer implemented enti-
`ties.
`
`FIG. 2 shows in a flow chart the sequence of action in
`accordance with the present method in the streaming or other 25
`download process between the client device and the gateway
`or online store.
`
`FIG. 3 shows in a flow chart the sequence of actions in
`accordance with the present method between the content
`provider and the gateway or online store.
`FIG. 4 shows the client of FIG. 1 in a block diagram.
`FIG. 5 shows the gateway of FIG. 1 in a block diagram.
`
`DETAILED DESCRIPTION
`
`30
`
`35
`
`FIG. 1 shows in a block diagram the environment in which
`the present method and apparatus operate. This is generally in
`the form of a computer implemented network with the Inter-
`net 12 being the communications channel. The protocols used
`for communications there over are described above and con- 40
`
`ventional in the field of downloads and streaming content
`such as digital files including audio, video and other types of
`data. The method and apparatus disclosed here are not limited
`to streaming or to audio and/or video, but are generally useful
`for protecting data. To the left hand side of the Internet 12 in 45
`FIG. 1 is the content provider entity 16. This is not per se an
`apparatus, but is an entity such as, e.g., a commercial entity
`such as a movie studio, television network, etc. Content pro-
`vider 16 has under its control a file store 20, typically a
`computer server, on which are stored a large number of con- 50
`tent assets. The file store 20 stores, for instance, a large
`number of videos, audios, television programs, movies, etc.,
`each in typically in some well known format such as the
`MPEG-4 compressed format, although the compression is
`not a requirement. These stored files are “in the clear” that is 55
`unencrypted and in this state are for the internal use of the
`content provider.
`As explained further below, each asset (a video or televi-
`sion program or movie) is one-by-one transmitted over a
`secure communications channel under control of the content 60
`
`provider 16 to a security server 22, the functionality which is
`described below. One function of the security server 22 is to
`conventionally encrypt the asset using a content encryption
`key as further described below. The mere routine encryption
`of an asset using a content key is well known. Exemplary 65
`types of encryption that are suitable are further described
`below. The encrypted asset is later provided over another
`
`4
`
`secure communication channel to a published asset store
`(server) 26. This particular server 26 is accessible via the
`Internet 12 by conventional connections as is, e.g., an Internet
`cache host or a streaming server. As explained further below,
`the encrypted asset
`is eventually streamed (or in some
`embodiments downloaded) from the published asset server
`26 via the Internet. As shown, this encrypted asset is trans-
`ferred ultimately to a client device 30 such as an Apple TV
`device. Device 30 is a hardware device with resident client
`
`software which chiefly operates, as does any conventional
`client, for playing streaming video and that also has the secu-
`rity aspects further described herein for decryption, since the
`asset is distributed in an encrypted form.
`Client 30 is connected typically also via the Internet 12 to
`what is referred to here as a gateway server (“gateway”) 34.
`Server 34 is another server (computer platform) with resident
`software as described further herein. Most of the operations
`of gateway server 34 are those carried out by a typical online
`or Internet media/audio/video commercial vendor such as the
`
`iTunes Store operated by Apple Inc.
`In accordance with this disclosure, the gateway server car-
`ries out security functions in terms of providing security
`information for the asset decryption and encryption to the
`client 30 and to the security server 22. The security informa-
`tion as shown here includes encryption information Eki,
`decryption information Dki, and altered decryption informa-
`tion D'ki. This is explained further below. Note that most of
`the functionality shown in the FIG. 1 system for downloading
`and/or streaming video is conventional and not described here
`in any detail. The remainder of this disclosure focuses on the
`security features for protecting the assets. Note that while
`here the security server 22 is shown as being under the control
`of the content provider entity 16, this is not necessarily the
`case and the security server 22 could be operated by another
`entity or supplied by another entity. The interaction between
`the security server 22, the gateway server 34 and the client 30
`constitute the security transactions in accordance with this
`disclosure for protection of the assets.
`The term “server” is used in its normal meaning in the
`computer field. It refers generally to a computer connected to
`a network such as the Internet. Typically the computer
`includes memory such as a hard disk which stores data and
`other types of files. The server computer, otherwise known as
`a platform or hardware, executes particular server software
`which carries out the server function. Servers of this type
`embodied in hardware and software are available from a
`number of well known vendors and are routine in the field of
`
`computer networks.
`The nature of the client is also described above. Generally
`the term “client” here refers to a consumer electronics device
`
`(including a computer) which executes client software and
`connects to the Internet, either directly or via a client com-
`puter (not shown) for in this case obtaining video and/or audio
`files (assets).
`Gateway server 34 is another server and typically includes
`a large number of actual servers, all interconnected and oper-
`ated by a vendor of content such as the iTunes store operated
`by Apple, Inc. Generally the description here does not specify
`how the actual assets are transferred or used since that is
`
`routine in the field. Also note that there may be other security
`aspects in the FIG. 1 system since such content typically
`protected by what is called in the field DRM (Digital Rights
`Management), which provides, in addition to content encryp-
`tion, various other types of protective mechanisms to prevent
`content misuse.
`
`The following explains operation of the FIG. 1 system in
`two parts. The first part is transactions between the client 30
`
`Page 00008
`
`Page 00008
`
`

`

`US 8,196,214 B2
`
`5
`and the gateway server 34, that is the client side (see FIG. 2).
`The second part is transactions between the gateway server 34
`and the content provider 16 (see FIG. 3). However, note that
`these are interleaved in time and that the activities on one side
`do not all occur before the other. However, in each of FIGS. 2
`and 3 the activities occur generally in the order shown within
`each figure.
`Each of the elements shown in FIG. 1 which include the
`
`security server 22, the gateway server 34 and the client 30
`execute resident software which carries out, in combination,
`the functionality of FIGS. 2 and 3. Therefore this system
`requires what is referred to generally as a “compliant” client
`30 to carry out the functionality ofFIGS. 2 and 3 and similarly
`compliant servers 22 and 34, so these, while they are based on
`conventional software and hardware, have been modified
`(typically in terms of the software) to perform the function-
`ality and operations described herein.
`Generally therefore each ofthese elements includes a com-
`puter program also referred to as code or software code or
`software which is a series of computer instructions. Program-
`ming the code for each of these elements to carry out this
`functionality is well within the skill of one of ordinary skill in
`the art in light of this disclosure. Typically the software is
`coded in the C or C++ computer languages or other similar
`languages. The servers 22, 34 and client 30 typically store
`only compiled versions of this code, that is the machine or
`object code, which is also conventional in the field. Moreover,
`the system is subject to other software security approaches
`such as, for instance, code obfuscation to prevent hackers
`from reverse engineering or understanding the software,
`especially the client 30 software. The security server 22 and
`the gateway server 34 typically are under control of commer-
`cial entities who are interested in protecting the content. In
`some situations (as in FIG. 1) the security server 22 is under
`separate control than is gateway 34 and therefore the security
`server 22 software may also be subject to protection to pre-
`vent tampering by content provider 16. In some cases the
`security server 22 is actually supplied to the content provider
`10 by the entity that operates or owns the gateway server 34.
`Therefore FIG. 2 depicts in flow chart form the operations
`in terms of security occurring between the client 30 and the
`gateway server 34. At 40 the client (actually the user of the
`client, who is a person) selects an asset from the online “store”
`which is part of the gateway server 34. For instance this is the
`iTunes Store and is accessed by the conventional iTunes client
`software resident on the client 30. This selection involves the
`
`client forming an Internet connection with the gateway server
`34 and then accessing a web page menu which lists all content
`available from gateway server 34. The client user typically
`selects an item (asset) by clicking on its place in the menu,
`indicating an interest in obtaining the item. When the client
`user browses the iTunes store at gateway 34 upon selection of
`the particular item of content such as a movie or television
`program, the client 30 device informs the gateway 34 of its
`GUID and what content it wishes to view, sometimes referred
`to as the item identification. This operation initiates a syn-
`chronous channel between the gateway and the client which,
`for instance, is a conventional http/tcp connection.
`At 42 in response the gateway 34 transmits to the client 30
`the Internet location Universal Resource Locator (URL) of
`the asset at the server 26. This URL is a typical Internet type
`address. It typically references a content item to be stored in
`the published assets store 26, further described hereinafter. In
`more detail, the gateway 34 transmits back along the synchro-
`nous channel the asset information which is, for instance, in
`the form of an XML message of the type well known in the
`computer field containing a URL to the encrypted asset (the
`
`5
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`streaming URL), a URL to the asset’s commercials (a down-
`load URL) and a URL to the policy (also a download URL).
`The client 30 is told from where to fetch the content by
`following or downloading this streaming URL. This stream-
`ing URL may point to a server under control of the content
`provider or to a hosting server. This XML message may be
`signed and if that is the case, the client 30 verifies the signa-
`ture. Typically this is an RSA signature verified with an X509
`certificate. Since the XML is being sent by the gateway
`server, it should be the gateway server’s certificate and it is
`generally the gateway that computes this signature which is
`for instance a conventional RSA type signature. Note that the
`downloaded policy is later verified and enforced as ofthe start
`of playback at the time of decryption by the client as
`described further below. At 44 the client requests from the
`content provider 16 the particular selected asset by passing
`the item identification of the selected asset to the content
`
`provider. At 46 the content provider 16 begins to transfer
`(e.g., stream) the encrypted requested asset, which is a video
`or audio typically, to the client from published assets server
`26. These assets are each encrypted as further described
`below. This is a routine Internet enabled transfer of content.
`
`The downloaded policy is a set ofrules which describe how
`the associated downloaded commercials should be played, at
`what times they should be played in the asset, and whether the
`user of the client can skip and/or fast forward through the
`commercials. The nature of the policy can be determined by
`the gateway 34, the content provider 16 or other entities. Note
`that in this case the commercials are not per se part of the
`published asset, that is, they are usually not encrypted. More-
`over, typically the commercials are not subject to streaming,
`but are downloaded. Of course, there is no reason to provide
`security for the commercials since copying or recording of
`same is unlikely (and even desirable). Typically the policy
`ensures that the asset when played by the client must include
`the commercials.As pointed out above, it may be allowed that
`the user can skip or fast forward through the commercials but
`typically the policy does not allow this. Hence the commer-
`cial file management is not subject to the security aspects as
`described herein and is essentially conventional. Therefore
`there will be no further description here ofthe commercials or
`their use or the policy. It is understood that commercials are
`each played during a pause in the content, e.g. a movie.
`At 48 the client 30 receives via the Internet 12 (which is the
`communications network here) the as set as a streaming audio
`or video or other form. Streaming is not required; this transfer
`may be a download in other embodiments, but streaming is
`preferred because it reduces the chance of tampering or hack-
`ing with the asset. The policy and commercials are also dis-
`tributed to the client at this time via downloads from their
`
`server (not shown).
`The asset includes, typically as a header file or a header,
`certain key decryption information designated here Dkf. This
`key information is needed for the decryption by the client of
`the encrypted as set. As soon as the client has streamed enough
`of the asset it extracts there from the decryption information
`Dki. The client extracts this decryption information Dkl. from
`the asset header which itself is typically not encrypted. In one
`embodiment the decryption information Dkl. is a generic pro-
`tected version of the content (asset) decryption key. This
`content key is the key required to decrypt the as set and (in the
`case of a symmetric cipher) is also used by the security server
`22 to encrypt the plain text content from asset store 20. In one
`embodiment the encryption technique is the well known AES
`encryption which is a commercially available symmetric
`cipher. Of course, use ofAES is not limiting. For instance, the
`content may be encrypted using other symmetric (private
`
`Page 00009
`
`Page 00009
`
`

`

`US 8,196,214 B2
`
`7
`key) ciphers or public/private key encryption of the type
`provided commercially by RSA. In this example to express
`this logically, the decryption information Dki:AES_encrypt
`(key :gateway key 01, data:content key). In other words, in
`this case the decryption information Dkl. has as its kernel
`(data) the content key. In this case the asset is encrypted with
`the same content key for all audio and Video streams, and the
`content key is not session specific or device specific in terms
`of the client. That is, there is typically only one version of the
`published asset held in the published asset server 26 and this
`is encrypted with the content key which is typically an AES
`type encryption/decryption key.
`The gateway keys 01, 02, etc. are AES keys generated by
`the gateway server 34 and stored there. They are used to
`encrypt the content key, that is to produce the value Dki. The
`gateway key number i (index) is one out of 11 possible 128-bit
`AES gateway keys. The intention is not to encrypt each con-
`tent key with the same AES gateway key since that poses a
`security risk in case of compromise. One way to solve this is
`to have a set of11 possible l28-bitAES keys stored in memory
`in the gateway server and randomly or rotationally pick one
`out of 11 each time the gateway has to create a set of Dkl.
`decryption information. Also, the Dkl. decryption information
`is signed (via a conventional digital signature) by the gateway
`server 34 when the gateway server generates Dki.
`Next at 52 the client having extracted the Dkl. information
`assembles playback request which includes the decryption
`information Dk,, antireplay information AR, and the client
`GUID (global unique identifier) and sends it to the gateway.
`Antireplay is a well known technology used to make content
`downloads and stream session specific. It typically involves
`some session unique aspect such as a random number or a
`time stamp. There are many known generic and proprietary
`antireplay (AR) mechanisms suitable for use herein. AR
`information conventionally guarantees that a session is intact.
`If the upstream and downstream antireplay information dif-
`fers, the session is considered broken or compromised and is
`terminated. It is a value or designator uniquely associated
`with the client. An example of this is a device MAC (Media
`Access Control) address. It serves in effect as a unique serial
`number for each client. The combination of the antireplay
`information AR and client GUID renders the playback
`request both session and device specific.
`At 56 the gateway verifies the decryption information Dkl.
`by, e.g., a conventional RSA digital signature verification.
`After verifying the integrity and authenticity of decryption
`information Dk, at 58, the gateway extracts the decryption
`information Dkf and decrypts it to extract there from the
`content key by means ofABS decryption.
`At 62 the gateway server “repackages” or alters the decryp-
`tion information Dkl. to a new form Dk'i. Expressed in logical
`form as
`above, Dk'l.:AES_encrypt(key:GUID+AR,
`data:content key). Thus Dk'l. is in effect the content key which
`is the data, encrypted using as a key the string which is a
`derivation or concatenation of the client GUID with the ses-
`
`sion AR information to produce a 16 bit AES key. This key
`length and the use of ABS are merely illustrative.
`Then at 64 the gateway server sends this “repackaged”
`value of Dk'l. back to the client.
`Then at 68 in FIG. 2 the client verifies the repack-
`aged decryption information Dk'i. This is typically an
`HMAC_SHA1 integrity check or done implicitly by decryp-
`tion since the GUID and AR information are unique to that
`client and session. After verifying, the client performs the
`inverse
`(decryption