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

Abstract

A method of authentification of data sent in a digital transmission characterised by the organisation and authentification of the data prior to transmission into a hierarchy of at least one root directory unit (75), subdirectory unit (76) and file unit (77), data in a file (77) being acted upon by an authentification algorithm and an associated file authentification value (82) stored in the referring subdirectory unit (77), this file authentification value (82) being in turn acted upon by an authentification algorithm and an associated subdirectory authentification value (79) stored in the referring root directory. Other aspects of the invention relate to the authentification of a second root directory (78) by generation of a second authentification value (83) and the authentification of data before encapsulation in tables or sections of a transport stream.

Description

AUTHENTICATION OF DATA IN A DIGITAL TRANSMISSION SYSTEM The present invention relates to a method of authenticating data sent in a digital transmission system. The transmission of digital data broadcasting is well known in the field of pay television systems, where encoded audiovisual information is sent, usually via satellite or a satellite / cable link, to many subscribers, each having a decoder able to decode the transmitted program to see it subsequently. Terrestrial digital broadcasting systems are also known. Recent systems have also used the broadcast link to transmit other data, in addition to, or as well as, audiovisual data, such as computer programs or interactive applications to the decoder or to a connected PC. A particular problem with the transmission of application data consists in the need to verify the integrity and origin of any such data. Since data of this kind can be used to reconfigure the decoder, as well as to implement any number of interactive applications, it is essential that the received data is complete and identified as originating from a known source. Otherwise, operational problems associated with the downloading of incomplete data may arise, as well as running the risk that the decoder is susceptible to attacks by third parties or similar things. Attempts to authenticate such data have focused on the verification of levels of encapsulation or formatting of data in a packet flow. For example, the European patent application EP 0752786 describes a system in which the data is encapsulated in a series of modules, or using the terminology associated with the MPEG standard, a series of tables or sections, the tables or sections that then they are encapsulated in packets in an MPEG transport stream. The authentication operations are performed in relation to the tabulated data, a directory table containing, for example, a list of all the tables containing the data for that application together with a list of routing calculation values, associated with each table, to allow verification of the table below. The table of the directory itself can be signed before the transmission, in such a way that the information in the directory table and the associated tables can be modified without changing the calculation values of the address and the signature.

The problem with these known systems is that they are inadequate to handle more complex data organization structures. In particular, the use of a single directory table containing a complete list of routing calculation values for each associated table means that these systems can not be easily adapted to handle large tables of variable numbers. In the same way, the system is not well adapted to allow the authentication of the software provided by a number of operators of the broadcasts, since a single table of the MPEG directory links all the tables, and since the authentication operations are. perform outside the stage of formatting the data in the tables for the encapsulation and the diffusion of packages. Generally this operation is carried out under the control of a single operator. In accordance with a first aspect of the present invention, there is provided a method of authenticating the data that is sent in a digital transmission system characterized by the organization of the data before transmission in a hierarchy of at least one directory unit root, a subdirectory unit and a file unit, the data in a file being activated by means of an authentication algorithm and an associated file authentication value, stored in the reference subdirectory, this value of file authentication being activated in turn by means of an authentication algorithm and an associated subdirectory authentication value, stored in the reference root directory. Unlike the known systems, where a single table directory refers to all the associated tables, the use of a multiple hierarchy structure, together with the application of an authentication algorithm in each step in the hierarchy provides a structure of safe and odularized data. As a file authentication value in a subdirectory is in turn authenticated at a higher level by means of a corresponding value in the root directory, it is not possible to change an element in a lower level without changing the authentication values to a higher level high (and vice versa). Preferably, the authentication of the file data is carried out by means of applying a routing calculation algorithm to some or all of the data in the file, the resulting routing calculation value being stored as the authentication file value in the reference subdirectory. Similarly, the authentication of a subdirectory can be carried out by applying a routing calculation algorithm to the authentication value of the file (and other data if desired), the resulting routing calculation value being stored as the value of authentication of the subdirectory in the reference root directory. Other modalities may be considered, for example, where the file data is encrypted in accordance with a cryptographic algorithm, and the cryptographic key (or its identifier key number) used as the authentication value stored in the subdirectory. This file key can in turn be encrypted, and the cryptographic key can be stored in the root directory as the authentication value, and so on. Although it is possible, it is much more complicated to put this modality in its place, due to the increased complexity in the operations necessary to generate the values of the cryptographic key. In contrast, the use of the routing calculation algorithm to perform the authentication of each module allows a particularly simple and rapid verification of the integrity of each module that is carried out. In one embodiment, a simple addressing calculation algorithm such as the checksum calculation can be used. However, the above would not allow a forgery detection, since it is relatively simple to determine how any change in a message affects the address calculation value. Preferably, the addressing calculation algorithm corresponds to a cryptographically secure algorithm that generates a substantially unique address calculation value from a set of determined data. Appropriate routing calculation algorithms that can be used for this purpose include, for example, the algorithm of Message Digest version 5 (MD5) or the Secure Hash Algorithm (SHA) (Secure Total Algorithm). Conveniently, the authentication of the file data for a plurality of files is carried out by means of applying a routing calculation algorithm to a data accumulation of a plurality of files to generate a single routing calculation value. Likewise, the authentication of a number of subdirectories can be carried out by means of applying a routing calculation algorithm to an accumulation of file authentication values of a plurality of subdirectories (and other data if desired) to generate a single address calculation value. The use of a cumulative totalizer process to cover a plurality of data modules (files, subdirectories, etc.) in a lower layer - further simplifies the system in comparison, for example, with systems that store a list of individual routing calculation values for each module. Again, the above allows the system to reduce the calculation steps needed in each level and reduces the size of the authentication data stored in a higher layer. In the case of the modalities that use a routing calculation algorithm to authenticate each layer, the system will be 'open', that is, all the routing calculation values will be legible up to the root directory. Since the routing calculation algorithms are publicly available, theoretically a third party can change the stored data, for example, to a file level without detecting whether the routing calculation values corresponding to the level of the subdirectory and the root directory are also they will change at the same time. To avoid the above, at least some of the data stored in the root directory is activated by means of a secret key of a cryptographic algorithm, and the cryptographic value that is stored in the root directory. Preferably, the cryptographic value corresponds to a digital signature. Suitable public / private key encoders for this purpose include, for example, the RSA algorithm.

