0001 The present invention pertains to the secure protection and identification of messages on a network, as well as to corresponding devices. 0002 In order to secure the flow of messages on an unsecure network, whether this flow be achieved in particular by radio broadcasting, by cable or by internet network, it is conventional to use enciphering keys, also referred to as encryption keys. In general, the sender of the messages is furnished with such an enciphering key and the receiver, with a corresponding identification key. The keys may be private or public, depending on the applications envisaged. For example, a sender uses a key pair, of which he broadcasts a public enciphering key making it possible to encipher messages and keeps for himself just a private deciphering key. 0003 Enciphering of messages has two main types of applications: 0004 message authentication, for which the results of the enciphering are incorporated into the messages in the form of a signature; the identification key can then be either a deciphering key or an enciphering key; 0005 message encryption, for which the results of the enciphering replace portions of the enciphered message; the identification key is then a deciphering key. 0006 In both these types of applications, it is advisable to minimize the risks of interception and of fraudulent deciphering of the messages by a third party, or of falsification by the fraudulent affixing of a signature. Several systems have therefore been proposed in order to complicate the possibilities of unauthorized enciphering or deciphering. 0007 Thus, techniques have been developed for enabling the regular modification of the corresponding enciphering and identification keys. Some of these techniques rely on the despatching of new identification keys across the communication network, while making it difficult to recognize these keys (for example by encrypting the keys), in particular when the latter are private keys. However, these techniques are vulnerable to interception of the keys despatched and to their use, despite the precautions taken. Moreover, with each despatch of a new key, they require the recognition and the installation of the latter by the receiver, this possibly being detrimental to the efficiency of the latter. 0008 Document EP-0,506,637 describes a system for the validation and verification of mobile stations of a cellular radio communications network. The system includes a fixed key and a modifiable key which is referred to as a rolling key, both in the network and in the mobile stations. These keys are applied as inputs to an authentication algorithm and a comparison of the responses generated by the network and in each mobile station makes it possible to pinpoint frauds. The rolling key is updated simultaneously in the network and the mobile station upon each bilateral authentication, as a function of historical authentication information common to both. 0009 The security of exchanges can thus be enhanced, since the keys are regularly modified without travelling through the network. However, a drawback of such a system is that it requires a calculation of a new rolling key upon each bilateral authentication. Moreover, problems of asynchronism might arise in the presence of a technical malfunction and might thus render the authentication unusable. To remedy this, specific mechanisms have to be built in, thereby complicating the systems and running the risk of reducing the reliability of the authentication. 0010 U.S. Pat. No. 6,105,133 discloses a bilateral system for the authentication and encryption of sending/receiving stations. The exchanges between any two of the stations are securely protected by authentication and encryption, and by the use of an enciphering key modified upon each connection between these stations. This key is calculated independently in each of the stations, on the basis of the identifier of the other station, of parameters recorded in a fixed manner in both stations and of a change value communicated from one station to the other. 0011 This technique enhances the reliability of the system by allowing frequent modification of the enciphering key, avoiding the transfer of this key over the network and ensuring synchronization of the key updates in the sending and receiving stations. At each update however, it requires the calculation of a new key in the sender and in the receiver. The times required for these calculations could jeopardize the operations to be performed rapidly after the reception of the messages. In particular, these times are the cause of malfunctioning when the messages to be decrypted and/or authenticated are followed by other messages whose processing requires a knowledge of the earlier messages, and when the time span between the earlier messages and the later messages is insufficient to acquire this knowledge. 0012 U.S. Pat. No. 5,301,233 discloses a process for the transmission and reception of personalized programs. Each program consists of encrypted elements and contains for each of its elements, an identifier of the intended receiver. Only the latter is authorized to access the corresponding elements. An access control message allows the receiver to reconstruct a control word used for the encryption of the elements intended therefor. This message contains in particular a service key identifier and optionally a signature obtained using the identified service key. This possible signature, applied to the control word, makes it possible to be sure of the validity of this word and to ignore the program received should the response be negative. The key identification technique, not specified, relies on a batch of information for key generation, this batch being contained in the key identifier, the latter extending for example over three bytes for a signature on eight bytes (col. 5, 1.42-52). 0013 U.S. Pat. No. 5,222,137 relates to the dynamic selection of encryption keys for encrypted radio transmissions. During operation, a radio having key identifiers and corresponding keys communicates with other identical radios. It transmits and receives encrypted signals comprising unencrypted key identifiers. Before each transmission, the sending radio automatically selects one of the key identifiers and uses the corresponding encryption key to encrypt the message to be transmitted. The receiving radios determine the encryption key used, by means of the key identifier received, and use it to decrypt the message. The level of security is thus enhanced, since this method makes it possible to ensure dynamic protection of the contents by enabling modification of the key used upon each despatch. 0014 However, it requires sufficient operational volume and memory space to process each of the messages received. In cases where the information must be rapidly available and where the size of the messages may be substantial, in particular for the despatching of services to individual receivers, this situation might cause delays, or even the triggering of memory wiping mechanisms which may lead to losses of information. 0015 The present invention relates to a security device for protecting messages intended to be despatched over a network and relying on the 0016 Document WO-00/79734 concerns a system and method for receiving over a network a broadcast from a broadcast source. There is notably disclosed an announcement containing a session description and optionally an authentication header, the session announcement being preferably provided with an authentication and integrity part. 0017 No specific mechanism is specified for improving the enciphering and authentication reliability. 0018 The article A Security Analysis of the NTP Protocol Version 2 by Matt Bishop, Computer Security Applications Conference, 1990, Proceedings of the sixth annual Tucson, Ariz., USA 3-7 Dec. 1990, IEEE Comput. Soc., US, 3 Dec. 1990, pp. 20-29, ISBN: 0-8186-2105-2, relates to a process for providing accurate time service on the Internet through the Network Time Protocol (NTP), and discloses in particular suited security mechanisms. Notably, origin authentication and packet integrity mechanism is described. According to it, the synchronization messages that are sent in the network from a peer sender to a peer receiver may include indices that reference authentication keys and algorithms, when an authentication mode is chosen. Each peer is associated to a unique key or none. The peer sender is then intended to use either that given key in determined cases, or the key of the receiving peer in other determined cases, or otherwise a given default key if the active peer's key is not available. 0019 That predetermined key change method is quite relevant for synchronization on the Internet, but lacks flexibility in other situations, notably for broadcasting messages. 0020 The patent application WO98/43431 discloses a method for downloading data from various sources to an MPEG receiver/decoder, in which interactive applications can be downloaded and run thereon. The application code is arranged as modules for each application and the preliminary sending of a directory table enables to specify table identifiers of the modules. That directory table also comprises en encrypted signature, as well as a key identifier corresponding to a private key used by the involved sending source for encrypting the signature. As multiple public encryption keys are stored in the receiver/decoder, the applications can thus be created by different sources. 0021 This disclosure is interesting for flexibly adapting receivers to multiple sources for authentication of the received messages. However, no mechanism is provided for improving the authentication reliability for each of those sources. use of a modifiable enciphering key, the security device making it possible to modify this key without having to make it travel via the network, to synchronize the updates of keys in the sender and the receiver of the messages, and to perform the changes of keys very rapidly, while also making it possible to avoid delays or detrimental memory space requirements. 0022 Moreover, the device of the invention can be implemented in an economical manner, without calling upon sophisticated algorithms for updating keys. 0023 The invention also relates to a device for identifying messages received via a network, making it possible to obtain the advantages mentioned above. 0024 The invention also applies to a sender of messages comprising one or more security devices according to the invention, to a receiver of messages comprising one or more identification devices according to the invention and to a computer program product, a message and corresponding security and identification processes. 0025 In what follows, the following designations are employed: 0026 authentication, a procedure relating to a guarantee of origin and of integrity of messages travelling through a network, relying on the use of digital signatures contained in the messages and produced by means of keys before sending the messages, 0027 encryption, a procedure of substituting for a plain text, an unintelligible text which cannot be utilized as is, 0028 decryptlon, a procedure for replacing an encrypted text with a plain text, obtained by returning the encrypted text to its initial form, 0029 enciphering, a procedure for determining an encrypted text from a message or from a portion of a message, this encrypted text being used either as replacement for a plain text (encryption), or as a signature (authentication), 0030 decipherment, a procedure for at least partial reconstruction of a plain text from an encrypted text, either for attesting the origin and the integrity of the message containing the text (authentication), or for replacing the encrypted text with the plain text (decryption), 0031 securing, a procedure for enciphering a message or a part of a message, for authentication or encryption purposes, 0032 identification, a procedure for using an encrypted text received in a message for identifying this message, either by its origin and its integrity (authentication), or by its content (decryption); 0033 The invention applies generally to security processes using electronic signature/authentication and/or or using encryption/decryption. It relies on the use of enciphering keys on transmission and on enciphering keys and/or deciphering keys on reception, deciphering keys being implemented for decryption and deciphering keys and/or enciphering keys being implemented for authentication. 0034 A favoured field of application of the invention is digital television, in particular for the broadcasting of audiovisual data, PSI (Program Specific Information), SI (Service Information), interactive data, signalling data or private data. Specifically, certain digital broadcasting networks and certain networks with return channels, in particular terrestrial and microwave frequency networks, are vulnerable to piracy, in particular to spoofing. Piracy may then consist in intercepting data, in modifying them and in broadcasting or injecting the modified data into the network. Especially useful applications relate to electronic commerce and home banking. 0035 For this purpose, the subject of the invention is a security device for protecting messages intended to be despatched over a network, to at least one receiver comprising means for control of identification of messages by a modifiable current identification key. That security device comprises: 0036 a unit for control of enciphering of at least a part of each of the messages by means of a modifiable current enciphering key, 0037 a unit for changing the current enciphering key, designed for selecting this key from a predetermined set of available enciphering keys, 0038 and a unit for registering in the message a key identifier, enabling the receiver to select the current identification key from a predetermined set of available identification keys corresponding to this predetermined set of the available enciphering keys, this key identifier enabling the receiver to modify the current identification key in such a way that this current identification key corresponds to the current enciphering key. 0039 According to the invention, security device comprises means of control of addition to each of the messages, of a signature consisting of a result of the enciphering of this part of the message by means of the current enciphering key, and the messages are service announcement messages. 0040 The expression service announcement message is understood to mean a message despatched upstream within the framework of a service, giving information and instructions relating to the subsequent despatching of one or more other messages of this service. These other messages are bearers of content (content messages) or of immediate-triggering instructions (triggers). In advantageous forms of embodiment, the service announcement message comprises a header in the SAP format (standing for Session Announcement Protocol) and a payload in the SDP format (standing for Session Description Protocol). 0041 The ATVEF specifications (that is to say according to the Advanced Television Enhancement Forum Standard) provide for the optional presence of an authentication field in the service announcement messages. 0042 As indicated above, the expression identification keys designates deciphering or enciphering keys which are associated respectively with enciphering keys used by the security device. For decryption, the set of identification keys is a set of deciphering keys, each deciphering key having the same length as the corresponding enciphering key used for the encryption. 0043 For authentication, this set consists of deciphering keys, enciphering keys or a combination of both types of keys, generated respectively from the corresponding enciphering keys on transmission. Each identification key, and most especially enciphering key, used by the receiver then preferably has a length which is substantially less than the corresponding enciphering key used by the security device to generate the signature. Specifically, it is not necessary to decrypt or to reconstruct the signature completely: a partial coincidence is sufficient to ensure the authenticity of the message. The authentication operations are thus simplified and, for the identification keys consisting of enciphering keys, the risks of fraudulent production of signatures are reduced by not broadcasting the complete enciphering keys used on transmission to the receivers. 0044 The despatching of a simple identifier is sufficient for obtaining precisely the desired identification key, in a quasi-instantaneous manner in the receiver. This result is achieved by virtue of a prior recording of two corresponding sets of available keys, respectively on transmission and on reception, and of the indexing of these keys. Unexpectedly, the protection of the information transmitted does not rely however on encryption of the content messages and the presence of one and the same set of keys in identical send/receive systems (radios), as in the prior document U.S. Pat. No. 5,222,137. The security device of the invention actually implements an authentication process applied to service announcement messages, between sending and receiving devices which can be totally dissymmetric. 0045 The device of the invention is all the more unexpected since the formats used in the world of interactive television, in particular for the ATVEF and MHP (Multimedia Home Platform) standards, do not support the possibility of integrating into the service announcement messages a key identifier making it possible to calculate the signature of the announcement message. Thus, in the example of ATVEF, the RFC (Request For Comment) document in progress regarding the Session Announcement Protocol, RFC 2974, stipulates that it is possible to sign the service announcement messages by calculating the signature on an announcement message devoid of any information relating to its authentication. 0046 The MHP standard specifies for its part the manner in which applications and broadcasting data are to be authenticated and the manner in which data transferred onto a return channel are to be protected. However, it does not provide for any authentication of signalling messages, the latter fulfilling the function of service announcement messages. 0047 The device of the invention therefore runs fundamentally counter to the received wisdom on the subject. 0048 This solution makes it possible to avoid at receiver level, needless allowance for messages of an announced service, of the content message or trigger type, when this service is not valid. The receivers are thus made less bulky and superfluous consumption of operations and memory space is pared, without compromising on the reliability and the security of the system. 0049 Moreover, the encryption of the content messages affords a further possibility, which may prove desirable in certain cases but which in most situations is not indispensable. Processing costs and memory space costs, not only in respect of unauthorized services (unauthenticated service announcement message) but also in respect of validated services, are then avoided in the absence of such encryption. 0050 The device of the invention authorizes a change of key upon the despatching of any message, or of any message of a given type. In a first form of indication of keys, the key identifier is adjoined to any message which may form the subject of a key modification. The key corresponding to this indicator on reception is then systematically selected on the basis of the identifier, and used for identification. In a second form of indication of keys, the key identifier is supplemented with a key modification binary indicator. On reception, the current identification key is then held in memory until the key change indicator signals a change of key. In a third form of identification of keys, the key identifier is specified only in the case of an actual change of key. Otherwise, the key identifier is replaced by a default value (for example 0), signalling that the key previously used is still valid. This third economical form is beneficial in cases of sending messages to a collection of receivers which are always listening for messages and do not miss any. It is applicable in particular in multicasting over the Web. 0051 The key identifier can be determined in various ways, both as regards the frequency of change and the key selection performed. Thus, in a first form of change, the key identifier is changed when requested by a user on transmission, who may thus determine both the occurrences of change and the new keys selected. In a second form of change, the key identifier is modified periodically, according to a period chosen by the user, and the new identifier is drawn randomly. In a third form of change, the identifier is modified according to a predetermined series of values, at instants which are chosen randomly but spaced apart by durations lying between a minimum duration and a maximum duration. In the second and the third forms of change, it is preferable for the user employing the system to be able to modify the current key in any way and at any moment. 0052 The keys on transmission and on reception can be private or public. Preferably, the keys on transmission are private, so as to guarantee the identity of the sending party, the keys on reception advantageously being public. Additionally, in the case of supplementary security using encryption of subsequent content messages of the service, the keys on reception for this encryption are advantageously private, so as to guarantee the confidentiality of the messages. 0053 Advantageously, the enciphering control unit calls upon an enciphering library in which the available enciphering keys are stored. 0054 The predetermined set of available identification keys is advantageously a set of deciphering keys. 0055 Moreover, preferably, the part of the message to be enciphered consists of the message in full minus signature, including the key identifier. Thus, authentication pertains not only to the identity of the sending party and the payload of the message, but more generally to all the information contained in the message, including to the choice of the identification key and to any operating parameters at receiver level. 0056 In an advantageous form of embodiment, the security device of the invention is able to encrypt the messages, this functionality being applied preferably to the content messages following the authenticated service announcement messages. It is then beneficial for the encryption key to be identified according to a mode similar to that employed for the authentication of the service announcement messages. Preferably, each of the messages to be encrypted comprising a header and a payload, the enciphering control unit is designed to control: 0057 an enciphering of the part of the message to be encrypted by a current encryption key, this part comprising at least a portion of the payload, 0058 and a replacement in the message of this part by encrypted information consisting of a result of the enciphering of this part by means of the current encryption key. 0059 In a variant of this form of embodiment, a two-level enciphering of the messages of the service to be encrypted, which follow the authenticated service announcement messages, is produced in the following way: 0060 encryption with a current encryption key selected from a first set of available keys, 0061 then signature with a current authentication key selected from a second set of available keys, the enciphering for authentication being preferably applied to the whole message minus signature, including the encrypted part. 0062 According to a preferred form of application, the service announcement messages are chosen at least from among ATVEF announcement messages and/or system announcement messages. 0063 Each ATVEF announcement message of a service is followed by at least one HTTP (according to the HyperText Transfer Protocol method) content message then by one or more service triggers. The system announcement messages of a service, generally private and multicast, are for their part followed by a binary file of the service. The latter announcement messages advantageously have a form similar to that of the ATVEF announcement messages. A detailed description pertaining to the use of service announcement messages other than ATVEF announcement messages will be found in the European patent application filed on 23 Oct. 2000 under the filing number 00402921.1 and its PCT extension under the filing number EP/01/12333. 0064 Each of the service announcement messages having an authentication field of variable length, the registering unit is preferably designed to register the key identifier in this authentication field. This embodiment is advantageous through its simplicity, since it allows very flexible utilization of a field already provided in the service announcement message, without having to add a specific field. 0065 In a preferred form of application other than ATVEF and system announcement messages, the service announcement messages are chosen at least from among MHP signalling messages. 0066 According to a first mode of recognition of keys, each of the key identifiers is associated with a determined one of the available enciphering keys and with a determined one of the available identification keys corresponding to this enciphering key. 0067 The key to be used on reception is therefore given in a one-to-one manner by the key identifier selected. This embodiment allows rapid success in guaranteeing the origin and integrity of the message. 0068 According to a second mode of recognition of keys, each of the key identifiers is associated with a determined block of enciphering keys from among the set of available enciphering keys and with a determined block of identification keys corresponding respectively to the enciphering keys, from among the set of available identification keys. 0069 The key identifier selected does therefore not allow the receiver to know immediately the identification key to be used. It has to carry out successive tests with the various keys of the intended block, until the appropriate one is reached. This mode of embodiment therefore offers additional protection against piracy, at the cost of increased complexity and increased duration of authentication or decryption. 0070 Advantageously, the registering unit is designed to choose the key identifier from among a number of values (possibly corresponding to keys or to blocks of keys) lying between 8 and 12, and preferably equal to 10. In other embodiments ensuring enhanced security, this number of values equals 256 (coding of the identifier on one byte) or even 65536 (coding on two bytes). 0071 Additionally, the keys on transmission and on reception may preferably be updated. For example, the set of identification keys is designed to be modified remotely, by connection of the receivers to servers, identification of the receivers and secure recovery of a table of identification keys via the network. 0072 The invention also applies to a sender of messages. According to the invention, the latter comprises at least one security device in accordance with any one of the modes of embodiment of the invention, this sender being preferably designed to send the messages by broadcasting. 0073 The expression broadcasting designates the transmission of identical data to a collection of destinations, whether this be performed in particular by radio broadcasting, by cable or by Internet. 0074 The invention also relates to a device for identifying messages received via a network, each of the messages including a part enciphered by means of a modifiable current enciphering key. This identification device comprises: 0075 a unit for control of identification of the enciphered part, by means of a modifiable current identification key, 0076 and a unit for extracting from this message a key identifier, enabling the current identification key to be selected from a predetermined set of available identification keys corresponding to a predetermined set of available enciphering keys in such a way that this current identification key corresponds to the current enciphering key. 0077 According to the invention, identification control unit is a unit for control of authentication of the enciphered part, this enciphered part being a current signature, and the messages are service announcement messages. 0078 This device for identifying messages is preferably capable of identifying the messages securely protected by means of any one of the modes of embodiment of a security device in accordance with the invention. 0079 The invention also applies to a receiver of messages. According to the invention, this receiver comprises at least one identification device in accordance with any one of the modes of embodiment according to the invention. Furthermore, this receiver is preferably designed to receive the messages originating from a sender of messages in accordance with the invention. 0080 The subject of the invention is also a computer program product. According to the invention, this product comprises functionalities for implementing the units of the security device for protecting messages or of the device for identifying messages, in accordance with any one of the modes of embodiment of the invention. 0081 The expression computer program product is understood to mean a computer program medium, which may consist not only of a storage space containing the program, such as a disc or a cassette, but also of a signal, such as an electrical or optical signal. 0082 The invention pertains moreover to a message intended to be despatched over a network to at least one receiver. This message includes: 0083 at least one part enciphered by means of respectively at least one modifiable current enciphering key, 0084 and at least one key identifier, respectively enabling the current identification keys to be selected from predetermined sets of available identification keys, the current identification keys making it possible to identify the enciphered parts respectively. 0085 According to the invention, the enciphered part is a signature and the message is a service announcement message. 0086 This message is preferably obtained by means of a security device for protecting messages and is preferably intended for a device for identifying messages in accordance with any one of the modes of embodiment of the invention. 0087 Another aspect of the invention is a security process for protecting messages intended to be despatched over a network, to at least one receiver comprising means for control of identification by a modifiable current identification key. The security comprises: 0088 a step of selecting a current enciphering key from at least one predetermined set of available enciphering keys, making it possible to encipher at least part of each of the messages, 0089 a step of registering in this message a key identifier, enabling the receiver to select the current identification key from a predetermined set of available identification keys corresponding to the predetermined set of available enciphering keys, this key identifier enabling the receiver to modify the current identification key in such a way that this current identification key corresponds to the current enciphering key, 0090 and a step of enciphering the part of the message to be enciphered by means of the current enciphering key. 0091 According to the invention, the enciphering step consists in producing a signature of this part and the messages are service announcement messages. 0092 This security process for protecting messages is preferably implemented by means of a security device for protecting messages in accordance with any one of the modes of embodiment of the invention. 0093 The invention also pertains to a process for identifying messages received via a network, each of these messages including a part enciphered by means of a modifiable current enciphering key. This identification process comprises: 0094 a step of extracting from this message a key identifier, by means of which a current identification key is selected from a predetermined set of available identification keys, the current identification key corresponding to the current enciphering key, 0095 and a step of identifying the enciphered part by means of the current identification key. 0096 According to the invention, the enciphered part is a signature and the messages are service announcement messages. 0097 This process for identifying messages is preferably implemented by means of a device for identifying messages in accordance with any one of the modes of embodiment of the invention.

