U.S. patent application number 10/914478 was filed with the patent office on 2006-02-09 for system and method for reduced hierarchy key management.
This patent application is currently assigned to Comcast Cable Holdings, LLC. Invention is credited to Charles L. Compton, James William Fahrny.
Application Number | 20060031873 10/914478 |
Document ID | / |
Family ID | 35759015 |
Filed Date | 2006-02-09 |
United States Patent
Application |
20060031873 |
Kind Code |
A1 |
Fahrny; James William ; et
al. |
February 9, 2006 |
System and method for reduced hierarchy key management
Abstract
A controller for managing media stream decryption keys includes
a media decryption engine, a table, and a content key list. The
media decryption engine receives an encrypted media stream from a
headend and presents a decrypted media stream to a receiving device
in response to a decryption key, wherein the decryption key is a
function of a content key. The table contains a content key index
and a plurality of corresponding content keys. Content keys that
correspond to a particular encrypted media stream are selected from
the content key list using an index from the content key table, and
that is referenced by an identifier received from a headend in
connection with the encrypted media stream.
Inventors: |
Fahrny; James William;
(Pueblo, CO) ; Compton; Charles L.; (Bryn Mawr,
PA) |
Correspondence
Address: |
BROOKS KUSHMAN P.C.
1000 TOWN CENTER
TWENTY-SECOND FLOOR
SOUTHFIELD
MI
48075
US
|
Assignee: |
Comcast Cable Holdings, LLC
Philadelphia
PA
|
Family ID: |
35759015 |
Appl. No.: |
10/914478 |
Filed: |
August 9, 2004 |
Current U.S.
Class: |
725/31 ;
348/E7.056; 348/E7.06; 348/E7.07; 380/200; 380/239 |
Current CPC
Class: |
H04N 7/17309 20130101;
H04L 2209/60 20130101; H04L 9/0836 20130101; H04N 21/2347 20130101;
H04N 21/4405 20130101; H04N 21/4623 20130101; H04L 9/0897 20130101;
H04N 7/1675 20130101; H04N 21/835 20130101; H04N 21/26613 20130101;
H04N 7/162 20130101 |
Class at
Publication: |
725/031 ;
380/200; 380/239 |
International
Class: |
H04N 7/167 20060101
H04N007/167 |
Claims
1. A controller for managing media stream decryption keys, the
controller comprising: a media decryption engine that receives an
encrypted media stream from a headend and presents a decrypted
media stream to a receiving device in response to a decryption key,
wherein the decryption key is a function of a content key; a table
containing a content key index and a plurality of corresponding
content keys; and a content key list, wherein content keys that
correspond to a particular encrypted media stream are selected from
the content key list using an index from a content key table that
is referenced by an identifier received from a headend in
connection with the encrypted media stream.
2. The controller of claim 1 wherein the decryption key is a
working key that is changed periodically.
3. The controller of claim 1 wherein the list of the content keys
and the key index are loaded into the controller from the
headend.
4. The controller of claim 1 further comprising a combiner
configured to receive the selected content key and a working key
modifier, and generate the decryption key in response to the
selected content key and the working key modifier.
5. The controller of claim 4 wherein the identifier is a program
identifier in the media stream.
6. The controller of claim 4 wherein the combiner generates the
decryption key using at least one of an exclusive OR (EXOR) and a
hashing operator.
7. The controller of claim 1 wherein the identifier is a video on
demand identifier and the table further contains video on demand
epochs related to respective content keys, and the decryption keys
are further presented in response to a respective video on demand
epoch that is selected when the content key is selected.
8. The controller of claim 3 wherein entitlement management message
(EMM) updates that are downloaded from the headend to the
controller are used solely to deliver entitlements after a first
list of the content key tables is sent, and the index table is
updated in lieu of sending new keys for each new EMM.
9. The controller of claim 1 wherein the index further comprises
initialization vector (IV) values and the content key list contains
IVs, wherein content keys and IVs that correspond to a particular
encrypted media stream are selected from the content key and IV
list using the index from a content key and IV table that is
referenced by the identifier that is received from the headend in
connection with the encrypted media stream.
10. The controller of claim 1 further comprising at least one hash
operator configured to provide a one-way hash operation to at least
one of the index, the content key, and the decryption key.
11. A method of managing media stream decryption keys, the method
comprising: receiving an encrypted media stream from a headend and
presenting a decrypted media stream to a receiving device in
response to a decryption key using a media decryption engine,
wherein the decryption key is a function of a content key; storing
a content key index and a plurality of corresponding content keys
in a table; and selecting content keys that correspond to a
particular encrypted media stream from a content key list using an
index in the content key table that is referenced by an identifier
received from the headend in connection with the encrypted media
stream.
12. The method of claim 11 wherein the decryption key is a working
key that is changed periodically.
13. The method of claim 11 further comprising loading the list of
the content keys and the key index into the controller from the
headend.
14. The method of claim 11 further comprising receiving the
selected content key and a working key modifier, and generating the
decryption key in response to the selected content key and the
working key modifier using a combiner in the controller.
15. The method of claim 14 wherein the identifier is a program
identifier in the media stream.
16. The method of claim 12 generating the decryption key using at
least one of an exclusive OR (EXOR) and a hashing operator via the
combiner.
15. The method of claim 11 wherein the identifier is a video on
demand identifier and the table further contains video on demand
epochs related to respective content keys, and the decryption keys
are further presented in response to a respective video on demand
epoch that is selected when the content key is selected.
17. The method of claim 11 further comprising downloading
entitlement management message (EMM) updates from the headend to
the controller solely to deliver entitlements after a first list of
the content key tables is sent, and updating the index table in
lieu of sending new keys for each new EMM.
18. The method of claim 11 wherein the index further comprises
initialization vector (IV) values and the content key list contains
IVs, wherein content keys and IVs that correspond to a particular
encrypted media stream are selected from the content key and IV
list using the index from a content key and IV table that is
referenced by the identifier that is received from the headend in
connection with the encrypted media stream when Cipher Block
Chaining is used as the mode of a selected algorithm.
19. The method of claim 11 further comprising at least one hash
operator configured to provide a one-way hash operation to at least
one of the index, the content key, and the decryption key.
20. A system for distribution, reception and display of media
streams, the system comprising: a headend configured to generate
and present at least one encrypted media stream; a media decryption
engine that receives the at least one encrypted media stream and
presents a decrypted media stream in response to a decryption key,
wherein the decryption key is a function of a content key; and a
table containing a content key index and a plurality of
corresponding content keys, wherein content keys that correspond to
a particular encrypted media stream are selected from the content
key table using an entry in the content key index that is
referenced by an identifier that is received from the headend in
connection with the encrypted media stream.
21. The system of claim 20 further comprising a network configured
to receive the at least one encrypted media stream and present the
at least one encrypted media stream to at least one of a set top
box (STB) and a receiving device that include the media decryption
engine and the table.
Description
BACKGROUND OF THE INVENTION
[0001] 1. Field of the Invention
[0002] The present invention relates to a system and method for
reduced hierarchy key management.
[0003] 2. Background Art
[0004] Media (e.g., digital video, audio, combination video and
audio, and the like) stream generation and distribution systems
(e.g., cable systems) use keyed encryption and decryption to
provide security to the media stream content (e.g., to reduce or
prevent unauthorized use of or intrusion upon the media streams).
Conventional products that are used to provide management of the
encryption/decryption keys are generally unwieldy and expensive to
implement and use.
[0005] In a typical, conventional media stream conditional access
system (CAS), Category Keys or Session Keys are used to decrypt
Entitlement Control Messages (ECMs) to obtain a Content Key or
Control Word in the media stream. Each media program stream has a
unique Content Key or Control Word.
[0006] Therefore, it would be desirable to have a system and a
method for a reduced hierarchy key management that is lower in
cost, easier to implement, and easier to use than conventional
approaches.
SUMMARY OF THE INVENTION
[0007] The present invention generally provides a system and a
method for a reduced hierarchy key management that is lower in cost
and easier to implement and easier to use than conventional
approaches. The present invention generally provides novel concepts
in the ability to securely renew (using role based authentication)
and re-configure Key Management products to support both
proprietary and non-proprietary systems.
[0008] According to the present invention, a controller for
managing media stream decryption keys is provided. The controller
comprises a media decryption engine, a table, and a content key
list. The media decryption engine generally receives an encrypted
media stream from a headend and presents a decrypted media stream
to a receiving device in response to a decryption key. The
decryption key is generally a function of a content key. The table
may contain a content key and index and a plurality of
corresponding content keys. Content keys that correspond to a
particular encrypted media stream may be selected from the content
key list using an index from the content key table, and that is
referenced by an identifier received from a headend in connection
with the encrypted media stream. The table may optionally (i.e.,
alternatively) contain initialization vector (IV) values that may
be indexed and selected.
[0009] Also according to the present invention, a method of
managing media stream decryption keys is provided. The method
comprises receiving an encrypted media stream from a headend and
presenting a decrypted media stream to a receiving device in
response to a decryption key using a media decryption engine. The
decryption key is generally a function of a content key. The method
further comprises storing a content key index and a plurality of
corresponding content keys in a table, and selecting content keys
that correspond to a particular encrypted media stream from a
content key list using an index in the content key table that is
referenced by an identifier received from the headend in connection
with the encrypted media stream. The table may optionally (i.e.,
alternatively) contain initialization vector (IV) values that may
be indexed and selected.
[0010] Further, according to the present invention, a system for
distribution, reception and display of media streams is provided.
The system comprises a headend, a media decryption engine, and a
table. The headend may be configured to generate and present at
least one encrypted media stream. The media decryption engine
generally receives the at least one encrypted media stream and
presents a decrypted media stream in response to a decryption key.
The decryption key is a function of a content key. Content keys
that correspond to a particular encrypted media stream are selected
from a content key table using an entry in the content key index
that is referenced by an identifier received from the headend in
connection with the encrypted media stream.
[0011] The above features, and other features and advantages of the
present invention are readily apparent from the following detailed
descriptions thereof when taken in connection with the accompanying
drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
[0012] FIGS. 1(a-d) are diagrams of media stream decoders of the
present invention; and
[0013] FIGS. 2(a-b) are diagrams of media processing and delivery
systems implementing the present invention.
DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT(S)
[0014] Terms used to describe the present invention are defined as
follows:
[0015] AES: Advanced Encryption Standard. AES is generally a much
more secure algorithm to use for the storing of digital content in
a digital video recording when compared to DES. The standard key
length used for AES is 128 bits.
[0016] DES: Data Encryption Standard. A fixed-key-length security
algorithm that employs 56-bit length keys. Any 56-bit number can be
implemented as a DES key. The relatively short key length renders
DES vulnerable to brute-force attack wherein all possible keys are
tried one by one until the correct key is encountered (i.e., the
key is "broken").
[0017] Electronic Code Block (Mode): ECB, In ECB the message is
divided into 64-bit blocks, and each block is encrypt separately.
Encryption is independent for each block.
[0018] Entitlement Control Message (Stream): ECM, Messages that
generally define access requirements of a program, specify the
tiers required for subscription, and the cost associated with
impulse purchase of the program. The index may be delivered in the
ECM as a reference to the content key. Encrypted program keys may
be delivered in the ECM stream.
[0019] Entitlement Management Message (Stream): EMM, Messages that
define access rights for each individual decoder. The EMM stream is
processed with the access control device, however, the user
processor buffers EMMs and feeds them to the access control device
via an interface.
[0020] Hash: A function (or process) that converts an input (e.g.,
the input stream) from a large domain into an output in a smaller
set (i.e., a hash value, e.g., the output stream). Various hash
processes differ in the domain of the respective input streams and
the set of the respective output streams and in how patterns and
similarities of input streams generate the respective output
streams. One example of a hash generation algorithm is Secure
Hashing Algorithm-1 (SHA-1). Another example of a hash generation
algorithm is Message Digest 5 (MD5). The hash may be generated
using any appropriate algorithm to meet the design criteria of a
particular application.
[0021] Headend: The control center of a cable television system,
where broadcast signals are received and distributed. The headend
generally contains antennas, preamplifiers, frequency converters,
demodulators, encoders, compressors, automatic switching equipment
and other related equipment that receives, amplifies, filters,
encrypts, encodes, and converts incoming satellite and terrestrial
streams for presentation to distribution channels.
[0022] Initialization vector: IV, An initialization vector in a
block cipher is a block of bits that is combined with the first
block of data in any of several feedback modes. The IV will make
each ciphertext unique, even when similar plain text is encrypted
with the same key in chain block coding (CBC) mode.
[0023] Keylist: A list of decoder addresses and respective decoder
keys in ordered pairs. Keylists may be used by the Uplink Control
System (UCS) for generation of authorization messages that are
addressed to the diagnostic circuit that is embedded in decoders
that are specific to the encoder system.
[0024] Program: A time contiguous collection of motion image
information, audio information, or a combination thereof that is
transmitted (i.e., presented, broadcast, sent, delivered, etc.) as
an entity.
[0025] Program Key: An encryption/decryption key that controls
access, encryption/decryption, etc. of a particular program.
[0026] Triple-DES: (3-DES) Application of DES encryption three
times using three different keys or, alternatively, using a one key
for the first and third segments of a three segment key and a
second key for the middle segment, for a total key bit-width of 112
or 168 bits is also used to protect certain structures and the key
inside entitlements.
[0027] Unit address: A unique number that identifies and
distinguishes one decoder from another. One example of a unit
address is a Media Access Control (MAC).
[0028] Unit key (or Private key): A key that is unique to a
respective decoder. Messages intended for a particular decoder are
encrypted using the respective unit key.
[0029] Unit keylist: A file that contains unit addresses and
respective unit keys.
[0030] Uplink Control System (UCS): Software that is used to
support the secure delivery of digitally compressed services. The
UCS generally provides the capability to authorize and de-authorize
individual decoders on an event-by-event basis.
[0031] UTC: Universal Time Code
[0032] Working key: A low level key that generally changes several
times per second. The working key generally has a validity that is
equal to or shorter in duration than the program to which it is
related. The working key is also referred to as the "control word."
In one typical example, the working key changes every 20 to 30
seconds. In one example (e.g., services that do not have a video
component), the working key epoch (i.e., the period of time during
a program for which a working key is valid) duration may be set at
an appropriate time interval. However, any appropriate time for
changing the working key may be implemented to meet the design
criteria of a particular application. The working key is used to
derive the keystream. The working key is generally delivered in an
encrypted form with the respective program key.
[0033] Working Key File: A file that contains the working keys for
the entire program that is encrypted in the program key, generally
in chronological order.
[0034] The reduced hierarchy key management of the present
invention generally provides a system and method for renewable and
re-configurable security for delivering Entitlement Management
Messages (EMM's), Entitlement Control Messages (ECM's), Content
Keys, and the associated keys. In a typical Conditional Access
System (CAS), Category Keys or Session Keys (decrypted from the
EMM) are used to decrypt the ECM to obtain the Content Key or a
Control Word in the video stream. Each media stream (e.g., video
program stream) generally has a unique Content Key or Control Word.
The reduced hierarchy key management of the present invention
generally uses a highly secure method to deliver a set of symmetric
keys such as triple-DES or AES (which can be protected using one or
more mutually defined algorithms and data such as one way (e.g.,
SHA-1, MD5, and the like) hashing and Exclusive OR (EXOR)
operations as part of the EMM for all program media streams. ECB
modes of AES, DES or triple-DES do not require an initialization
vector (IV) while CBC modes do require and IV. The system and
method of the present invention may optionally (i.e.,
alternatively) include an IV that may be indexed and selected if
CBC mode is used for the algorithm chosen.
[0035] Both the headend delivering the key list and the receiving
device may be able to receive encrypted data and obtain the
clear-text keys. An index table is also generally delivered for
referencing each of the delivered keys. The EMM updates can
generally be used solely to deliver the entitlements after the
first table is sent. In one example, the reduced hierarchy of the
present invention can obtain a key index by using a program
identifier (PID). In another example, the reduced hierarchy of the
present invention can obtain a key index via a session ID such as a
Video On Demand (VOD) Session ID. The key index is generally used
to determine the index which references one or more related content
keys.
[0036] The key index is generally used to obtain the key (and
alternatively an IV) when Cipher Block Chaining mode is used. The
index table can be updated as a countermeasure in lieu of sending
new keys for each new EMM. The number of keys can be less than the
total number of program streams and content keys because some
streams can be derived mathematically from combinations of other
keys. In other cases, entire service tiers can be on the same
general key and derivative keys may be generated for each program
stream in the respective tier. The system and method of the present
invention may eliminate the delivery and management of Category or
Session Keys and the related ECMs from the headend.
[0037] For VOD services, a table of keys can be generated and
delivered at session setup time. The keys for VOD service may be
delivered with synchronization information related to key change as
well as other information for short term working key epochs. A VOD
Session ID or, alternatively, a Program ID may be used as an index
to reference the keys list with the appropriate record of
information for the VOD transport decryption. In alternative
embodiments of reduced hierarchy key management of the present
invention, one-way hashing may be implemented in the protection,
selection and processing of the decryption key.
[0038] The reduced hierarchy key management of the present
invention generally provides a new, more secure, and elegant system
and method to deliver content keys for decrypting the program
streams in conditional access systems (e.g., Broadcast and Video On
Demand applications). The key management of the present invention
may dramatically reduce the complexity required to deliver new
content keys when a first Entitlement Message has been sent (i.e.,
presented, transmitted, provided, broadcast, etc.) to each set top
box. The reduced hierarchy key management system and method of the
present invention may be implemented as a portion of a new CAS
system. The new CAS system generally provides for the manufacture
and distribution of devices that are compatible with
infrastructure, regardless of specific content security mechanisms
that are used in that infrastructure. The new CAS system may
provide far more efficient manufacturing, distribution and
operations, and in fact enable new business models, including the
retail availability of extremely low cost customer premises
equipment (CPE) when compared to conventional approaches.
[0039] The reduced hierarchy key management of the present
invention provides the user with flexibility and also helps to
simplify Impulse Pay Per View (IPPV) and Video On Demand (VOD)
security in the headend when compared to conventional approaches.
The simplified key management structure of the present invention
can be applied to IPPV and VOD technologies and thereby standardize
the overall approach to security for VOD.
[0040] The commercial value of the unique improved system and
method for reduced hierarchy key management of the present
invention is potentially very large because the present invention
may provide all of the Consumer Electronics (CE) industry to
innovate new types of products for multiple system operators
(MSOs). Furthermore, all CE companies are potential customers. The
present invention may lower the overall cost of producing headends,
STBs and digital televisions, lower the cost and ease the
operational complexities for IPPV and VOD, thereby providing the
MSOs significant cost savings when compared to conventional
approaches. Further, by enabling dramatically lower costs as well
as increased innovation and new business models, the reduced
hierarchy key management of the present invention may improve the
competitive position of cable television implementations versus
alternative video providers such as Digital Broadcast Satellite
(DBS) (i.e., Digital TV transmissions via satellite) and emerging
telecommunications-based video systems.
[0041] Referring to FIG. 1a, a diagram illustrating a media decoder
(i.e., controller, processor, apparatus, circuit, device, etc.) 100
of the present invention is shown. The decoder 100 may be
implemented in connection with a digital media stream distribution
system (described in more detail in connection with FIGS. 2(a-b)).
The controller 100 is generally implemented as a security processor
(or processing system) that provides at least one security feature
(e.g., encryption, decryption, authentication, security key
management, copy protection, digital rights management, etc.) to at
least one digital media input/output stream. The decoder 100
generally has an input 102 that receives at least one signal (e.g.,
VIDIN and PID), an input/output 104 that receives/presents a signal
(e.g., TFHE) as well as additional data, signals, messages, and the
like, an input 106 that receives a working key modifier and
application function signal (e.g., WKM), and an output 108 that
presents a signal (e.g., VIDOUT).
[0042] The streams VIDIN and VIDOUT may be implemented as digital
media streams that may be in an encrypted and in a clear (i.e.,
unencrypted or decrypted) state (or condition), respectively. The
streams VIDIN and VIDOUT are each generally implemented as a
digital media signal stream (e.g., an MPEG, MPEG-2, etc. stream or
other transport stream). In one example, the stream VIDOUT may be
implemented as a decrypted (and decompressed) version of the stream
VIDIN. However, the streams VIDIN and VIDOUT may be implemented
having any appropriate format and protocol to meet the design
criteria of a particular application.
[0043] The signal PID may be implemented as a program identifier
for the respective program that has been selected by a user (e.g.,
customer, client, viewer, listener, etc.). The signal TFHE may be
implemented as at least one entitlement management message (EMM)
that is received from and presented to the headend via an
out-of-band (OOB) transmission. The working key modifier and
application function (e.g., a factor, an operator, or a combination
of a factor and an operator that was applied to the content key to
enhance encryption) WKM is generally combined with a content key to
generate a working key that is used to decrypt an encrypted media
stream (e.g., the stream VIDIN) to generate a clear output media
stream (e.g., the media stream VIDOUT).
[0044] The controller 100 generally comprises a media stream
transport decryption engine 110, a table 112, a list 114, and a
combiner 116. The decoder 100 is generally implemented via at least
one processor (e.g., microprocessor, controller, etc.) and at least
one memory (e.g., random access memory (RAM), read only memory
(ROM), NVROM, flash, EPROM, etc.) where one or more processes,
routines, engines, lists, tables, etc. may be stored. The engine
110, the table 112, the list 114, and the combiner 116 are
generally implemented within the processor and memory of the
decoder 100.
[0045] The engine 110 may have a first input that may receive a
stream (e.g., VIDIN) from a headend (described in connection with
FIG. 2), an input that may receive a stream decryption working key
(e.g., WK), and an output that may present (i.e., transmit,
broadcast, send, etc.) a stream (e.g., VIDOUT). The decryption
engine 110 may be configured to decrypt (and decompress) the media
stream VIDIN and present the clear media stream VIDOUT in response
to the working key WK and the media stream VIDIN. The decryption
key WK is generally a function of the content key.
[0046] The input/output 104 may provide for interfacing that
corresponds to (or is related to) entitlement management message
(EMM) downloads that are authenticated between the headend (e.g.,
headend 202, described in more detail in connection with FIGS.
2(a-b)) and the media decoder 100. The input/output 104 may further
provide for interfacing that corresponds to downloads to the
decoder related to at least one of entitlement structure, content
keys lists, IV lists, content key index tables, and digital
signatures.
[0047] The table 112 generally comprises a content key index table.
The contents of the table 112 are generally loaded from the headend
(e.g., via the input/output 104). During the downloading from the
headend, the content key list table may be decrypted and extracted
using the respective unit or device key. The table 112 may receive
the identifier PID via the input 102. The table 112 may present an
index (e.g., IND) to the content key list 114 in response to the
identifier PID based on the respective value in the table 112 using
a content key index contained therein. In an alternative (i.e.,
optional) example, the table 112 comprises a content key and IV
index table.
[0048] The list 114 generally contains a list of content keys that
may be referenced by respective index values (e.g., the index IND).
The contents of the list 114 may be loaded via the input/output
104. The list 114 may be configured to present a content key to the
combiner 116 in response to the respective index IND. The content
keys (and, alternatively or optionally, IV values) in the list 114
that correspond to a particular encrypted media stream VIDIN are
selected from the content key (and, alternatively or optionally,
IV) table 112 using an entry in the content key (and, alternatively
or optionally, IV) index that is referenced by the identifier PID
that is received from the headend in connection with the encrypted
media stream VIDIN. Content keys and IVs that correspond to a
particular encrypted media stream are selected from the content key
and IV list using the index IND from a content key and IV table
that is referenced by the identifier PID that is received from the
headend in connection with the encrypted media stream when Cipher
Block Chaining is used as the mode of a selected algorithm.
[0049] The combiner 116 may be configured to present the working
key WK to the engine 110 in response to the working key modifier
WKM and the content key. The combiner 116 may combine the working
key modifier WKM and the content key using at least one of a hash
and an exclusive OR (EXOR) operation (i.e., routine, algorithm,
process, method, steps, blocks, etc.). In one example (an optional
or alternative mode of operation), the combiner 116 may be
configured to periodically change the working key WK. For example,
the combiner 116 may change the working key WK every four video
display frame times.
[0050] The present invention obviates the need for the
transmission, receipt, and processing of respective entitlement
control messages (ECMs) as are used in conventional approaches. As
such, the reduced hierarchy key management of the present invention
is lower in cost, easier to implement, and easier to use than
conventional approaches.
[0051] Referring to FIG. 1b, a diagram illustrating an alternative
media decoder (i.e., controller, processor, apparatus, circuit,
device, etc.) 100' of the present invention is shown. The
decoder/controller 100' may be implemented similarly to the
decoder/controller 100 and may further comprise one or more one-way
hash operators 118 (e.g., operators 118a-118n). The hash operators
118 may be configured to provide a one-way hash operation (i.e.,
process, routine, algorithm, etc.) to at least one of the index IND
as selected from the table 112 via the list 114, the key selected
from the 112, and in connection with the modifier WKH to generate
the decryption (i.e., working) key WK.
[0052] Referring to FIG. 1c, a diagram illustrating an alternative
media decoder (i.e., controller, processor, apparatus, circuit,
device, etc.) 100'' of the present invention is shown. The decoder
100'' may be advantageously implemented in connection with video on
demand (VOD) key management. The media stream VIDIN may be an
encrypted VOD media stream. The media stream VIDOUT may be clear
VOD media stream. The input 102 may receive the media stream VIDIN.
In one example, the input 102 may receive the identifier PID. In
another example, the input 102 may receive a VOD session identifier
(e.g., VODID). The decoder 100'' generally does not receive the
working key modifier WKM.
[0053] The input/output 104 may provide for interfacing that
corresponds to (or is related to) EMM downloads that are
authenticated between the headend and the media decoder 100'. The
input/output 104 may further provide for interfacing that
corresponds to downloads to the decoder related to at least one of
entitlement structure, VOD key records lists, IV lists, content key
index tables, and digital signatures.
[0054] The controller 100'' generally comprises the media stream
transport decryption engine 110, a table 112'', and a list 114''.
The decoder/controller 100'' is generally implemented without a
combiner such as the combiner 116 of the decoder 100. The engine
110 may receive a video content key (e.g., VK) instead of the
working key WK. The engine 110 may generate and present the clear
media stream VIDOUT in response to the media stream VIDIN and the
decryption key VK.
[0055] The table 112'' generally comprises a content key (and,
alternatively or optionally, IV) index table. The contents of the
table 112' are generally loaded from the headend (e.g., via the
input/output 104). The table 112'' may receive the identifier PID
or, alternatively, the identifier VODID via the input 102. The
table 112'' may present an index (e.g., IND'') to the content key
list 114'' in response to the identifier PID or, alternatively, the
identifier VODID based on the respective value in the table 112''
using a key record index contained therein.
[0056] The list 114'' generally contains a list of VOD content keys
(e.g., the keys VK) that may be referenced by respective index
values (e.g., the index IND''). The contents of the list 114'' may
be loaded via the input/output 104. The list 114'' may be
configured to present a content key to the engine 110 in response
to the respective index IND''. The VOD content keys (and,
alternatively or optionally, IVs) VK in the list 114'' that
correspond to a particular VOD encrypted media stream VIDIN are
selected from the content key (and, alternatively or optionally,
IV) table 112'' using an entry in the content key record index that
is referenced by the identifier PID or, alternatively, the
identifier VODID that is received from the headend in connection
with the encrypted media stream VIDIN. The stream decryption keys
VK are generally presented to the engine 110 on respective key
epochs.
[0057] Referring to FIG. 1d, a diagram illustrating an alternative
media decoder (i.e., controller, processor, apparatus, circuit,
device, etc.) 100''' of the present invention is shown. The
decoder/controller 100''' may be implemented similarly to the
decoder/controller 100'' and may further comprise the one or more
one-way hash operators 118a-118n. The hash operators 118 may be
configured to provide a one-way hash operation to at least one of
the index IND as selected from the table 112'' via the list 114'',
the key selected from the 112'', and in connection with the
decryption (i.e., working key) VK.
[0058] Referring to FIG. 2a, a diagram illustrating a media stream
processing and distribution system 200 implemented in connection
with the present invention is shown. The distribution system 200
generally comprises a headend 202, a network 204, at least one set
top box (STB) 206 (generally a plurality of STBs 206a-206n), and at
least one respective receiving device (i.e., receiver, transceiver,
display device, etc.) 208 (generally a plurality of devices
208a-208n). The distribution system 200 is generally implemented as
a media service provider/subscriber system wherein the provider (or
vendor) generally operates the headend 202 and the network 204, and
also provides a subscriber (i.e., client, customer, service
purchaser, user, etc.) with the STB 206.
[0059] The STB 206 is generally located at the subscriber location
(not shown, e.g., home, tavern, hotel room, business, etc.) and the
receiving device 208 is generally provided by the client. The
device 208 is generally implemented as a television, high
definition television (HDTV), monitor, host viewing device, MP3
player, audio receiver, radio, personal computer, media player,
digital video recorder, game playing device, etc. The device 208
may be implemented as a transceiver having interactive capability
in connection with the STB 206, the headend 202, or both the STB
206 and the headend 202.
[0060] The headend 202 is generally electrically coupled to the
network 204, the network 204 is generally electrically coupled to
the STB 206, and each STB 206 is generally electrically coupled to
the respective device 208. The electrical coupling may be
implemented as any appropriate hard-wired (e.g., twisted pair,
untwisted conductors, coaxial cable, fiber optic cable, hybrid
fiber cable, etc.) or wireless (e.g., radio frequency, microwave,
infrared, etc.) coupling and protocol (e.g., HomePlug, HomePNA,
IEEE 802.11(a-b), Bluetooth, HomeRF, etc.) to meet the design
criteria of a particular application. While the distribution system
200 is illustrated showing one STB 206 coupled to a respective one
device 208, each STB 206 may be implemented having the capability
of coupling more than one device 208 (not shown).
[0061] The headend 202 generally comprises a plurality of devices
210 (e.g., devices 210a-210n) that are implemented as amplifiers,
pre-amplifiers, data servers, computers, processors, security
encryption and decryption apparatuses or systems, and the like
configured to provide video and audio data (e.g., movies, music,
television programming, and the like), processing equipment (e.g.,
provider operated subscriber account processing servers),
television service transceivers (e.g., transceivers for standard
broadcast television and radio, digital television, HDTV, audio,
MP3, text messaging, gaming, etc.), media streams, and the like. In
one example, the headend 202 may generate and present (i.e.,
transmit, provide, pass, broadcast, send, etc.) the stream VIDIN,
the signal TFHE, and the program identification signals PID and
VODID.
[0062] The network 204 is generally implemented as a media stream
distribution network (e.g., cable, satellite, and the like) that is
configured to selectively distribute (i.e., transmit and receive)
media service provider streams (e.g., standard broadcast television
and radio, digital television, HDTV, audio, MP3, text messaging,
games, etc.) for example, as the stream VIDIN, the downloads TFHE,
and the identifiers PID and VODID, to the STBs 206 and to the
receivers 208, for example, as the stream VIDOUT. The stream VIDIN,
the downloads TFHE, and the identifiers PID and VODID are generally
distributed based upon (or in response to) subscriber information.
For example, the level of service the client has purchased (e.g.,
basic service, premium movie channels, etc.), the type of service
the client has requested (e.g., standard TV, HDTV, interactive
messaging, video on demand, pay-per-view, impulse-pay-per-view,
etc.), and the like may determine the media streams that are sent
to (and received from) a particular subscriber.
[0063] The STB 206 is generally implemented as an STB having
multiple stream capability (e.g., standard broadcast television and
radio, digital television, audio, MP3, high definition digital
television (HDTV), text messaging, etc.). The STB 106 generally
comprises at least one respective media decoder (e.g., an
appropriate one of the decoders (controllers) 100, 100', 100'' and
100'''). The STB 206 may receive encrypted (and compressed) video
and audio data (e.g., the stream VIDIN), the EMM signal and
downloads TFHE, and the id signals PID and VODID, present the EMM
signal TFHE to the headend 202 via the network 204, and present
clear video and audio data (e.g., the stream VIDOUT) to the
receiver 208.
[0064] Referring to FIG. 2b, a diagram illustrating a media stream
processing and distribution system 200' implemented in connection
with the present invention is shown. The distribution system 200'
generally comprises the headend 202, the network 204, and at least
one of the receiving device (i.e., receiver, transceiver, etc.)
208' (generally a plurality of the devices 208a'-208n'). The
receiving device 208' is generally coupled directly to the network
204 and receives the stream VIDIN, the signal TFHE, and the program
identification signals PID and VODID, and receives and presents the
EMM signal TFHE. The receiving device 208' generally comprises at
least one respective media decoder (e.g., an appropriate one of the
decoders (controllers) 100, 100', 100'' and 100''').
[0065] In yet another example (not shown), the system 200' may be
implemented having at least one STB 206 coupled to the network 204
and with at least one receiver 208 coupled thereto, as well as
having at least one device 208' that is directly coupled to the
network 204.
[0066] As is readily apparent from the foregoing description, then,
the present invention generally provides an improved system (e.g.,
the decoders 100 and 100') and an improved method for a reduced
hierarchy key management that is lower in cost, easier to
implement, and easier to use than conventional approaches.
[0067] While embodiments of the invention have been illustrated and
described, it is not intended that these embodiments illustrate and
describe all possible forms of the invention. Rather, the words
used in the specification are words of description rather than
limitation, and it is understood that various changes may be made
without departing from the spirit and scope of the invention.
* * * * *