Signing and authentication devices and processes and corresponding products, notably for dvb/mpeg mhp digital streams

The present invention relates to signing devices and authentication devices, processes and related products, and more particularly to Digital Video Broadcasting (DVB) / MPEG (Moving Picture Experts Group) digital streams and MHP (Multimedia Home Platform) standards.

Therefore, the present invention relates to the field of digital television. Digital television environments include video and audio content (typically MPEG audio / video), interactive content, triggers, Program Specific Information (specific information about transmission programs, abbreviated as "PSI"), and services. Includes information (EPG (Electronic Program Guide) (abbreviated as "SI")), personal data, signatures, etc. Content (ie, PSI, SI and some personal data) structures, destinations and related information under the content are usually integrated in the signature.

These various data are usually distributed over an MPEG-2 transport stream, which is a video / audio stream transported in a packetized basic stream (PES), the MPEG-2 section. Consists of other information transported in (signaling, PSI, SI, interactive content, ...). Some digital broadcast and broadband networks are more or less vulnerable to spoofing. Technically competent pirates attack data, modify it, and rebroadcast (or restream) it to the network. Terrestrial and microwave broadcast networks are more vulnerable than satellite or cable networks.

In fact, some of the listed data items, such as audiovisual content, PSI and SI, are pure broadcast content, and therefore their piracy bothers the user, but at least has an economic impact on the user. Will not be given. However, an interactive terminal with a reply channel can perform television commerce (t-commerce) or home banking applications. Impersonation of such an application therefore not only greatly annoys the user, but also causes the user to lose a lot of money.

Interactive systems such as the DVB multimedia home platform specify how to authenticate broadcast applications and how to protect the data content transferred to the reply channel. However, fraud remains possible, as it is possible to change the signature in an appropriate manner, such as adding, replacing or deleting content, without any obvious contradiction. Therefore, for streams built according to the ATVEF (Advanced Television Enhancement Forum) standard, there is a tendency to provide not only content but also authentication of the signature itself, as is specifically done.

However, such a method poses certain difficulties for DVB digital streams as the streams are remultiplexed at the network headend. Therefore, even PIDs (packet identifiers) or PMTs (Program Map Tables, one table per program representing the PIDs of the PES that make up the program, in addition to the personal information associated with the program), are required by the network. At risk of being modified for. This means recalculating all hash codes and signatures, including those for giving the private key to each multiplexer to calculate the appropriate signature. Here, the cost of providing each multiplexer with an authenticated key pair is enormous. Such situations discourage those skilled in the art from developing such signature authentication strategies.

<p> The present invention relates to devices for signing digital streams intended to be transmitted by communication networks adapted for DVB digital stream authentication, and for making communications more secure, especially for applications of MHP.</p><p> The present invention also relates to corresponding processes, devices, associated decoders, processes for authenticating digital streams received by communication networks, corresponding software and digital streams.</p>

