HK1101742B - Authentification of data in a digital transmission system - Google Patents

Description

Authentication of data in digital transmission system

The present application is a divisional application of an invention patent application having an application date of 25/3 in 1999, a divisional filing date of 11/5 in 2004, an application number of 200410043104.7, and an invention name of "authentication of data in a digital transmission system".

Technical Field

The present invention relates to a method of authenticating transmitted data in a digital transmission system.

Background

Broadcast transmission of digital data is well known in the field of pay TV systems in which scrambled audiovisual information is transmitted to a number of users, each having a decoder capable of descrambling the transmitted program for subsequent viewing, typically using a satellite/cable link. Terrestrial digital broadcasting systems are also known. In addition to or as well as audiovisual data, recent systems also use broadcast links to transmit other data, such as computer programs or interactive applications to decoders or connected PCs.

One particular problem with application data transfer is that: the integrity and origin of any such data needs to be verified. Since this type of data can be used to reconfigure the decoder, as well as to implement any number of interactive applications, it is essential that the received data be complete and identified as originating from a well-known signal source. Otherwise, operational problems related to downloading incomplete data and the danger of this decoder becoming unguarded for attacks by third parties and the like may arise.

Previous attempts to authenticate such data have focused on verification at the level of encapsulation or formatting of the data in the packet stream. For example, european patent application EP0752786 describes a system in which data is encapsulated in a series of modules or in a series of tables or parts using terms related to the MPEG standard, and these tables or parts are then encapsulated in packets of an MPEG transport stream.

The authentication operation is performed with respect to tabulated data, such as a directory table containing a list of all tables with data for that application, along with tables associated with each table to allow later verification of hash values of the table data. The directory table itself may be marked prior to transmission so that the information in the directory table and associated tables may not be modified without changing the hashes and signature.

A problem of such known systems is that they are not suitable for handling more complex data composition structures. In particular, the use of a single directory table containing the complete hash value table for each correlation table means that: such systems are not readily adaptable to handle large or variable numbers of tables.

Since a single MPEG directory table links all the tables and since these authentication operations are done at the stage of formatting the data in the tables for packet encapsulation and broadcasting, this system is also not suitable for allowing authentication of software provided by many broadcast operators. This operation is typically done under the control of a separate operator.

Disclosure of Invention

According to a first aspect of the present invention there is provided a method of authenticating data transmitted in a digital transmission system, characterised in that the data is organized prior to transmission into a hierarchy of at least a root directory unit, sub-directory units and file units (hierarchy), in that the data in a file is acted upon by an authentication algorithm and a file authentication value is stored in the associated sub-directory, the file authentication value being associated with the data, in turn the file authentication value is acted upon by an authentication algorithm and the associated sub-directory authentication value is stored in the associated root directory.

The invention also provides a method of verifying received data transmitted in a digital transmission system in which a receiving decoder acts on data in a file using an authentication algorithm and compares the resulting value with an authentication value stored in the relevant sub-directory, and also acts on at least the file authentication value stored in this sub-directory using an authentication algorithm and compares the subsequently resulting value with the relevant sub-directory authentication value stored in the relevant root directory.

Unlike known systems in which a single table directory refers to all of the associated tables, the use of a multi-level structure with an application of an authentication algorithm at each step of the hierarchy provides a secure and modular data structure. Since the file authentication values in the subdirectories are sequentially authenticated at the upper level using the corresponding values in the root directory, it is impossible to change one element at the lower level (and vice versa) without changing the authentication value at the upper level.

Preferably, the authentication of the file data is accomplished by applying a hashing algorithm to some or all of the file data, and the resulting hash value is stored as a file authentication value in the relevant subdirectory. Similarly, the authentication of the subdirectory can be accomplished by applying a hashing algorithm to the file authentication value (and other data, if desired), and the resulting hash value is stored as the subdirectory authentication value in the associated root directory.

For example, other embodiments may be envisaged in which file data is encrypted according to an encryption algorithm and a key (or its identification key number) used as an authentication value stored in this subdirectory. This file key may in turn be encrypted and the encrypted key stored in the root directory as an authentication value or the like. Although possible, this embodiment is rather complex to implement due to the increased complexity of the operations necessary to generate the encryption key values.

