Signing and authentication devices and processes and corresponding products

Signature and authentication equipment and methods and corresponding product technical fields

[0001] The present invention relates to signing and authentication (authentication) equipment and methods and related products, especially for DVB (Digital Video Broadcasting)/MPEG (Moving Picture Experts Group) digital streams, especially for MHP (Multimedia Home Platform) standard.

Background technique

[0002] Therefore, it particularly relates to the field of digital television. The digital TV environment includes the broadcasting or streaming of different types of data. For example, different types of data include audiovisual content (typically MPEG audio/video), interactive content, triggers, and program-specific information (and the transmitted program Relevant special information, abbreviated as "PSI"), service information (supplemental information that enables the receiver to automatically configure and enables users to browse the service through the EPG-Electronic Program Guide, abbreviated as "SI"), special data, information Order etc. Generally, information related to the source, sink, and structure of the content (that is, PSKSI and some dedicated data) is integrated in the signaling.

[0003] These data are usually transported through the MPEG-2 transport stream, which consists of audiovisual streams transported in PES (Packet Unit Stream) and other information (signaling, PSI, SI, interactive content...) composition. Some digital broadcast networks and broadband networks are more or less vulnerable to spoofing attacks. A well-equipped pirate can interpret the data on the network, modify it, and rebroadcast (or re-stream) the data. Terrestrial and microwave broadcasting networks are more vulnerable to attacks than satellite or cable networks. Therefore, the problem is to ensure the security of digital data transmission on the MPEG-2 network.

[0004] In fact, some data items listed as audiovisual content, PSI and PI are pure broadcast content, so the piracy of them will cause users' annoyance, but at least it will not affect their wealth. However, interactive terminals with return channels can run t-commerce (TV commerce) or home banking applications. The spoofing of such applications will not only make users very angry, but may also cost them a lot of money.

[0005] Authentication of data content is already well known. In particular, reference WO-99/49614 describes a method for authenticating data sent in a digital stream, in which the data is organized hierarchically to form at least one root directory unit, sub-directory unit, and file unit. Sign the data in the file and store the relevant file authentication value in the reference subdirectory unit. Sign the file authentication value in turn, and store the relevant subdirectory authentication value in the reference root directory unit. Other schemes of this disclosure involve authenticating the second root directory by generating a second authentication value, and authenticating the data before encapsulating in a table or part of the transport stream.

[0006] Similarly, document WO-99/62248 discloses a method implemented in an interactive television system for managing modules of interactive television applications. The system transmits modules from a broadcasting station to multiple receiving stations. The receiving station has a module manager, stores module requests, and monitors multiple channels of modules corresponding to the requests. In a detailed embodiment, the application program to be transferred is composed of a series of modules, each of which is a directory module. The catalog module contains entries for each module in the application and sufficient information to allow the receiving station to access all modules of the application. In addition, an authentication mechanism can also be used in the receiving station to ensure that the currently downloaded conveyor belt and/or module are authentic.

[0007] In addition, interactive systems such as the DVB multimedia home platform specify how to authenticate broadcast applications, and it specifies how to protect data content transmitted through the return channel. However, spoofing is still possible because

CN 1628447 Β

Change the signaling in an appropriate way to cancel, replace or add content without any obvious difference. Therefore, attempts are not only to provide authentication of the content, but also to the authentication of the signaling itself, for example, especially for streams constructed according to the ATVEF (for Advanced Television Enhancement Forum) standard.

[0008] However, this method causes a special problem for DVB digital streams, because the streams are usually re-multiplexed in the head-end of the network. Therefore, due to network requirements, PID (packet identifier) or even tables such as PMT (representing a program mapping table, one table for each program, in addition to the dedicated information related to the program, may indicate the PID of the PES that constitutes the program), etc. The content of is in danger of being modified. This would mean calculating all hash codes and signatures again, which involves giving a private key to each multiplexer to calculate the appropriate signature. Now, the cost for providing verified key pairs to each multiplexer will be huge. Technicians who developed this signaling authentication strategy have discovered this situation.

Summary of the invention

[0009] The present invention relates to a device for signing a digital stream to be transmitted through a communication network, which is suitable for DVB digital stream authentication, especially for MHP applications, and makes communication more secure.