Conveniently, the data encoded by means of the secret key to generate a signature stored in the root directory comprises at least one or more authentication values of subdirectories. However, if it is possible to consider other data in the root directory than the values, authentication of the subdirectories that are being signed with the purpose of 'closing' the system, in an alternative to the generation of a signature, part or The root directory can be simply encrypted or encrypted, the receiver having an equivalent key to dibe the cryptographic data of the root directory, in which case a symmetric key algorithm such as a DES can be used. the authentication process has been dibed above with reference to two hierarchical levels, similar ad infinitum authentication steps can be carried out for additional referenced files, subdirectories, root directories, etc. Similarly, although the structure has been defined as root / directory subdirectory / archive for the sake of language clarity, no other characteristics are assumed particularity of each unit in a layer, other than the reference to a lower layer unit by means of two units of higher layers. As can be understood, the structure of the data can also be root directory / subdirectory / second root directory or any other combination. The following modalities that are dibed focus on a lower layer unit, that is, referred to by means of a directory or subdirectory. However, as will become clear, even when it has been referred from a higher layer, this unit itself can be a directory unit, a subdirectory unit, and so on. In one embodiment, a referred unit includes a cryptographic value generated by means of a secret key, an authentication value for this unit being calculated based on the results of an authentication algorithm on the cryptographic value and stored in the reference unit. In particular, as with the modality of the equivalent of the root directory dibed above, a referred unit can be signed, the authentication value for that unit being calculated as the result of a routing calculation function in that signature. The referred unit may correspond, for example, to a file or subdirectory. However, this embodiment is particularly adapted to the situation in which the unit referred to is a root directory for an additional set of data, for example, data of different origin and where the referred root unit also includes a signature. In this case, a first operator can assemble and sign the data up to the level of the root directory. Thereafter, a second operator can refer to these data without knowing the cryptographic key, any link simply being authenticated in the reference unit by means of the address calculation value of the signature in the referred root directory. Of course, the authentication of both data sets will only be possible for a receiver that has the necessary keys to verify the signatures in both root directories. As dibed above, the present invention can be applied to any set of data units of multiple hierarchies. This can even be applied to the organization of tables or packages in the transport flow, if multiple levels of the root directory, subdirectory, file, etc. can be provided in a packet flow. However, this invention applies particularly to the case in which the units correspond to a set of data files encapsulated in tables or data sections, these tables being then encapsulated in data packets to form a critical flow. transport.