0098 The invention will be better understood and illustrated by means of the following exemplary embodiments and implementations, which are in no way limiting, with reference to the appended figures in which: 0099 FIG. 1 is a basic diagram showing a sender and a receiver of messages in accordance with the invention, implementing a first form of selection of the keys; 0100 FIG. 2 represents in greater detail a first mode of embodiment of the sender of FIG. 1, usable for authentication; 0101 FIG. 3 illustrates the content of an ATVEF service announcement message containing an authentication field, which is despatched by the sender of FIG. 2; 0102 FIG. 4 details the content of the authentication field of FIG. 3; 0103 FIG. 5 illustrates the content of an intermediate version of the message produced by the sender of FIG. 2, with filling-in of the authentication field; 0104 FIG. 6 shows sets of broadcasters of the radiobroadcasting type, controlled by a central server, involving senders in accordance with that of FIG. 2; 0105 FIG. 7 represents in greater detail a first mode of embodiment of the receiver of FIG. 1, usable for authentication of ATVEF service messages in combination with the sender of FIG. 2, but also in particular for the authentication of system service messages and for decryption; 0106 FIG. 8 represents in greater detail a second mode of embodiment of the sender of FIG. 1, usable for combined encryption and authentication; 0107 FIG. 9 illustrates the content of an ATVEF service announcement message containing an authentication field and an encryption field, which is despatched by the sender of FIG. 8; 0108 FIG. 10 diagrammatically shows a signature library implementing a second form of selecting the keys, with blocks of keys, which is used as a variant in the sender of FIG. 1; 0109 FIG. 11 diagrammatically shows an authentication library with blocks of keys corresponding to the library of FIG. 10, used as a variant in the receiver of FIG. 1; 0110 FIG. 12 illustrates the content of a variant of an ATVEF service announcement message containing an authentication field, which is despatched by the sender of FIG. 2; 0111 and FIG. 13 details the content of the authentication field of FIG. 12.