<p> Accordingly, the present invention is intended to sign a digital stream intended to be transmitted by a communication network by generating at least one signature embedded in the digital stream, which is obtained from the encryption applied to the digital stream. Applies to the equipment of. These digital streams consist of several information entities, which are: -at least content related to audiovisual information, and-at least one consisting of a collection of information related to content structure, content destination and content source. Signaling, which contains important data structures called descriptors, and includes signaling that is mainly constructed by arranged grouping called tables.</p><p> According to the present invention, the signing apparatus is intended to apply encryption to at least signaling, a descriptor selectively determined between the signaling descriptors, called an authentication descriptor.</p><p> Therefore, in contrast to applying signing to the complete section (a subtable of signaling, which has a limited size), which is the natural solution when signaling is signed, signaling identification. Descriptor is selected for the signature. The direct advantage of such a surprising solution is that the signature allows the selection of descriptors that remain modified by the remultiplexing stage. Therefore, protection against malicious modifications can be achieved very efficiently and avoid significant complexity in the authentication process due to remultiplexing at the network headend.</p><p> Also, when it is determined that the signature retains some descriptors that are intended to be modified during remultiplexing, the remultiplexing device takes into account the modified descriptors. It can be made easier and faster than if the complete section had to be re-signed to provide the generation of. In fact, with careful selection of modification descriptors, most of the information obtained at the send level for signing can be preserved in some cases, especially in the form of invariant digest values resulting from hashing. And only a small part of the signature information needs to be recalculated for signature.</p><p> By "video-audio information", it means audio information and video information.</p><p> Preferably, the digital stream is constructed according to DVB and MPEG standards, and in particular according to MHP.</p><p> The signing device of the present invention is a PSI table, PMT, PAT (a program access table, which represents a link between the PID of a PMT transport packet and the number of programs for each transmitting program), CAT. (Gives the PID of the PES carrying the Entitlement Management Message (EMM) in the case of a conditional access table and at least one program with conditional access), and the DVB-SI table. And for NIT (Network Information Table), SDT (Service Description Table), EIT (Event Information Table), TOT (Time Offset Table), AIT (Application Information Table), BAT (Bouquet Association Table), etc. It can be applied to the authentication of any MPEG / DVB table. The signing device can also be applied to any MPEG / DVB private table based on the MPEG2 system (ISO / IEC 13818-1).</p><p> The signing device advantageously consists of means for allowing the user to select an authentication descriptor. The user is, for example, a member of the broadcasting team. Therefore, one of the selected descriptors is included in the stream, and therefore the receiver is given information about the descriptors used when receiving those streams, or those descriptors are , It has been agreed in advance between the transmitter and the receiver. Another solution is, for example, to determine a more systematically selected descriptor in a particular standard version.</p><p> Preferably, the signing device is intended to: -introduce the signature in the state of at least one lowest level signature descriptor in the digital stream, and-add at least one authentication descriptor for that signature into the digital stream. , -At least one higher level signature descriptor comes from applying encryption to both the content of the lowest level signature descriptor and the authentication descriptor.</p><p> This signing device is very intended to ensure safe, flexible and reliable interoperability between various parties such as broadcasters and manufacturers.</p><p> In practice, this signing device can provide a public key infrastructure (PKI) as soon as several levels are provided. Therefore, a root certificate authority is established with any other certificate authority (for top-level signatures).</p><p> Preferably, the signing device consists of a digital stream, a means incorporated into the address of the authentication descriptor. This is an effective way to make the receiver aware of the descriptors used for signing.</p><p> Therefore, the embedding means is intended to introduce at least one hash descriptor in each of the digital streams, which is advantageous. The hash descriptor consists of at least one digital value resulting from the application of the hash algorithm to at least one authentication descriptor. The hash descriptor also consists of the address of the authentication descriptor used to calculate its digital value. Such achievements improve the effectiveness of the authentication because it depends on the intermediate results sent to calculate the signature and therefore to examine the authentication.</p><p> More specifically, the built-in means is preferably intended to arrange hash descriptors in a digital stream according to a tree structure, with at least one hash descriptor calculated from at least one other hash descriptor having a lower level. Will be done. Nested calculations of digest values allow for the forward calculation of the base value (ie, the root digest value) for which the signature will ultimately be obtained, while taking into account all the necessary information about the various authentication descriptors. Make sure that.</p><p> The digest value preferably has a fixed value, as is usually done in known hash algorithms.</p><p> Also, the following embodiments with built-in means are preferred, where each table consists of at least one section with a limited size, and each section introduces a descriptor continuously in the section at least. It consists of one loop. Those built-in means belong to at least one predetermined loop of a given section by enumerating-the number of sections and-their occurrence number, and each of the loops has at least one occurrence number. It is advantageously intended to specify the address of each of the signature descriptors it has.</p><p> In this way, the identity of the descriptor used for authentication can be effectively and easily identified.</p><p> Information transmitted by other cases for addressing includes:-section version number and / or-section type.</p><p> In certain achievements using embedded means, if the signing device is in the form of personal data in at least one particular section, such as a particular section linked to a section containing the signature and the authenticated descriptor. Some are advantageously intended to introduce at least one digest value and authentication data. Such achievements allow at least some authentication information to be separated from other signaling data.</p><p> Thus, in a preferred embodiment, a particular section represents a lower level digest value in the other section and favorably in the form of a root hash descriptor and an authentication descriptor and a signature that gives the root digest value. Intended to include authentication data and signatures. This is a great advantage as DVB / MPEG-2 cannot put descriptors in the first part of a section and is valid for the rest of the section.</p><p> In other embodiments with a particular section, the signature, authentication data and root hash descriptors are not only located in the particular section, but all other hash descriptors (eg, at a higher level in that section). .. This is possible by using DVB / MPEG-2 because the addressing mechanism can directly address the descriptors in the table.</p><p> The present invention is also intended to be carried out by any embodiment of the signature device in accordance with the present invention, preferably with respect to the process corresponding to the above device.</p><p> Another object of the present invention is a device for authenticating a digital stream received by a communication network by examining at least one signature embedded in the digital stream. Each of these digital streams is an information entity: -at least the content associated with the credentials, and-at least one signaling consisting of a collection of information related to the content structure, content destination and content source. , The signaling includes signaling important data structures called descriptions, which are mainly constructed by arranged grouping called tables.</p><p> According to the present invention, the signing apparatus is intended to apply encryption to at least signaling, a description that is selectively determined between the signaling descriptions, called an authentication description, from which the signature is calculated. ..</p><p> The authentication device is preferably intended to be applied to a digital stream composed of signatures generated by a signature device according to the present invention.</p><p> The present invention also relates to a decoder, characterized in that it comprises an authentication device according to the present invention.</p><p> Another object of the invention is an authentication process corresponding to the authentication apparatus of the invention, preferably intended to be performed by any of the latter embodiments.</p><p> The present invention also relates to a computer program product consisting of program code instructions for performing the authentication process or signing step of the present invention when the program is executed on a computer.</p><p> The term "computer program product" needs to be understood as embracing any embodiment of a computer program and is associated with signals (electronic signals, optical signals, etc.) as well as recording carriers (cassettes, disks, etc.). It is possible to be.</p><p> The present invention is an information entity: -at least one signaling consisting of content related to credentials, -a set of information related to content structure, content destination and content source, the signaling of which is Consists of an entity containing at least one signature embedded in digital content, which contains important data structures signalized, called descriptions, and is built primarily by arranged groupings called tables. Further applied to digital streams.</p><p> The digital stream is preferably generated by any embodiment of the signing apparatus described in the claims.</p>

