KR20080069327A - Method for the protected distribution of contents in iptv environment - Google Patents

Abstract

A method for protecting and distributing contents in an IPTV is provided to provide security for audio and video contents during their transmission and storing in an IPTV. The first device receives a scrambled program including a scrambled data component and a descrambled key. The first device rebundles the descrambled key by using a unique key related to the first device. The second device receives the scrambled data component and the rebundled descrambled key. The second device obtains the descrambled key from the rebundled descrambled key. The second device descrambles the scrambled data component by using the descrambled key. The unique key related to the first device is a public key which is positioned at the first device. A corresponding private key is positioned at the second device.

Description

METHODO FOR THE PROTECTED DISTRIBUTION OF CONTENTS IN IPTV ENVIRONMENT}

1A and 1B are system block diagrams of an XCA structure in accordance with the present invention.

2 is a block diagram of a typical XCA device used in the XCA architecture of FIG.

3 illustrates a model for distributing public and private keys in accordance with the invention of FIG.

4 is a block diagram illustrating generation of a LECM in accordance with the invention of FIG. 1.

5 is a block diagram illustrating the flow of content in accordance with the invention of FIG.

6 is a schematic diagram illustrating protection of an NRSS interface in accordance with the invention of FIG. 1.

7 and 8 are schematic diagrams for creating a secure and authenticated link according to the invention of FIG.

The present invention relates to a method for content protection distribution in an IPTV environment. The scrambled content can be recorded in all situations, but only authorized copies are processed for descrambling and viewing.

Copyright holders and content creators, such as movie studios and production companies, seek to protect their investments, such as movies, programming, services, software, and the like. Such content is typically supplied to consumers through rental and retail sales of network broadcasts, premium programming cables or satellite channels, pay-per-view events, and videocassettes.

Analog videocassette recorders (VCRs) allow consumers to watch content at their convenience. Fortunately, such analog VCRs reduce the quality of the recording in each generation so that the second or third generation is generally unacceptable to most viewers. However, in digital technology, there is no longer a generation degradation characteristic inherent in analog technology. The nature of digital storage and transmission allows continuous copy generation to be produced at the same quality as the original master. Today, most products receiving digital video services have only analog outputs. Next generation products with digital outputs will allow the convenience of higher quality recording and networked systems. Home networks that receive content for display and storage should also now protect the content against illegal copying or distribution.

The draft Video Home Recording Act of 1996 defines the Copy Generation Management System (CGMS) as a mechanism that manages the creation of copies but not the viewing of such copies. The concept of CGMS does not satisfactorily match the rights of the copyright holder. In practice, the copyright holder has a greater interest in controlling the actual viewing of the material as opposed to copying the material. Today, even when using industry standard analog copy protection technology, particular attention is paid to the individual ability to view copies. This is different from restricting the copy device from actually creating such a copy.

This problem is exacerbated by the rapid development of digital media distribution such as the Internet. Therefore, there is a need to provide a secure solution to protect the intellectual property of the copyright holder.

The present invention is, in part, in recognizing the problems described above and in part in providing a solution to the above problems. Overall, the present invention provides a method for managing access to scrambled program content. The present invention protects content within the network by rebundling a key required for descrambling, such as a TDES key, into a new entitlement control message (ECM) (known as LECM). The method includes receiving a scrambled program (eg, scrambled data component and descrambling key) at a first device and rebundling the descrambling key using a unique key associated with the first device. can do. The descrambling key is used to descramble the scrambled data component obtained from the rebundling descrambling key at the second device.