0112 The figures are regarded as forming an integral part of the disclosure. 0113 In the figures, identical or similar elements are designated by the same references. Moreover, the functional entities described and illustrated do not necessarily correspond to physically distinct entities of the systems, but may for example consist of functionalities of one and the same piece of software or of circuits of one and the same component. 0114 In FIGS. 3 to 5, 9, 12 and 13, the numbers indicated give, in bits, the distributions of fields in the messages represented. Moreover, the suffixes A and C are used to designate authentication entities, the suffix B for encryption entities and the suffix A for authentication entities after encryption. 0115 A send and receive assembly comprises (FIG. 1) one or more senders 1 of MSG messages via a network 5 to one or more receivers 2. In the example detailed below, the network 5 is a broadcasting unidirectional transmission network and we concentrate on a broadcasting server (associated with the sender 1) sending to a plurality of customers (associated respectively with the receivers 2). For simplicity, we concentrate on just one of the senders 1 and one of the receivers 2. 0116 Very diagrammatically, the sender 1 is provided so as to receive a message M0 and transform it into the message MSG to be sent, by adding various items of information intended for transfer over the network 5 and for the reading of the message MSG and of possible subsequent messages by the appropriate receivers 2. Correspondingly, the receiver 2 is provided to extract from the message MSG received the meaningful content represented by the message M0. The message M0 is preferably a message of a particular type (service announcement message), as detailed further below, the sender 1 and the receiver 2 not processing all the types of messages in the same way. 0117 The sender 1 comprises in particular (FIG. 1) various elements intended for this transformation of the message M0, such as in particular: 0118 a unit 14 for registering permissions, which is designed to insert permission identifiers PERM into the messages M0; these identifiers PERM make it possible to transmit control instructions to the receiver 2 for access to various functionalities of the latter; 0119 a device 3 for securely protecting messages, for defining judicious modes of enciphering (signature or encryption) of at least a part of the message M0, for triggering this enciphering and inserting information for utilizing the enciphered parts, intended for the receiver 2, into the message M0; in the example chosen, the registration unit 14 is upstream of the security device 3, in the sender 1; as variants, their positions are reversed, or at least one of these two subassemblies is upstream of the sender 1; 0120 and an enciphering library 15, for example a library of dynamic links or DLL (Dynamic Link Library), comprising an enciphering module 17; by convention, this library 15 is allocated to the sender 1, although in practice it may be a program simply accessible by the sender in the strict sense. 0121 More precisely, the enciphering library 15 is furnished with an indexed table 16 of enciphering keys K1, K2 . . . Kn, the enciphering module 17 being designed to perform the enciphering according to one of the enciphering keys Ki, as a function of instructions given by the security device for protecting messages 3. Moreover, the latter comprises: 0122 an enciphering control unit 11, capable of triggering the enciphering module 17 by communicating the necessary information thereto, in particular regarding the choice of the enciphering key Ki to be used; 0123 a unit 12 for changing current key, making it possible to modify the current key Ki to be used by despatching corresponding information to the enciphering control unit 11; this unit 12 relies for example on random (both as regards the occurrences and the chosen values) modifications of the current key Ki, with possibility of direct intervention by a user; 0124 and a unit 13 for registering in the message M0 a key identifier KeyID, making it possible to indicate for the attention of the receiver 2 the current enciphering key Ki chosen; in the example presented, this registration unit 13 routinely performs the recording of the key identifier KeyID in the messages M0 of the type concerned. 0125 Similarly, the receiver 2 comprises in particular: 0126 a unit 24 for reading the permission identifiers PERM in the message MSG received; 0127 a device 4 for identifying messages, for defining the relevant modes of identification (by deciphering/enciphering for authentication or decryption) of the enciphered part of the message MSG and for triggering this identification; 0128 and an identification library 25 comprising an identification module 27 and allocated by convention to the receiver 2. 0129 More precisely, the identification library 25 is furnished with an indexed table 26 of identification keys K1, K2 . . . Kn, corresponding one by one to the enciphering keys K1, K2 . . . Kn of the enciphering library 15. The identification module 27 is designed to perform the identification according to one of the identification keys Ki, as a function of instructions given by the message identification device 4. Moreover, the latter comprises: 0130 an identification control unit 21, capable of triggering the identification module 27 by communicating the necessary information thereto, in particular regarding the choice of the identification key Ki to be used; 0131 and a unit 23 for extracting from the message MSG the key identifier KeyID, giving the current identification key Ki chosen in correspondence with the current enciphering key Ki of the sender 2. 0132 The succinct account given above is essentially functional, and it is exclusively centred around specific features in conjunction with a particular assembly for securely protecting and identifying messages. The sender 1 can in reality comprise several security devices such as that referenced 15, possibly in combination. For example, the secure protecting of the messages combines encryption and signature, and/or distinct devices are applied respectively to various types of message. Similarly, the receiver 2 can comprise several identification devices. Such possibilities will become more clearly apparent in the light of the examples hereinbelow of particular embodiments. 0133 A first mode of embodiment of the sender 1, referenced 1A (FIG. 2), is applied to authentication. In this embodiment, the sender 1A subjects only the service announcement messages M0 to the operations for securely protecting and registering the permission identifiers PERM, the other types of message (such as content messages and triggers) not being subjected thereto. The service announcement messages under consideration are by way of illustration ATVEF announcement messages or system announcement messages, these two types of message having a similar structure in the examples under consideration. The messages MSG produced, denoted MSG-A, are subjected to broadcasting via the network 5. 0134 In the example set forth, the enciphering keys Ki (signature keys) are moreover private keys, and the identification keys Ki (authentication keys) public keys which may be distributed to the customers, including possibly via the network 5 (transmission is then preferably securely protected). By way of more specific example, the signature keys Ki have 596 bytes each and the identification keys Ki are deciphering keys of 148 bytes each, these keys being created respectively from the signature keys Ki and transferred so as to reside at the customers' premises. The indexed tables 16 and 26 of respectively signature and authentication keys each comprise for example 10 corresponding keys. 0135 The sender 1A essentially comprises: 0136 a server drive system 31, referenced 31A, including the unit 12 for changing current key, the unit 13 for registering the key identifier KeyID and the unit 14 for registering the permission identifiers PERM; this drive system 31A is designed to receive the message M0 from an information source 10 and to produce a message M1, containing the key identifier KeyID for authentication, denoted KeyIDSGN, and the permission identifiers PERM but without signature; 0137 a broadcasting server 32A comprising in particular a control unit 37 controlling the operation of all of the elements of the server 32A (links not represented in FIG. 2 for simplicity) and a database 33 designed to gather the messages M1 originating from the drive system 31A; this broadcasting server 32A is intended to transform the message M1 into the message MSG-A; 0138 and the enciphering library 15, in the form of an authentication library 15A. 0139 The broadcasting server 32A also comprises two modules acting successively on the message M1: a completion module 35 and an encapsulation module 36. The completion module 35, which contains the enciphering control unit 11 in the form of an authentication control unit 11A, is responsible for registering complementary information (Internet addresses, ports, etc.) in the message M1 so as to produce a message M2, and for calling upon the authentication library 15A so as to produce a signature SGN and integrate it into the message M2, thus producing a message M3. The presence of the authentication key identifier KeyIDSGN in the message M2 despatched to the library 15A allows the latter to select the desired key Ki immediately so as to generate the signature SGN. Advantageously, the current enciphering key Ki is held in memory in the library 15A. 0140 The subcontracting by the broadcasting server 32A of the signature to the library 15A, as well as the possible recording of the current key Ki in the library 15A rather than in the server 32A, allow the latter to retain a character of a general nature. What is more, they allow the drive system 31A and the library 15A to retain together control of the operations relating to the key identifiers KeyIDSGN and permission identifiers PERM. Moreover, the addition of the signature SGN at the end of the chain, just before broadcasting by the broadcasting server 32A, is beneficial since the latter can thus be fed by numerous customers without it being necessary to duplicate the signature library 15A and the enciphering keys Ki, and since the modification of the key identifier KeyIDSGN can be centralized. Furthermore, in case of compression and/or encryption, the signature is effected after these operations. 0141 The signature SGN is calculated preferably over the whole of the announcement message M2, including the header (which contains in particular the identifiers KeyIDSGN and PERM) and the payload, thus making it possible in particular to detect any external modification of the data relating to the current signature key KeyIDSGN (hence for authentication by the customers) and to the permissions. 0142 The encapsulation module 36 is intended to transform the announcement message M3 by chopping and addition of layers for transport over the network 5. In the example presented, the module 36 generates IP (Internet Protocol) packets with UDP (Unidirectional Data Protocol)/IP/SLIP (Serial Line IP) layers. For content messages, the module 36 uses, beforehand, the UHTTP (Unidirectional HyperText Transfer Protocol) protocol and the MIME (Multipurpose Internet Mail Extensions) format. 0143 The message MSG-A thus signed allows each of the customers to verify the authenticity of the services provided: if the customer recognizes the signature SGN as valid, he opens listening channels (sockets) for the content messages and possibly the triggers which have to follow. In the converse case, the customer declines to take the announcement message MSG-A into consideration. To authenticate the signature SGN, the customer uses the key identifier KeyIDSGN, which allows him immediately to select the appropriate identification key Ki from the corresponding identification library 25 (authentication library). He is thus able to decide rapidly whether to open the sockets or not and thus avoid missing out on all or some of the content packets arriving subsequently. For example, when a first content packet is broadcast 500 ms after the announcement message, it is absolutely essential for all the signature verification and socket opening operations to have been executed during this time span. 0144 A specific implementation of the sender 1A is illustrated hereinbelow. In this example, the announcement messages MSG-A of the ATVEF type are broadcast on a multicast IP address 224.0.1.113, port 2670, and those of the system type on a multicast IP address 235.0.1.113, port 32670. Each of the messages MSG-A (FIG. 3) consists of a header in the SAP format denoted SAP-A and a payload in the SDP format, the header SAP-A comprising the following fields: 0145 version V of SAP (3 bits, V1); 0146 ARTEC (5 bits) composed of 5 items: 0147 type of address A (0 for the IPv4 protocol, 1 for IPv6); 0148 reserved field R (0); 0149 type of message T (0 for a session announcement packet, 1 for a session erasure packet); 0150 encryption field E (for Encryption: 0 for SDP unencrypted, 1 for SDP encrypted); 0151 compression C (0 for uncompressed payload, 1 for compressed payload); 0152 length L-AUTH (unsigned value on 8 bits) of an authentication field AUTH referenced AUTH-A and inserted just before the SDP, and expressed as a number of 32-bit words; 0153 hash identifier (protection algorithm used by the Internet for digital signatures) MSG ID HASH (on 16 bits), the hash value having to change whenever a field of the SDP is modified; when this identifier equals 0, the customer must always subject the SDP to a syntactic analysis (parsing); 0154 IP address denoted ORIG (1 word of 32 bits) of the sender 1A, hence of the broadcasting server 32A; this address can be set to 0.0.0.0 for a zero value of the hash identifier and in the absence of passage through a mandatory server (proxy); 0155 and authentication field AUTH-A, whose length is determined by the parameter L-AUTH. 0156 The authentication field AUTH-A (FIG. 4) comprises not only a signature field SGN of 128 bytes (size chosen as a function of system limitation), but also a specific authentication header denoted ENT-A occupying four bytes, which includes the following subfields: 0157 version V of protocol used (3 bytes, V1); 0158 padding indicator P (1 bit), which serves to signal the presence of possible padding so as to culminate in an authentication field having a total length which is a multiple of double-words (32-bit words); in the present case, P0 (no padding) since the authentication field has a total length of 132 bytes; 0159 type of authentication used TYPE (4 bits); in this instance, TYPE0 (PGP format, standing for Pretty Good Privacy); 0160 PERM permission flags (8 bits); 0161 field reserved (8 bits) for future use; 0162 key identifier KeyIDSGN (8 bits). 0163 The header ENT-A therefore contains two bytes which are especially useful for the customers: those of the fields KeyIDSGN and PERM, which respectively allow the customers to immediately determine the correct authentication key Ki and to ascertain the appropriate permissions in respect of the subsequent messages of the service (content messages and triggers). 0164 In the example presented, the byte available for the permission flags PERM is utilized in the form of a mask of eight values. The permission flags PERM pertain to accesses to the following functionalities, relating to so-called critical resources of the receiver 2 (the authorization values are first given in hexadecimal notation): 0165 00001: access to a modem of the receiver 2 so as to initiate a connection to an online server of a service operator associated with the sender 1; 0166 00002: access to a modem of the receiver 2 so as to initiate a connection to an online server of any service operator; 0167 00004: use of a secure connection to an online server; 0168 00008: access to a hard disk of the receiver 2 so as to read data therefrom or write data thereto permanently; 0169 000010: access to a flash memory of the receiver 2 so as to read data therefrom or write data thereto permanently; 0170 000020: access to a chip card of the receiver 2 so as to read data therefrom or write data thereto permanently; 0171 000040: access to a tuner of the receiver 2 so as to modify a current station. 0172 In a variant embodiment, the byte available for the permissions is used in the form of a table with 256 entries, each of the entries corresponding to a unique permission level. As in the example above, eight permissions are obtained which can be combined with each other. 0173 The number of permissions can be extended without difficulty, in particular by incorporating the reserved field of one byte into the permission field (switch to sixteen permissions) and/or by allocating two double-words instead of one to the header ENT-A of the authentication field AUTH-A. 0174 During operation, the drive system 31 adds a header in the SAP format to the service announcement message M0, integrating therein in particular the permission flags PERM for this service and possibly a key identifier KeyIDSGN (the latter is configurable by the drive system 31, but by default, is determined by the library 15A). The length L-AUTH of the authentication field AUTH-A is fixed at one double-word (L-AUTH1), in such a way as to register the header ENT-A therein without the signature SGN. The message M1 obtained (FIG. 5) then contains in the authentication field AUTH1 (reduced to a header ENT1) of the header in the SAP format (denoted SAP1) only the permission flags PERM and a reserved field, initialized to zero. This message is received in the database 33 of the broadcasting server 32A. 0175 The completion module 35 then verifies whether the header SAP1 is present (if not, it adds it without signature), registers in M1 the complementary information required (so-called patch of the SDP with addresses and ports of the content messages and triggers), and calls upon the library 15A, passing as arguments a buffer memory containing the message M1 and a size of the buffer. 0176 The library 15A performs the following operations: 0177 verification of whether the permission flags PERM are present; if they are, normal continuation of operations; if they are not, return to the broadcasting server 32A with error code; in an improved version, should the permission flags PERM be absent, allocation of a default mask; 0178 verification of whether the service announcement message M1 is already signed; if it is, return to the broadcasting server 32A; 0179 if it is not, updating of the length L-AUTH to 132 bytes (021 double-words), addition and updating of the header ENT-A of the authentication field AUTH-A, calculation (with L-AUTH1) and addition into the buffer of the signature SGN and updating of the size of the buffer; the signature SGN is determined from the header SAP1 as a whole (not containing the signature field SGN, since L-AUTH1) and from the payload of the message M1; it is obtained by the RSA (RivestShamirAdleman) algorithm, by means of the calculation of a hash MD5 over this whole, of the recovery of the appropriate current signature key Ki and of the calculation of the RSA signature on hash with this key Ki; in a variant embodiment, the authentication field AUTH-A is totally ignored in respect of the signature (L-AUTH0 instead of a double-word); 0180 and return to the broadcasting server 32A. 0181 Next, the encapsulation module 36 encapsulates the message M3 thus obtained, before broadcasting over the network 5. 0182 With this technique, the signature is calculated just once per service (it is calculated on the announcement message), whether this service be despatched as a carousel or in one occurrence (one shot). 0183 To modify the key identifier KeyIDSGN, a message is for example despatched to the broadcasting server 32A across an interface for the programming of applications or API (Application and Programming Interface), the server 32A then merely notifying the library 15A of the new value of this identifierthe modification is for example performed routinely every month. 0184 In an illustrative example hereinbelow of service announcement messages at input (M1) and at output (MSG-A) of the broadcasting server 32A, the header SAP1 is indicated by bold characters between square brackets, the header (ENT1, ENT-A) of the authentication field (AUTH1, AUTH-A) being underlined, and the payload being indicated by normal characters (the notation is hexadecimal). 0185 The message M1, associated with L-AUTH001, PERM027 and with three reserved bytes equal to 000, is as follows: 100000000 2001 0000 53AA 0B8D 2700 0000 763D 300A...S......v0.00000010 6F3D 2D20 3935 3530 3035 3931 3320 3935o955005913 9500000020 3530 3035 3931 3320 494E 2049 5034 20315005913 IN IP4 100000030 3732 2E33 302E 3930 2E31 3630 0A73 3D6372.30.90.160.sc00000040 6D6F 6E63 686F 6978 0A65 3D64 7570 6F6Emonchoix.edupon00000050 7440 7468 6D75 6C74 692E 636F 6D0A 703Dtthmulti.com.p00000060 2B31 2D36 3537 2D34 3733 2D34 3833 300A1-657-473-4830.00000070 613D 6C61 6E67 3A65 6E0A 613D 7476 652Dalang:en.atve-00000080 656E 6473 3A33 3030 0A61 3D74 7665 2D74ends:300.atve-t00000090 7970 653A 7072 696D 6172 790A 613D 7476ype:primary.atv000000A0 652D 6964 3A64 3631 3633 6164 612D 3766e-id:d6163ada-7f000000B0 6164 2D33 6235 342D 6262 3839 2D66 3166ad-3b54-bb89-f1f000000C0 6161 3430 3736 6637 620A 613D 7476 652Daa4076f7b.atve-000000D0 7072 6F66 696C 653A 310A 743D 3020 300Aprofile:1.t0 0.000000E0 6D3D 6461 7461 2032 3238 3530 2074 7665mdata 22850 tve000000F0 2D74 7269 6767 6572 0A63 3D49 4E20 4950-trigger.cIN IP00000100 3420 3232 372E 3337 2E33 322E 3433 0A6D4 227.37.32.43.m00000110 3D64 6174 6120 3232 3835 3120 7476 652Ddata 22851 tve-00000120 6669 6C65 0A63 3D49 4E20 4950 3420 3232file.cIN IP4 2200000130 342E 3337 2E33 322E 3434 0A4.37.32.44.