The transmitter 1 of the digital stream 10 transmits those streams to the receiver 2 having the decoding capability by the network 5 (Fig. 1). Transmitter 1 is typically intended to broadcast stream 10, and network 5 is, for example, a broadband network or broadcast network, such as a wired or satellite network in particular. In other embodiments, network 5 includes the Internet. In the case shown in the figure, the digital stream 10 is composed of a DVB / MPEG-2 stream and therefore contains, in particular, its associated signaling data and content. Signaling is built primarily on tables and contains descriptors. Stream 10 depends on the MHP standard.

The transmitter 1 comprises a signing device 11 for signing a digital stream to be transmitted and a user interface 15 that allows the sender, for example, a broadcaster, to specifically control the signing process. The signing device 11 is intended to sign signaling as well as content. The signature device 11 includes a selection module 12 in which the user interfaces 15 select a portion of the signature descriptor, called an authentication description, used for signaling authentication. In this way, encryption is applied to the stream to obtain the associated signature. The signing device 11 also includes a digital stream 10 transmitted, a built-in module 13 that can be incorporated into the address of the authentication descriptor, and each receiver 2 for the digital stream is a received signature, in particular, It is composed of an authentication device 21 capable of examining a signature for signaling authentication. The authentication device 21 can consider the authentication descriptor represented in stream 10 for authentication.

