Patent Application
20070258586
1. Field of the Invention
The invention relates to personal video recorders, and more particularly, to a personal video recorder having dynamic security functions for improved content protection.
2. Description of the Prior Art
A personal video recorder (PVR) is a generic term referring to a device that is similar to a video cassette recorder (VCR) but records television data utilizing a digital format as opposed to an analog format such as used by a VCR. A PVR can also be referred to as a hard disk recorder (HDR), a digital video recorder (DVR), a personal video station (PVS), or a personal TV receiver (PTR). While VCRs utilize analog tapes to record and play programs broadcast over television, PVRs encode video data in digital formats such as Moving Pictures Expert Group (MPEG) MPEG-1 or MPEG-2 and store the data in a digital storage device such as a hard drive. PVRs need to provide similar functionality as VCRs (recording, playback, fast forwarding, rewinding, and pausing) and also include the ability to instantly jump to any part of a television program without having to rewind or fast forward the data stream. A benefit of the PVR system is that these functions can also be applied to a television program that is currently being received. That is, from the respect of a user, the functions of the PVR are still available even when she/he is watching a live television broadcast.
A PVR is essentially made up of two portions: (1) a device that accommodates its hardware elements such as the hard disk drive, power supply and buses, and (2) software that may access a subscription service for providing program information and provides the ability to encode and decode data streams. Additionally, when implemented as a set-top box, the PVR receives a transport stream as an input signal. In this situation, because the transport stream has crossed a network of some kind, there may be errors in the input signal. Furthermore, packets of the input signal received from the transport stream may arrive in any order and may be reduced in size due to the properties of the network. For example, the packet size defined in the wireless networks, cable based networks, optical networks, and asynchronous transfer mode (ATM) networks are different from each other.
Transport (de)Packetization and (de)Multiplexing refers to the means of dividing each bit stream into “packets” of information, the means of uniquely identifying each packet or packet type, and the appropriate methods of interleaving or multiplexing video bit stream packets, audio bit stream packets, and data bit stream packets into a single transport mechanism. The structure and relationships of these bit streams is carried in service information bit streams, also multiplexed in the single transport mechanism. In developing the transport mechanism, interoperability among digital media—such as terrestrial broadcasting, cable distribution, satellite distribution, recording media, and computer interfaces—was a prime consideration. The digital television (DTV) system employs the MPEG-2 Transport Stream syntax for the packetization and multiplexing of video, audio, and data signals for digital broadcasting systems. The MPEG-2 Transport Stream syntax was developed for applications where channel bandwidth or recording media capacity is limited and the requirement for an efficient transport mechanism is paramount.
In general, the transport streams 106, 108 aim for trans-network data delivery. In order to allow proper interconnectivity and network transportation, data information is segmented into 188 byte packets with Transport Header and Adaptation on top of a Packetized Elementary Stream (PES), Program Specific Information (PSI) or Program Information (SI) using multiplexer 110 (where PSIP is used in ATSC and SI is used in DVB). Please note that the PES packet is the unit structure of transforming an elementary stream and is defined by the MPEG-2 coding system.
The data stream including television program content is provided by a service provider. In order to protect their content, service providers typically encrypt the data corresponding to the television program for transportation across the network. For example, in order to protect intellectual property of content during transport, condition access (CA) or CableCard is used to provide content security. The basic concept of CA involves using a secret key exchange method between two sides, service provider and users, and then scrambling the content with secret keys.
As mentioned above, service providers have a vested interest in the security of television programming and other content to insure bill-of-service in place. Any illegal copying, viewing, or other uses of the data must be prevented and forbidden. If PVR systems simply store plain text (unencrypted) data within the PVR system, this will make content copy more feasible. Therefore, it is obvious that service providers would prefer to have PVR systems store the content in a more secure and encrypted format. However, storing data in an encrypted format within the PVR system tends to make some of the must have functions such as random access of different time areas of the program difficult. For example, if a user wants to fast forward three minutes, the PVR system cannot directly skip an equivalent to three minutes worth of encrypted data from its storage medium because some of the encrypted data skipped may actually contain packets corresponding to secret key information. That is, the PVR system may be unable to decrypt the data because the PVR system does not know the corresponding key with which the data was originally encrypted. Therefore, a PVR with dynamic security functions need to be improved to provide sufficient content protection while continuing to support must have user functions like random access.
One objective of the claimed invention is therefore to provide a method of embedding information in a synchronization byte of a packet stored in a personal video recorder to thereby allow dynamic security functions for improved content protection at the same time enable random access functions.
According to an exemplary embodiment of the claimed invention, a method of processing a transport stream comprising a plurality of packets to output a protected transport stream is disclosed. Each packet comprising a packet header and a payload, the packet header comprising a sync field, the sync field carrying a preset sync pattern. The method comprising (a) providing a set of secret keys having a predetermined number of secret keys; (b) generating a key indication value; (c) selecting a secret key from the set of secret keys according to the key indication value to form a selected secret key; (d) generating an encrypted packet based on the selected secret key and a packet in the transport stream by: encrypting the payload of the packet according to the selected secret key, and storing the key indication value in the sync field; and (e) generating the protected transport stream based on the encrypted packet.
According to another exemplary embodiment of the claimed invention, a method of processing a protected transport stream comprising a plurality of packets to generate a decrypted transport stream is disclosed. Each packet comprising a packet header and a payload, the packet header comprising a sync field. The method comprising (a) providing a set of secret keys having a number of secret keys; (b) identifying a packet of the protected transport stream as an encrypted packet or an unencrypted packet according to the sync field of the packet; (c) extracting a key indication value from the sync field of the encrypted packet in the protected transport stream; (d) selecting a secret key from the set of secret keys according to the extracted key indication value; (e) generating a decrypted packet based on the encrypted packet and the selected secret key, comprising: decrypting the payload of the encrypted packet based on the selected secret key; and (f) outputting the decrypted packet and the unencrypted packet, if available, to form the decrypted transport stream.
According to another exemplary embodiment of the claimed invention, an apparatus is disclosed for processing a transport stream comprising a plurality of packets to output a protected transport stream. Each packet comprising a packet header and a payload, the packet header comprising a sync field, the sync field carrying a preset sync pattern. The apparatus comprising a table storing a set of secret keys having a predetermined number of secret keys; a key selecting module for generating a key indication value and selecting a secret key from the set of secret keys according to the key indication value to form a selected secret key; an encryption module for receiving a packet in the transport stream and generating an encrypted packet by encrypting the payload of the clear packet according to the selected secret key to form the payload of the encrypted packet and storing the key indication value within the sync field of the encrypted packet; wherein each encrypted packet is outputted to form the protected transport stream.
According to another exemplary embodiment of the claimed invention, an apparatus is disclosed for processing a protected transport stream comprising a plurality of packets to output an unprotected transport stream, each packet comprising a packet header and a payload, the packet header comprising a sync field. The apparatus comprising a key table storing a set of secret keys having a number of secret keys; a demux unit for receiving the protected transport stream, identifying a packet of the protected transport stream as an encrypted packet or an unencrypted packet according to the sync field of the packet, outputting the encrypted packet to form an encrypted packet stream and outputting the unencrypted packet, if available, to form an unencrypted packet stream; a key extraction module for outputting a selected secret key by extracting a key indication value from the sync field of an encrypted packet in the encrypted transport stream and using the key indication value to look into the key table to obtain the selected secret key; a decryption module for receiving the encrypted packet, generating a decrypted packet based on the encrypted packet and the selected secret key by at least decrypting the payload of the encrypted packet according to the selected secret key, outputting each decrypted packet to form a decrypted packet stream; and a mux unit for generating the unprotected packet stream by multiplexing the decrypted packet stream and the unencrypted packet stream, if available.
These and other objectives of the present invention will no doubt become obvious to those of ordinary skill in the art after reading the following detailed description of the preferred embodiment that is illustrated in the various figures and drawings.
The de-multiplexer 204 separates the transport stream packets 201 passed by the PID filter 202 into packets that do not require encryption (unencrypted packets 208) and packets that require encryption, which are passed to the encryption module 206. The separation operation performed by the de-multiplexer 204 is also performed according to the packet identifier of each transport stream packet 201. For example, packets having packet identifiers that correspond to protected content such as feature movies requiring encryption are passed to the encryption module 206. Packets having packet identifiers that correspond to unprotected content (i.e., unencrypted packets 208) such as free programming that do not require encryption are passed directly to multiplexer 212.
Encryption of packets is performed by the encryption module 206 as follows. The key table 216 provides a set of secret keys having a predetermined number of secret keys. For example, in one embodiment, 16 secret keys are included in the key table 216. For each packet that is to be encrypted, the key selection module 214 selects a particular secret key from the key table 216. The actual selection technique can be implemented in a number of ways. For example, a random key from the key table 216 is utilized in one embodiment, or a fixed rotation order is utilized in another embodiment. Other methods of key selection by the key selection module 214 could be implemented and the present invention is not limited to only random or fixed order key selection.
After selecting a particular secret key from the key table 216, the key selection module 214 passes the selected key and also generates and passes a key indication value to the encryption module 206. The key indication value is an indication of which key from the key table 216 was selected for encryption and could be something as simple as an index value from the key table, or something more complicated such as a unique hash value corresponding to the selected secret key. The encryption module 206 generates an encrypted packet 210 by encrypting the payload of the packet to be encrypted utilizing the selected secret key. Additionally, the encryption module 206 stores the key indication value within the synchronization field (hereafter referred to as the sync field) of the encrypted packet 210. In this way, the key indication value referring to the selected secret key is carried within the synchronization field of each encrypted packet 210, and this allows a decryption section (explained in more detail later) to also select the same secret key and decrypt the payload of each encrypted packet 210. Additionally, storing the key indication value within the sync field of each encrypted packet 210 has the added benefit of allowing random access of different areas of data corresponding to a particular content program upon playback. Further explanation of randomly accessing different areas of the content program, and different embodiments explaining how the key indication value is stored within the sync field are discussed later in this description. The encrypted packets 210 generated by the encryption module 206 are passed to the multiplexer 212.
In order to increase the security and allow for an infinite number of possible keys, the key table control unit 220 is utilized to generate new secret keys and to update the set of secret keys in the key table 216 by replacing some (or all) of the secret keys within the key table 216 with new secret keys. Additionally, the extra control packet generator 218 generates at least one extra control packet 222 to carry control information regarding the new secret keys that were generated by the key table control unit 220 and stored in the key table 216. For example, the control information could contain encrypted copies of the new secret keys, seed values for the algorithm that was utilized to create the new secret keys, or could contain other information that would allow the decryption section (explained later) to generate new secret keys for decryption that correspond to the new secret keys that were added to the key table 216 and used for encryption. The extra control packets 222 containing the information regarding the new secret keys in the key table 216 are also passed to the multiplexer 212. The multiplexer 212 multiplexes the unencrypted packets 208, the encrypted packets 210, and the extra control packets 222 into a single protected transport stream, which is then stored within the storage device 224. In this way, any content that has been designated as protected content, such as feature movies etc, is stored in within the storage device 224 of the PVR system in an encrypted form.
Decryption of the encrypted packets 304 is performed as follows. In order to determine which key from the key table 315 should be utilized to decrypt each encrypted packet 304, the key extracting module 314 examines the sync field of each encrypted packet 304 and selects the appropriate secret key from the key table 315 according to the key indication value stored within the sync field. As previously mentioned, the key indication value indicates which key from the key table 216 in
The PID filter 320 is optionally utilized to filter the decrypted transport stream 319 to only allow packets that correspond to content that has been selected for playback by the PVR system and extra control packets 308 to be passed to the following stages for processing. For example, a user of the PVR system may only want to watch a particular content stream, and the PID filter 320 only passes packets having a PID corresponding to the particular content stream to pass to demultiplexer 322, in addition to the extra control packets 308. Demultiplexer then separates the packets that were passed by the PID filter 320 into packets that have been scrambled and packets that have not been scrambled. The demultiplexer performs this separation operation according to the packet header. As was previously mentioned and will be readily understood by a person of ordinary skill in the art, the transport_scrambling_control field within the packet header indicates if the MPEG-2 Transport Stream packet payload has been scrambled. Note that the MPEG-2 Transport Stream packet header, the optional adaptation field, and the payload of a Null MPEG-2 Transport Stream packet are never scrambled. Further information regarding the packet header is described in
The multiplexer 326 combines the de-scrambled packets outputted by the de-scrambler 324 and the packets received directly from the demultiplexer 322 into a single stream. The demultiplexer 328 then passes the extra control packets 308 to the control module 332, and passes the other packets containing content data to the A/V decoder 330 for playback.
As was previously mentioned, when each encrypted packet 304 is decrypted, the secret keys in the key table 315 of
Concerning the MPEG-2 Transport Stream Packet Syntax, in the packet header, the Packet Identifier (PID) is a 13-bit value used to identify Transport packet from multiplexed packets within the MPEG-2 Transport Stream. Assigning a unique PID value to each bit stream allows Transport Stream packets form up to 8192 (213) separate bit streams to be simultaneously carried within the MPEG-2 Transport Stream. The PID provides a unique bit stream associate to each Transport Stream packet.
The payload_unit_start_indicator is used to signal decoder (by being set to ‘1’) that something “interesting”(start of new PES or PSI) can be found within the payload of the current MPEG-2 Transport Stream Packet. When the payload of the Transport Stream packet contains PES packet data, the payload_unit_start_indicator has the following significance: A ‘1’ indicates that the payload of this Transport Stream packet will commence with the first byte of a PES packet. A ‘0’ the Transport Stream packet payload contains the continuation of a previously started PES along with any necessary stuffing bytes. If the payload_unit_start_indicator is set to ‘1’, it implies that one and only one PES packet starts in this Transport Stream Packet. Two PES packets (or portions thereof) are not permissible in a single Transport Stream packet. This form of signaling, combined with hardware filtering in the decoder, allows for considerable efficiencies in decoding the contents of the stream.
For MPEG-2 sections (PSI and private sections) carried as payload, when the payload_unit_start_indicator field is set to ‘1’, then the first byte of the MPEG-2 Transport Stream packet payload carries the pointer_field, which indicates the byte offset from the start of the Transport Stream packet payload to the beginning of the next PSI or private section. If the payload_unit_start_indicator field is set to ‘0’, then the first byte of the Transport Stream packet payload is not a pointer_field. Instead, the Transport Stream packet payload contains the continuation of a previously started PSI or private section along with any necessary stuffing bytes.
As previously mentioned, the transport_scrambling_control field indicates if the MPEG-2 Transport Stream packet payload has been scrambled. Note that the MPEG-2 Transport Stream packet header, the optional adaptation field, and the payload of a Null MPEG-2 Transport Stream packet (see Section 7.3.2.1) are never scrambled. The adaptation_field_control field signals the inclusion of the optional adaptation field. The most significant bit of the two-bit field always indicates the presence of the adaptation field. The least significant bit indicates the presence of payload.
The continuity_counter field is a 4-bit rolling counter associated with MPEG-2 Transport Stream packets carrying the same PID. The counter is incremented by one for each consecutive Transport Stream packet for a given PID except when the adaptation_field_control field is set to indicate that the Transport Stream packet contains an adaptation field only (no payload) or if it is set to the ‘reserved’ value, or if the Transport Stream packet is a duplicate 7 (these exception cases are known as “non-incrementing conditions”). The continuity_counter is considered “continuous” if it has incremented by one from the continuity_counter value in the previous Transport Stream packet of the same PID or when any of the non-incrementing conditions have been met. The continuity counter is considered “discontinuous” if it has not incremented by one from the continuity counter value in the previous Transport Stream packet having the same PID and nonincrementing condition has not been met. Except in the case when the discontinuity_indicator flag has been set to ‘1’ to signal a discontinuous continuity_counter, if a receiver encounters a situation where the continuity_counter is discontinuous, then it should assume that some number of MPEG-2 Transport Stream packets have been lost.
Two other fields, the transport_error_indicator and the transport_priority, which are not typically used in ATSC transport Streams, are also carried in the packet header. The transport_error_indicator may be used to indicate that at least one uncorrectable bit error exists in the Transport Stream packet. The transport_priority field may be used to indicate that a Transport Stream packet with the field set to ‘1’ is of higher priority than other Transport Stream packets having the same PID which do not have the field set to ‘1’. The payload field carries the data content. The data content can be one of many types; for example, an MPEG-2 PES packet (which itself may contain an elementary stream) or one or more PSI or private sections.
In this exemplary embodiment, at any point in time, there are sixteen different secret keys within the key table 214 that are used to encrypt content for storage in the storage device 224. During playback operations, the decryption section 300 is used to retrieve data from the storage device 302. For encrypted packets 304 (i.e., packets having their sync byte modified), decryption is performed by the decryption module 312 according to the secret key indicated by the modified sync byte pattern (i.e., the key indication value stored within the sync field).
As previously mentioned, random access functions such as providing the ability to perform such operations as recording, playback, fast forwarding, rewinding, pausing, and also include the ability to instantly jump to any part of a recorded television or other program content are desirable functions for a PVR system. According to the present invention, random access of different packets is possible because the key extracting module 314 can easily determine which secret key is used for decryption by the decryption module 314. That is, the key extracting module 314 determines which secret key should be used by inspection of the modified sync field of each encrypted packet 304. Additionally, because the sync field (sync_byte) is not a reserved field of the transport packet (transport_packet) shown in
In one embodiment, if the keys within the key table 216 and 315 are not changed, by simply indicating which of the secret keys of the key table 214 was utilized to encrypt a packet, if a user wants to fast forward three minutes, the PVR system 200 can directly skip three minutes worth of encrypted data on the storage device 302 and still be able to immediately determine which secret key of the key table 315 needs to be utilized to decrypt data of the encrypted packets 304 retrieved from the storage device 302. Therefore, the PVR system 200 according to this embodiment of the present invention allows for both content protection and random access of the data in the storage device 302.
It should also be noted that the respective secret keys used in the above operations for encrypting (step 618) and decrypting keys are not necessarily the same secret key. For example, encryption and decryption will use same key for same packet; however, we can change the key every number of transport packets based on system design need. With embedded key in TS and packet insertion scheme it will able to change keys on the fly with less CPU or control logic interference.
The present invention provides a method of embedding information in a synchronization byte of a packet to be stored in a personal video recorder (PVR). The method allows dynamic security functions for improved content protection and comprises steps of providing a set of secret keys having a predetermined number of secret keys; generating a key indication value; selecting a secret key from the set of secret keys according to the key indication value to form a selected secret key; generating an encrypted packet based on the selected secret key and a packet in the transport stream by: encrypting the payload of the packet according to the selected secret key, and storing the key indication value in the sync field; and generating the protected transport stream based on the encrypted packet. In this way, random access of different packets in the PVR is possible because a decryption module can easily determine which secret key is used. That is, it can be determined which secret key should to be used to decrypt a stored packet by inspection of the modified synchronization byte. Additionally, by inserting an extra packet into the PVR every time period T, unlimited new security keys can be used by the PVR system according to the present invention. In contrast to the prior art, this method of providing a new secret key every predetermined number of packets is much faster than having to examine every packet stored in the PVR to see if the packet corresponds to a key exchange packet.
Those skilled in the art will readily observe that numerous modifications and alterations of the device and method may be made while retaining the teachings of the invention. Accordingly, the above disclosure should be construed as limited only by the metes and bounds of the appended claims.