0186 The message MSG-A obtained after processing of the message M0 by the broadcasting server 32A, associated with L-AUTH021, PERM027 and KeyID007, is as follows: 200000000 2021 0000 53AA 0B8D 2027 0007 6797 BE9E ..S.....g...00000010 7169 8F8D FDF1 B330 38FF 957C D0A2 B515qi.....08......00000020 1F98 DABC CB04 9F03 0EB8 3D27 E5AA 047A.............z00000030 35AF F2FF DC65 4F04 28E3 CA3F 948D 1D8A5....eO.(......00000040 4540 D763 DB68 3ADD CAEF 5EB1 4116 F939E.c.h:...{circumflex over ()}.A..900000050 7C29 862F E7B8 75C1 081C 3830 5A55 AEC2)./..u...80ZU..00000060 1031 62C0 E52D AC19 1CCF 7471 D28E 8997.1b..-....tq....00000070 7F46 9473 4F2A B5EF 8047 2DE9 87EF A49E.F.sO*...G-.....00000080 4E90 5DB7 0981 C001 DB17 F07F763D 300AN..........v0.00000090 6F3D 2D20 3935 3530 3035 3931 3320 3935o 955005913 95000000A0 3530 3035 3931 3320 494E 2049 5034 20315005913 IN IP4 1000000B0 3732 2E33 302E 3930 2E31 3630 0A73 3D6372.30.90.160.sc000000C0 6D6F 6E63 686F 6978 0A65 3064 7570 6F6Emonchoix.edupon000000D0 7440 7468 6D75 6C74 692E 636F 6D0A 703Dtthmulti.com.p000000E0 2B31 2D36 3537 2D34 3733 2D34 3833 300A1-657-473-4830.000000F0 613D 6C61 6E67 3A65 6E0A 613D 7476 652Dalang:en.atve-00000100 656E 6473 3A33 3030 0A61 3D74 7665 2D74ends:300.atve-t00000110 7970 653A 7072 696D 6172 790A 613D 7476ype:primary.atv00000120 652D 6964 3A64 3631 3633 6164 612D 3766e-id:d6163ada-7f00000130 6164 2D33 6235 342D 6262 3839 2D66 3166ad-3b54-bb89-flf00000140 6161 3430 3736 6637 620A 613D 7476 652Daa4076f7b.atve-00000150 7072 6F66 696C 653A 310A 743D 3020 300Aprofile:1.t0 0.00000160 6D3D 6461 7461 2032 3238 3530 2074 7665mdata 22850 tve00000170 2D74 7269 6767 6572 0A63 3D49 4E20 4950-trigger.cIN IP00000180 3420 3232 372E 3337 2E33 322E 3433 0A6D4 227.37.32.43.m00000190 3D64 6174 6120 3232 3835 3120 7476 652Ddata 22851 tve-000001A0 6669 6C65 0A63 3D49 4E20 4950 3420 3232file.cIN IP4 22000001B0 342E 3337 2E33 322E 3434 0A4.37.32.44.