A particularly interesting example will be described below. An important entry point for signaling digital television services (interactive or not) is the PMT (Program Map Table) specified in the MPEG-2 System Standard (ISO / IEC 13818-1). For signaling in interactive MHP applications, the PMT is the application code and data (DSM-CC DSI message, DSM-CC representing the Digital Storage Media-Command &amp; Control standard, and Download Server Initiative, as shown in Figures 2 and 3. , ISO / IEC 13818-6 Includes the position of the stream that transports DSI, which is an abbreviation for the international standard, and the position of the stream that transports AIT (application information table). The technical achievements below make it possible to protect the signaling data for interactive MHP applications, and therefore the decoding platform can check if the signaling data has been modified for the transport network. .. In addition, the MPEG-2 system standard prohibits scrambling of PMTs, therefore there is no need to consider scrambling here.

Signaling protection is based on hash code, signature and authentication. The encoding of these authentication messages is done by specifying three new descriptors, each of which contains the above objects. hash_descriptor signature_descriptor certificate_descriptor The hash_descriptor field is introduced here independently for each section that should be individually authenticated, and for such a given table section, the latter consists of several sections. Whether or it consists of only one section will be considered below. On the other hand, the signature_descriptor field applies to all hash_descriptors in a table, and the certificate_descriptor field pertains to all signature_descriptors in that table.

Specifying hash_descriptor The hash_descriptor can be placed in a PMT (or any other MPEG-2 table to be authenticated) or in an AIT loop. More specifically, it is positioned in each descriptor loop that contains the descriptor to be authenticated. The location of that loop is not a problem as hash_descriptor contains descriptor_address that can uniquely address each descriptor.

The hash_descriptor contains a hash code, also called a digest value, that is calculated for the descriptor pointed to by the descriptor_address. For AIT or PMT, it contains the following descriptor in the same loop as hash_descriptor. The indicated descriptor itself resides in the hash_descriptor field, which allows for an iterative calculation process.

The syntax of hash_descriptor is for:

hash_descriptor () {descriptor_tag 8 uimsbf descriptor_length 8 uimsbf digest_count 16 uimsbf for (i = 0; i &lt;digest_count; i ++) {digest_type 8 uimsbf digest_count 8 uimsbf for (j = 0; j &lt;discriptor_count; i ++) { descriptor_address 40 uimsbf} for (j = 0; J &lt;digest_length; J ++) {digest_byte 8 bslbf}}} where uimsbf and bslbf are unsigned integer most significant bit first and bit string left bit, respectively. It is an abbreviation for "first".

Labeling of descriptor_tag: hash_descriptor.

descriptor_length: The length of the hash_descriptor.

digest_content: This 16-bit value represents the number of the digest value in this hash descriptor.

digest_type: Represents the digest algorithm used for related descriptors, if any. The permissible values are shown in Table 1. Here, MD-5 (MD is an abbreviation for "Message Digest") is defined in RFC 1321 (RFC is an abbreviation for "Request For Comment"). http://www.ietf.org/rfc1321.txt) and SHA-1 (SHA is an abbreviation for Secure Hash Algorithm) are FIPS-180-1 (FIPS Publication 180-1: Sedure Hash Standard, National Institute of) Standards and Technology, 1994; http //www.itl.nist.gov/fipspubs/fip180-1.htm).

<tables num="1"><img file="JP2005526451A_D0001.tif" /></tables> descriptor_content: This 16-bit value represents the number of descriptors associated with the digest value. The value of this field is greater than 0.

descriptor_address: This is the generic address of the descriptors that can be placed in a section, described in more detail.

descriptor_length: This integer value gives the number of bytes in each digest value. It depends on the digest type as shown in Table 1.

digest_byte: This 8-bit value has 1 byte of digest value.

The signature_descriptor specification The syntax of the descriptor is as follows.

signature_descriptor () {descriptor_tag 8 uimsbf descriptor_length 8 uimsbf signature_id 8 uimsbf signature_length 8 uimsbf for (i = 0; i &lt;N; i ++) {signature specific data}} Labeling of signature_tag: signature_descriptor.

descriptor_length: The length of signature_descriptor.

signature_id: This ID (abbreviation for IDentifier) can have signatures from more than one authority. This is the generic address of the descriptors that can be placed in the section, which will be described in more detail.

signature_length: Represents the length of the loop that follows.

The field signature specific data is the following ASN.1 structure, which is a combination of a BER (Basic Encoding Rules) structure and a DER (Distinguished Encoding Rules) structure. Includes (abbreviation for Abstract Syntax Notation one language).

Signature :: = SEQUENCE {CertificateIdentifier AuthorityKeyIdentifier, HashSignatureAlgorithm HashAlgorithmIdentifier, SignatureValue BIT STRING} certificateIdentifier: ITU-T X.509 extension associated with the AuthorityKeyIdentifier field (International Telecommunications Union-Telecommunications Standarzation Section, Recommendation X.509 : The Directory Authentication Framework, 1997). It identifies the certificate carrying the authenticated public key used to look up the signature.

AuthorityKeyIdentifier :: = SEQUENCE {KeyIdentifier [0] KeyIdentifier OPTIONAL, AuthorityCertIssuer [1] GeneralNames OPTIONAL AuthorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL} It is not necessary to execute using the key identifier element (keyIdentifier) that exists in some cases. The AuthorityKeyIdentifier structure contains both the authorityCertIssuer and the corresponding authorityCertSerialNumber of the authority's certificate.

The autthorityCertIssuer field contains a field directoryName (hence the same as the field issueName used in MHP) that gives the issuer name of the certificate that carries the public key used to look up the signature.

hashSignatureAlgorithm: This field identifies the hash algorithm used. The encryption algorithm required to calculate the signature is already described in the certificate that authenticates the relevant key (in the SubjectKeyInfo field). In this way, only the identification of the hash algorithm is needed. The supporting algorithms are MD5 and SHA-1, whose identifiers are classically given by (see RFC 2379).

Md5 OBJECT IDENTIFIER :: = {iso (1) member-body (2) US (840) rsadsi (113549) digestAlgorithm (2) 5} sha-1 OB OBJECT IDENTIFIER :: = {iso (1) dentified-organization (3) ) oiw (14) secsig (3) algorithm (2) 26} signatureValue: MHP identification signature certificate_descriptor specification The descriptor contains several repetitively used certificates as in classical PKI technology. In particular, the leaf certificate is placed first in certificate_descriptor, and the root certificate included for consistency only is shown last.