Unlike authentication in the packet or at the table level, this embodiment allows a complete independence between the assembly of authenticated data and its encapsulation in a transport flow and, again, facilitates the supply of software from different sources in the transport flow controlled by a single broadcast operator. The data authenticated in accordance with this modality can even be transmitted by means of different transmission routes (for example, a bidirectional telecommunications link or a satellite link) that uses alternative encapsulation formats to transmit the data. Preferably the data units correspond to the data objects formatted in accordance with the DSMCC standards. In one embodiment, the data objects are encapsulated thereafter in tables and packets conforming to the MPEG standard. In accordance with a second aspect of the present invention, there is provided an authentication method of a first and a second set of linked data units sent in a digital transmission system, characterized in that at least one of the first sets of units includes a signature generated by a secret key acting in that first unit, at least this signature value that is authenticated by means of an authentication algorithm and the authentication value that is stored in a unit in the second set of units that are referred to that first unit. In accordance with a third aspect of the present invention, there is provided a method of authenticating data sent in a digital transmission system, characterized in that the data is organized in a series of data files, the authentication carried out between file independently and before the step or stages of formatting and encapsulation of data used by the digital transmission system to prepare the data for transmission in a packet transport stream. In particular, authentication can be carried out before formatting into tables or sections, such that then the tables are encapsulated in packets of data in the packet transport stream. As mentioned above, the use of an authentication process applied prior to the preparation of the data for transmission has the effect that the data can thereafter be directed to a receiver by any number of channels, such as as a broadcast channel or a telecommunications channel, without changing the authentication process. Likewise, once a receiver or decoder has reconstituted the data files of the format associated with the transmission route, a verification can be carried out on this data, regardless of the transmission mode chosen. Of course, any or all of the features of the first aspect of the invention and its preferred embodiments may be combined with the second and third aspects of the invention. The present invention has been described above in relation to the steps for generating the authentication data before transmission. The invention in its broadest and preferred embodiments also applies to the reverse steps that are carried out in a receiver to verify this data. In its broadest aspects, the present invention can be applied to any digital transmission system. However, preferably the invention is applied to a digital television system and, in particular, to data modules carrying application software for use in a receiver / decoder of the digital television system. As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting, for example, primarily digital audiovisual or multimedia data, although the present invention is particularly applicable to a digital television system. diffused, the invention can also be applied to a fixed telecommunications network for multimedia Internet applications, to a closed circuit television, and so on. As can be understood, the term "digital television system" includes, for example, any satellite, terrestrial, cable or other system The term "receiver / decoder" or "decoder" used in the present application may involve a receiver for receiving signals whether encoded or uncoded, for example, television and / or radio signals, which may be broadcast or transmitted by other means The term may also involve a decoder to decode the received signals. / decoders may include an integral decoder with the receiver for decoding the received signals, for example, in a 'top box', such a decoder operating in combination with a physically separate receiver, or that decoder including additional functions, such as a web browser and / or integrated with other devices such as a video recorder or a television. The term MPEG refers to the data transmission standards developed by the 'Motion Pictures Expert group' working group of the International Standards Organization and in particular, but not exclusively, the MPEG-2 standard developed for digital and published television applications. in the documents ISO 13818-1, ISO 13818-2, ISO 13818-3 and ISO 13818-4 In the context of the present patent application, the term includes all variants, modifications or developments of the MPEG formats applicable to the field of digital data transmission The term DSMCC refers to the data file format standards described in the MPEG documents and in the current ISO 13818-6 document, and will be described, as an example only, as a preferred embodiment. of the invention with reference to the appended figures, in which: Figure 1 shows a schematic sketch of a digital television system for use with the present Fig. 2 shows the structure of a system decoder in Fig. 1. Fig. 3 shows the structure of a number of components within the MPEG broadcast transport stream. Figure 4 shows the division of a software application into a number of MPEG tables. Figure 5 shows the relationship between the DSMCC data files and the MPEG tables eventually produced. Figure 6 shows the relationship of the client, the server, the network administrator as defined in the context of the DSMCC.