Instead, the use of a hashing algorithm to perform the authentication of each module enables a particularly simple and fast verification of the integrity of each module. In one embodiment, a simple hashing algorithm such as check and compute may be used. However, this cannot detect forgery because it is relatively simple to determine how any change in the message affects this hash value.

Preferably, the hash algorithm corresponds to a cryptographic security algorithm that generates a substantially unique hash value from a given set of data. Suitable hashing algorithms that may be used for this purpose include, for example, the message digest version 5(MD5) algorithm or the Secure Hash Algorithm (SHA).

Advantageously, the authentication of the file data of the plurality of files is accomplished by applying a hash algorithm to the accumulation of data from the plurality of files to generate a single hash value. Likewise, authentication of many subdirectories may be accomplished by applying a hashing algorithm to the accumulation of file authentication values (and other data, if desired) from multiple subdirectories to generate a single hash value.

The use of a cumulative hash method covering multiple data modules (files, subdirectories, etc.) at a lower level further simplifies the system compared to, for example, systems that store a table of individual hash values for each module. This in turn enables the system to reduce the computational steps required at each stage and reduce the size of the authentication data stored in the upper layers.

In the case of an embodiment that uses a hashing algorithm to authenticate each layer, this system would be "open," i.e., all hash values would be readable onto the root directory. Since hashing algorithms are publicly available, data stored on the file layer, for example, can be changed without the third party theoretically detecting whether the corresponding hash values on the root directory layer are also changed at the same time.

To avoid this, at least some of the data in this root directory is acted upon with a secret key of an encryption algorithm and the resulting encrypted value is stored in this root directory. Preferably, the encrypted value corresponds to a digital signature. Suitable private/public key algorithms for this purpose include, for example, the RSA algorithm.

Advantageously, the data encrypted using the secret key to generate the signature stored in the root directory includes at least one or more subdirectory authentication values. However, it is conceivable to mark data in the root directory other than the child directory authentication value to "shut down" the system.

As an alternative to signature generation, only the whole or part of the root directory may be encrypted or scrambled, the receiver having an equivalent key to decrypt the encrypted root directory data. In this case, a symmetric key algorithm such as DES may be used.

As will be appreciated, while the authentication process has been described above in connection with two hierarchical levels, similar authentication steps can be accomplished indefinitely for other related files, subdirectories, root directories, etc.

Likewise, although this structure is defined as a root directory/subdirectory/file for the sake of language simplicity, the specific characteristics of each element in the layer are not assumed, except that it is arranged to lower level elements with two upper level elements. As will be appreciated, this data structure may likewise be just a root directory/subdirectory/second root directory or any other combination.

The embodiments described below focus on the units in the lower layers, i.e. to which directories or subdirectories refer. As will become clear, although pointing to this unit from the upper level, this unit itself may be a directory unit, a sub-directory unit, etc.

In an embodiment, a respective unit comprises an encrypted value generated by means of a key, the authentication value for the unit being calculated on the basis of the result of an authentication algorithm associated with the encrypted value and being stored in the respective unit. In particular, as with the equivalent root directory embodiment described above, the relevant cell may be marked, and the authentication value for that cell calculated as the result of the hash function on that signature.

For example, the relevant units may correspond to files or subdirectories. However, this embodiment is particularly suited to situations where the relevant root element is a root directory for another set of data (e.g., data of a different origin) and the relevant root element also includes a signature. In this case, the first operator can combine and mark data onto the level of this root directory.

Thereafter, the second operator can consult this data without knowing the encryption key, and any link is authenticated in the relevant cell using only the hash value of the signature in the relevant root directory. Authentication of both sets of data is of course only possible for receivers having the keys necessary to verify the signatures in the two root directories.

As described above, the present invention can be applied to any group of multi-level data units. The invention can even be applied to the construction of tables or packets in a transport stream if multiple layers of root directories, sub-directories, files etc. can be provided in the packet stream. However, this invention is particularly suited to situations where the units correspond to a set of data files encapsulated in data tables or portions, which are thereafter encapsulated in data packets to form a transport stream.

Unlike authentication at the packet or table level, this embodiment enables complete independence between the combination of authentication data and its encapsulation in the transport stream and in turn facilitates the provision of software from different sources in a transport stream controlled by a single broadcast operator. The data authenticated according to this embodiment may even be transmitted via a different transmission route (e.g., a bi-directional telecommunications link or a satellite link), using a selected encapsulation format to transmit the data.