0187 In a particular deployment of senders 1A (FIG. 6), a central drive system 40 of a service operator, comprising a central server 45, is connected to broadcasters 41, 42 and 43 via specialized links (leased lines) 46. 0188 Each of the broadcasters 41-43 comprises a broadcasting server 32, of the type of that 32A detailed hereinabove, as well as a device 47 for broadcasting audiovisual programmes and a VBI encoder referenced 48, responsible for encoding information originating from the server 32 and from the device 47 and for broadcasting it to the antenna 49. During operation, the central drive system 40 obtains from various sources (broadcasters, advertisers, content providers, etc.) information regarding services to be broadcast, programs their broadcasting and finally makes them available to the broadcasting server 32 slightly before their broadcasting. It guarantees in particular the authenticity of public keys through the delivery of digital certificates 51, 52 and 53 to the broadcasters 41 to 43 respectively. This central drive system 40 also fulfils the functions of the drive system 31 described above, so that the service announcement messages MSG broadcast by the broadcasters 41 to 43 can be selectively advised of the permissions and be signed by means of variable keys, without giving rise to adverse delays of authentication on reception. 0189 Each of the receivers 2 comprises in particular (FIG. 7): 0190 a VBI drive referenced 61, designed to extract a payload from information received from the senders 1A (such as the broadcasters 41 to 43) and comprising a field WST (World Standard Teletext), to calculate error control codes FEC (Forward Error Correction) and to control a decoding of SLIP frames of the payload; 0191 a module 62 for decapsulating layers for transport on the network 5, capable of receiving from the drive 61 the decoded SLIP frames and of extracting therefrom, after decoding, the content of the IP/UDP frames, in the form of a header in the SAP format and of a payload in the SDP format for the service announcement messages MSG; 0192 a browser 63, provided with an identification device 4 and with a permission reading unit 24 (referenced 4N and 24N respectively), of the type of those described above, 0193 a loader 67, provided with an identification device 4 and with an optional permission reading unit 24 (referenced 4C and 24C respectively), of the type of those described above, 0194 and an authentication library of the type of that referenced 25 described above; the indexed table 26 of keys is stored in a permanent memory of the receiver 2, for example of the flash memory type, in a code of the library 25. 0195 The browser 63 is designed to perform the following functions on receipt of each service announcement message MSG-A: 0196 recover the header and the payload of the message MSG-A via a listening socket 64; 0197 call a signature verification function in the library 25, by passing it as input a pointer to the message MSG-A; 0198 and should authentication succeed, open listening sockets 65 and 66 respectively for the content messages and the subsequent triggers, by applying the permissions indicated by the permission flags PERM of the message MSG-A so as to specify access to the functionalities of the browser 63 to be applied to the broadcast application. 0199 The library 25 signature verification function executes more precisely the following operations: 0200 calculation of a hash MD5 on the signatureless header SAP-A and payload as a whole, the indicator L-AUTH giving the length of the authentication field AUTH-A being set to 1; in a variant corresponding to that indicated for the signature calculation, the authentication field AUTH-A is ignored in respect of authentication, the indicator L-AUTH being set to 0; 0201 recovery of the key identifier KeyIDSGN in the authentication field AUTH-A of the header SAP-A and selection of the appropriate authentication key Ki; 0202 verification of the signature SGN of the authentication field AUTH-A, of the RSA type, by recalculation on the hash of the signature by means of the selected key Ki; should the signature be invalid, return of the value 0; 0203 if the signature SGN is valid, return of the permission flags PERM. 0204 Thus, the payload of the message MSG-A is ignored except in the case where authentication succeeds. In the converse case, no listening socket is opened for the subsequent messages of the service announced and the customer remains deaf to the data which arrive. 0205 The operation of the loader 67 is similar in respect of a system announcement message, received via a listening socket 68: a socket 69 is opened for subsequent content messages only if the message is authenticated, by means of a call to the library 25. 0206 A second mode of embodiment of the sender 1, referenced 1B (FIG. 8), is applied to a combination of encryption and authentication. This embodiment differs from the previous one essentially by the presence in the sender 1B of encryption elements, complementary to the signature elements and designed to act upstream of them. The encryption elements and those of the signature rely respectively on the selection of two current enciphering keys from two indexed tables 16 of keys (FIG. 1), and call respectively on an encryption library 15B and a signature library 15A, of the type of the enciphering library 15 described in a general manner above. The receiver 2 includes an indexed decryption table corresponding to the indexed table of encryption keys, these decryption keys being preferably private. The indexed encryption and decryption tables comprise for example 10 keys each. 0207 Thus, the drive system 31, referenced 31B, comprises both units 12 for changing current key and also devices 13 for securely protecting messages for he encryption (respectively 12B and 13B) and for signature after encryption (respectively 12A and 13A). 0208 Moreover, the broadcasting server 32, referenced 32B, comprises a completion and encryption module 34 including an encryption control unit 11B and a signature module 38 downstream of the module 34, including a signature control unit 11A, the control units 11B and 11A being of the type of the enciphering control unit 11. This server 32B integrates an authentication field AUTH, referenced AUTH-B, into the header in the SAP format, in a similar manner to the first mode of embodiment. 0209 The completion and encryption module 34 is responsible for adding complementary information required in the message M1 as in the previous mode of embodiment, and for calling on the encryption library 15B so as to encrypt the message M4 thus obtained, by transmitting an encryption key identifier KeyIDCRYPT thereto. The enciphering module 17 of the library 15B (FIG. 1) then carries out the encryption of the payload, but not of the initial data of the header or of the authentication field AUTH-B. The key identifier KeyIDCRYPT is for example generated randomly. 0210 The signature module 38 is designed to receive from the encryption library 15B a message M5 resulting from this encryption and comprising in particular an authentication key identifier KeyIDSGN, and to call on the signature library 15A so as to obtain a signed message M6. The enciphering module 17 of the library 15A (FIG. 1) determines and affixes a signature pertaining to the message M5 as a whole, by means of the current key given by the key identifier KeyIDSGN, as in the previous mode of embodiment. 0211 The encapsulation module 36 plays the same role as previously and makes it possible to obtain the message MSG to be broadcast, denoted MSG-B. 0212 By way of illustration (FIG. 9), the message MSG-B comprises, in addition to its payload, a header in the SAP format referenced SAP-B which is structured as follows: 0213 fields V, ARTEC, L-AUTH, MSG ID HASH and AUTH-B similar to those of the first mode of embodiment; 0214 encryption key identifier KeyIDCRYPT (1 double-word); 0215 indicator of time exceeded TIMEOUT (1 double-word), useful when the payload is encrypted and when the sending of the announcement message involves a proxy; 0216 padding indicator P (1 bit), signalling padding before encryption; the last byte of the decrypted payload then gives the number of padding bytes added; 0217 and random field (31 bits) containing a true random number and intended to be discarded after decryption. 0218 The set CRYPT of encrypted fields consists of the indicator P, of the random field and of the payload, while the identifier KeyIDCRYPT and the field TIMEOUT form an unencrypted encryption header ENT-CRYPT. 0219 In a variant embodiment applicable to any one of the pairs of associated enciphering and identification libraries (FIGS. 10 and 11), the enciphering library 75 comprises an indexed table 76 of blocks B1, B2 . . . Bn of enciphering keys, instead of a table of keys. Each of the blocks Bi itself includes several keys Ki,1, Ki,2 . . . Ki,ii, whose number may vary according to the block considered. Similarly, the identification library 85 comprises an indexed table 86 of blocks B1, B2 . . . Bn of identification keys, each of the blocks Bi including several keys Ki,1, Ki,2 . . . Ki,ii corresponding respectively to the keys Ki,1, Ki,2 . . . Ki,ii of the blocks Bi of the enciphering library 75. 0220 Knowledge of the key identifier KeyID does not therefore make it possible to ascertain in a one-to-one manner the key Ki,j chosen for the enciphering by the enciphering module 77, and hence the associated identification key Kij which is to be used by the identification module 87 of the library 85, but only the blocks Bi and Bi to which these keys respectively belong. All the keys of the identified block Bi must therefore be tried in succession until the decryption succeeds. 0221 According to a variant deployment of the identifiers, the authentication key identifier KeyIDSGN and/or permission identifier PERM are outside the authentication field AUTH in the header of the message MSG. Thus, the messages for authentication can be enciphered by including these identifiers in the signature calculation SGN, but while excluding the authentication field AUTH (L-AUTH0) therefrom. 0222 In another mode of embodiment (FIGS. 12 and 13), the permission flags PERM are disposed in the payload field. According to the example illustrated, the service announcement message MSG produced, referenced MSG-C, contains a header in the SAP format, denoted SAP-C, without permissions but with a reserved field of two bytes in the header ENT-C of the authentication field AUTH-C. Its payload in the SDP format, denoted SDP-C, includes the permission flags PERM on two bytes, for example at the start of the field. The permissions field needs more payload space than header space, since it now requires writing in text rather than binary format, and a permissions field identification label. 0223 An exemplary application in the digital broadcasting of data according to the MHP standard, over networks meeting the MPEG-2 standard, will now be detailed. This example relates to the protection of PMT tables (Program Map Tables) specified in the MPEG-2 standard (ISO/IEC 13818-1) and of AIT tables (Application Information Tables), the scrambling of the PMT tables being prohibited by the MPEG-2 standard. For the mechanisms described, a root certification authority is established, as optionally are other certification authorities. 0224 A PMT table constitutes an important entry point for the signalling of a service, interactive or otherwise. In the case of interactive MHP applications, the PMT table contains the positions of the stream transporting the AIT table and of the stream transporting the code and the application data (pointer to the DSM-CC DSI, standing for Digital Storage MediaCommand and Control and Digital Speech Interpolation). 0225 The protection of the signalling is based on hash codes, signatures and certificates. The coding of these cryptographic messages is done by introducing three new descriptors, denoted hash_descriptor, signature_descriptor and certificate_descriptor respectively. 0226 The first descriptor, hash_descriptor, can be placed in the first or the second loop of the AIT or PMT table. The hash code is calculated on the descriptors to which the pointer is pointing, in a specific loop. A descriptor loop of the next hierarchical level can include hash codes of the lower level. The syntax of the hash_descriptor is for example defined by means of the following parameters: 0227 digest_count: 16-bit value identifying the number of preprocessing values (digest values) in this hash descriptor; 0228 digest_type: 8-bit value identifying the preprocessing algorithm which may possibly be used for associated descriptors; the authorized values are chosen from among: 0229 0: preprocessing length 0, non authentication; 0230 1: preprocessing length 16, hash algorithm MD5 as defined in document RFC 1321; 0231 2: preprocessing length 20, hash algorithm SHA-1 (SHA standing for Secure Hash Algorithm) as defined in document FIPS-180-1; 0232 others : possibilites reserved; 0233 descriptor_count: 16-bit value identifying the number of descriptors associated with the preprocessing value; this value must be larger than zero; 0234 descriptor_pointer: pointer identifying a descriptor which forms part of the hash calculation; 0235 descriptor_tag: tag of the descriptor to which the descriptor_pointer parameter is pointing; 0236 digest_length: integer value giving the number of bytes in each preprocessing value; it depends on the type of preprocessing as indicated above in respect of the digest-type parameter; 0237 digest_byte: 8-bit value containing a byte of the preprocessing value. 0238 The syntax of the hash_descriptor descriptor is thus written: 3hash_descriptor( )descriptor_tag8uimsbfdescriptor_length8uimsbfdigest_count16uimsbffor(i0; i<digest_count; i)digest_type8uimsbfdescriptor_count8uimsbffor(j0; j<descriptor_count; j)descriptor_pointer8uimsbfdescriptor_tag8uimsbffor (j0; j<digest_length; j)digest_byte8bslbf