Figure 7 shows the directory, subdirectory and objects of the file authenticated in this embodiment of the invention. In Figure 1 there is shown an overview of the digital television system 1 in accordance with the present invention. The invention includes a mostly conventional digital television system 2 which uses the known MPEG-2 compression system to transmit compressed digital signals. In more detail, the MPEG-2 compressor 3 in a broadcast center receives a stream of digital signals (typically a stream of video signals). The compressor 3 is connected to a multiplexer and encoder 4 via link 5. The multiplexer 4 receives a plurality of additional input signals, assembles the transport stream and transmits compressed digital signals to transmitter 6 of the broadcast center via the link 7, which can of course assume a wide variety of forms including telecommunications links. The transmitter 6 transmits the electromagnetic signals by means of upper links 8 to a radio beacon of satellite response 9, where these are electronically processed and broadcast by means of the speculative downlink 10 to the ground receiver 12, in the form of a dish of its own or rented by the end user. The signals received by the receiver 12 are transmitted to an integrated receiver / decoder 13 owned or rented by the end user and connected to the television set 14 of the user. The receiver / decoder 13 decodes the compressed signal MPEG-2 into a television signal for the television set 14. Of course, other transport channels for data transmission are possible, such as a terrestrial broadcast, cable transmission, combination of satellite / cable links, telephone networks, etcetera. In a multi-channel system, the multiplexer 4 handles the audio and video information received from a number of parallel sources and interacts with the transmitter 6 to broadcast the information along a number of corresponding channels. In addition to audiovisual information, you can enter messages or applications or any other type of digital data in some or all of these interlaced channels with the information transmitted from digital audio and video. In such a case, a digital data stream in the form of, for example, files and software messages of DSM-CC format, will be compressed and packaged in MPEG format by means of the compressor 3. The discharge of the data will be described in more detail below. software modules. A conditional access system 15 is connected to multiplexer 4 and receiver / decoder 13, and is located partially in the broadcast center and partially in the decoder. The latter allows the end user to access digital television broadcasts from one or more broadcast providers. A smart card can be inserted, capable of deciphering the messages related to the commercial offers (ie, one or several television programs sold by the broadcaster), on the receiver / decoder 13. By using the decoder 13 and a smart card, the end user can buy commercial offers either in subscription mode or a pay-per-event mode. In practice, the decoder can be configured to handle multiple access control systems, that is, the Simulcrypt or Multicrypt designs. As mentioned above, the programs transmitted by the system are encoded in the multiplexer 4, the conditions and the cryptographic keys applied to a given transmission being determined by the access control system 15. The transmission of the data encoded in this way he is well known in the field of pay television systems. Typically, the encoded data is transmitted together with a control word for the decoding of the data, the control word itself being cryptographed by a so-called key of use and transmitted in cryptographic form. The decoder 13 then receives the encoded data and the cryptographic control word, which has access to an equivalent of the usage key stored in a smart card inserted in the decoder to describe the cryptographic control word and thereafter decode the transmitted data. A subscriber for payment will receive, for example, in a monthly broadcast EMM (for its acronym in English Entitlement Management Message) the key to use necessary to describe the cryptographic control word, in such a way that it is allowed to see the transmission. In addition to their use to describe audiovisual television programs, similar usage keys can be generated and transmitted to be used in the verification of other data such as software modules, as will be described later. An interactive system 16, which is also connected to the multiplexer 4 and the receiver / decoder 13 and again located partially in the broadcast center and partly in the decoder, allows the end user to interact with various applications by means of a channel Modem back 17. The back modem channel can also be used for communications used in the conditional access system 15. An interactive system can be used, for example, to allow the viewer to communicate immediately with the transmission center for demand the authorization to see a particular event, download an application, and so on. Referring to Figure 2, the physical elements of receiver / decoder 13 or the upper case adapted for use in the present invention will now be briefly described. The elements shown in this figure will be described in terms of functional blocks. The decoder 13 comprises a central processor 20 which includes associated memory elements adapted to receive the input data from a serial interface 21, a parallel interface 22, and a modem 23 (connected to the rear modem channel 17 of FIG. 1). ). The decoder is further adapted to receive inputs from an infrared remote control 25 by means of a control unit 26 and the contacts of the switch 24 in the front panel of the decoder. The decoder also prosecutes two smart card readers 27, 28, adapted to read bank or subscriber smart cards 29, 30 respectively. The input can also be received through an infrared keyboard (not shown). The reader of the subscription smart card 28 is committed to a subscription card 30 inserted and with a conditional access unit 29 to provide the necessary control word to a demultiplexer / decoder 30 to allow the encoded broadcast signal to be decoded . The decoder also includes a conventional tuner 31 and a demodulator • 32 for receiving and demodulating the satellite transmission before it is filtered and demultiplexed by the unit 30. The data processing within the decoder is generally handled by means of the central processor 20. The architecture of the central processor software corresponds to a virtual machine that interacts with a lower-level operating system implemented in the hardware components of the decoder. Now we will describe, with reference to Figures 3 and 4, the data packet structure within the broadcast MPEG transport stream sent by the transmitter to the decoder As will be noted, although the description will focus on the tabulation format that is used to the MPEG standard, the same principles apply equally to other packetized data flow formats, referring in particular to Figure 3, an MPEG bit stream includes an access table program ('PAT') 40 having a packet identification ('PID') of 0. The PAT contains references to the PIDs of the program map tables ('PMTs'). ") 41 of a number of programs Each PMT contains a reference to the PIDs of the audio MPEG tables flows 42 and the video MPEG tables 43 for that program A packet that has a PID of zero, ie the program of the access table 40, provides the entry point for all MPEG accesses in order to download the applications and data for them, two new types of flows are defined, and the relevant PMT also contains references to the PIDs of the application streams of MPEG 44 tables (or sections thereof) and MPEG 45 data tables (or sections thereof) In fact, while it may be convenient in some cases to define separate stream tips for executable software applications and the data to process them for such s Oftware, the above is not essential. In other embodiments, data and executable code can be assembled in a single stream that can be accessed by means of the PMT as described. Referring to Figure 4, in order to download, for example, an application within flow 44, application 46 is divided into modules 47, each formed by an MPEG table. Some of these tables comprise a single section while others may be made of a plurality of sections 48. A typical section 48 has a header, which includes a one-byte table identification ('TID') 50, section number 51 from that section in the table, the total number 52 of sections in that table and a reference extension 53 two-byte TID Each section also includes a data part 54 and a CRC 55. For a particular table 47, all the sections 48 constituting table 47 have the same TID 50 and the same extension TID 53. For a particular application 46, all tables 47 that constitute that application 46 have the same TID 50, but different respective TID extensions. 46, a single MPEG table is used with a directory table 56. The directory table 56 has, in its header, the same TID as the other tables 47 that constitute the application. It has a previously determined TID extension from zero for identification purposes and due to this fact only a single table is needed for the information in the directory. All other tables 47 would normally have non-zero TID extensions and are composed of a number of associated sections 48. The header of the directory table also includes a version number of the application to be downloaded. Referring again to Figure 3, the. PAT 40, the PMTs 41 and the application and the components of the data stream 44, 45 are transmitted cyclically. Each application that is transmitted has a respective TID previously determined. To download an application, the MPEG table that has the appropriate TID and a TID extension of zero is downloaded to the receiver / downloader. This is the directory table for the required application. Then the data in the directory is processed by means of the decoder to determine the TID extensions of the tables that constitute the required application. Thereafter you can download any required table that has the same TID as the directory table and a TID extension determined from the directory. The decoder is configured to verify the directory table for any update of the same. The above can be done by periodically downloading the directory table again, for example every 30 seconds, or from one to five minutes, and comparing the version number of the previously downloaded directory table. If the version number recently downloaded is the same as a later version, then the tables associated with the table in the previous directory are deleted, and the tables associated with the new version downloaded and assembled. In an alternative configuration, the input bit stream is filtered by using a masking corresponding to the TID, the TID extension and a version number, with values set for the TID of the application, a TID extension of zero and a version number one greater than the version number of the currently downloaded directory. In accordance with the above, an increase in the version number can be detected, and once detected, the directory is downloaded and the application is updated, as described above. If an application is to be finished, an empty directory is transmitted with the following version number, but without any module listed in the directory. In response to receiving such an empty directory, the decoder 2020 is programmed to eliminate the application. In practice, software and computer programs can be introduced to implement the applications in the decoder, in particular in the data stream received via the satellite link as described, but also through a serial port. , the link of the smart card and so on. Such software may comprise high-level applications used to implement interactive applications within the decoder, such as network browsers, test applications, program guides, and so on. The software can also be downloaded to change the working configuration of the decoder software, for example, by means of patches or similar, the applications can also be downloaded by means of the decoder, and can be sent to a PC or the like. In this case, the decoder acts as a software communication router, which eventually runs on the connected device In addition to this routing function, the decoder can also function to convert MPEG packaged data. before sending them to the PC in organized computer software files, for example, in accordance with the DSMCC protocol (see below). Previously, the measures implemented to verify the totality and origin of the application data have been focused in the verification of the tables in the MPEG packet flow, particularly in conventional systems, a Direction calculation function is applied to each of the individual sections 48 before transmission and the verification value or signature that results for each section stored in a list in the directory table 56 is sent to the decoder. Making a comparison of the address calculation value subsequently calculated by the decoder with the verified value stored in the directory for a received section allows the integrity of the received section to be verified. The data within the directory 40 can also be subject to a process of calculation of direction to generate an additional verification of the value or signature for the directory table 40. In addition, this verification value can be encoded by means of a private key and it can be stored in the directory table. Only those decoders that process a corresponding public key can authenticate the signature. In contrast to such conventional systems, the present embodiment relates to an element for securing and verifying the application data organized in a multiple hierarchy of data files or objects at the application level. The foregoing will be understood more clearly from Figure 5 which shows the relationship between the data organized in a set of data files 60 UU DSMCC, in an assembled application 46 and as encapsulated within a series of MPEG 47 tables. Before transmission , the data files are assembled in application 46 and, thereafter, they are formatted by means of an MPEG compressor in MPEG tables or modules 47, as described above, including a header 49 specific to the MPEG packet stream and including the ID table, the version number, and so on. Then these tables are encapsulated by means of the MPEG compressor in MPEG packets. As will be appreciated, there may not be a fixed relationship between the data organized in the data file 61 and the eventual MPEG tables. After reception and filtering through the decoder, the packet headers are discarded and the series of tables is reconstituted from the payload of tables 47. The DSMCC format for the data files is a particular adapted rule for using in multimedia networks and which defines a series of message formats and command sessions to establish communication between a user client 70, a server user 71 and the resource manager of the network 72. See Figure 6. The administrator could be considered of network resources 72 as a logical entity that acts to manage the allocation of resources within a network. Although initially intended for use in the context of bidirectional network communication, the most recent applications of the DSM-CC standard have focused on its use for unidirectional broadcast purposes. The communication between a client and a server is established by means of a series of sessions, a first series of messages that are exchanged between a user (client 70 or server 71) and the administrator of the network 72, in order to configure the client and / or the server for communication. Such messages are formatted in accordance with the so-called DSMCC protocol U-N (user to network). A subset of this protocol has been defined in particular to disseminate the data download. Once a communication link has been established, the messages are subsequently exchanged between the client 70 and the server 71, in accordance with the DSMCC-U-U (user-to-user) protocol. A sequence of messages of this type correspond to the data files 60 of Figure 5. In the case of the DSMCC UU messages, the data is organized in a series of messages 61 grouped according to the BIOP (for its acronym in English ) or the Broadcast InterOrb Protocol (InterOrbital Broadcast Protocol). Each message or object 61 comprises a header 62, a subheader 63 and a payload 64 that contains the data itself. In accordance with the BIOP protocol, header 62 contains, among other things, an indication of the message type and the version of the BIOP while the subheading indicates the type of object and other information that is defined by the system architect. The data objects 64 within the payload of the DSMCC U-U files can generally be defined as one of three types; Directory objects, file objects and flow objects. Directory objects define root directories or subdirectories used to refer to a series of associated file objects that contain the current application data. The flow objects can be used to allow a temporal relationship to be established between the data contained in the data files and the same MPEG packet flow. The foregoing can be used, for example, in the case of interactive applications contained in the data files designated to be synchronized with the elementary video or audio streams received and processed by the decoder. As mentioned above, otherwise there might not be a direct correlation between the MPEG packaged data and the data files. Contrary to MPEG tables, where a single directory refers to a set of tables with only a single hierarchy level, the data files 60 can be organized in a somewhat more complex hierarchical manner. As with files stored on a PC or server, a home directory or root directory can refer to one or more subdirectories that in turn refer to a second level of data files. The reference could be made to a second root directory associated with another set of application data. Referring to Figure 7, an example of the file structure for a set of data files or units is shown. A root directory DIR AO indicated in 75 references a group of subdirectories Al to A4 indicated in 76. Each subdirectory 76 refers to one or more sets of associated object files 77. For the sake of clarity, only a single group of files of objects Fl, F2, etc., associated with the subdirectory A4 is displayed. In practice, you can refer to a number of groups of object files for each of the subdirectories Al to A4. Within each directory and subdirectory, a set of authentication steps is introduced for the files linked to that directory. With reference to the root directory 75, the subheader 63 comprises a routing calculation value obtained by means of applying a routing calculation algorithm to some or all of the data stored in the files of the subdirectories Al to A4 indicated 76. The algorithm of The address calculation used can be of any type known as, for example, the 'Message Digest' algorithm MD5 In a procedure, the algorithm can be applied to each file or subdirectory associated individually, and a list of the address calculation values for each subdirectory 76 stored in the root directory 75 before transmission, however, although that solution allows a higher degree of verification in terms of verifying each subdirectory, this solution may be somewhat inefficient in terms of processing time. that the decoder needs to calculate the corresponding signatures. The subheader 63 of the directory 79 preferably comprises a cumulative address calculation value 79, calculated by applying the MD5 addressing calculation algorithm to the combined subheader and payload sections 6e, 64 of the subdirectories 76, that is, without the header 62. In particular, the address calculation values 82 contained within the subdirectories 76 and referring to the file layer of objects 77 are included in this calculation of addressing calculation. In the case of the subdirectory A4 shown in Figure 7, this subdirectory itself refers to a set of files of objects Fl - Fn indicated at 77. In this case, a cumulative address calculation value 82 is generated for the combined content of the object files 77. This value is included in the routing calculation process that gives rise to the address calculation value 79. Therefore it is not possible to change any of the object files 77 without changing the value address calculation 82 of subdirectory 76, which in turn will change the address calculation value 79 of the directory 75. In the present case, a combined address calculation value is calculated for all the Al-A4 subdirectories referred to in the directory. This routing calculation value is stored together with an identifier of the group of subdirectories from which the data has been taken. In other modes, a series of combined or individual address calculation values and the corresponding identifiers can be stored in the subheader of the directory. For example, a second set of subdirectories ", which are also associated with the root directory but relate to a different set of data or executable codes that can also be grouped together and a computed cumulative address calculation value for these subdirectories that is calculated and stored in the subheading of the root directory, as well as a single routing calculation value associated with a single directory can be stored in the subheading of the root directory.The authorization of data files in groups or individuals certainly does not prevent the root directory (or, of course, any other file) that is also • referred to unvalidated data files or without addressing calculation, but it will be necessary that the absence of the validation of such file be taken into account in any operation with this file, in this respect, it may not be necessary, for example, to authenticate the flow of objects. The use of a routing calculation function in this case first allows the decoder to verify the integrity or the totality of the downloaded data files. In the case, for example, of a failure or interruption of the transmission, the operation of a cumulative address calculation algorithm in the received subordinate file will not give the same result to the address calculation value for these files stored in the root directory . The decoder will then be alerted of the presence of possible errors in the downloaded data and will again load the defective data files. As will be appreciated, in the case of a routing calculation algorithm, the calculation of the routing calculation value is carried out in accordance with a series of publicly known calculation steps and, as such, any person can generate the value of routing calculation for a given set of data files. Therefore, it is usually not possible to verify the origin of such data files by simply verifying the routing calculation values. To overcome this problem, a signature value for the root directory 75 is calculated by using a secret key value, known only to the operator. This key can correspond to a key obtained by means of a symmetric key algorithm, such as the Data Encryption Standard or DES algorithm. However, preferably a private / public key algorithm such as the Rivest algorithm, Shamir and Alternan or RSA, the operator responsible for producing the data files, possessing the private key value, the public key values being contained, is used. by the decoders. As shown in Figure 7, the root directory 75 comprises a key identifier or magic number 80 which will identify for the decoder the public key that is used in the verification step together with the calculated signature value 81 generated by means of using the operator's private key. In this case, the signature value 81 is generated by means of applying the private key retained by the operator to some or all of the data within the directory 75, preferably including the payload data 64 and / or the value or values 79 cumulative. Then the decoder can verify this signature value 81 using the corresponding public key identified by the key number 80. In this example, the data in directory 75 is not coded and the private key is simply used to provide a value signature that can be verified by means of the public key. In the alternative modalities, part or all of the contents of the directory can be coded by means of the private key and thereafter remove the key by means of a corresponding key.