The data units preferably correspond to data objects formatted according to the DSMCC standard. In one embodiment, these data objects are thereafter encapsulated in tables and packets according to the MPEG standard.

According to a second aspect of the present invention there is provided a method of authenticating first and second groups of linked data units transmitted in a digital transmission system, characterised in that a unit of the first group of units includes a signature generated using a secret key applied to that first unit, in that at least the value of the signature is authenticated using an authentication algorithm and in that the authentication value is stored in a unit of the second group of units relating to that first unit.

According to a third aspect of the present invention there is provided a method of authenticating data transmitted in a digital transmission system, characterised by grouping data into a series of data files, the authentication being performed between the files independently of and prior to a data formatting and encapsulation stage whereby the digital transmission system is arranged to prepare the data for transmission in a packet transport stream.

In particular, the authentication may be done prior to formatting in tables or sections, which are then encapsulated in data packets of the transport packet stream.

As described above, the use of the authentication process employed prior to preparing to transmit data has the effect that this data can thereafter be routed to the receiver using any number of channels, such as broadcast channels or telecommunications channels, without altering this authentication process. Likewise, once the receiver or decoder has reconstructed the data files from the format associated with the transmission route, the data may be validated independently of the selected transmission mode.

Any or all of the features of the first aspect of the invention and its preferred embodiments may of course be combined with the second and third aspects of the invention.

The invention has been described above in relation to the steps used to generate the authentication data prior to transmission, and is equally applicable in its broadest preferred embodiment to the reverse steps performed at the receiver used to validate this data.

In its broadcast aspect, the present invention may be applied to any digital transmission system. However, the invention is preferably applied to digital television systems and in particular to data modules carrying application software for use in receivers/decoders of such digital television systems.

As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, primarily audiovisual or multimedia digital data. Although the invention is particularly applicable to broadcast digital television systems, the invention may also be applied to fixed telecommunications networks for multimedia internet applications, to closed circuit televisions, and the like. As will be appreciated, the term "digital television system" includes, for example, any satellite, terrestrial, cable, and other system.

The term "receiver/decoder" or "decoder" as used herein may not be a receiver for receiving encoded or unencoded signals (e.g., television and/or radio signals) that may be broadcast or transmitted by some other device. This term may not be a decoder for decoding the received signal. Embodiments of such a receiver/decoder may include a decoder integral with a receiver for decoding received signals in, for example, a "set-top box", such a decoder functioning with a physically separate receiver, or such a decoder including additional functionality, such as a web browser and/or integral with other devices such as a video recorder or television set.

The term MPEG refers to the data transmission standard established by the international standards organization working group "moving pictures expert group" and refers in particular, but not exclusively, to the MPEG-2 standard established for digital television applications and set forth in documents ISO13818-1, ISO 13818-2, ISO 13818-3 and ISO 13818-4. In the context of the present patent application, this term includes all changes, modifications or developments of the MPEG format applicable to the field of digital data transmission.

The term DSMCC refers to a data file format standard as described in MPEG files and in the current file ISO 13818-6.

Drawings

Preferred embodiments of the present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

FIG. 1 shows a schematic diagram of a digital television system for use with the present invention;

FIG. 2 shows the structure of a decoder of the system of FIG. 1;

FIG. 3 shows the structure of many of the components within an MPEG broadcast transport stream;

FIG. 4 shows the software application being partitioned into a number of MPEG tables;

FIG. 5 shows the relationship between the DSMCC data file and the resulting MPEG table;

FIG. 6 shows client, server, network manager relationships defined in the context of DSMCC;

figure 7 shows the directory, subdirectory and file objects identified in this embodiment of the invention.

Detailed Description

A general diagram of a digital television system 1 according to the invention is shown in fig. 1. The present invention includes the most conventional digital television system 2 that transmits compressed digital signals using the well-known MPEG-2 compression scheme. More specifically, the MPEG-2 compressor 3 in the broadcast center receives a digital signal stream (typically a video signal stream). This compressor 3 is connected to a multiplexer and scrambler 4 by means of a link 5.