[0010] It also relates to a corresponding method, a device and a related decoder, and a method for authenticating a digital stream received through a communication network, and corresponding software and digital stream.

[0011] Therefore, the present invention is applied to a device that signs a digital stream to be transmitted through a communication network by generating at least one signature to be incorporated into the digital stream obtained by encryption applied to the digital stream . Each of these digital streams includes several information entities, including:

[0012]-content, at least related to audiovisual information;

[0013]-and at least one signaling, consisting of a collection of information related to the source, destination and structure of the content. Due to network requirements, the signaling can be reliably modified in the network, including what is called a descriptor The necessary data structure is mainly constructed by arranged groups called tables.

[0014] According to the present invention, the signature device is used to apply encryption at least to the signaling, and more specifically, the descriptors that are selectively determined among the descriptors applied to the signaling are called authentication descriptors. .

[0015] So, in contrast to the natural solution that would be adopted if the signaling has been signed, which is to apply the authentication process to the entire part (the sub-table of the signaling, which has a limited size), the specific descriptor of the signaling is selected for authentication . The immediate advantage of this surprising solution is that for signatures, descriptors that are not touched by the re-multiplexing step can be selected. Therefore, the protection against malicious modification can be realized very effectively, while avoiding the huge complexity of the authentication process due to re-multiplexing in the network head end.

[0016] In addition, in a re-multiplexing device, even when it is decided to retain some descriptors that will be modified during re-multiplexing, the entire part has to be signed again to generate a description that takes into account the modification. Compared with the updated signature of the symbol, it is lighter and faster. In fact, with the wise choice of modified descriptors, most of the information obtained at the launch stage can be retained, especially in the form of the unchanged digest value obtained by the hash, but only for the signature, the signature must be recalculated A small part of the information.

[0017] "Audiovisual information" means audio and/or video information.

[0018] Preferably, the digital stream is constructed according to the DVB and MPEG standards, more specifically according to the MHP standard.

[0019] The signature device of the present invention can be applied to the authentication of MPEG/DVB forms, especially for PSI forms: PMT, PAT (program access table, which means that for each program sent, the program number and PMT transmission grouping The link between PIDs), CAT (conditional access table, in the case of at least one program with conditional access, gives the right to carry management

Message-EMMs PES PID), and used in DVB-SI tables: NIT (network information table), SDT (service description table), EIT (event information table), TOT (time offset table), AIT (application Program information table), BAT (bundle association table). The signature device can also be applied to any MPEG/DVB-specific table based on the partial syntax of the MPEG2 system (ISO/IEC 13818-1).

[0020] Advantageously, the signature device includes means for enabling the user to select the authentication descriptor. For example, the user is a member of a broadcast group. Bei U, incorporate any one of the selected descriptors into the stream, so that when the receiver receives these streams, it will notify the receiver of the descriptor used, or before the transmitter and receiver The selected descriptors are agreed upon. Another solution is to determine the selected descriptor more systematically, for example, according to a specific standard version.

[0021] Preferably, the signature device is used for:

[0022]-introducing the signature in at least one lowest-level signature descriptor into the digital stream;

[0023]-and at least one certificate descriptor that will also include certificate data related to the signature;

[0024]-and at least one higher-level signature descriptor obtained by applying encryption to the lowest-level signature description and the content of the certificate descriptor is incorporated into the digital stream.

[0025] This is of great significance for safely and flexibly ensuring interoperability among multiple participants such as broadcasters and manufacturers.

[0026] In fact, as long as a few levels are provided, it will be able to lead to a public key infrastructure (PKI). Then, establish root certificate authority (for the highest level signature), and optionally, establish other certificate authority.

[0027] Preferably, the signature device includes means for incorporating the address of the authentication descriptor into the digital stream. This is an effective way to let the receiver know the description used for the signature.

[0028] Therefore, it is advantageous that the incorporation device is used to introduce at least one hash descriptor into each of the digital streams. The hash descriptor includes at least one digest value obtained by applying a hash algorithm to at least one of the authentication descriptors, and is used to calculate the signature. The hash descriptor also includes the address of the authentication descriptor used to calculate the digest value. These methods increase the efficiency of authentication because it relies on transmitting intermediate results for calculating the signature and thus for verifying its authenticity.