The file named CertificateFile contains the root certificate and all the certificates in the authentication chain described in the previous certificate_descriptor. The profile for signifying certificates is defined in ETSITS 102 812 V1.1.1 (European Telecommunication Standards Institute, Technical Specification).

The certificatte_descriptor is defined as follows.

certificate_descriptor () {descriptor_tag 8 uimsbf descriptor_length 8 uimsbf signature = id 8 uimsbf certificate_here_flag 1 bslbf reserved 7 bslbf if (certificate_here_flag == 1) {certificate_cout 16 uimsbf for (i = 0; i &lt;certificate_count; i ++) {certificate_length 24 uimsbf certificate ()}}} descriptor_tag: Labeling of certificate_descriptor.

descriptor_length: The length of certificate_descriptor.

signature_id: This ID links the authentication to a specific signature.

certificate_here_flag: This is a bitfield that indicates that the certificate will be positioned in this descriptor when set to 1.

certificate = count: This 16-bit integer carries the number of certificates in the certificate identifier.

certificate_length: This 24-bit integer carries the number of bytes in the certificate.

certificate (): This field carries a single "certificate" data structure as defined by ITU-T X.509.

For MHP platforms, the same authentication management used for interactive applications is used. Otherwise, a mechanism for certificate management is specifically established.

Generic addressing of descriptors in the MPEG / DVB section (field descriptor_address in hash_descriptor) The addressing mechanism for addressing descriptors in MPEG and DVB tables is described in detail here. A variable length addressing mechanism can be used, which is more compact and capable of storing addresses in a fashionable manner. However, in this embodiment, the address has a constant length of 40 bits, which makes the process easier. Looking at the current MPEG and DVB standards, we can identify three different types of sections.

The first section type (hereinafter referred to as type0) is the structure described below, that is, the type0 section, and type0_section () {table_id ... for (i = 0; i &lt;N; i ++) { It has a PAT table, a CAT table and a TOT table constructed using descriptor ()} CRC_32}. Here, table_id gives the identification of the table, and CRC is an abbreviation for "Cyclic Redundancy Check".

In the case of the type0 section, the bytes in the address have the following meanings. 1st byte: Table section number 2nd byte: 0 3rd byte: 0 4th byte: i (N), which addresses the descriptor in the type0 section loop.

The second section type (hereinafter referred to as type1) is the structure described below, that is, the type1 section, and type1_section () {table_id ... for (i = 0; i &lt;N; i ++) { It has an SDT table and an EIT table constructed using ... for (i = 0; i &lt;N2; i ++) {descriptor ()}} CRC_32}. 1st byte: Table section number 2nd byte: 0 3rd byte: i (N1), which addresses the outer loop of the type1 section. Fourth byte: j (N2), which addresses the inner loop of the type1 section.

The third section type (hereinafter referred to as type2) is the structure described below, that is, the type2 section, and type2_section () {table_id ... for (i = 0; i &lt;N; i ++) { descriptor ()} ... for (j = 0; j &lt;N2; j ++) {... It has a NIT table, a BAT table, a PMT table, and an AIT table constructed using for (k = 0; j &lt;N3; k ++) {descriptor ()}} CRC_32}. 1st byte: Table section number 2nd byte: i (N1), which addresses the first loop of the type2 section. Third byte: j (N2), which addresses the outer loop of the type2 section. Fourth byte: k (N3), which addresses the inner loop of the type2 section.