The multiplexer 4 receives a plurality of other input signals, combines the transport streams and transmits the compressed digital signals to the transmitter 6 of the broadcast centre via a link 7, which link 7 can of course take various forms, including a telecommunications link. The transmitter 6 transmits electromagnetic signals via an uplink 8 to a satellite transponder 9 where they are electronically processed and broadcast via a theoretical downlink 10 to an earth receiver 12, typically in the form of a parabolic reflector owned or leased by the end user. The signal received by the receiver 12 is sent to an integrated receiver/decoder 13 owned or leased by the end user and connected to the end user's television set 14. The receiver/decoder 13 decodes the compressed MPEG-2 signal into a television signal for the television set 14.

Other transport channels for data transmission are of course possible, such as terrestrial broadcast, cable transmission, combined satellite/cable links, telephone networks, etc.

In a multi-channel system, the multiplexer 4 processes audio and video information received from a number of parallel signal sources and interacts with the transmitter 6 to broadcast the information along a corresponding number of channels. In addition to audiovisual information, messages or applications or any other type of digital data may be introduced in some or all of these channels interleaved with the transmitted digital audio and video information. In such a case, for example, the digital data stream in the form of DAM-CC format software files and messages will be compressed and packetized into MPEG format using compressor 3. The downloading of the software modules will be described in more detail below.

A conditional access system 15 is connected to the multiplexer 4 and the receiver/decoder 13 and is located partly in the broadcast centre and partly in the decoder, which enables an end user to access digital television broadcasts from one or more broadcast providers. A smart card capable of decrypting messages relating to commercial offerings (i.e. one or several television programs sold by a broadcast provider) can be inserted in this receiver/decoder 13. Using this decoder 13 and smart card, the end user can purchase these commercial offers in either a subscription mode or a pay-per-view mode. In practice, this decoder may be configured to handle multiple access control systems, such as single or multiple cipher designs.

As described above, the programme transmitted by this system is scrambled at the multiplexer 4, and the conditions and encryption keys applied to a given transmission are determined by this access control system 15. The transmission of scrambled data in this manner is well known in the field of pay TV systems. In general, scrambled data is transmitted together with a control word for descrambling the data, this control word itself being encrypted with a so-called exploitation (exploitation) key and transmitted in encrypted form.

The scrambled and encrypted control word is then received by a decoder 13 having access to an equivalent exploitation key stored on a smart card inserted in the decoder to decrypt the encrypted control word and then descramble the transmitted data. The pay-per-time user will receive the exploitation key necessary to decrypt this encrypted control word, for example in an EMM (entitlement management message) broadcast monthly, to allow viewing of this transmission. In addition to its use in decrypting audiovisual programs, a development key similar to the transmission may be generated for verification of other data, such as software modules, as will be described below.

An interactive system 16, also connected to the multiplexer 4 and the receiver/decoder 13 and again located partly in the broadcast centre and partly in the decoder, enables the end user to interact with various applications via a modem back channel 17. This modem back channel may also be used for communications used in the conditional access system 15. The interactive system may be used, for example, to enable a viewer to communicate with the transmission center in a timely manner to request authorization to view a particular event, download an application, and so forth.

Referring to fig. 2, the physical components of a receiver/decoder 13 or set-top box suitable for use in the present invention will now be briefly described. The components shown in this figure will be described in terms of functional blocks.

The decoder 13 comprises a central processor 20 with associated memory means and adapted to receive input data from a serial interface 21, a parallel interface 22 and a modem 23 (connected to the modem back channel 17 of fig. 1).

The decoder is also arranged to receive inputs from an infrared remote control 25 via a control unit 26 and from switch contacts 24 on the front panel of the decoder. This decoder also has two smart card readers 27, 28 adapted to read bank or subscription smart cards 29, 30, respectively. Input may also be received via an infrared keyboard (not shown). The subscription smart card reader 28 interfaces with the inserted subscription card 30 and with the conditional access unit 29 to provide the necessary control words to the multiplexer/descrambler 30 to enable descrambling of the encrypted broadcast signal. The decoder also includes a conventional tuner 31 and demodulator 32 to receive and demodulate the satellite transmissions before filtering and demultiplexing by unit 30.

The processing of data within the decoder is typically handled by a central processor 20. The software structure of the central processor corresponds to a virtual machine that interacts with a lower level operating system implemented in the hardware portion of the decoder.

The packet structure of data within a broadcast MPEG transport stream transmitted from a transmitter to a decoder will now be described with reference to figures 3 and 4. As will be appreciated, although the description will focus on the tabulation format used in the MPEG standard, the same principles apply equally to other packet data stream formats.