In accordance with an aspect of the present invention, the descrambling key is encrypted, and the step of rebundling comprises decrypting the encrypted descrambling key using a key associated with the scrambled program, and the rebundled descrambling key (ie, Re-encrypting the descrambling key using the key associated with the first device to generate the LECM.

According to another aspect, the present invention provides a method for managing access to a scrambled program received from a service provider in a network. The encrypted descrambling key associated with the scrambled program is decrypted at the access device using the key associated with the service provider, and then the key is re-encrypted using the public key associated with the access device. The presentation device decrypts the re-encrypted descrambling key and descrambles the scrambled data component using the descrambling key. The invention can also be used to manage access to scrambled pre-recorded programs.

According to yet another aspect, the present invention provides a method for recording a scrambled program received from a service provider. The method includes receiving a scrambled program and decrypting an encrypted descrambling key at an access device (which in this case may be a video recording device) using a key associated with the service provider. The descrambling key is re-encrypted using the public key associated with the access device. The recording device records the scrambled data component and the re-encrypted descrambling key on a medium connected to the recording device.

General purpose prevention systems for IPTV, also known as extended conditional access (XCA), are defined in this application. XCA is an alternative copy protection system designed to be used through renewable security devices such as smart cards. The Consumer Electronics Manufacturers Association (CEMA) has three standards for interconnecting digital television with other devices: (1) EIA-775-digital television 1394 interface, (2) EIA-761-8-VSB. Remodulator interface, and (3) the EIA-762-16 VSB remodulator interface. EIA-761 and EIA-762 are unidirectional transmission interfaces, while EIA-775 supports bidirectional communication. Although XCA is successfully used in accordance with any of these interconnect standards, it is not limited to these three standards.

The flow of information is mostly unidirectional in XCA systems. The content is passed from the source to the display while maintaining its original scrambling. Because content is chain protected instead of link protected, subsequent links do not need to determine or set a key. All information is always conveyed exactly from the source device to the sink device, ie towards the presentation device (set-top box or digital television (DTV) typically associated with the television) for final viewing.

To illustrate the invention the following definitions are used. Encryption or scrambling is the process of transforming plaintext into ciphertext (ie, E _c'k [M]; Message M is encrypted via encryption algorithm C using key K}, decryption or descrambling is the reverse process. Traditionally, encryption and decryption are used when discussing control words or keys, and scrambling and descrambling are used when discussing audio / video content. A control word (CW) is a key used to scramble and descramble audio / video content. A cryptographic system is a system for achieving confidentiality, that is, information security objectives.

In a symmetric cryptographic system, the cryptographic and decryption keys can be identical or easily determined from each other. In an asymmetric or public key cryptosystem, it is computationally difficult for at least one key to be determined from another key because the encryption and decryption keys are different. Although the two keys are mathematically related, it is not possible to derive the private key through suitable computational resources. As described in more detail below, each access device includes a unique public key to locally encrypt the descrambling key (LECM). This unique public key is transmitted from the conditional access (CA) server when the access device is initialized in the field or stored in the access device during manufacture. During initialization, as described in more detail below, an access device may access the CA server to obtain a unique public key using the identification of the access device.

In particular, XCA protects digital MPEG-2, or equivalent encoded audio / video (A / V) content during transmission and storage. This is achieved by mapping three basic controls: "playback control", "record control" and "one-generational control" to "viewing control". do. With XCA, economically valuable content is always scrambled under the control and responsibility of the distributor or within the consumer's home network. Recording of scrambled content is always allowed in all situations, but only authorized copies are processed for descrambling and viewing in licensed devices.

XCA handles two important elements for viewing control: time and space. View control over time provides a mechanism for regulating when content can be viewed today or in the future. View control over the space defines where and who can see the material. At the same time, this area covers the entire viewing space, giving the copyright owner complete control over how content should be distributed and used.

XCA provides three levels of entitlement. First, content that is freely distributed in an unrestricted form is "free-copy" content. Examples of "free-copy" content may be broadcast television, informational commercials or similar materials supported by advertisers. Local viewing programming, or "copy-once" content, gives a single household the ability to make and view copies at any time. However, such a copy cannot be transferred to another local network because LECMs created in one network cannot be decrypted in another local network. Examples for this type of content may be sporting events or premium services. Finally, "never-copy" or immediate viewing programming content only allows viewing in real time, that is, the recorded copy will never be viewed. Examples for this type of content may be pay-per-view programming or other expensive content.

1A and 1B illustrate the unique features of the XCA structure 10, namely the concept of local protection and conditional access. Economically valuable content 11 from tape, DVD, cable, satellite or terrestrial broadcasts is generally delivered via a private conditional access service. Audio / video content and keys are protected using a secret conditional access structure and supplied to all subscribers of the service. The subscriber who purchased the content is provided with a key necessary to descramble the content. An access device 14, such as a set-top box, for example, generally associates with a smart card to obtain or generate a key for descrambling video content. In the XCA structure, this is the handling of conditional access. Local protection is protection of content within the home network boundary after the access device receives the scrambled program from the service provider.

Generally, a consumer electronics (CE) device 20 (“XCA device”) used within the XCA structure 10 is defined in FIG. 2. Such a device has, at a minimum, a switching unit 22 and a digital input stage 24. Depending on the type of device, the device may include one or more of the following elements, such as security device 26 (typically updateable), storage unit 28, analog output stage 30 and / or digital output stage 34. It may also include. Some device types include, for example, (1) XCA access device 14 (e.g., set-top box, DVD player, DTV) creating "XCA protected content" and (2) XCA presentation device 16 (e.g. , DTV) descrambles "XCA protected content", and (3) the XCA recording device 18 (e.g., DVHS or DVD recorder) only creates or decodes the "XCA protected bitstream". Limited to certain features, such as not being able to scramble.

The access device typically operates in cooperation with an XCA / NRSS converter card (see 26A in FIG. 5). The XCA / NRSS translator card generates XCA protected content from XCA universal protected content or secret conditional access (CA) protected content. Presentation devices such as DTV 16 operate in cooperation with an XCA / NRSS terminal card (see 26B in FIG. 5) for descrambling XCA protected content. If the DTV is used as an access device as well as a presentation device, the DTV can operate through both the converter card 26a and the terminal card 26b, or the functions of both cards 26a and 26b are integrated into one card. Can be.

The XCA structure uses the ECM to carry (1) clear content that is not protected by any means, such as broadcast programs, for example, and (2) control words (CW), such as digital satellite or cable services, for example. XCA using local ECM (LECM) to carry CA content, (3) CW or key (LECM encrypted using public key associated with access device 14), which is scrambled by the CA system. XCA content scrambled by (4), and (4) NRSS content scrambled by the XCA NRSS copy protection structure. In addition, XCA content scrambled using Universal ECM (UECM) to carry CW can also be processed by this system. UECM is encrypted using one unique universal public key common to all networks and can be used for example for pre-recorded content.

Typical functionality for the XCA device of FIG. 2 is described below. Digital input 24 includes all the circuitry and software necessary to obtain a digital signal. The digital input terminal may take the form of a digital bus (e.g., IEEE 1394), telco, LAN, RF VSB / QAM, and the like. Similarly, digital output stage 34 includes all the circuitry and software necessary to provide a digital signal and may take the form of a digital bus (eg, IEEE 1394), telco, LAN, RF VSB / QAM, and the like.

Security device 26 may process CA functions and XCA functions and modify the type of content, regardless of whether it is updatable, such as an NRSS card, or embedded within host device 20. Secure device 26 can only be connected to one single XCA device at a time, providing modified content. The table below summarizes the allowed variants.

Signal input ＼ signal output clear CA XCA NRSS clear Yes (T0) no no no CA Yes (T4) Yes (T0) Yes (T1) Yes (T2) XCA Yes (T5) no Yes (T0) Yes (T3) NRSS no no no Yes (TO)

The following variants are applicable to security devices that are both removable and built-in.

TO is an identification variant. The output stream exactly matches the input stream. This enables card chaining.

T1 If the user has the correct CA authority, then the secure device recovers CW and descrambles the content. The secure device then generates a TDES key, re-scrambles the content, and encrypts the LECM using its public key. If the content source is an ATSC compatible system (ie, TDES scrambling), descrambling may not be needed.

T2 If the user has the correct CA authority, then the secure device recovers CW and descrambles the content. The security device then re-scrambles the content following the request of the XCA NRSS interface protection system described in more detail below. CA providers define this variant.

T3 If the user has the correct XCA rights, then the secure device uses the CW of LECM to descramble the content. The secure device then re-scrambles the content following the request of the XCA NRSS interface protection system.

The following two variants apply only to embedded security devices:

T4 If the user has the correct CA authority, then the secure device recovers CW and descrambles the content. CA providers define this variant.

T5 If the user has the correct XCA rights, then the secure device uses the CW of LECM to descramble the content.

The translator card supports at least variant T1, and the terminal card supports at least variant T3. In addition to the above requirements, if secure device 26 is updatable and capable of non-volatile storage of program content, then its storage will not accept NRSS content. If the security device 26 modifies the content (e.g., scramble / re-scramble the content or encrypt / re-encrypt the LECM), then the security device 26 will follow NRSS-A or NRSS-B. will be. Finally, if security device 26 requires NRSS interface protection 35, then security device 26 may be configured as an XCA NRSS interface as referenced in EIA-679B (described in more detail below). I will use a protection system.

The storage unit 28 may be removable such as a fixed or recordable DVD, DVHS tape or the like such as a hard drive. The storage unit 28 may store the clear or XCA content and replay the content later when requested by the system. That is, storage unit 28 may read and optionally record content, but does not modify the type of content.

Presentation device 16 descrambles 35 the NRSS copy protection stream, if necessary, and then decodes 36 MPEG2 content. The descrambled and decoded content is then presented to the user in analog form by passing the content through a digital-to-analog converter 38. The end result can be the analog output of a hi-fi amplifier or a physical signal such as a TV display. Presentation device 16 may have one or more analog outputs, that is, uncompressed digital outputs. In this case, the output is protected by the associated copy protection system.

The switching unit 22 routes the content within the XCA device. The function of the switching unit 22 is only limited to routing, and does not change the type of content. The following table defines several routing options depending on the content format.

Sauce sink Digital output stage 34 or storage device 28 Security device (26) (removable or built-in)    Express device (16) Digital input 24 or storage device 28 clear Yes Yes Yes Scrambling Yes Yes NA ¹ NRSS No ² No ² No ² Security device 26 (removable or built-in) clear Yes Yes Yes Scrambling Yes Yes NA ¹ NRSS no Example ³ Yes

Footnote 1: It is pointless to send scrambled content to the presentation unit. The presentation unit cannot descramble the data and therefore cannot use any scrambled content.

Footnote 2: NRSS data shall not be accepted by digital inputs or storage units. Thus, NRSS data cannot be sent to other parts of the device.

Footnote 3: NRSS data can be authorized from one security device to another for 'display chaining'. The content may pass through subsequent devices in sequence, but the key (or NRSS CP secret key) should not be disclosed to any other device (including secure device).

Before accepting the public key used to generate the LECM (ie rebundling of the ECM), the access device must verify that it has a legitimate public key, i.e., a public key generated by an authorized entity. do. Certification is one way to provide this assurance. The access device will only provide XCA content using the authorized public key. A public key certificate is a signed message that associates a public key with an originating entity.

A unique local public / secret key pair is assigned to the security device 26 used in the XCA architecture. There are two types of security devices: devices with transducer modules and devices with terminal modules. Every translator and terminal module can be assigned a unique RSA public key / secret key pair with a unique 64-bit identification and a 1024-bit length.

A model for distributing public and private keys for a translator module is illustrated in FIG. 3, where a trusted third party (TTP), the CA provider itself or an independent authority is a copy of the public / private key. Create it and keep it in the database. The public key must exist in the translator module of the secure device associated with the access device before any translation can be made. The corresponding secret key is downloaded to the terminal module when requested.

There are two modes for distributing public keys:

Offline mode: In this mode, a set of XCA_IDs are passed to the card issuer or card manufacturer. Each ID is paired with a corresponding public key. The card issuer or card manufacturer stores the information on the secure device in a way to ensure its integrity.

On-line mode: In this mode, only the XCA_ID is passed to the card issuer or card manufacturer. The XCA_ID is stored in the secure device in a way to ensure its integrity. When first used in the field, the translator module requests its public key from the TTP. Transfers are made using a secure, authenticated channel defined by the CA provider.

In response to the request of the terminal module, the TTP delivers the secret key of the designated translator module to the terminal module only. The transmission will use a secure and authenticated channel defined by the CA provider. The terminal module will request the secret key of the designated converter module when it receives a LECM from an unknown converter module. The converter module issues such LECM at least at the beginning of each session. The session starts each time the access device delivers content to the presentation device. The TTP is responsible for monitoring the request to detect invalid requests. The security policy associated with this task is determined by the CA provider as part of its risk analysis.

The communication between the converter / terminal modules 26a and 26b and the TTP will be under the control of the CA provider operating the XCA system. TTP will select and implement the appropriate communication channel and message protocol needed to distribute the key. In implementing an XCA system, a CA provider can choose a specific communication channel or secret message protocol. CA providers will need to collaborate and exchange data to ensure interoperability of secure devices in the home network. This need may arise, for example, when the translator card and the terminal card are provided by different CA providers. When the terminal card has requested a secret key belonging to the translator card from the TTP, the TTP will have to obtain the secret key from the CA provider that owns the translator card.

The key for descrambling the content is rebundled in the LECM by the access device 14. That is, the encrypted ECM carrying the descrambling key is decrypted by the access device 14 and then re-encrypted using the local public key associated with the access device to generate the LECM. In particular, the XCA system 10 achieves local security by merely descrambles the content when the content is viewed in connection with, for example, a local presentation device (eg, digital television) 16. Secret conditional access protects the content transmission from the service provider (ie tape, DVD or broadcast 11) to the user access device 14. The XCA structure protects content in local networks.

In particular, XCA works on the principle that content must always be encrypted, including in the case of distribution and storage. As an example, consider premium programming delivery from a multi-program video provider. The provider's secret CA system is responsible for making the content available to consumers in accordance with the authority for which consent has been made. In an ATSC-compatible digital delivery system, a program is MPEG compressed and scrambled using a Triple DES (TDES) algorithm. The key for descrambling the program is contained in an authority control message (ECM) which itself is encrypted in some secret unknown form. Consumers authorized to view the program must be provided with either a descrambled transport stream or a scrambled transport stream with the key required for descrambling at the time of viewing. The first case is not provided for the protection of the content.

As shown in Fig. 4, the XCA rebundles (i.e. ECM transitions) the key required for descrambling (i.e., the TDES key) to the new ECM protected by the local public key associated with the access device (i. (42) thereby protecting content on the local network. This processing is typically performed at the access device 14 and preferably the security device 26. In this form, only a device capable of descrambling MPEG programs by recovering a TDES key is a local presentation device such as, for example, a DTV. Since every local network contains a unique set of public / private pairs, only local systems that have recorded or watched the original content can access any copy derived from its local network distribution content. You can watch. Even if there is a rogue device that performs an illegal and unauthorized copy, such a copy is only viewable within the local network.

The flow of content with an XCA domain is further described using FIG. 5. The CA and XCA functions may be selectively removed from the access device and placed in a specific security device 26 known as translator card 26a. Similarly, terminal card 26b may optionally assume the CA, XCA and NRSS functionality (ie, security side) of presentation device 16. In particular, the flow of content within the XCA domain includes delivering the incoming CA content from the access device 14 to the CA module 42 of the secure device 26a. CA module 42 recovers the control word (CW) or key for CA content and delivers CW to converter module 46 which generates the required LECM. The translator module 46 delivers the XCA protected content back to the access device 14, which in turn delivers the XCA protected content to the presentation device 16. XCA protected content is delivered to secure device 26b, in particular terminal module 50, via CA module 48. Terminal module 50 recovers CW from LECM and descrambles XCA protected content. The clear content is now delivered to the NRSS CP module 52, and both the NRSS CP module 52 and the presentation device 16 are involved in generating the scrambling key. Scrambling keys are generally symmetric keys, but other approaches using public keys may be used. The functionality of NRSS CP module 52 is shared by secure device 26b (denoted 52a) and presentation device 16 (denoted 52b). The NRSS CP module 52 scrambles the content using this scrambling key, preferably by using DES, and then passes the scrambled content to the NRSS CP module 52b in the presentation device 16, and the NRSS CP module 52b descrambles scrambled content for display.

In an XCA system, both real-time and pre-recorded content remain scrambled throughout the system. The XCA presentation device 16 using the copy protection system as defined in EIA-679 and EIA-796 achieves final descrambling. In this form, copy protection management is provided throughout, ie from the source of scrambling to the final viewing display. As illustrated in FIG. 6, the XCA protects the NRSS interface by rescrambled content using a single DES according to a randomly generated key between the presentation device and the NRSS card. This protocol, known as the Diffie-Hellman key agreement, ensures that the third party cannot simply recover the key by tapping the smart card interface.

In particular, the protection of the NRSS interface is based on three basic principles. The first is to limit the devices that can receive copy protection data by requesting a license. Second, scramble the data and protect the key such that such a passive device cannot record the signal and decode the clear bitstream. Finally, it connects the host presentation device and the terminal card and authenticates the host device to make it difficult for such an active device to record the bitstream to generate the bitstream.

Thus, in general, a method for establishing an XCA-protected NRSS link includes: (1) authenticating a presentation host device, (2) establishing a unique shared secret key for a particular presentation device / terminal card pair; (3) generating a content protection key (e.g., a shared key) in real time; (4) scrambling content to be returned to a host (e.g., a DTV) in accordance with DES; Descrambling the content received by the host. These steps are illustrated in FIG. 6.

Every XCA presentation device will be manufactured with a unique ID. This ID can be used to identify the manufacturer and the specific XCA presentation device. This ID is guaranteed to be unique by the manufacturer, but is not validated or secure anyway. This allows the host to be uniquely identified for security and also makes device revocation substantially unmanageable. Forging clearly valid IDs is very simple, but the security method outlined below eliminates any important value in implementing security.

Terminal cards based on NRSS can create a secure and authenticated link with the presentation device by communicating with a trusted third party (TTP). The device ID or model number and serial number can be used to obtain the correct DH public key for any given host. In this configuration, as illustrated in Fig. 7, an ID / serial number is sent to the TTP (steps 1 and 2). The TTP queries the manufacturer database for the host (step 3), determines the correct public key for the XCA presentation device (step 4), and sends some secret certificate to the CA module over a secure channel (step 5). . Alternatively, as illustrated in FIG. 8, the card may request a public key from the host device (step 1) and send the public key to a CA head-end or TTP for authentication and storage (step 2). . There are many practical communication messages and channels. Possible for the communication channel is telephone line, return path communication, transmission of the EMM through the distribution network, or even shipping of physical units.

Only devices that are permitted to use the XCA NRSS copy protection system outlined herein may be (1) a digital input capable of receiving data from the NRSS interface or (2) any mass storage means capable of receiving data from the NRSS interface. It is a device not provided.

The shared secret key will be set between any given pair of presentation devices and terminal cards. In the option of a terminal card, a single shared secret key value can be used for all sessions, or a new-shared secret key can be generated for each session if additional security is required. The method for generating a secret key is outlined in the copy protection framework for NRSS (Section 20.3 of part A or Section 8.9.3 of part B of EIA-679B). Control words to protect content moving across the NRSS interface will be generated according to the NRSS standard (Section 20.5 of Part A or Section 8.9.5 of Part B of EIA-679B).

The interval for updating the NRSS content scrambling key is the same as the interval for updating the content scrambling key in the local network packet. The update rate in the local network packet can be set in part using the source_sequence_number. At each new source_sequence_number, a new NRSS key must be used. If the new key is an EVEN key in the negotiated pair, then the new negotiation must begin at the same time that the new key is used. If this negotiation does not terminate before the next increment of the source_sequence_number, then the terminal card should stop providing NRSS content because the host does not work properly. This requires the host (and card) to be able to complete the key negotiation in less than 900mS.

Content scrambled for protection on the NRSS interface will follow the NRSS standard (Sections 20.5.3 and 20.5.4 of Part A or Sections 8.9.5.3 and 8.9.5.4 of Part B of EIA-2679B). All packets in the main video stream and the main audio stream (which are active) will be scrambled.

XCA uses the EIA-679A copy protection format (# 1) with a field size defined below.

Data type_id ID value Size in bytes Host_id 05 8 N_Host 07 8 N_ module 08 8 Host DH Public Key 13 96 Module DH Public Key 14 96 CCI 18 8

Every CA system to be used in an ATSC broadcasting system is assigned a unique CA_system_ID. Similarly, XCA uses a unique CA_system_ID to perform local translations. The value chosen for XCA is 0x1180. Broadcasters will include this ID in their list of CA providers. During the transmission of the content, an unused PID will be allocated for the XCA LECM. Each program that needs to be converted to XCA will appear as a PMT, which contains the XCA_System_ID indicating the assigned LECM PID. The empty packet with the LECM PID does not need to be injected into the broadcast transport stream when the CA ECM is replaced by the LECM in the conversion process.

The MPEG2 transport stream is composed of transport packets as shown below.

Syntax No. of bits Mnemonic MPEG2_transport_stream () {do {transport_packet ()} while (nextbits () = = sync_byte)}

Transport packets protected under XCA security are scrambled using triple-DES, ie according to the ATSC specification for conditional access. PIDs carrying both non-local and local ECM (LECM) will be specified by the program map table defined in the MPEG2 standard.

The local ECM table will be packets sorted with the syntax defined below.

Syntax No. of bits Mnemonic LECM_transport_packet () {sync_byte 8 bslbf transport_error_indicator 1 bslbf payload_unit_start_indicator 1 '1' transport_priority 1 bslbf PID 13 uimsbf transport_scrambling_control 2 '00' adaptation_field_control 2 '01' continuity_counter 4 uimsbf pointer; data_byte 8 uimsbf {}

here:

sync_byte: Fixed 8-bit field with value '0x47'.

transport_error_indicator: 1-bit flag. When set to '1', it indicates that there is at least one uncorrectable bit error in the packet.

payload_unit_start_indicator: The 1-bit flag will be set to '1' and the first byte of the payload of this transport stream packet will carry a pointer_field.

transport_priority: 1-bit flag. When set to '1', it indicates that the packet has a higher priority than other packets with the same PID that do not have the bit set to '1'.

PID: 13-bit packet identifier.

transport_scrambling_control: The 2-bit field shall be set to '00', meaning that the packet is not scrambled at the transport level.

adaptation_field_control: The 2-bit field shall be set to '01', meaning that there is no adaptation field after the transport stream packet header.

continuity_counter: 4-bit field that increments with each transport stream packet with the same PID. It wraps around zero after reaching its maximum value.

pointer_field: The 8-bit field contains the number of bytes immediately following the pointer field up to the first byte of the first section present in the payload of the transport stream packet. A value of 0x00 indicates that the section starts immediately after the pointer field.

data_byte: Contiguous 184 bytes of data from the local authorization control message section or packet stuffing bytes after the local authorization control message section. A packet stuffing byte of 0xFF value can be found after the last byte of either section. In that case, all subsequent bytes up to the packet end will also be stuffing bytes of the oxFF value.

The local rights control message may include one or more sections, each of which may vary in length. The LECM may include at least (1) the XCA device identification of the security device that generated the LECM, (2) copy control information that may be used to assert viewing rights, and (3) descrambling keys.

The present invention is useful for providing local security of audio and video content during transmission and storage in IPTV.

Claims (16)

A method of managing content protection distribution in IPTV, in a network comprising a first device interconnected with a second device, the method comprising: (a) at the first device, receiving the scrambled program comprising a scrambled data component and a descrambling key; (b) at the first device, rebundling the descrambling key using a unique key associated with the first device; (c) at the second device, receiving the scrambled data component and the rebundled descrambling key; (d) obtaining, at the second device, the descrambling key from the rebundled descrambling key; (e) at the second device, descrambling the scrambled data component using the descrambling key Including, how to manage the content protection distribution in IPTV. The method of claim 1, The descrambling key is encrypted, The rebundling step, (a) decrypting the encrypted descrambling key using a key associated with the scrambled program; (b) re-encrypting the descrambling key using the unique key associated with the first device to generate the rebundled descrambling key. Including, how to manage the content protection distribution in IPTV. 3. The device of claim 2, wherein the unique key associated with the first device is a public key, the public key is located in the first device, and a corresponding private key is located in the second device. How to manage content protection distribution in IPTV. The method of claim 2, wherein the rebundling is performed in a first smart card connected to the first device, and the acquiring and descrambling are performed in a second smart card connected to the second device. How to manage content protection distribution on IPTV. 2. The method of claim 1, further comprising initializing the first device in the network. 6. The method of claim 5, wherein the initializing step comprises receiving a public key from a conditional access provider, wherein the receiving step comprises authentication of the conditional access provider. . 6. The method of claim 5, wherein the public key is pre-stored in a smart card connected to the first device or in the first device. The method of claim 1, wherein the descrambling key is encrypted using a Local Entitlement Control Message (LECM) when the scrambled program is received from a pre-recorded medium, or the scrambled key. A method of managing a content protection distribution in IPTV, protected by an Entitlement Control Message (ECM) when a program is received from a service provider.  The method of claim 1, wherein the first device is an access device and the second device is a presentation device. A presentation device for managing access to scrambled programs, (a) means for receiving, by an access device, the scrambled program comprising a rebundled descrambling key and a scrambled data component encrypted using a network key; (b) a module for decrypting the rebundled descrambling key to generate the descrambling key; (c) a module for descrambling the scrambled data component using the descrambling key to obtain a descrambled program; And (d) means for presenting the descrambled program And a presentation device for managing access to the scrambled program. 10. The method of claim 9, wherein the scrambled program is received from a service provider, the descrambling key is encrypted, The rebundling step is: At the second device, decrypting the encrypted descrambling key using a key associated with the service provider; At the access device, re-encrypting the descrambling key using a public key associated with the access device, Acquiring the descrambling key at the presentation device may include: Decrypting, at the presentation device, the re-encrypted descrambling key to obtain the descrambled program. Including, how to manage the content protection distribution in IPTV. 12. The method of claim 11, wherein the scrambled program is pre-recorded on a medium and provided to the access device, wherein the encrypted descrambling key is received from the pre-recorded medium. The method of claim 2, wherein after rebundling the descrambling key: At the recording device, receiving the scrambled data component and the re-encrypted descrambling key; Recording the scrambled data component and the re-encrypted descrambling key on a medium connected to the recording device; And Providing the scrambled data component and the re-encrypted descrambling key to a presentation device. Further comprising, how to manage the content protection distribution in IPTV. The method of claim 13, wherein the scrambled program is pre-recorded on a medium. A method of modifying content information included in a scrambled program received from a service provider at a secure device, the method comprising: Receiving, at the secure device, the scrambled program comprising scrambled content information and a descrambling key; At the secure device, descrambling the scrambled content using the descrambling key; Generating another scrambling key at the secure device; Re-scrambling the content using the another scrambling key; Encrypting a Local Rights Control Message (LECM) containing the another scrambling key using a unique key; And Providing the re-scrambled content and the LECM (Local Rights Control Message) to a presentation device. And modifying the content information at the secure device. 16. The method of claim 15, further comprising determining a user entitlement for the scrambled program prior to descrambling the scrambled content.

Images