[0029] More specifically, the merging device is preferably configured to arrange the hash descriptors in the digital stream according to a tree structure, and pass at least one other hash descriptor with a lower level. To calculate at least one of the hash descriptors. The nested calculation of the digest value can gradually calculate the basic value (that is, the root digest value) from which the signature is finally obtained, while ensuring that all necessary information related to multiple authentication descriptors is considered.

[0030] Preferably, the digest value has a fixed size, which is the same as the usual situation in the existing hash algorithm.

[0031] It is also preferable to have the following embodiment with an incorporation device, each table includes at least one section having a limited size and assigned a number, and each section includes at least one ring that successively introduces a descriptor into the section. Advantageously, these incorporation devices are used to specify the address of each of said authentication descriptors belonging to at least one given ring of a given part and having at least one number of occurrences respectively for each of these rings, by at least mentioning and:

[0032]-the part number

[0033]-and the number of these occurrences.

[0034] In this way, the identifier of the descriptor used for verification can be recognized efficiently and in a simple manner.

[0035] Other possible transmission information for addressing includes:

[0036]-the version number of the part,

[0037]-and/or the type of the part.

[0038] In a specific implementation with the incorporation device, advantageously, the signature device is used to introduce a signature and possibly at least one digest value and certificate data into at least one specific part in the form of dedicated data, the The specific part is linked with the part containing the authentication descriptor. This implementation allows at least some authentication information to be separated from other signaling signals.

[0039] Therefore, in a preferred embodiment, the specific part is used to contain signature and certificate data, advantageously, in the form of signature and certificate descriptor, and the root digest value is given and points to the lower of the other parts. The root hash descriptor of the level digest value. This may be very advantageous because the structure of DVB/MPEG-2 does not allow the descriptor to be set at the beginning of a part, and this is valid for the entire remainder of the part. That is, all the descriptors are located somewhere in the ring, which is why the top-level descriptor cannot be sent directly with the part.

[0040] In another embodiment with a specific part, not only the signature and certificate data and the root hash descriptor are set in the specific part, but all other hash descriptors are set in the specific part ( For example, at the top level of the section). This is possible for DVB/MPEG-2 because the addressing mechanism allows direct addressing of the descriptors in the table.

[0041] The present invention also relates to a method corresponding to the above device, for execution by any embodiment of the signature device according to the present invention.

[0042] Another object of the present invention is a device for authenticating the digital stream received through a communication network by checking at least one signature incorporated in the digital stream. Each of these digital streams includes several information entities, including:

[0043]-content, at least related to audiovisual information;

[0044]-and at least one signaling, which is composed of a collection of information related to the source, destination and structure of the content. Due to network requirements, the signaling can be reliably modified in the network, including what is called a descriptor The necessary data structure is mainly constructed by arranged groups called tables.

[0045] According to the present invention, the authentication device is used to apply authentication at least to the signaling, and more specifically, a descriptor that is selectively determined among the descriptors applied to the signaling is called an authentication descriptor , Which calculates the signature.

[0046] Preferably, the authentication device is applied to a digital stream including a signature generated by the signature device according to the present invention.

[0047] The invention also relates to a decoder, characterized in that it comprises an authentication device according to the invention.

[0048] Another object of the present invention is an authentication method corresponding to the authentication device of the present invention, preferably for execution by any embodiment of the authentication device according to the present invention.

[0049] The present invention also relates to a computer program product, including program code instructions for executing the steps of the signature or authentication method according to the present invention when the program is executed on a computer.

[0050] The term "computer program product" should be understood to include any materialization of computer programs, not only related to storage support (tape, disk, ...), but also related to signals (electrical signals, optical signals, ...).

[0051] The present invention is also applied to a digital stream including several information entities, these entities include:

[0052]-content, at least related to audiovisual information;

[0053]-and at least one signaling, consisting of a collection of information related to the source, destination, and structure of the content. Due to network requirements, the signaling can be reliably modified in the network, including what is called a descriptor The necessary data structure, and the main

To be constructed by arranged groups called tables,

[0054] Incorporating at least one signature into the digital stream.

[0055] According to the present invention, the signature is calculated based on the signaling, and more specifically, the descriptor that is selectively determined from the descriptors of the signaling is called an authentication descriptor.

