U.S. patent application number 11/011241 was filed with the patent office on 2006-06-15 for systems, methods, and media for adding an additional level of indirection to title key encryption.
Invention is credited to Julian A. Cerruti, Matthew Francis Rutkowski, Amal Ahmed Shaheen.
Application Number | 20060126831 11/011241 |
Document ID | / |
Family ID | 36583874 |
Filed Date | 2006-06-15 |
United States Patent
Application |
20060126831 |
Kind Code |
A1 |
Cerruti; Julian A. ; et
al. |
June 15, 2006 |
Systems, methods, and media for adding an additional level of
indirection to title key encryption
Abstract
Systems, methods and media for encrypting and decrypting content
files are disclosed. More particularly, hardware and/or software
for adding an additional level of indirection to a title key
encryption scheme are disclosed. Embodiments may include generating
by a cryptographic system a binding key based on binding
information. Embodiments may also include encrypting by the
cryptographic system a secret key with the binding key and
generating a title key associated with at least one content file.
Embodiments may also include encrypting by the cryptographic system
the title key with the secret key and the at least one content file
with the title key. Further embodiments may include receiving an
indication that the binding information has changed, generating a
new binding key based on the new changed binding information, and
re-encrypting the secret key with the new binding key.
Inventors: |
Cerruti; Julian A.; (San
Jose, CA) ; Rutkowski; Matthew Francis;
(Pflugerville, TX) ; Shaheen; Amal Ahmed; (Austin,
TX) |
Correspondence
Address: |
IBM CORPORATION (JSS);C/O SCHUBERT OSTERRIEDER & NICKELSON PLLC
6013 CANNON MOUNTAIN DRIVE, S14
AUSTIN
TX
78749
US
|
Family ID: |
36583874 |
Appl. No.: |
11/011241 |
Filed: |
December 14, 2004 |
Current U.S.
Class: |
380/30 ; 380/37;
380/44 |
Current CPC
Class: |
H04L 9/0891 20130101;
H04L 2209/60 20130101; H04L 9/0841 20130101 |
Class at
Publication: |
380/030 ;
380/044; 380/037 |
International
Class: |
H04L 9/30 20060101
H04L009/30; H04L 9/00 20060101 H04L009/00; H04K 1/00 20060101
H04K001/00; H04K 1/06 20060101 H04K001/06; H04K 1/04 20060101
H04K001/04 |
Claims
1. A method for encrypting one or more content files, the method
comprising: generating by a cryptographic system a binding key
based on binding information; encrypting by the cryptographic
system a secret key with the binding key, the secret key being
associated with the one or more content files; generating by the
cryptographic system a title key associated with at least one
content file; encrypting by the cryptographic system the title key
with the secret key; and encrypting by the cryptographic system the
at least one content file with the title key.
2. The method of claim 1, further comprising: receiving by the
cryptographic system an indication that the binding information has
changed from a source; generating by the cryptographic system a new
binding key based on the new changed binding information;
re-encrypting by the cryptographic system the secret key with the
new binding key; and updating by the cryptographic system a state
of the one or more content files in response to the re-encrypted
secret key.
3. The method of claim 1, further comprising storing by the
cryptographic system one or more of the encrypted content, the
encrypted title key, and the encrypted secret key.
4. The method of claim 1, further comprising transmitting by the
cryptographic system one or more of the encrypted content, the
encrypted title key, and the encrypted secret key.
5. The method of claim 1, further comprising updating by the
cryptographic system a state of the one or more content files in
response to the secret key.
6. The method of claim 1, wherein the generating the binding key
step comprises: wherein the binding information comprises a media
key block and a binding identifier; processing by the cryptographic
system the media key block using a set of device keys to produce a
media key; and producing by the cryptographic system the binding
key based on the media key and the binding identifier.
7. The method of claim 1, wherein the generating the binding key
step comprises performing a Diffie-Hellman key exchange by the
cryptographic system to establish a session key, wherein the
established session key is used as the binding key.
8. The method of claim 1, wherein the generating the binding key
step comprises performing a Public Key-Private Key exchange by the
cryptographic system to establish a session key, wherein the
established session key is used as the binding key.
9. The method of claim 1, wherein the one or more content files
comprises one or more of an audio data file, a video data file, a
media data file, a streaming media file, an application file, a
text file, or a graphic file.
10. A method for decrypting an encrypted content file, the method
comprising: accessing by a cryptographic system an encrypted secret
key and an encrypted title key; generating by the cryptographic
system a binding key based on binding information; decrypting by
the cryptographic system the encrypted secret key with the binding
key to recover a secret key; decrypting by the cryptographic system
the encrypted title key with the secret key to recover a title key;
and decrypting by the cryptographic system the encrypted content
with the title key.
11. The method of claim 10, wherein the accessing step comprises
receiving by the cryptographic system the encrypted secret key and
the encrypted title key from a source.
12. The method of claim 10, wherein the generating the binding key
step comprises receiving by the cryptographic system the binding
information from a source.
13. The method of claim 10, wherein the generating the binding key
step comprises: wherein the binding information comprises a media
key block and a binding identifier; processing by the cryptographic
system the media key block using a set of device keys to produce a
media key; and producing by the cryptographic system the binding
key based on the media key and the binding identifier.
14. The method of claim 10, wherein the generating the binding key
step comprises performing a Diffie-Hellman key exchange by the
cryptographic system to establish a session key, wherein the
established session key is used as the binding key.
15. The method of claim 10, wherein the generating the binding key
step comprises performing a Public Key-Private Key exchange by the
cryptographic system to establish a session key, wherein the
established session key is used as the binding key.
16. A data processing system for encrypting one or more content
files, the system comprising: a reception system, the reception
system being adapted to receive information from a source; a
transmission system, the transmission system being adapted to
transmit information to a recipient; a binding key system, the
binding key system being adapted to generate a binding key from
binding information; a secret key system, the secret key system
being adapted to access a secret key and to encrypt the secret key
using the generated binding key; a title key system, the title key
system being adapted to generate a title key and to encrypt the
title key with the secret key; and an encryption/decryption system,
the encryption/decryption system being adapted to encrypt the one
or more content files using the title key.
17. The system of claim 16, wherein the reception system is further
adapted to receive an indication that the binding information has
changed.
18. The system of claim 16, wherein the binding information
comprises a media key block and a binding identifier, and wherein
the binding system is further adapted to process the media key
block using a set of device keys to produce a media key and to
produce the binding key based on the media key and the binding
identifier.
19. The method of claim 16, wherein the binding system is further
adapted to perform a two-way key exchange to establish a session
key, and wherein the established session key is used as the binding
key.
20. The system of claim 16, wherein the secret key system is
further adapted to decrypt an encrypted secret key, wherein further
the title key system is further adapted to decrypt the encrypted
title key with the secret key, and wherein further the
encryption/decryption system is further adapted to decrypt the one
or more content files using the title key.
Description
FIELD OF INVENTION
[0001] The present invention is in the field of data encryption.
More particularly, the present invention relates to systems,
methods and media for adding an additional level of indirection to
title key encryption mechanisms used for content encryption.
BACKGROUND
[0002] As the use of digital technology becomes more pervasive,
content such as television programming, music, and movies are being
increasingly delivered to consumers in digital format. Content
owners, such as record labels, studios, distribution networks, and
artists, desire for their content to only be used by certain users
or in certain ways. Protecting the copyrights of these content
owners from indiscriminate reproduction and distribution poses a
considerable challenge in the digital age, as exact duplicates of
the content may often be easily created and transmitted to other
users.
[0003] Content protection schemes for digital media attempt to
protect the content enough to discourage at least casual violations
of the content copyright while minimizing the cost and processing
power necessary to implement the scheme and making the process as
transparent to users as possible. One common type of content
protection scheme is to encrypt the content with a key. A recipient
of the encrypted content with a copy of the key may decrypt and
access the content, while a recipient without a copy of the key
(such as a third party attempting to improperly access the content)
will be unable to decrypt and access the content. The content owner
may also revoke a key if it believes the key has been jeopardized,
reducing the ability for users to distribute keys to others (such
as by posting the keys on the Internet).
[0004] Broadcast encryption schemes allow digital delivery of
encrypted content without requiring two-way communication between
the recipient and source, eliminating the two-way communications
(such as handshakes) necessary for many public distribution systems
while potentially improving security. By eliminating two-way
communications, the potentially expensive return channel on a
receiver may be eliminated, lowering overhead and costs for device
manufacturers and users. A home network, for example, that shares
content among a cluster of different recording or playback devices,
such as stereos, personal computers, and televisions, may use a
broadcast encryption scheme to protect content in different forms
of storage from unauthorized use. Some broadcast encryption
schemes, such as International Business Machine Corp.'s (IBM's)
eXtensible Cluster Protocol (xCP), provide for binding protected
content to a dynamic cluster of networked recording and playback
devices, allowing for the content to be managed under a single
protection scheme independent of particular storage or transmission
interfaces and protocols. Content in IBM's xCP scheme may move
freely among devices in the domain but will be useless to devices
outside the domain. Other examples of broadcast encryption
applications include Content Protection for Recordable Media (CPRM)
media, Content Protection for Pre-Recorded Media (CPPM) media, and
Advanced Access Content System (AACS) next-generation media.
[0005] Broadcast encryption schemes bind a piece of content to a
particular entity, such as a piece of media, a server, or a user.
Broadcast encryption binds the content by using a media key block
(also known as a key management block KMB or session key block)
that allows compliant devices to calculate a cryptographic key (the
media or management key, or Km) using their internal device keys
while preventing circumvention (non-compliant) devices from doing
the same. Broadcast encryption does not require authentication of a
device and can be implemented with symmetric encryption, allowing
it to be much more efficient than public key cryptography. After
calculating a media key Km by processing the media key block (MKB),
the scheme uses the media key Km to bind the content to an entity
(with a binding identifier IDb), resulting in the binding key (Kb).
A title key (Kt) is then chosen and encrypted with the binding key
Kb, resulting in an encrypted title key (EKt). The content itself
may then be encrypted with the title key Kt and the encrypted
content may be stored with the encrypted title key EKt. A compliant
device that receives the encrypted content and the encrypted title
key EKt may use the same MKB and the binding identifier IDb to
decrypt the content. The compliant device first may reproduce the
same binding key Kb using the MKB, the binding identifier IDb and
its device keys, and then decrypts the title key Kt from the
encrypted title key EKt using the binding key Kb. Once the
compliant device has the title key Kt, it may decrypt the content
itself. A circumvention device will not have device keys that can
be used to process the MKB and thus will not be able to reproduce
the binding key Kb or be able to decrypt the content. Also, if the
content has been copied to a different entity with a different
identifier IDb' by a non-compliant device, the compliant device
with valid device keys will not be able to calculate the correct
binding key Kb because the binding identifier IDb' is different
than the original one.
[0006] While the above broadcast encryption scheme provides an
effective mechanism for providing encrypted broadcast content to a
group of devices, it suffers from some disadvantages. For example,
the encryption of the content depends upon the MKB and binding
identifier IDb used in the process of encrypting the content,
either of which may change frequently under certain circumstances.
New MKB's which revoke non-compliant devices may be introduced into
a system in some cases, changing the system MKB. If devices are
added to or leaves a cluster, the binding identifier IDb changes
(by changing the authorization table, one of its components). If
either the MKB or binding identifier IDb of a particular entity
change, any piece of content that is bound to this entity using a
binding key Kb dependent upon them must have its title key
re-encrypted using the new values so that compliant devices will
still be able to access the content. If there are large amounts of
content that need to be changed, re-encryption of the title keys Kt
for each of them will require significant amounts of processing
time. For content files that are shared over a network, there may
also be remote synchronization problems. An arbitration mechanism
would be required to ensure that only one device performs the
re-encryption of the title keys for a particular piece of
content.
[0007] The problems described above are exacerbated on many network
content-sharing systems with large numbers of small content files,
such as home-based or consumer networks. Content is typically
delivered to consumers in many small files which results in a very
large number of files on a home network. For example, each song on
a music album may be a separate file (and thus have a separate
encrypted title key) and a user may have hundreds or thousands of
songs. Consumer devices, such as stereos or video players, also
typically have relatively small amounts of processing power. The
combination of the large number of files to be re-encrypted and the
lower capability of consumer devices results in a very inefficient
and time-consuming procedure that must be performed each time
binding information changes. The problems described above may also
occur in Advanced Access Content Systems (AACS) and 4C Entity LLC's
Content Protection System Architecture (CPSA) recordable media
where several files may be stored and new MKB's may be introduced
into the system.
[0008] There is, therefore, a need for an effective and efficient
system of encrypting content on a broadcast encryption system.
There is a particular need for such a system when there are a large
number of encrypted content files to be handled.
SUMMARY
[0009] The problems identified above are in large part addressed by
systems, methods and media for adding an additional layer of
indirection to title key encryption. One embodiment includes
generating by a cryptographic system a binding key based on binding
information. Embodiments may also include encrypting by the
cryptographic system a secret key with the binding key and
generating a title key associated with at least one content file.
Embodiments may also include encrypting by the cryptographic system
the title key with the secret key and the at least one content file
with the title key. Further embodiments may include receiving an
indication that the binding information has changed, generating a
new binding key based on the new changed binding information, and
re-encrypting the secret key with the new binding key.
[0010] Another embodiment a method for decrypting an encrypted
content file. The embodiment generally includes accessing by a
cryptographic system an encrypted secret key and an encrypted title
key and generating by the cryptographic system a binding key based
on binding information. The embodiment may also include decrypting
by the cryptographic system the encrypted secret key with the
binding key to recover a secret key and decrypting the encrypted
title key with the secret key to recover a title key. The
embodiment also may include decrypting by the cryptographic system
the encrypted content with the title key. Further embodiments may
include receiving by the cryptographic system the encrypted secret
key and the encrypted title key from a source.
[0011] A further embodiment provides a data processing system for
encrypting one or more content files. The system may generally
include a reception system for receiving information from a source
and a transmission system for transmitting information to a
recipient. The system may also generally include a binding key
system for generating a binding key from binding information and a
secret key system for accessing a secret key and encrypting the
secret key using the generated binding key. The system may also
generally include a title key system for generating a title key and
encrypting the title key with the secret key and an
encryption/decryption system for encrypting the one or more content
files using the title key. Further embodiments include the
reception system being further adapted to receive an indication
that the binding information has changed.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Other objects and advantages of the invention will become
apparent upon reading the following detailed description and upon
reference to the accompanying drawings in which, like references
may indicate similar elements:
[0013] FIG. 1 depicts an environment for a content encryption
system for a home network according to one embodiment;
[0014] FIG. 2 depicts a cryptographic system of the content
encryption system of FIG. 1 according to one embodiment;
[0015] FIG. 3 depicts an example of a flow chart for encrypting
content using a title key and a secret key according to one
embodiment;
[0016] FIG. 4 depicts an example of a flow chart for decrypting
encrypted content using a title key and a secret key according to
one embodiment; and
[0017] FIG. 5 depicts an example of a flow chart for re-encrypting
encrypted content when binding information has changed according to
one embodiment.
DETAILED DESCRIPTION OF EMBODIMENTS
[0018] The following is a detailed description of example
embodiments of the invention depicted in the accompanying drawings.
The example embodiments are in such detail as to clearly
communicate the invention. However, the amount of detail offered is
not intended to limit the anticipated variations of embodiments;
but, on the contrary, the intention is to cover all modifications,
equivalents, and alternatives falling within the spirit and scope
of the present invention as defined by the appended claims. The
detailed descriptions below are designed to make such embodiments
obvious to a person of ordinary skill in the art.
[0019] Systems, methods and media for encrypting and decrypting
content files are disclosed. More particularly, hardware and/or
software for adding an additional level of indirection to a title
key encryption scheme are disclosed. Embodiments may include
generating by a cryptographic system a binding key based on binding
information. Embodiments may also include encrypting by the
cryptographic system a secret key with the binding key and
generating a title key associated with at least one content file.
Embodiments may also include encrypting by the cryptographic system
the title key with the secret key and the at least one content file
with the title key. Further embodiments may include receiving an
indication that the binding information has changed, generating a
new binding key based on the new changed binding information, and
re-encrypting the secret key with the new binding key.
[0020] By using a secret key to encrypt the title key, an
additional level of indirection for title key encryption is added.
The addition of the secret key reduces the amount of processing
time required in the event that binding information changes. In
prior art systems, changes in the binding information necessitated
re-encrypting each title key with a new binding key created from
the new binding information. As each piece of content in some
systems may have its own title key, the amount of re-encryption
processing can be very large. Under the content encryption system
of the disclosed embodiments, only the secret key need be
re-encrypted in the event that binding information changes. As a
secret key can be associated with any amount of content files, the
use of a secret key in addition to a title key advantageously
reduces the amount of processing required when binding information
changes.
[0021] While specific embodiments will be described below with
reference to particular configurations of hardware and/or software,
those of skill in the art will realize that embodiments of the
present invention may advantageously be implemented with other
substantially equivalent hardware and/or software systems.
[0022] Turning now to the drawings, FIG. 1 depicts an environment
for a content encryption system for a home network according to one
embodiment. In the depicted embodiment, the content encryption
system 100 includes a broadcast encryption scheme implemented over
one or more receivers 104 networked together via network 102 in a
cluster that forms a home network 110. Network 102 may be any type
of wired or wireless network, such as Local Area Networks (LANs) or
Wide Area Networks (WANs). Each receiver 104 may be considered a
peer as a participant in the cluster. Content may be any data
deliverable from a source to a recipient (from one receiver 104 to
another) and may be in the form of files, such as an audio data
file, a video data file, a media data file, a streaming media file,
an application file, a text file, or a graphic file. The content
encryption system 100 of the depicted embodiment allows the
receivers 104 within the home network 110 to freely share (and
utilize) encrypted content between them while preventing
non-compliant devices from decrypting that encrypted content. A
receiver 104 may optionally have the ability to record content onto
a recorded device 106 for use outside the home network 110. A
circumvention device 108 is depicted solely to represent a
non-compliant device that is denied access to protected content on
the home network 110.
[0023] One or more of the receivers 104 may act as a cluster server
that may update MKBs and/or authorize other devices, such as a home
gateway of a home network 110. The cluster server may include a
media key block (MKB), a common network identifier known as a
binding identifier (IDb), and an authorization table. As described
in more detail in relation to FIG. 3, the binding key (Kb) may be
created as a combination of the MKB, the IDb, and the authorization
table. The MKB (also known as a session key block, key management
block, key media block, or management key block) may typically be
sent alongside content and allows compliant devices to calculate a
media key (Km) by a process known as "processing the MKB" while
preventing non-compliant or circumvention devices 108 from doing
the same. The binding identifier IDb may be a common network
identifier for the home network 110. The authorization table may
include an indication of all devices in the home network 110,
including all receivers 104.
[0024] A receiver 104 may be any type of device that receives
content from a content owner, a content service or from another
receiver 104 with a home network 110, such as a content storage,
playback, or recording device, including televisions, DVD players,
stereos, MP3 players, personal computers, set-top boxes, mobile
phones, consumer devices, portable devices, or wearable devices.
Receivers 104 may be added or removed from the home network 110
which may necessitate changing the authorization table and thus the
binding key Kb.
[0025] Home network 110 may be a series of interconnected consumer
devices such as receivers 104 that allow the interconnected devices
to share content. In one embodiment, home network 110 may include
network content protection such as IBM's xCP Cluster, which may
provide a trusted domain that groups compliant devices into a group
in which content may freely be shared. Devices that are outside the
trusted domain cannot compute the right key and thus are unable to
access network content. By encrypting the content in a home network
110, the home network 110 owner may freely use her content within
any devices in the home network 110 while third parties are
prohibited from using copies of the content on their own system.
The content encryption system 100 protects the content by requiring
a substantially unique binding key Kb for each home network 110
that may be required to access any properly encrypted content.
Thus, if a user makes a copy of content of the home network 110 for
a friend, that friend will be unable to access that content on
their own home network as it will have a different binding key
Kb.
[0026] Under prior art systems, all content on the home network 110
would be encrypted with a title key Kt which would itself be
encrypted with the binding key Kb. Any device that wished to access
a piece of content would have to decrypt the content beforehand. To
do so, the device would first determine the media key Km from the
MKB and then use the media key Km in conjunction with the binding
identifier IDb and the authorization table to recover the binding
key Kb. The device may then use the binding key Kb to recover the
title key Kt from the encrypted title key EKt, and then use the
title key Kt to decrypt the encrypted content. Because the title
key Kt is encrypted with the binding key Kb, any changes to the
binding key Kb necessitate re-encrypting each title key Kt with the
new binding key Kb. The binding key Kb of the prior art may change,
for example, when a new device is introduced into the home network
110 (changing the authorization table), when a new MKB is brought
in from a trusted external source (such as a broadcast channel) and
the MKBs are merged, or when the binding identifier IDb is
changed.
[0027] In the content encryption system 100 of the disclosed
embodiments, the need to re-encrypt each title key Kt whenever the
binding key Kb changes is eliminated. As described in more detail
in relation to FIGS. 2-5, the content encryption system 100 uses a
secret key (Ka) to add an additional level of indirection to the
title key encryption. First, a binding key Kb is calculated using
the same process as in prior art systems. A different secret key Ka
is then encrypted with the binding key Kb and the encrypted secret
key EKa is kept as part of the state information of a group of
content files. A title key Kt is then generated and encrypted with
the secret key Ka chosen for the group of files and the content
itself is encrypted with the title key Kt. To decrypt a content, a
receiver 104 may calculate a binding key Kb from a media key Km and
the binding identifier IDb. With the binding key Kb and the
encrypted secret key EKa from the state information for the group
of files, the receiver 104 may then decrypt the secret key Ka.
Using the secret key Ka and the encrypted title key EKt, the
receiver 104 may recover the title key Kt and thus the encrypted
content. When either the MKB or the binding identifier IDb changes,
the receiver 104 need only recalculate EKa instead of having to
recalculate each title key Kt and encrypted title key EKt. In this
case, the receiver 104 would calculate the old binding key Kb as
well as a new binding key Kb' (based on Km' and/or IDb'). Using the
old Kb, the receiver 104 calculates the secret key Ka and then uses
that secret key Ka to calculate a new encrypted secret key EKa
using the new binding key Kb'. The state of the group of files need
only be updated to use the new encrypted secret key EKa' and any
encrypted title keys EKt do not need to be re-encrypted.
[0028] By avoiding the need to change and re-encrypt title keys Kt
whenever the binding key Kb changes, a significant amount of
processing and complication can be advantageously avoided. A
receiver 104 may have a very large amount of content files, each
with its own encrypted title key EKt, which would take a
significant amount of processing to re-encrypt. For example, an
audio receiver 104 may have thousands of different song files each
with separate encrypted title keys EKt. A secret key Ka may instead
be associated with the content of the audio receiver 104, allowing
the methodology of the disclosed embodiments be used to reduce
processing power needed to accommodate changes in binding
information. In another example, a secret key Ka may apply to all
content in a home network 110 that has thousands of music, movie,
and other content files. By using a secret key Ka associated with
that home network 110, the need to re-encrypt each title key Kt
when binding information changes is avoided.
[0029] FIG. 2 depicts a cryptographic system 200 of the content
encryption system 100 of FIG. 1 according to one embodiment.
Cryptographic system 200 may any combination of hardware and/or
software that may perform one or more of such tasks as
receiving/transmitting transmissions, encrypting/decrypting
content, encrypting/decrypting keys, and attaching keys to content.
A typical cryptographic system 200 may be a general purpose
computer with a computer program that, when loaded and executed,
carries out the methods described herein. Alternatively,
cryptographic system 200 may be a specific use computer system
containing specialized hardware for carrying out one or more of the
functional tasks of the cryptographic system 200. A specific use
computer system may be part of a receiver 104, for example, such as
an encryption/decryption module associated with a DVD player.
Cryptographic system 200 may include one or more central processing
units (CPUs) 202, an input/output (I/O) interface 204, memory 206,
a bus 208, external devices 210, and a database 212.
[0030] Cryptographic system 200 may also be in communication with a
source 240 or a recipient 242. Source 240 may be the source of any
content to be encrypted or decrypted or any entity capable of
sending transmissions, such as a content owner, a content service
provider, or a receiver 104 in a home network 110. Information
received from a source 240 may include any type of information,
such as encrypted content, content, content usage conditions, a
MKB, encrypted title keys EKt, or binding identifiers IDb.
Similarly, a recipient 242 may be any entity capable of receiving
transmissions or that is a destination for any encrypted content or
other information, such as a receiver 104 in a home network
110.
[0031] CPU 202 may include a single processing unit or may be
distributed across one or more processing units in one or more
locations, such as on a client and server or a multi-processor
system. I/O interface 204 may include any system for exchanging
information with an external source. Memory 206 may include any
known type of data storage and/or transmission media, including
magnetic media, optical media, random access memory (RAM),
read-only memory (ROM), and data caches. Memory 206 may reside at a
single physical location, including one or more types of data
storage, or it may be distributed across a plurality of physical
systems in various forms. Bus 208 may provide a communications link
between components of cryptographic system 200, such as between the
CPU 202 and the memory 206, and may include any type of
communication link, including electrical, optical, or wireless
links. External devices 210 may include any known type of external
device such as speakers, a video display, a keyboard or other user
input device, or a printer. Database 212 may provide storage for
information used to facilitate performance of the disclosed
embodiments such as storage of encryption keys, encrypted content,
binding identifier information, and authorization tables. Database
212 may include one or more storage devices, such as a magnetic
disk drive or optical disk drive, and may include data distributed
across, for example, a local area network (LAN), a wide area
network (WAN), or other network.
[0032] Memory 206 may include components stored in memory that
perform various tasks, including one or more of a reception system
220, a transmission system 222, a binding key system 224, a secret
key system 226, a title key system 228, and an
encryption/decryption system 230. Reception system 220 may receive
information, such as encrypted content or title keys Kt, in a
transmission from a source 240. Transmission system 222 may
transmit any information, such as encrypted content, to a recipient
242. Alternatively, transmission system 222 may also store any
information in database 212.
[0033] The binding key system 224 may generate a binding key Kb
from a binding identifier IDb and a media key Km. The binding key
system 224 may also generate the media key Km by processing the MKB
with a set of device keys. The secret key system 314 may access the
secret key Ka and encrypt the secret key Ka using the binding key
Kb. The secret key system 314 may also recover the secret key Ka
from an encrypted secret key EKa using the binding key Kb. In the
event that the secret key Ka changes, the secret key system 314 may
also update the state of any affected content files. The title key
system 228 may generate a title key Kt and encrypt the title key Kt
with a secret key Ka. The encryption/decryption system 230 may use
the title key Kt to encrypt or decrypt any content. The operation
of the binding key system 224, secret key system 226, title key
system 228, and encryption/decryption system 230 are described in
more detail in relation to FIGS. 3-5.
[0034] FIG. 3 depicts an example of a flow chart for encrypting
content using a title key Kt and a secret key Ka according to one
embodiment. In flow chart 300, content may be encrypted and bound
to a particular entity, such as a home network 110 or a receiver
104. The elements of the method of flow chart 300 may be performed,
in one embodiment, by components of a cryptographic system 200.
Flow chart 300 begins with element 302, generating a binding key
Kb, which may be performed by binding key system 224. To generate a
binding key Kb 312, the binding key system 224 performs a one-way
function on a binding identifier IDb 304 using a media key Km 308,
as represented by the equation: Kb=G(Km,IDb) in one embodiment. In
this embodiment, the G function represents a one-way function where
one data value (the media key Km 308) is combined with a second
value (the binding identifier IDb) to produce a data value
representing a key (the binding key Kb 308). Any type of one-way
function for which the inputs may not be deduced from the outputs
may be used for the G function, such as the Data Encryption
Standard (DES) or Advanced Encryption Standard (AES) one-way
functions. The binding key system 224 may calculate the media key
Km 308 used at element 302 by processing the MKB 310 using a set of
device keys 340 at element 306. The binding key Kb 312 may uniquely
identify the entity the content is being bound to and may include a
cryptographic hash of the authorization table.
[0035] After generating the binding key Kb 312, flow chart 300
continues to element 314, encrypting the secret key. At element
314, the secret key system 226 of a cryptographic system 200 may
encrypt a secret key Ka 316 with the binding key Kb 312 to produce
an encrypted secret key EKa 318, as represented by the equation:
EKa=E(Kb,Ka) in one embodiment. In this embodiment, the E function
represents an encryption function where one value (the secret key
Ka 316) is encrypted with another value (the binding key Kb 312) to
produce an encrypted block (the encrypted secret key EKa 318). The
secret key system 226 may use any type of function, such as a DES
or AES encryption function.
[0036] The secret key Ka 316 and encrypted secret key EKa 318 may
be associated with a group of files of any size. In one embodiment,
the secret key Ka 316 may be relatively long lived and unique for a
whole group of protected files. In one embodiment, the secret key
Ka 316 would change infrequently in comparison to binding
information or other types of keys. A secret key Ka 316 may be
assigned to a group of protected files of any size. One secret key
Ka 316 may be assigned to, for example, each piece of media where
several content files are stored, each partition in a file system
of a storage device, or a particular group of files on a content
server.
[0037] After encrypting the secret key Ka 316, flow chart 300
continues to element 320, generating the title key Kt. At element
320, the title key system 228 of the cryptographic system 200
generates a title key Kt 322 and then encrypts the title key Kt 322
with the secret key Ka 316 at element 324 to produce an encrypted
title key EKt 326, as represented by the equation: EKt=E(Ka,Kt) in
one embodiment. In this embodiment, an encryption function E
encrypts one value (the title key Kt 322) with another value (the
secret key Ka 316) to produce an encrypted block (the encrypted
title key EKt 326). Flow chart 300 also continues to element 328,
encrypting content after generating the title key Kt 322. The
content itself may be encrypted with the title key Kt 322 by the
encryption/decryption system 230. After encrypting the content and
the title key Kt 322, flow chart 300 continues to element 330,
where the encrypted content and/or the encrypted title key EKt 326
may be transmitted or stored, such as by the transmission system
222, after which the flow chart terminates. In one embodiment, the
encrypted content and the encrypted title key EKt 326 associated
with that content may be stored or transmitted together for ease of
decryption by recipients 242.
[0038] FIG. 4 depicts an example of a flow chart for decrypting
encrypted content using a title key and a secret key according to
one embodiment. In flow chart 400, encrypted content may be
decrypted by components of a cryptographic system 200 such as a
receiver 104. Flow chart 400 begins with element 402, accessing
encrypted content, encrypted secret key EKa 318, and an encrypted
title key EKt 326. These items may be accessed from any source and
in any manner, such as via broadcast or from database 212. The
encrypted content is the content to be decrypted in flow chart 400
by using the encrypted secret key EKa 318 and encrypted title key
EKt 326. Flow chart 400 then continues to element 404, where the
binding key system 224 generates a binding key Kb 312. Element 404
may use substantially the same process as element 302 of FIG. 3 and
the discussion will not be repeated. The binding key system 224 may
generate the binding key Kb 312 from the binding identifier IDb 304
and the media key Km 308 and it may generate the media key Km 308
by processing the MKB 310 at element 306 using device keys 340.
[0039] After generating the binding key Kb 312, flow chart 400
continues to element 406, decrypting the secret key. At element
406, the secret key system 226 of a cryptographic system 200 may
recover the secret key Ka 316 using the binding key Kb 312 to
decrypt the encrypted secret key EKa 318, as represented by the
equation: Ka=E(Kb,EKa) in one embodiment. The encrypted secret key
EKa 318 may be part of the state information for a group of content
files. Third party circumvention devices 108 will not be able to
successfully process the MKB and thus will not be able to decrypt
and recover the secret key Ka 316.
[0040] After recovering the secret key Ka 316, flow chart 400
continues to element 408, decrypting the title key Kt 322. At
element 408, the title key system 228 of the cryptographic system
200 may decrypt the encrypted title key EKt 326 with the secret key
Ka 316 to produce the title key EKt 322, as represented by the
equation: Kt=E(Ka,EKt) in one embodiment. With the title key 322,
the encryption/decryption system 230 may then decrypt the content
that is encrypted with the title key 322 at element 410, after
which the flow chart terminates.
[0041] FIG. 5 depicts an example of a flow chart for re-encrypting
encrypted content when binding information has changed according to
one embodiment. In flow chart 500, encrypted content may be
re-encrypted by components of a cryptographic system 200 such as a
receiver 104 or recipient 242. Flow chart 500 begins with element
502, where the binding key system 224 generates a binding key Kb
312 based on existing binding information. Element 404 may use
substantially the same process as element 302 of FIG. 3 and element
404 of FIG. 4 (including processing the MKB 310 at element 306) and
the discussion will not be repeated. At element 502, the binding
key system 224 may generate the binding key Kb 312 from the binding
identifier IDb 304 and the media key Km 308 and it may generate the
media key Km 308 by processing the MKB 310 at element 306 using
device keys 340.
[0042] After generating the original binding key Kb 312, flow chart
500 continues to element 504, receiving an indication that the
binding information has changed. Binding information may include a
binding identifier IDb 304 or the MKB 310. Either binding
identifier IDb 304 or the MKB 310, or both, may change to new
values of new binding identifier IDB' and/or new MKB'. The binding
identifier IDb 304, for example, may change if the authorization
table changes, which may occur when a new device enters the network
(such as a new receiver 104 in a home network 110). The new binding
identifier IDb 304 will result in a change to the binding key Kb
312. The MKB 310 may change whenever a new MKB is brought in from
an external source, such as a trusted broadcast stream, and the
MKB's are merged, which results in a new media key Km 308 and thus
a new binding key Kb 312. Binding information may also change when
the rights or permissions on one or more content files changes.
[0043] After receiving an indication that the binding information
has changed, flow chart 500 continues to element 506, generating a
new binding key Kb' 522 using the updated binding information.
Element 506 may use substantially the same process as element 302
of FIG. 3, element 404 of FIG. 4, and element 502 and the
discussion will not be repeated. The methodology at element 506 may
depend on what particular binding information has changed. Element
506 may use a new binding identifier IDb' 514 (or original binding
identifier IDb 304 if it has not changed) and/or a new MKB' 520 (or
original MKB 310 if it has not changed) to create the new binding
key Kb' 522, processing the new MKB' 520 (if available) at element
518 with a set of device keys 340 to create a new media key Km'
516.
[0044] Flow chart 500 continues to element 508, decrypting the
secret key. Alternatively, element 508 may be performed before
generating the new binding key at element 506. At element 508, the
secret key system 226 of a cryptographic system 200 may recover the
secret key Ka 316 using the old binding key Kb 312 to decrypt the
encrypted secret key EKa 318, substantially similar to the method
of FIG. 4 at element 406.
[0045] After recovering the secret key Ka 316 and generating the
new binding key Kb' 522, flow chart 500 continues to element 510,
encrypting the secret key Ka 316. At element 510, the secret key
system 226 of the cryptographic system 200 may encrypt the secret
key Ka 316 using the new binding key Kb' 522 to produce an
encrypted secret key EKa' 524, as represented by the equation:
EKa'=E(Kb',Ka) in one embodiment. After producing the new encrypted
secret key EKa' 524, flow chart 500 continues to element 512,
updating the state of the group of files to reflect the new
encrypted secret key EKa' 524, after which the flow chart
terminates. Even though the binding information has changed, the
title keys Kt 322 for all of the content files need not be
re-encrypted. As one of skill in the art will appreciate,
re-encrypting only a secret key Ka 316 instead of all title keys Kt
322 associated with a number of content files may significantly
reduce the processing resources necessary in response to a change
in binding information. The difference in required processing
resources increases as the number of content files increasing,
making the content encryption process 100 of the disclosed
embodiments particularly useful for schemes with large numbers of
content files, such as home networks 110.
[0046] In an alternative embodiment, additional grouping levels may
be achieved by using additional levels of indirection. For example,
a new key (Kz) could be used to encrypt several secret keys Ka. For
example, the new key Kz could be used to encrypt all the secret
keys Ka present on each disk of an optical jukebox. The new key Kz
may be re-encrypted whenever the binding information changes,
eliminating the need to change the encrypted secret keys EKa. In
this embodiment, decryption may require an additional step of
decrypting the encrypted secret key EKa with the new key Kz to
recover the secret key Ka. Additional layers of indirection may
also be added.
[0047] The content encryption system 100 of the disclosed
embodiments is not restricted to broadcast encryption schemes but
may be used for any system where compliant devices may calculate a
starting key which resembles in some way the media key Km 308 of
the broadcast encryption model. The content encryption system 100
thus may prove useful as a binding model for any scenario where
there are several pieces of content that need to be bound to an
object whose binding key is likely to change, such as
Diffie-Hellman or Public Key Infrastructure (PKI) systems. In one
example, a client-server based system may have several different
pieces of content stored and each encrypted with a particular title
key. Each of these title keys could be encrypted with a server key
(equivalent to the secret key Ka) and this server key could be
encrypted with a session key (equivalent to the binding key Kb)
each certain period of time. When a client connects to the system,
it may download the encrypted content with encrypted title keys and
also the current encrypted server key. The session key can be
acquired using a two-way Diffie-Hellman exchange or a PKI Public
key-Private key exchange. The decryption process would be the same
as the broadcast encryption model and when the session key changes,
there is no need to re-encrypt all the title keys used to encrypt
each piece of content.
[0048] In general, the routines executed to implement the
embodiments of the invention, may be part of an operating system or
a specific application, component, program, module, object, or
sequence of instructions. The computer program of the present
invention typically is comprised of a multitude of instructions
that will be translated by the native computer into a
machine-readable format and hence executable instructions. Also,
programs are comprised of variables and data structures that either
reside locally to the program or are found in memory or on storage
devices. In addition, various programs described hereinafter may be
identified based upon the application for which they are
implemented in a specific embodiment of the invention. However, it
should be appreciated that any particular program nomenclature that
follows is used merely for convenience, and thus the invention
should not be limited to use solely in any specific application
identified and/or implied by such nomenclature.
[0049] It will be apparent to those skilled in the art having the
benefit of this disclosure that the present invention contemplates
methods, systems, and media for adding an additional level of
indirection to title key encryption. It is understood that the form
of the invention shown and described in the detailed description
and the drawings are to be taken merely as examples. It is intended
that the following claims be interpreted broadly to embrace all the
variations of the example embodiments disclosed.
* * * * *