In any case, the generation of a cryptographic code signature or block value, by using a secret key, allows the decoder to verify the integrity and origin of the directory 75 and, by deduction, the integrity and origin of the files to which the root directory refers. Since the cumulative address calculation values for the reference files are included in the calculation of the signature 81, it is not possible to alter these values without being detected in the verification step. Since each routing calculation value is generally unique to a given data set, it would therefore not be possible to change the content of any of the subordinate routing calculation files without changing its characteristic routing calculation value and, in this way, the signature value that results from a directory. The root directory 75, the subdirectories 76 and the object files 77 are all generated by a system broadcast operator, indicated here as operator A. In this case, these files will have a common origin that can be verified and known. However, depending on the application to be implemented, the reference can also be made to a set of data files associated with a second operator B. In this case, subdirectory 76 includes a reference to the root directory DIR BO of a second set of data files, indicated at 78. It is also possible to consider connections between data files from different sources at other levels, for example, a file hierarchy in which a first subdirectory in a set of files refers to a subdirectory of a second set of data files, and so on. As with the DIR root directory AO for operator A, the DIR BO root directory indicated at 78 includes one or more cumulative routing key values 84 associated with its associated subdirectories (not shown), a key number 85 that identifies the public key of the operator B to be used in the verification step and a signature value 86 generated by the private key of. corresponding operator. An address calculation value for this directory is calculated by using the routing calculation value 84 and the signature 86 in the directory subheader as well as the payload data 64 of directory 78. This calculation value is then stored of address in the subdirectory A4, allowing by the same a verification of the integrity of the data in the table of the directory that is going to be carried out. It is assumed that because of the fact that the signature 86 and the address calculation values 84 are included in the calculation of-1 address calculation value 83, the integrity of the rest of the data files to which the root directory 78 are included in the calculation of the routing calculation value 83, you can also assume the integrity of the rest of the data files to which the directory rias refers, since none of these subordinate files can be changed without changing the address calculation value 84 and, more importantly, the signature value 86. Since the signature value 86 is only calculable by a person possessing the operator's private key, the integrity of all the files to the that directory 78 refers to, if it is assumed that the corresponding routing calculation values were calculated for additional subordinate subdirectories and object files. you. In this way, application data relating to executable or similar programs generated by a second operator with applications associated with a first operator can be interleaved in a reliable and secure manner. As will be noted, a number of variations are possible, notably to reduce the amount of address or signature calculation data in each stage. In particular, in the case of a signature or address calculation value in a directory or subdirectory used to verify a data file of a lower level, the address signature or address calculation value can be generated by using only the calculation value of lower level addressing and no other data. For example, the combined address calculation value 79 can be generated in the AO of directory 75 by using the combined address calculation values 82, 83 of each of the subdirectories A1-A4 indicated in 76. Since these values are as unique as the data in the payloads of the subdirectory, the combined address calculation value 79 will remain unique to the subdirectories in question. further, the integrity of the lower level of the object and of the directory files 77, 78 can still be assumed since the address calculation values 82 are still used in the calculation. Similarly, the computed address calculation value 82 can be calculated to verify the directory BO indicated at 78 simply by using the signature value 86. Since the above depends on and is uniquely associated with the address calculation values 84, the address calculation values depend in turn on the next level of files, the integrity of all the data file sets referred to in the directory can still be assumed.