[0056] Preferably, the digital stream is generated by any embodiment of the claimed signature device.

Description of the drawings

[0057] The present invention will be better understood and illustrated by the following non-limiting embodiments with reference to the accompanying drawings, in which:

[0058] FIG. 1 is a schematic diagram of a signature device and corresponding authentication device according to the present invention;

[0059] Figure 2 shows the DVB/MPEG-2 unit stream, including audiovisual and dedicated data streams and related tables (PAT.PMT and AIT), and points out the links between the tables and the streams;

[0060]-and FIG. 3 show in detail some tables (PMT and AIT) shown in FIG. 2, which are related to the unit flow, and are related to application information and application flow.

Detailed ways

[0061] The transmitter 1 of the digital stream 10 sends these streams 10 through the network 5 to the receiver 2 with decoding capability (FIG. 1). The transmitter 1 is typically used for the broadcast stream 10, for example, the network 5 is a broadband or broadcast network , And especially cable or satellite networks. In another embodiment, the network 5 is constituted by the Internet. In the case shown, the digital stream 10 is constituted by a DVB/MPEG-2 stream, thereby including in particular content and signaling data related to it. The signaling is mainly composed of tables and includes descriptors. Stream 10 may comply with the MHP standard.

[0062] The transmitter 1 includes: a signature device 11 for signing the digital stream 10 to be sent; and a user interface 15 for specifically enabling a sender such as a broadcaster to control the signature process. The signing device 11 is used to sign signaling, not only content. It contains a selection module 12, which allows the user to select some descriptors of signaling through the user interface 15, called authentication descriptors, which are used for signaling authentication. Therefore, it is encrypted to obtain the relevant signature. The signature device 11 also includes an incorporation module 13 capable of incorporating the address of the authentication descriptor into the digital stream 10 sent.

[0063] Each receiver 2 includes an authentication device 21 capable of checking the received signature, especially the signature used for signaling authentication. The authentication device 21 can consider the authentication descriptor indicated in the stream 10 for authentication.