0239 For the second descriptor, signature_descriptor, the following parameters are used (in addition to parameters already defined for the hash_descriptor descriptor): 0240 signature_id: this identifier makes it possible to employ signatures of several authorities; 0241 signature_length : indicates the length of the next loop; as well as a signature specific field described below. 0242 This descriptor, which is placed ahead of the first hash_descriptor descriptor in a descriptor loop, has the following syntax: 4signature_descriptor( )descriptor_tag8uimsbfdescriptor_length8uimsbfsignature_id8uimsbfsignature_length8uimsbffor(i0; i<N; i)signature specific data

0243 The signature specific data field contains the structure which follows, expressed in the ASN.1 (standing for <<Abstract Syntax Notation one >>) DER specification language: 5Signature :: SEQUENCE certificateidentifierAuthorityKeyIdentifier,hashSignatureAlgorithmHashAlgorithmIdentifier,signatureValueBIT STRING

0244 whose signatureValue field gives the signature value (in the form of a string of bits BIT STRING), this value depending on the choice of MHP specification, and whose other certificateldentifier and hashSignatureAlgorithm fields are defined hereinbelow. 0245 The certificateldentifier field identifies the certificate bearing a certified public key used to verify the signature. It is defined according to the ITU-T (standing for International Telecommunication UnionTelecommunications Standardization Sector) extension X.509 54 for the AuthorityKeyldentifier type field. The structure of the latter contains in particular an optional key identification field Keyldentifier (Keyidentifier type). It also contains an authorityCertlssuer (GeneralNames type) element, itself containing a directoryName field having the value of the certificate bearing the public key used, as well as an authorityCertSerialNumber (CertificateSerialNumber type) element giving a corresponding serial number. These two elements, a prori optional in the AuthorityKeyidentifier field type must be filled in. We thus have: 6AuthorityKeyidentifier :: SEQUENCE keyidentifier0 KeyIdentifier OPTIONAL,authorityCertIssuer1 GeneralNames OPTIONAL,authorityCertSerialNumber2 CertificateSerialNumberOPTIONAL