Referring specifically to fig. 3, the MPEG bitstream includes a program access table ("PAT") 40 having a packet identification ("PID") 0. This PAT contains reference marks for the PIDs of the program map table ("PMT") 41 for a number of programs. Each PMT contains a reference to the PIDs of the streams of the audio MPEG table 42 and video MPEG table 43 for that program. It is this packet of the program access table 40 with PID of 0 that provides an entry point for all MPEG accesses.

To download applications and data from, two new stream types are defined, and the associated PMT also contains a reference to the PID of the stream applying MPEG table 44 (or part thereof) and data MPEG table 45 (or part thereof). Indeed, while it may be convenient in some cases to define separate stream types for the executable application software and the data processed with such software, this is not essential. In other implementations, the data and executable code may be combined in a single stream accessed using the PMT described above.

Referring to fig. 4, in order to download an application, for example, within stream 44, application 46 is divided into modules 47, each formed using MPEG tables. Some of these tables include a single portion, while other tables may be made up of multiple portions 48. A typical section 48 has a header that includes a one byte table identification ("TID") 50, a number of sections 51 for that section in the table, a total number of sections 52 in that table, and a two byte TID extension reference 53. Each section also includes a data section 54 and a CRC 55. For a particular table 47, all portions 48 making up that table 47 have the same TID 50 and the same TID extension 53. For a particular application 46, all tables 47 that make up that application 46 have the same TID 50, but different respective TID extensions.

For each application 46, a single MPEG table is used as the directory table 56. This directory table 56 has the same TID in its header as the other tables 47 that make up this application. However, this directory table has a predetermined TID extension of 0 for identification purposes and due to the fact that only a single table is required for the information in this directory. All other tables 47 will typically have a non-zero TID extension and consist of a number of related sections 48. The title of this directory table also includes the version number of the application to be downloaded.

Referring again to fig. 3, the PAT40, PMT41, and application and data stream portions 44, 45 are sent cyclically. Each application sent has a respective predetermined TID. To download the application, an MPEG table with the appropriate TID and zero TID extension is downloaded to the receiver/decoder, which is the directory for the required application. The data in this directory is then processed by this decoder to determine the TID extensions that make up the table for the required application. Any required tables with the same TID as the directory table and the TID extension determined from this directory can then be downloaded.

The decoder is arranged to check whether the directory table has any updates. This may be done by downloading this table of contents again periodically, for example every 30 seconds or one or five minutes, and comparing the version numbers of the previously downloaded table of contents. If the newly downloaded version number is not the latest version number, the table associated with the previous directory table is deleted, and the table associated with the new version is downloaded and combined.

In an alternative arrangement, the incoming bit stream is filtered with a value set for the TID of this application, a TID extension of zero and a version number greater than the version number of the currently downloaded directory using a mask corresponding to the TID, TID extension and version number. Thus, the incrementing of the version number can be detected and upon detection, the directory downloaded and the application updated, as described above. If the application is to be ended, an empty directory with the next version number is sent, but without any modules listed in this directory. In response to receiving such an empty directory, the decoder is programmed to delete the application.

In fact, the software and computer programs implementing the applications in this decoder can be introduced through any part of this decoder, in particular in the data stream received through the satellite link described above, but also through a serial port, smart card link, etc. Such software may include advanced applications for implementing interactive applications within the decoder, such as web browsers, question and answer applications, program guides, and the like. The operating configuration of the decoder software may also be changed by downloading the software, for example, using a "patch" or the like.

The application program may also be downloaded through the decoder and sent to a PC or the like connected to the decoder. In such a case, this decoder acts as a communication router for the software that is ultimately run on the connected device. In addition to this routing function, the decoder can also be used to convert MPEG packet data into computer file software constructed, for example, by the DSMCC protocol (see below) before routing to the PC.

Previously, measures for verifying the integrity and origin of application data have focused on verifying tables in MPEG packet streams. In particular, in conventional systems, a hash function is applied to each individual portion 48 prior to transmission and the resulting check value or signature for each portion is stored in a list in the directory table 56 that is transmitted to the decoder. Comparing the hash value subsequently calculated by the decoder with the check value stored in the directory for the received part enables verification of the integrity of the received part.