Claims (26)

1. A method of authenticating data sent in a digital transmission system characterized by the organization of the data before transmitting in a hierarchy of at least one root directory unit, a subdirectory unit and a file unit, the data in a file on which is acted by means of an authentication algorithm and an associated file authentication value stored in the referred subdirectory, this authentication value file on which in turn acts by means of an authentication algorithm and a value of authentication of an associated subdirectory stored in the root directory to which it refers.

2. A method as claimed in claim 1, wherein the authentication of the file data is carried out by means of applying a routing calculation algorithm to part of, or to all the data in the file, the value of Resulting address calculation being stored as the authentication value of the file in the subdirectory to which it refers.

3. A method as claimed in claim 1, wherein the addressing calculation algorithm corresponds to a cryptographically secure algorithm, which generates a substantially unique addressing value from a given set of data.

4. A method as claimed in any of the preceding claims, wherein the authentication of the file data for a plurality of files is carried out by means of applying a routing calculation algorithm to a data accumulation of a plurality of files to generate a single address calculation value.

A method as claimed in any one of the preceding claims, wherein the authentication of a subdirectory is carried out by means of applying a routing calculation algorithm to at least one file authentication value, the calculation value of resulting addressing being stored as a subdirectory of authentication value in the root directory to which it refers.

6. A method as claimed in any one of the preceding claims, wherein the authentication of a plurality of subdirectories is carried out by means of applying a routing calculation algorithm to an accumulation of file authentication values from a plurality. of subdirectories to generate a single routing calculation value.