0246 The hashSignatureAlgorithm field identifies the hash algorithm used. The encryption algorithm employed to calculate the signature need not be specified here, since it is already described in a SubjectKeyinfo field of the certificate certifying the key. The two algorithms provided for are MD5 and SHA-1, whose structures are as follows: 7md5 OBJECT IDENTIFIER ::iso(1) member-body(2) US(840) rsadsi(113549)digestAlgorithm(2) 5 sha-1 OBJECT IDENTIFIER ::iso(1) identified-organization(3) oiw(14) secsig(3)algorithm(2) 26

0247 The third descriptor, certificate_descriptor, makes it possible to construct a CertificateFile file, which contains all the certificates of the certification string, up to and including the root certificate. The leaf certificate and the root certificate are placed respectively first and last in the descriptor, the latter being included only for consistency. The certificate coding profile is defined in the ETSI (standing for European Telecommunications Standard Institute) Standard TS 102 812 V1.1.1. 0248 The certificate_descriptor descriptor, placed ahead of the first signature_descriptor descriptor in a descriptor string, contains a certificate( ) field bearing a single certificate data structure as defined by the ITU-T X.509 Standard. The structure of the descriptor is expressed as a function of the following parameters: 0249 signature_id: identifier tying the certifications to a specific signature; 0250 certificate_here_flag: 1-bit field indicating that the certificates are disposed in the descriptor should the value be 1, and that the certificates of an application must be used, otherwise, a tie then having to be defined; 0251 certificate_count: 16-bit integer indicating the number of certificates in the certificate descriptor; 0252 certificate_length: 24-bit integer specifying the number of bytes in the certificate. 0253 The structure of the certificate_descriptor descriptor is specified thus: 8certificate_descriptor( )descriptor_tag8uimsbfdescriptor_length8uimsbfsignature_id8uimsbfcertificate_here_flag1bslbfreserved7bslbfif(certificate_here_flag 1)certificate_count16uimsbffor(i0; i<certificate_count; i)certificate_length24uimsbfcertificate( )

0254 The method set forth makes it possible to protect PMT and AIT tables against piracy operations. Moreover, in network head-ends, it can happen that streams are remultiplexed and that PID identification packets or event PMT table contents are modified on account of network requirements. Such remultiplexings are allowed for by the method developed hereinabove in so far as only a subselection of descriptors is authenticated or else a remultiplexing apparatus reauthenticates the modified descriptors. 0255 Although the above description is aimed at the authentication of PMT and AIT tables, the method set forth is also applicable to any other type of table defined according to the MPEG/DVB Standards, such as for example PAT, CAT, NIT, SDT, EIT, SIT or DIT tables.