The data within the directory 40 may likewise be hashed to generate another check value or signature for this directory table 40. Furthermore, the check value can be encrypted with a private key and stored in the directory table. Only those decoders that possess the corresponding public key can authenticate the signature.

In contrast to such conventional systems, the present embodiment relates to means for protecting and verifying application data structured in multi-level data files or objects at the application level, as will be more clearly apparent from fig. 5 which shows the relationship between data structured and encapsulated within a series of MPEG tables 47 in a set of DSMCC U-U data files 60 at a combined application 46.

These data files are assembled in the application 46 before transmission and thereafter formatted by the MPEG compressor into MPEG tables or modules 47 which as described above include headers 49 specific to this MPEG packet stream and include table IDs, version numbers, etc. These tables are then encapsulated into MPEG packets using an MPEG compressor. As will be appreciated, there may not be a fixed relationship between the data constructed in the data file 61 and the final MPEG table 47. After reception and filtering with this decoder, these packet headers are discarded and the series of tables is reconstructed from the payload of the broadcast packet. Thereafter, these table headers 49 are discarded and the application 46 is reconstructed from the payload of the table 47.

The DSMCC format for data files is a standard which is particularly suitable for use in multimedia networks and defines a series of message formats and dialog instructions for communication between client users 70, server users 71 and network resource managers 72. See fig. 6. The network resource manager 72 may be considered a logical entity for managing resource attributes within the network. Although originally conceived in the context of two-way network communications, recent implementations of the DSM-CC standard have focused on the use of its one-way broadcast usage.

The communication between the client and the server is established using a series of conversations, a first series of messages being exchanged between the user (client 70 or server 71) and the network administrator 72 to configure the client and/or server for communication. Such messages are formatted according to the so-called DSMCC U-N (user-network) protocol. A subset of this protocol is specifically defined for broadcast downloading of data.

Once the communication link has been established, messages are then exchanged between the client 70 and the server 71 according to the DSMCC U-U (user-user) protocol. A series of messages of this type corresponds to the data file 60 of figure 5. In the case of DSMCC U-U messages, the data is structured in a series of messages 61 according to a biep or broadcast InterOrb protocol combination.

Each message or object 61 includes a header 62, a subheader 63 and a payload 64 containing the data itself. According to the BIOP protocol, header 62 contains, among other things, an indication of the type of message and the BIOP version, while the subheaders indicate the type of object and other information defined by the system architecture.

The data objects 64 within the DSMCC U-U file may be generally defined as one of three types: directory objects, file objects, and stream objects. The directory object defines a root directory or subdirectory that is used to label a series of related file objects that contain actual application data. The stream object may be used to enable a temporary relationship to be established between the data contained in the data file and the MPEG packet stream itself. This can be used, for example, in the case of an interactive application that is contained in a data file and is designed to be synchronized with a basic video or audio stream that is received and processed by the decoder. As mentioned above, there may otherwise be no direct correlation between MPEG packet data and these data files.

Unlike MPEG tables, where a single directory only marks a set of tables with a single hierarchy, data files 60 can be constructed in a more complex hierarchical manner. As for the files stored in the PC or server, the main or root directory may relate to one or more subdirectories, which in turn relate to the second level data files. Even a second root directory related to another set of application data may be marked.

Referring to FIG. 7, one example of a file structure for a set of data files or cells is shown. The root directory DIR a0, indicated at 75, is labeled as a group of subdirectories a1-a4, indicated at 76. Each subdirectory 76 marks one or more groups of related object files 77. For the sake of brevity, only the target files F1, F2, etc. of a single group related to the sub-directory a4 are shown. In practice, many groups of target files may be labeled with each subdirectory A1-A4.

Within each directory and subdirectory, a set of authentication steps is introduced for the files linked to that directory. Referring to the root directory 75, the subheader 63 includes a hash value obtained by applying a hashing algorithm to some or all of the data stored in the subdirectory file a1-a4, indicated at 76. The hashing algorithm used may be of any known type, such as the message digest algorithm MD5, for example.

In one implementation, the algorithm may be applied separately to each relevant file or sub-directory and a table of hash values for each sub-directory 76 stored in the root directory 75 prior to transmission. However, while such a scheme can increase the inspection resolution in verifying each subdirectory, this scheme can be quite ineffective in terms of the processing time required by the decoder to calculate the corresponding signature.