7. A method as claimed in any of the preceding claims, on which at least part of the data stored in the root directory is acted upon by means of a secret key of a cryptographic algorithm and the resulting cryptographic value, stored in the directory root.

8. A method as claimed in claim 7, wherein the cryptographic data corresponds to a digital signature generated by using a private key of a cryptographic algorithm, the signature that can be verified by the use of a key corresponding public

9. A method as claimed in any of the preceding claims, wherein a referred unit includes a cryptographic value, generated by a secret key, an authentication value for this module that is calculated based on the results of an algorithm of authentication in the cryptographic value and stored in the reference unit.

10. A method as claimed in claim 9, wherein a signature value is generated for the unit referred to by means of a cryptographic algorithm, the signature value on which it is acting by means of a calculation algorithm of addressing to generate the authentication value.

11. A method as claimed in claim 9 or 10, wherein the unit to which it refers is a subdirectory or file unit.

12. A method as claimed in claim 9 or 10, in which the referred unit is a second root directory module.

A method as claimed in any of the preceding claims, wherein the units correspond to a set of data files, the data files that are encapsulated in tables or data sections, these tables being encapsulated thereafter in data packets to form a transport flow.

A method as claimed in claim 13, wherein the units correspond to formatted data objects as claimed in the DSMCC standard.