Top-level descriptor The top-level descriptor makes it possible to understand the hash_descriptor that points to everything in the section that has the certificate_descriptor and signature_descriptor fields, and the descriptor to be authenticated (ie, hash_descriptor containing the root digest value).

In this embodiment, the above descriptor is sent to a particular section, which particular section is linked to the section containing the descriptor to be authenticated. This particular linked section contains the same PID and Table_ID as that of the original section, but is distinguished from the latter by a particular indicator called "section_syntax_indicator". This section_syntax_indicator is set to 1 for all sections defined by DVB / MPEG, which means that the section syntax follows the generic section syntax. For a particular extension, section_syntax_indicator is set to 0, which means that private data exists after the field gives a particular section length (private_section_length). Their private data is specified in such a way that they can contain top-level information. The extension section has the following structure, for example.

Extension_section () {Table_id 8 uimsbf sction_syntax_indicator 1 bslbf private_indicator 1 bslbf reserved 2 bslbf private_section_length 12 uimsbf reserved 3 bslbf version_number 5 uimsbf certificate_descriptor () signature_descriptor () hash_descriptor ()} The field private_indicator specified in ISO / IEC 13818-1 of the definition part of the private section is prepared for future use, and the field version_number indicates which version of the table the extension section belongs to. (See EN 300 468 V1.3.1, especially for European Standards).

Examples The following examples show how AIT descriptors can be used for signatures. In this example, instead of traditionally authenticating each section separately, all the configured tables of some sections are totally authenticated. The first step is to select the descriptor to be authenticated. The second step is then to calculate the hash code for those descriptors by using the MD5 digest algorithm. The hash_descriptor, located in each loop that contains at least one authentication descriptor, contains the addresses of these descriptors and the MD5 digest value of these descriptors. The hash_descriptor is addressable and does not need to have a specific position in the loop. In this way, the hash code can be generated for the AIT section.

The following table shows the insertion of the hash_descriptor field in a normal AIT structure (as defined in ETSI TS 102812V 1.1.1).

<tables num="2"><img file="JP2005526451A_D0002.tif" /></tables>Here, rpchof is an abbreviation for remainder polynomial coefficients, highest order first.

A complete AIT table, like any DVB / MPEG table, consists of several sections. The top-level information needs to be generated after the hashcodes for all sections of the sable have been calculated. To do this, the top-level hash_descriptor, which considers all the hash_descriptor fields in the corresponding table, is calculated (root digest value) when the above descriptor addressing mechanism is used. The next step is to RSA encrypt this top-level hash_descriptor with a private key, which corresponds to the public key found in the leaf certificate of the corresponding certificate_descriptor (RSA encryption algorithm is Riverst-Shair-Adleman). Is an abbreviation for). The result of this RSA encryption is the signature stored in signature_descriptor. The three top-level descriptors are stored in the so-called extension section of the corresponding table. In the case of AIT, the table ID is usually 0x74, but the PID (packet identifier) is the value listed in the PMT of the corresponding service. The extension section containing the highest level descriptor has the same table ID and PID as that of the AIT to be authenticated, but section_syntax_identifier is set to 0 and looks like this:

Extension_section () {Table_id (0x74) 8 uimsbf sction_syntax_indicator (0x00) 1 bslbf private_indicator 1 bslbf reserved 2 bslbf private_section_length 12 uimsbf reserved 3 bslbf version_number 5 uimsbf certificate_descriptor () signature_descriptor The number of versions indicates which table version this extension section belongs to.

In the variant embodiment, all hash_descriptor fields are placed at the top level in extension_section.

In practice, it is recommended to set the section_syntax_indicator bit as "OK" (meaning that the demultiplexer processing the stream passes through the bits of state "0" or "1" independently), therefore. The required DVB / MPEG section itself and extension_section pass through a demultiplexer filter. Thus, the top-level descriptor in the extension section is directly available and authentication can be done immediately.

<figref num="1">It is a figure which shows the signature device and the corresponding authentication device according to this invention.</figref><figref num="2">FIG. 5 shows a DVB / MPEG-2 basic stream including a video / audio stream, a private data stream and related tables (PAT, PMT and AIT), and points to a link between the table and the stream.</figref><figref num="3">It is a figure which shows in detail a part of the table (PMT and AIT) in FIG. 2 in relation to a basic stream, application information and an application stream.</figref>