Thus, the subheader 63 of the directory 79 preferably includes a cumulative hash value 79 calculated by applying an MD5 hashing algorithm to the payload portions 63, 64 of the combined subheader and subdirectory 76 (i.e., without the header 62). In particular, a hash value 82 of the layer contained within the subdirectory 76 and referring to the target file 77 is included in this hash calculation.

In the case of subdirectory A4 shown in FIG. 7, this subdirectory itself relates to a group of target files F1-Fn, indicated at 77. In this case, a cumulative hash value 82 is generated for the combined content of the target file 77, and this value is included in the hash process to obtain this hash value 79. Therefore, it is not possible to change any target file 77 without changing the hash value 82 of the subdirectory 76, which in turn will change the hash value 79 of the directory 75.

In the present case, the combined hash value is calculated for all subdirectories A1-A4 labeled in this directory. This hash value is stored with an identifier of the group of subdirectories from which the data was obtained. In other embodiments, a series of combined or individual hash values and corresponding identifiers may be stored in the subheadings of the directory.

For example, a second group of subdirectories, which are also associated with this root directory but relate to a different group of data or executable code, may also be combined together, and the cumulative hash values calculated for these subdirectories calculated and stored in the subheader root directory. A single hash value associated with a single directory may also be stored in the subheader of this root directory.

The authorization of a group or individual data file does not of course prevent this root directory (or, indeed, any other file) from also relating to data files that are not verified or hashed, but such files must be taken into account in any operation that utilizes this file for not being verified. In this regard, for example, there may be no need to identify stream objects.

The use of a hash function in this case enables the decoder to verify the integrity or completeness of the downloaded data file. For example, in the event of a transmission failure or interruption, the operation of the cumulative hash algorithm on receiving the relevant files will not give the same result as the hash values of those files stored in this root directory. This decoder will then be alerted: errors may exist in the downloaded data and the decoder will reload the faulty data file.

As will be appreciated, in the case of a hashing algorithm, the calculation of this hash value is done according to a well-known series of calculation steps, and thus anyone can generate a hash value for a given set of data files. Thus, it is generally not possible to verify the origin of such data files merely by checking hash values.

To overcome this problem, the signature values for the root directory 75 are calculated using a key known only to the operator. This key may correspond to a key obtained using a symmetric key algorithm, such as the data encryption standard or the DES algorithm. However, it is preferred to use private/public key algorithms such as Rivest, Shamir and Alteman or RSA algorithms, the operator responsible for generating these data files having the private key value, the public key value being maintained by the decoder.

As shown in fig. 7, the root directory 75 includes a key identifier or magic number (magic number)80 identifying to this decoder the public key to be used in the authentication stage with a computed signature value 81 generated using the operator's private key. In this case, the signature value 81 is generated by applying the operator-held private key to some or all of the data in the directory 75, preferably including the payload data 64 and/or the cumulative hash value 79. The decoder can then verify the signature value 81 using the corresponding public key identified by the key number 80.

In this example, the data in the directory 75 is not encrypted, and this private key is used only to provide a signature value that can be verified using the public key. In an alternative embodiment, some or all of the contents of the directory may be encrypted using the private key and then decrypted using the corresponding key.

In either case, the use of secret keys to generate signature values or encrypted code blocks enables the decoder to verify the integrity and origin of the directory 75 and, of course, the files to which the root directory refers. Since the cumulative hash value of the relevant file is included in the calculation of the signature 81, it is not possible to change these values without detecting this at the authentication level. Since each hash value is generally unique to a given set of data, it is not possible to change the contents of any associated hash file without changing its characteristic hash value and thus changing the signature value of the resulting directory.

The root directory 75, subdirectories 76 and object files 77 are all generated by one broadcast operator of the system, denoted herein as operator a. In this case, the files will all have a common origin that is known and verifiable.

However, depending on the application to be implemented, it is equally possible to label a set of data files related to the second operator B. In this case the subdirectory 76 comprises a label for the root directory DIR B0 of the second group of data files, indicated at 78. It is also possible to envisage connections between data files from different sources on other levels (e.g. file hierarchy where a first sub-directory in a first group of files relates to a sub-directory of a second group of data files, etc.).

Like the root directory DIR a0 for operator a, the DIR B0 root directory, denoted at 78, includes one or more cumulative hash code values 84 relating to its associated subdirectories (not shown), a key number 85 identifying the public key of operator B used in the verification step, and a signature value 86 generated using the corresponding operator-specific key.