15. A method as claimed in claim 13 or 14 wherein the units are encapsulated in tables and packets as claimed in the MPEG standard.

16. An authentication method of a first and a second set of linked data units, sent in a digital transmission system, characterized in that one of the first set of units includes a signature generated by means of a secret key that acts on that first unit, at least this signature value being authenticated by an authentication algorithm, and the authentication value being stored in a unit in the second set of units that refers to that first unit.

17. A method as claimed in claim 16, wherein the cryptographic value corresponds to a digital signature generated by means of a secret key that acts on at least some of the data in that unit.

18. A method as claimed in claims 16 and 17, wherein the data units correspond to a set of data files encapsulated in tables or sections of data, these tables being subsequently encapsulated in data packets, to form a transport flow.

19. A method of authenticating data sent in a digital transmission system, characterized in that the data is organized in a series of data files, the authentication being performed between files, regardless of, and before the formatting stage or stages and data encapsulation using the digital transmission system, to prepare the data for transmission in a packet transport stream.

20. A method as claimed in claim 19, wherein the authentication of the data is performed before the encapsulation of data in a series of tables, these tables being subsequently encapsulated in data packets in the transport packet flow.

21. A method as claimed in any of the preceding claims, wherein the digital transmission system corresponds to a digital television system.

A method of verifying data received, sent in a digital transmission system, according to any of claims 1 to 15, wherein a receiver decoder acts on the data in a file with an authentication algorithm, and compares the resulting value with the authentication value stored in the reference subdirectory, and also acts on at least the authentication value of the file stored in the subdirectory with an authentication algorithm, and compares the subsequent resulting value with the authentication value of the subdirectory associated, stored in the reference root directory.

23. A method of verifying data received, sent in a digital transmission system, according to any of claims 16 to 18, wherein a decoder verifies the signature value in the first unit, using an associated public key, and also verifies the authentication value stored in the unit, in the second set of modules, using an authentication algorithm that acts on at least the signature value.

24. A method of verifying data received, sent in a digital transmission system, according to any one of claims 19 to 21, wherein the data verification step is performed after the data has been reassembled. data of the file by means of the decoder, from the encapsulated and formatted data transmitted by the digital transmission system.

25. A method of authenticating data sent in a digital transmission system, substantially as described herein.

26. A method of verifying data received, sent in a digital transmission system, substantially as described herein.