[0064] Now, an example of particular interest will be described. The important entry point for transmitting digital TV service (interactive or non-interactive) signals is the PMT (Program Map Table) specified in the MPEG-2 system standard (ISO/IEC13818-1). In the case of sending a signal for an interactive MHP application, PMT includes the location of the stream that transmits AIT (application information table) and the location of the stream that transmits application code and data (pointer to DSM-CC DSI message, DSM-CC Means "download service start, ISO/IEC 13818-6 international standard), as shown in Figure 2 and Figure 3. The following technical solution can protect the signaling data of the interactive MHP application, so that the decoding platform can check its transmission network Whether the above has been modified. In addition, the MPEG-2 system standard prohibits the scrambling of PMT, so scrambling is not considered here.

[0065] The protection of signaling is based on hash codes, signatures and certificates. These cryptographic messages are encoded by specifying three new descriptors, including the above objects:

[0066] · hash_descriptor

[0067] · signature_descriptor

[0068] · certificate_descriptor.

[0069] Here, for each part of the separate authentication, the hash_descriptor field is introduced separately, and we will consider this given part of the table below, regardless of whether the table is composed of multiple parts or only one part. On the other hand, the signature_descriptor field applies to all hash_descriptor fields in the table, and the certificate_descriptor field refers to all signature_descriptor fields in the table.

[0070] Description of hash_descriptor

[0071] The hash_descriptor can be located in the loop of AIT or PMT (or any other MPEG-2 table to be authenticated). More specifically, it is located in each descriptor ring including the descriptor to be authenticated. The position in the ring is not important, because hash_descriptor includes a descriptor_address field that can uniquely address each descriptor.

[0072] hash_descriptor contains a hash code, also called a digest value, which is calculated according to the descriptor pointed to by descriptor_address. In the case of AIT or PMT, it only includes descriptors following the same loop as hash_descriptor. The pointed-to description itself can be located in the hash_descriptor field, so that recursive-like calculation processing can be realized.

<td>[0073]</td><td colspan="3">The syntax of hash_descriptor is as follows:</td>

<td>[0074]</td><td>hash_descriptor () {</td><td></td><td></td>

<td>[0075]</td><td>descriptor_tag</td><td>8</td><td>uimsbf</td>

<td>[0076]</td><td>descriptor"ength</td><td>8</td><td>uimsbf</td>

<td>[0077]</td><td>digest_count</td><td>16</td><td>uimsbf</td>

<td>[0078]</td><td>for(i = 0 ;i &lt;digest_count ;i++) {</td><td></td><td></td>

<td>[0079]</td><td>digest_type</td><td>8</td><td>uimsbf</td>

<td>[0080]</td><td>descriptor_count</td><td>8</td><td>uimsbf</td>

<td>[0081]</td><td colspan="3">for(j = 0 ;j &lt;descriptor_count ;j++) {</td>

<td>[0082]</td><td>descriptor_address</td><td>40</td><td>uimsbf</td>

<td>[0083]</td><td>}</td><td></td><td></td>

<td>[0084]</td><td colspan="2">for(j = 0 ;j &lt;digest_length ;j++) {</td><td></td>

<td>[0085]</td><td>digest_byte</td><td>8</td><td>bslbf</td>

<td>[0086]</td><td>}</td><td></td><td></td>

<td>[0087]</td><td>}</td><td></td><td></td>

<td>[0088]</td><td>}</td><td></td><td></td>

[0089] Wherein "uimsbf" and "bslbf" respectively represent "unsigned integer most significant bit first" and "bit string leftmost bit first".

[0090] descriptor_tag: tag of hash_descriptor.

[0091] descriptor_length: the length of hash_descriptor.

[0092] digest_count: This 16-bit value identifies the number of digest values in this hash descriptor.

[0093] digest_type: This 8-bit value identifies the digest algorithm that may be used for the related descriptor. The allowable values are given in Table 1, where MD-5 is defined in RFC 1321 (RFC stands for Request for Comments; http://www.ietf.org/rfc/rfcl321.txt) (MD stands for "Message Digest" ), and in FIPS-180-1 (FIPS Public 180-1: Secure Hash Standard, National Institute of Standards and Technology, 1994; http://www. itl. nist. gov/fipspubs/fip 180-1. htm ) Defines SHA-1 (SHA stands for "secure hash algorithm").

[0094] Table 1-Allowable values of digest algorithm

[0095]

<td>value</td><td>Summary length</td><td>algorithm</td>

<td>0</td><td>0</td><td>Non-certified</td>

<td>1</td><td>16</td><td>MD-5</td>

<td>2</td><td>20</td><td>SHA-1</td>

<td>other</td><td></td><td>Keep</td>

[0096] descriptor_count: This 16-bit value identifies the number of descriptors related to the digest value. The value of this field should be greater than zero.

[0097] descriptor_address: This is the general address of the descriptor in the section, which will be explained in detail later. [0098] digest_length: This integer value gives the number of bytes of each digest value. It depends on the type of summary shown in Figure 1.

[0099] digest_byte: This 8-bit value holds one byte of the digest value.

[0100] Description of signature_descriptor

[0101] The syntax of the descriptor is as follows:

[0102] signature_descriptor () {

[0103] descriptor_tag uimsbf

[0104] descriptor "ength uimsbf

[0105] si gnature_i d uimsbf

[0106] signature_length uimsbf

[0107] for (i = 0; i &lt;N; i++) {

[0108] signature specific data

[0109]

[0110] }

[0111] descriptor_tag: the tag of signature_descriptor.

[0112] descriptor_length: the length of signature_descriptor.

[0113] signature_id: This ID (meaning "identifier") enables it to have signatures from more than one authority.

[0114] signature_length: indicates the length of the following loop.

[0115] Field^usignature specific data^,?Contains the following ASN. 1, ASN. 1 structure (representing the language of summary grammar comment one), which is a combination of BER (Basic Encoding Rules) and DER (Differentiated Encoding Rules) structures:

[0116] Signature: := SEQUENCE{

[0117] certificateidentifier

[0118] hashSignatureAlgorithm

[0119] signatureValue

AuthorityKeyIdentifier,

HashAlgorithmldentifier,

BIT STRING}

[0120] certificateidentifier: as defined in the ITU-T X.509 extension (representing the International Telecommunication Union-Telecommunication Standard Part, Recommendation X.509: Directory Authentication Framework, 1997), and is related to the AuthorityKeyIdentifier field.

Its identification carries the certificate of the verified public key used to verify the signature:

[0121] AuthorityKeyldentifier::= SEQUENCE{

[0122] keyidentifier[O]KeyIdentifier is optional,

[0123] authorityCertIssuer [l]GeneralNames optional,

[0124] authorityCertSerialNumber [2] CertificateSerialNumber optional}

[0125] The implementation does not require the use of the possible key identifier element ("keyidentifier") of the AuthorityKeyldentifier. The AuthorityKeyldentifier structure contains the authority certificate issuer identifier (authorityCertIssuer) and the corresponding authority certificate serial number element (authorityCertSerialNumber).

[0126] The authorityCertIssuer field contains the field directoryName", which gives the name of the issuer of the certificate carrying the public key used to check the signature (and thus is equal to the field issuerName used in the MHP).

[0127] hashSignatureAlgorithm: This field identifies the hash algorithm used. As it involves the encryption algorithm required to calculate the signature, it has been described in the certificate proving the relevant key (in the SubjectKeyInfo field). Therefore, only the identification of the hash algorithm is required. The supported algorithms are MD5 and SHA-1, where the identifier is classically given by the following formula (see RFC 2379):

[0128] md5 OBJECT IDENTIFIER::=

[0129] {iso (1) member-body (2) US (840) rsadsi (113549)

[0130] digestAlgorithm(2) 5}

[0131] sha-1 OBJECT IDENTIFIER::=

[0132] {iso (1) identified-organization (3) oiw(14) secsig(3)

[0133] algorithm (2) 26}

[0134] signatureValue: the value of the signature, which depends on the choice of the MHP specification.

[0135] Explanation of certificate_descriptor

[0136] Like the classic PKI technology, this descriptor contains several certificates that are used recursively. In particular, the leaf certificate is first set in the certificate_descriptor, and the root certificate included in it only for consistency is indicated at the end.

[0137] The file named CertificateFile contains all certificates in the certificate chain mentioned in certificate_descriptor, up to and including the root certificate. A profile for encoding certificates is defined in ETSI TS 102 812 VI.1.1 (representing "European Telecommunications Standards Institute, Technical Specifications").

[0138]

[0139]

[0140]

[0141]

[0142]

[0143]

[0144]

[0145]

[0146]

[0147]

[0148]

[0149] The certificate_descriptor is specified as follows:

certificate_descriptor () {descriptor_tag descriptor "ength signature_id certificate_here_flag reserved 7 1 if (certificate_here_flag = = 1) {certificate_cout 16 uimsbf for(i = 0 ;i &lt;certificate_count ;i++) {certificate_length certificate (); 1 bslbf uimsbf uimsbf uimsbf uimsbf

CN 1628447 Β

[0150]}

[0151]}

[0152]}

[0153] descriptor_tag: a tag of certificate_descriptor.

[0154] descriptor_length: the length of the certificate_descriptor.

[0155] signature_id: This ID links the certificate and a specific signature.

[0156] certificate_here_flag: a bit field, when set to 1, it means that the certificate is located in this descriptor.

Otherwise, the certificate from the application should be used, and the link must be defined.

[0157] certificate_count: This 16-bit integer carries the number of certificates in the certificate descriptor.

[0158] certificate_length: This 24-bit integer specifies the number of bytes of the certificate.

[0159] certificate 0: This field has a single "certificate" data structure defined by ITU-T X.509.

[0160] In the case of the MHP platform, the same certificate management as used for interactive applications can be used. Otherwise, a specific mechanism for certificate management should be established.

[0161] Ordinary addressing of descriptors in MPEG/DVB part

[0162] (Field descriptor_address in hash_descriptor)

[0163] Now, the addressing mechanism for addressing descriptors in MPEG and DVB tables will be described in detail. A variable length addressing mechanism can be used, which can store addresses in a more compact manner. However, in this embodiment, the address has a constant length of 40 bits, making the processing easier. Looking at the current MPEG and DVB specifications, three different types of parts can be identified.

[0164] The type of the first part (hereafter denoted as "type0") has the following structure, and the PAT, CAT, and TOT tables are constructed using this type0 part:

[0165] typeO_section () {

[0166] table_id

[016 knife...

[0168] for (i = 0; i &lt;N; i++) {

[0169] descriptor ()

[0170]}

[0171] CRC_32

[0172]}

[0173] table_id gives the representation of the table and the CRC representing the "cyclic redundancy check".

[0174] In the case of the type0 part, the bytes in the address have the following meanings:

[0175] The first byte

[0176] The second byte

[0177] Third byte

[0178] The number of parts in the fourth byte table;;

; I (N), this byte addresses the descriptor in the typeO part of the ring.

[0179] The second part type (hereinafter referred to as "type1") has the following structure and is constructed using this type1 part

SDT and EIT:

[0180] typel_section() {

[0181] table_id

[0182]

[0183] for (i = 0; i &lt;N1; i++) {

[0184]…

[0185] for (j = 0; j &lt;N2; j++) {

[0186] descriptor ()

[0187]}

[0188]}

[0189] CRC_32

[0190] }

[0191] The first byte

[0192] The second byte

[0193] Third byte

[0194] The number of parts in the fourth byte table;

i (N1), this byte addresses the outer ring of the typel part; j (N2), this byte addresses the inner ring of the typel part.

[0195] The third part type (hereinafter referred to as "type2") has the following structure, and is constructed using this type2 part

NIT, BAT, PMT and AIT forms:

[0196]

[0197]

[0198]

[0199]

[0200]

[0201]

[0202]

[0203]

[0204]

[0205]

[0206]

[0207]

[0208]

[0209]

[0210]

[0211]

[0212]

[0213]

[0214]

[0215]

[0216]

[0217] type2_section () {table id for (i = 0; i &lt;N1; i++) {descriptor () for (j = 0; j &lt;N2; j++) {for (k = 0; k &lt;N3; k++) {descriptor ()

The number of parts in the CRC 32 table; i (N1), this byte addresses the first ring of the type2 part; j (N2), this byte addresses the outer ring of the type2 part; k(N3), this byte seeks Address the inner ring of the type2 part.

In the case of the type2 part, the descriptor address requires five bytes: The first byte The second byte The third byte The fourth byte Top-level descriptor Through the top-level descriptor, understand the certificate_descriptor and signature_descriptor fields, And the hash_descriptor field that points to all other hash_descriptor fields in the part having the descriptor to be authenticated (ie, the hash_descriptor containing the root digest value).

[0218] In this embodiment, these descriptors are sent in a specific part, and the specific part and the

The part of the descriptor is linked. This link specific part contains the same PID and Table_ID as the original part, but is distinguished by a specific indicator called section_syntax_indicator. For all DVB/MPEG definition parts, set this section_syntax_indicator to one, which means that the part grammar follows the normal part grammar. For a specific extension, section_syntax_indicator is set to zero, indicating that the private data appears after the field (private_section_length) that gives the length of the specific section. These private data are specified in such a way that they can contain top-level information. For example, the extension part has the following structure:

<td>[0219]</td><td colspan="3">extension_section () {</td>

<td>[0220]</td><td>table_id</td><td>8</td><td>uimsbf</td>

<td>[0221]</td><td>section_syntax_indicator</td><td>1</td><td>bslbf</td>

<td>[0222]</td><td>private_indicator</td><td>1</td><td>bslbf</td>

<td>[0223]</td><td>reserved</td><td>2</td><td>bslbf</td>

<td>[0224]</td><td>private_section_length</td><td>12</td><td>uimsbf</td>

<td>[0225]</td><td>reserved</td><td>3</td><td>bslbf</td>

<td>[0226]</td><td>version_number</td><td>5</td><td>uimsbf</td>

<td>[0227]</td><td>certificate_descriptor()</td><td></td><td></td>

<td>[0228]</td><td>signature_descriptor()</td><td></td><td></td>

<td>[0229]</td><td>hash_descriptor ()</td><td></td><td></td>

[0230] }

[0231] The field private, indicator is a reserved bit for future use, and the table version to which the extended part of the field "version_number" belongs (in particular, see EN 300 468V1. 3. 1-For "European Standards").

[0232] Example

[0233] The following example shows how AIT descriptors can be used for signatures. In this example, global authentication is performed on the entire table formed by several parts, instead of separately authenticating each part as before. The first step is to select the descriptor to be authenticated. The second step is to use the MD5 digest algorithm to calculate the hash codes of these descriptors. The hash_descriptor located in each ring containing at least one authentication descriptor contains the address of these descriptors and the MD5 digest value of these descriptors. Since the hash_descriptor is addressable, it does not need to have a specific position in the ring. In this way, a hash code can be generated for the AIT part.

[0234] The following figure shows the insertion of hash_descriptor in the usual AIT structure (such as ETSI TS 102 812

VI. 1.1 defined):

CN 1628447 Β

<td></td><td>Number of digits</td><td>Identifier</td>

<td>Application_information_section() {Table_id</td><td>8</td><td>uimsbf</td>

<td>Section_syntax_indicator</td><td>1</td><td>bslbf</td>

<td>Reserved_for_future_use</td><td>1</td><td>bslbf</td>

<td>Common_descriptor_length for (i=0; i&lt;Nl; i++) {// hash_descriptor() / / ot her descrip to r ()}</td><td>12</td><td>uimsbf</td>

<td>application_loop_length for (i-0; i&lt;N2: i++) {applica ti on_iden tif ier ()</td><td>12</td><td>uimsbf</td>

<td>application_control_code</td><td>8</td><td>uimsbf '</td>

<td>application_descriptors_loop_length for (j=0; j&lt;N3; j++) {// hash_descriptor ()// other descriptor()}</td><td>12</td><td>uimsbf</td>

<td>}CRC 32}</td><td>32</td><td>rpchof</td>

[0236] Wherein "rpchof" means "remainder polynomial coefficients, the highest degree has priority".

[0237] A complete AIT table can be composed of several parts, the same as any DVB/MPEG table. After the hash codes of all parts of the table have been calculated, the top-level information must be generated. To this end, the calculation considers the top-level hash_descriptor (root digest value) of all hash_descriptor fields of the corresponding table, where the above-mentioned descriptor addressing mechanism is used. The next step is to use the private key corresponding to the public key that can be found in the leaf certificate of the corresponding certificate_descriptor to RSA-encrypt this top-level hash_descriptor (RSA cryptographic algorithm stands for Rivest-Shamir-Adleman). The result of this RSA-encryption is the signature stored in signature_descriptor. The three top-level descriptors are stored in the so-called extended part of the corresponding table. In the case of AIT, the table ID is always 0x74, but the PID (packet identifier) is the value listed in the PMT of the corresponding service. The extension section containing the top-level descriptor has the same PID and table ID as the AIT to be authenticated, but section_syntax_indicator is set to zero: [0238] extension_section () {

[0239] table-id(0x74) 8 uimsbf

[0240] section_syntax_indicator(0x00) 1 bslbf

<td>[0241]</td><td>private_indicator</td><td>1</td><td>bslbf</td>

<td>[0242]</td><td>reserved</td><td>2</td><td>bslbf</td>

<td>[0243]</td><td>private_section_length</td><td>12</td><td>uimsbf</td>

<td>[0244]</td><td>reserved</td><td>3</td><td>bslbf</td>

<td>[0245]</td><td>version_number</td><td>5</td><td>uimsbf</td>

<td>[0246]</td><td>certificate_descriptor()</td><td></td><td></td>

<td>[0247]</td><td>signature_descriptor()</td><td></td><td></td>

<td>[0248]</td><td>hash_descriptor ()</td><td></td><td></td>

<td>[0249]</td><td>}</td><td></td><td></td>

<td>[0250]</td><td>The version number indicates the version of the table to which this extended part belongs.</td><td></td><td></td>

<td>[0251]</td><td colspan="3">In a variant embodiment, all hash_descriptor fields are located in exten</td>

<td>[0252]</td><td colspan="2">In the implementation, it is recommended that section_syntax_indicator</td><td>Set as"</td>

The top level in _sion_section. Don't care" (indicating that the demultiplexer that processes the stream passes this bit, regardless of whether its state is "1" or "0"), so the required DVB/MPEG part itself and extension_section pass through the demultiplexer filter. Follow In this way, the top-level descriptor in the extended part is directly available and can be authenticated immediately.