The hash value for this directory is calculated using the hash value 84 and the signature value 86 in the subheader of this directory and also using the payload data 64 of the directory 78. This hash value is then stored in subdirectory a4 so that verification of the integrity of the data in the directory table can be accomplished.

Due to the fact that the signature value 86 and the hash value 84 are included in the calculation of the hash value 83, it is also possible to assume the integrity of the remaining data files involved in the root directory 78, since it is not possible to change these related files without changing the hash value 84, and more importantly this signature value 86. Since this signature value 86 can only be calculated by the person owning this private key, the integrity of all files involved in this directory 78 can be assumed, assuming that for the further relevant subdirectory the corresponding hash value is calculated with the target file.

In this way, application data generated by the second operator relating to executable programs or the like can be linked with the application program relating to the first operator in a safe and reliable manner.

As will be appreciated, many variations are possible to significantly reduce the amount of data hashed or tagged at each level. In particular, in the case of a signature or hash value in a directory or subdirectory for verifying lower level data files, the directory signature or hash value may be generated with only the lower level hash value and without other data.

For example, the combined hash values 82, 83 for each A1-A4 subdirectory, denoted at 76, may be used to generate the combined hash value 79 in the A0 directory 75. Since these values are unique just as the data in the payload of this subdirectory, the combined hash value 79 will still be unique to that subdirectory. Also, the integrity of the lower level target and directory files 77, 78 may still be assumed due to the hash value 82 still being used in the calculation.

Likewise, the hash value 82 calculated to verify the B0 catalog denoted at 78 may be calculated using only the signature value 86. Since this depends on and is uniquely associated with hash values 84, which in turn depend on the files of the next level, the integrity of the entire set of data files referenced by directory 78 can still be assumed.

Claims (6)

1. An apparatus for discriminating between a first set of data units and a second set of data units to be transmitted in a digital transmission system, said apparatus comprising:

means for generating a first signature by means of a secret key acting on a first element, the first element being an element of the first set of data elements;

means for storing the first signature in the first cell;

means for authenticating at least the first signature value using an authentication algorithm to obtain a first authentication value;

means for storing this first discrimination value in a second cell, the second cell being a cell in a second set of data cells, the second cell including the reference mark of the first cell;

means for authenticating at least the first authentication value in the second unit to obtain a second authentication value, the second authentication value being a hash value; and

means for generating a second signature for at least the second authentication value.

2. The apparatus of claim 1, wherein the first signature is generated by a secret key acting on at least some data in the first unit.

3. The apparatus of claim 1, wherein the data unit corresponds to a set of data files encapsulated in a data table or portion of a data table, the data tables thereafter encapsulated in data packets to form a transport stream.

4. The apparatus of one of claims 1 to 3, wherein the digital transmission system corresponds to a digital television system.

5. The apparatus of claim 1, wherein the first operator comprises:

means for generating a first signature by means of a secret key acting on a first unit, the first unit being a unit in said first set of data units, an

Means for storing the first signature in the first cell,

the second operator includes:

means for authenticating at least the first signature value using an authentication algorithm to obtain a first authentication value;

means for storing this first discrimination value in a second cell, the second cell being a cell in a second set of data cells, the second cell including the reference mark of the first cell;

means for authenticating at least the first authentication value in the second unit to obtain a second authentication value, the second authentication value being a hash value; and

means for generating a second signature for at least the second authentication value.

6. An apparatus for verifying data received in a digital transmission system, the data comprising a first group of data units and a second group of data units, a first data unit belonging to the first group of data units comprising a first signature generated by a secret key acting on the first data unit, a second data unit belonging to the second group of data units, the second data unit relating to the first data unit and comprising a first authentication value obtained from authenticating at least the first signature by an authentication algorithm, a second authentication value obtained from authenticating at least the first authentication value by the authentication algorithm and a second signature for at least the second authentication value, the second authentication value being a hash value, the apparatus comprising:

means for verifying a first signature in said first unit using an associated public key;

means for verifying a first authentication value stored in said element of the second set of data elements using an authentication algorithm acting on at least said first signature,

means for verifying the second authentication value using an authentication algorithm acting on at least the first authentication value; and

means for verifying at least a second signature for a second authentication value.