HK1117671B - Authentication of data transmitted in a digital transmission system - Google Patents

Description

Authentication of data transmitted in a digital transmission system

This application is a divisional application of patent application No. 01810646.3.

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

Broadcast transmission of digital data is well known in the field of pay television systems in which scrambled audiovisual information is transmitted, typically via satellite or satellite/cable links, to a plurality of subscribers, each subscriber having a decoder capable of descrambling the transmitted program for later viewing. Terrestrial digital broadcasting systems are also known. Recent systems also use broadcast links to transmit other data (such as computer programs or interactive applications) in addition to audio video data to a decoder or connected PC.

One particular problem with the transmission of application data is the need to verify the integrity and origin of any such data. Since such data can be used to reconfigure the decoder, and to implement applications for any number of interactions, it is important that the received data be complete and identified as originating from a known source. Otherwise, operational problems associated with downloading incomplete data may arise, as well as the risk that the decoder becomes open and thus subject to attack by third parties or the like.

Verifying the integrity of such data may be performed by verifying the packet data stream received directly by the decoder. The packet is typically marked by applying a hashing algorithm to at least some of the data in the packet prior to transmission. The resulting hash value is stored in the packet. After receiving a packet of data, the decoder applies the same hashing algorithm to the data and compares the hash value calculated by the decoder with the hash value stored in the received packet to verify the integrity of the received data. For example, in the event of a failure or corruption in a transmission, the computed hash value will be different from the received hash value. The decoder is then alerted to: there is a possible error in the present data packet and the faulty data packet will be reloaded. A problem associated with the use of well-known hash algorithms, such as the message digest algorithm MD5, is that the calculation of the hash value is carried out in accordance with a well-known series of calculation steps, with the result that anyone can calculate the hash value of a data packet. It is therefore not possible to verify the origin of the data packet received by the decoder. This is particularly important when the operational data file of the decoder is modified with the received data.

To overcome this problem, rather than using a hashing algorithm to compute a hash value for at least some of the data, the signature value for a data packet may be computed using a key value known only to the broadcaster. This key may be derived by using a symmetric key algorithm (such as the data encryption standard algorithm, or the DES algorithm), where the equivalent key is stored with the decoder. However, greater convenience may be provided by using asymmetric public/private key algorithms (such as the Rivest, Shamir and Adleman algorithms, or the RSA algorithm) in which the public and private keys form complementary parts of a mathematical formula.

The broadcaster responsible for generating the data packets stores the private key and computes the signature value by using the private key. The public key is stored in the decoder, which receives the data by hard-coding the public key into the decoder's memory during manufacture. After receiving the data packet, the decoder verifies the signature value by comparing the received data with the result of applying the public key algorithm to the received signature value using the stored public key.

Even in such a security system, the value of the public key may be leaked by being illegally publicly distributed. In such a situation, the broadcaster must revoke the equivalent public key quickly in order to prevent unauthorized reception of the data packet. In addition, new public/private keys must in turn also be used. The broadcaster will therefore need to replace the public key stored in the decoder of the legitimate user with a new public key. Depending on the sensitivity of the public key, this may require the broadcaster to return the decoders to the manufacturer at a cost and effort in order to hard-code the new public key into the memory of the decoders.

The present invention, at least in its preferred embodiments, seeks to solve these and other problems.

A first aspect of the invention provides a method of authenticating data transmitted in a digital transmission system, the method comprising the steps, prior to transmission:

determining at least two encrypted values for at least some of the data, each encrypted value being determined for the same data using a key of a corresponding encryption algorithm; and

outputting the at least two encrypted values along with the data.

The invention has particular, but not exclusive, application in situations where it is desirable to update security sensitive data, such as keys to be used in a new encryption algorithm, in order to ensure that the data is received "as issued". To provide such confidentiality, at least two encrypted values for at least some, preferably most, more preferably all, of the data are determined. Each encrypted value is determined using a key of a corresponding encryption algorithm. If one of the keys is compromised, it is possible for a "hacker" to intercept the data and change the content of the data and the encrypted value calculated by using the compromised key. However, it is impossible for a hacker to change the encrypted value calculated by using the unleakened key. Therefore, when the encrypted value is verified by using a key equivalent to the key used to calculate the encrypted value, the two values using the equivalent key will be different, which means that the data has become unreliable.

The data and encrypted values are preferably output for transmission to a receiver/decoder. Preferably, said data and said encrypted values are received by a receiver/decoder, wherein each encrypted value is processed using a key of said corresponding encryption algorithm, and each subsequently derived value is compared with said at least some data in order to authenticate said at least some data. If the data has become unreliable, the receiver/decoder may choose to ignore the data so that new keys that are compromised or unreliable will not be stored in the decoder's memory. Preferably, said received data is rejected by the receiver/decoder if at least one subsequently derived value differs from said at least some data.

The invention therefore extends to a method of authenticating transmitted data in a digital transmission system, said method comprising the steps of:

receiving said data and at least two encrypted values determined for at least some of the data, each encrypted value being determined for the same data using a key of a respective encryption algorithm;

storing a plurality of keys;

processing each encrypted value by using the stored key of the corresponding encryption algorithm;

comparing said later obtained value with said at least some data in order to authenticate said at least some data.

Preferably, each algorithm is asymmetric. In a preferred embodiment, each encrypted value corresponds to a digital signature calculated using the private key of the corresponding encryption algorithm, each signature being processable using the public key of said encryption algorithm.

Preferably, the method includes the step of outputting, together with each signature, an identifier of a public key to be used to process the signature. This enables the receiver/decoder to easily identify the key to be used to verify the signature

Preferably, the data comprises a key. In a preferred embodiment, the data comprises at least one digital certificate, preferably at least one digital root certificate, containing a public key of an encryption algorithm used to process the data. The at least one digital certificate may include a digital signature computed using a private key of an encryption algorithm using a public key contained in the certificate. Thus, the digital certificate can be securely sent to the translator without the translator having to be returned to the manufacturer in order to hard-code the new certificate into the translator's memory.

Preferably, the data comprises an identification of a revoked public key. The identification number may comprise an identification number of a digital certificate, preferably a digital root certificate, which contains said revoked public key. The data may comprise a plurality of said identification numbers, each identification number identifying a respective revoked public key. Thus, a list of identifiers of revoked keys may be securely sent to the decoder.

By means of the above method, data can be safely updated as long as the number of leaked keys is lower than the number of encrypted values stored with the data. The data and the at least two encrypted values may therefore be organized in a data file, which may include an indication of a minimum number of encrypted values to be stored in a subsequently generated data file. This enables the minimum number of encrypted values to be changed, e.g. increased, if keys are compromised such that the minimum number of encrypted values remains greater than the number of compromised keys.

Preferably, the data file is received by a receiver/decoder which compares the number of encrypted values stored in the data file with the minimum number and rejects the data file if the number of encrypted values stored in the data file is less than the minimum number.

The data file may be transmitted in a data module. A module encryption value for at least some of the data in the module may be calculated using a key of a transmitter encryption algorithm and stored in the data module. A data module may be received by the receiver/decoder which processes the module encryption value by using a key of the transmitter encryption algorithm and compares the later obtained value with the at least some data in the module to authenticate the at least some data in the module.

The encrypted values for at least some of the data in the module may correspond to a digital signature calculated using a private key of a transmitter encryption algorithm and may be processable using a public key of the encryption algorithm.

The digital transmission system may be a digital broadcast system such as a television or audio system.

The invention also provides apparatus for authenticating data to be transmitted in a digital transmission system, the apparatus comprising:

means for determining at least two encrypted values for at least some of the data, wherein each encrypted value is determined for the same data using a key of a corresponding encryption algorithm; and

means for outputting the at least two encrypted numerical values along with the data.

The invention also provides a system for authenticating data to be transmitted in a digital transmission system, said system comprising the apparatus described above. The system preferably further comprises a receiver/decoder comprising means for receiving said data and said encrypted values, means for processing each encrypted value by using a key of said corresponding encryption algorithm, and means for comparing each subsequently derived value with said at least some data to authenticate said at least some data.

The invention extends to a receiver/decoder comprising:

means for receiving a data file comprising said data and at least two encrypted values determined for at least some of the data, each encrypted value being determined using a key of a respective encryption algorithm;

means for storing a plurality of keys;

means for processing each encrypted value using the stored key of the corresponding encryption algorithm;

means for comparing said later obtained value with said at least some data for authenticating said at least some data.

The invention also extends to a system for authenticating data transmitted in a digital transmission system, said system comprising apparatus as defined above and a receiver/decoder as defined above.

The invention also extends to a signal comprising data and at least two encryption values determined for at least some of the data, each encryption value being determined using a key of a respective encryption algorithm.

The invention also extends to a method or apparatus, receiver/decoder, or signal for authenticating data substantially as herein described with reference to the accompanying drawings.

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

As used herein, the term "digital transmission system" includes any transmission system for transmitting or broadcasting primarily audiovisual or multimedia digital data. Although the invention is particularly applicable to broadcast digital television systems, the invention is also applicable to fixed telecommunications networks, closed circuit televisions, etc. for multimedia internet applications.

As used herein, the term "digital television system" includes any satellite, terrestrial, cable, and other system.

Suitable algorithms for generating private/public keys for use in the present invention may include RSA, Fiat-shamir, or Diffie-Hellman, and suitable symmetric key algorithms may include DES-type algorithms. However, unless necessary in its content or otherwise specified, there is generally no difference between the keys associated with the symmetric algorithm and the keys associated with the public/private algorithm.

For the sake of simplicity of language, the terms "scrambled" and "encrypted", as well as "control words" and "keys" are used for various parts of the text. However, it will be seen that there is no fundamental difference between "scrambled data" and "encrypted data", and "control word" and "key".

In addition, for the sake of language simplicity, the terms "encrypted" and "tagged," as well as "decrypted" and "authenticated" are used for various portions of the text. However, it will be seen that there is no fundamental difference between "encrypted data" and "signed data", and "decrypted data" and "verified data".

As such. The term "equivalent key" is used to refer to a key suitable for decrypting data encrypted by the first-mentioned key, or vice versa.

The above features relating to the method aspect of the invention may also be applied to the apparatus aspect and vice versa.

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

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

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

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

FIG. 4 shows the partitioning of a software application into multiple MPEG tables;

FIG. 5 shows the relationship between DSM-CC data files and the resulting MPEG table;

FIG. 6 shows the relationship of a client, server, network manager as specified in the DSM-CC environment;

FIG. 7 shows authenticated directory, subdirectory, and file objects;

FIG. 8 shows the format of a broadcaster certificate, a certificate authority certificate, and a root certificate authority certificate;

FIG. 9 shows the format of a certificate revocation list;

fig. 10 shows a format of a Root Certificate Management Message (RCMM);

fig. 11 shows the steps involved in RCMM processing after reception by the decoder.

An overview of a digital television system 1 according to the invention is shown in fig. 1. The present invention includes most conventional digital television systems 2 that use the known MPEG-2 codec system to transmit compressed digital signals. In more detail, the MPEG-2 compressor 3 at the broadcasting center receives a digital signal stream (typically a video signal stream). The compressor 3 is connected to a multiplexer and scrambler 4 via a link 5.

The multiplexer 4 receives a plurality of further input signals, combines the transported data streams and transmits the compressed digital signals to the transmitter 6 of the broadcast centre via a link 7, which link 7 may of course take a variety of forms, including a telecommunications link. The transmitter transmits an electromagnetic signal via an uplink 8 to a satellite transponder 9 where it is processed and broadcast via a theoretical downlink 10 to a terrestrial receiver 12, conventionally via a dish owned or leased by the end user. The signal received by the receiver 12 is sent to an integrated receiver/decoder 13 owned or leased by the end user and to a television set 14 connected to the end user. The receiver/decoder 13 decodes the compressed MPEG-2 signal into a television signal for the television set 14.

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

In a multi-channel system, a multiplexer 4 processes audio and video information received from multiple parallel sources and interacts with a transmitter 6 to broadcast the information along a corresponding number of channels. In addition to audio-visual information, messages or applications or any other kind of digital data may be introduced into some or all of these channels, interleaved with the transmitted digital audio and video messages. In such a case, a digital data stream in the form of DSM-CC (digital storage media command and control) formatted software files and messages will be compressed and packetized into MPEG format by the compressor 3. The downloading of the software modules is described in more detail below.

The conditional access system 15 is connected to the multiplexer 4 and the receiver/decoder 13 and is located partly in the broadcast centre and partly in the decoder. It enables end users to access digital television broadcasts from one or more broadcast providers. A smart card capable of decrypting messages relating to commercial offerings (i.e. one or several television programs sold by a broadcast provider) may be inserted into the receiver/decoder 13. By using the transcoder 13 and smart card, the end user can purchase commercial offerings in either a subscription mode or a pay-per-view mode. In practice, the transcoder may be configured as multiple access control systems capable of handling simultaneous cipher (Simulcrypt) or multiple cipher (multicorypt) designs. As described above, the programs transmitted by the system are scrambled in the multiplexer 4, and the conditions and encryption keys applied to a given transmission are determined by the access control system 15. The transmission of such scrambled data is well known in the field of pay television systems. Typically, scrambled data is transmitted together with a control word for data scrambling, the control word itself being encrypted by a so-called operation key and transmitted in an encrypted manner.

The scrambled data and encrypted control word are then received by the decoder 13, the equivalent of said operating key stored on the smart card inserted into the decoder is accessed in order to decrypt the encrypted control word and then unscramble the transmitted data. The paying user will receive the operation key necessary for decrypting the encrypted control word in the EMM (entitlement management message) broadcast every month to permit viewing of the transmission content. In addition to their use in decrypting av programs, similar operation keys may be generated and transmitted for use in authenticating other data, such as software modules as will be described below.

An interactive system 16, also connected to the multiplexer 4 and the receiver/decoder 13 and also partly located in the broadcast centre and partly in the decoder, enables the end user to interact with various applications via a modem return channel 17. The modem return channel may also be used in communications used in the conditional access system 15. An interactive system may be used to enable viewers to communicate immediately with the transmission center in order to require legal rights to authorize viewing of particular events, downloads, applications, and the like.

Physical unit of receiver/decoder

With reference to fig. 2, the physical units of a receiver/decoder 13 or 1 set-top box suitable for use in the present invention will now be described briefly. The elements shown in the figures will be described in terms of functional blocks.

The decoder 13 comprises a central processor 20 which includes associated memory elements adapted to receive input data from a serial interface 21, a parallel interface 22 and a modem 23 connected to the modem return channel 17 of fig. 1.

The decoder is further adapted to receive inputs from an infrared remote control 25 via a control unit 26 and from switch contacts 24 on the front panel of the decoder. The decoder also has two smart card readers 27, 28 adapted to read bank and subscription smart cards 29, 30 respectively. Input may also be received via an infrared keyboard (not shown). The subscription smartcard reader 28 accepts an inserted subscription card 30 and accepts the conditional access unit 29 to provide the necessary control words to the demultiplexer/descrambler 30 so that the encrypted broadcast signal can be descrambled. The decoder also includes a conventional tuner 31 and demodulator 32 to receive and demodulate the satellite transmission, which is then filtered and demultiplexed by unit 30.

The data is processed within the decoder, typically managed by a central processor 20. The software structure of the central processor corresponds to a virtual machine that interacts with a lower level operating system implemented with the hardware components of the decoder.

Packet structure of transmitted data

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

With particular reference to FIG. 3, the MPEG bitstream includes a program access table ("PAT") 40 having a packet identification ("PID") of 0. The PAT contains references to PIDs of program correspondence tables ("PMT") 41 for a plurality of programs. Each PMT contains a reference to the PID of the data streams of the video MPEG table 42 and the video MPEG table 43 for that program. Packets with PIDs of zero (i.e., program access table 40) provide entry points for all MPEG accesses.

In order to download the application and its data, two new stream types are specified, the associated PMT also containing references to the PIDs of the streams of the application MPEG table 44 (or their segments) and the data video MPEG table 45 (or their segments). Indeed, while it may be convenient in some situations to specify separate data stream types for the executable application software and the data processed by such software, this is not essential. In other implementations, the data and executable code may be assembled in a single data stream accessed through the PMT.

Referring to fig. 4, in order to download an application within the data stream 44, the application 46 is divided into modules 47, each formed from an MPEG table. Some of these tables include a single segment, while others are composed of multiple segments 48. A typical fragment 48 has a header that includes a one-byte table identifier ("TID") 50, the fragment number 51 of the fragment in the table, the total number of fragments 52 in the table, and a two-byte TID extension reference 53. Each segment also includes a data portion 54 and a CRC 55. For a particular table 47, all of the segments 48 that make up that table 47 have the same TID 50 and the same TID extension 53. For a particular application 46, all tables 47 that make up that application 46 have the same TID 50, but different TID extensions.

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

Referring back to fig. 3, PAT 40, PMT 41 and application and data stream components 44, 45 are sent cyclically. Each application being sent has a respective predetermined TID. For downloading the application, an MPEG table with the appropriate TID and TID extension of zero is downloaded to the receiver/decoder. This is a directory table for the required application. The data in the directory is then processed by the decoder to determine the TID extensions that make up the table for the required application. Thereafter, any required tables with the same TID as the directory table and the TID extension determined from the directory can be downloaded.

The decoder is arranged to check the directory table for any updates thereto. This may be done by downloading the catalog table again periodically (e.g., every 30 seconds, or every 1 minute or 5 minutes) and comparing the version numbers of the previously downloaded catalog tables. If the newly downloaded version number is a newer version number, the table associated with the previous directory table is deleted and the table associated with the new version is downloaded and assembled.

In an alternative arrangement the incoming bit stream is filtered by using masks corresponding to TID, TID extension and version number, which have values set for the applied TID, TID extension being zero and version number being 1 greater than the version number of the currently downloaded directory. Thus, the increment of the version number can be detected and, once detected, the directory is downloaded and the application is updated, as described above. If the application is to be terminated, an empty directory with the next version number is sent, but without any modules listed in the directory. In response to receipt of such an empty directory, the translator 2020 is programmed to delete the application.

In practice, the software and computer programs implementing the applications in the decoder may be introduced by any component of the decoder, in particular in the data stream received via the wireless link described, but also via a serial port, a smart card link, etc. Such software may include high-level applications used to implement interactive applications within the transcoder, such as web browsers, quiz applications, program guides, and so forth. The software may also be downloaded to change the working configuration of the decoder software by means of "inserts" (or the like).

The application may also be downloaded via the decoder and sent to a PC or the like connected to the decoder. In such a case, the transcoder functions as a communication router for the software that ultimately runs on the connected device. In addition to this routing function, the transcoder may also be used to convert MPEG packetized data into computer file software organized according to the DSM-CC protocol (see below) before routing to the PC.

Organization of data in data files

Fig. 5 shows the relationship between data organized in an assembled application 46 and contained within a series of MPEG tables 47 in a set of DSM-CC U-U (user-to-user) data files 60. Such a relationship is described in WO99/49614, the contents of which are incorporated herein by reference.

Before transmission, the data files are assembled into an application 46, and thereafter, grouped by the MPEG compressor into MPEG tables or modules 47, as described above, which include headers 49 specific to the MPEG packetized datastream, as well as table IDs, version numbers, and the like. As will be seen, there may not be a fixed relationship between the data files 61 and the data organized in the final MPEG table 47. After being received and filtered by the decoder, the packet header 49 is discarded and the application 46 reconstructed from the payload of the table 47.

The DSM-CC format for data files is a particularly well-suited standard for multimedia networks, which specifies a series of message formats and session commands for communication between client users 70, server users 71, and network resource managers 72, as shown in fig. 6. The network resource manager 72 may be viewed as a logical entity that manages the attributes of resources within the network.

Communication between the client and server is established by a series of sessions, a first sequence of messages being exchanged between the user (client 70 or server 71) and a network administrator 72 in order to configure the client and/or server for communication. Such messages are formatted according to the so-called DSM-CC U-N (from user to network) protocol. A subset of this protocol has been specifically defined for broadcasting download data.

Once the communication link is established, messages are later exchanged between the client 70 and the server 71 in accordance with the DSM-CC U-U protocol. This sequence of messages corresponds to the data file 60 of fig. 5. In the case of the DSM-CC U-U message, the data is organized in a message sequence 61 grouped according to the bio p or Inter Orb protocol.

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

The data objects 64 within the payload of a DSM-CC U-U file may be generally specified as one of three types; directory objects, file objects, and data stream objects. The directory object specifies a root directory or subdirectory that is used to reference a series of related file objects that contain actual application data.

The stream object may be used to enable a temporary relationship to be established between data contained in the data file and the MPEG packet data stream itself. This can be used in the case of interactive applications contained in data files and designed to be synchronized with the elementary video or audio data stream received and processed by the decoder. As described above, there may not be a direct relationship between MPEG packetized data and data files.

Unlike MPEG tables, where a single directory references a set of tables having only a single hierarchical level, data files 60 may be organized in a more complex hierarchical fashion. Just as for files stored in a PC or server, the main directory or root directory may refer to one or more subdirectories which in turn refer to data files of the second level. It is even possible to refer to a second root directory related to application data of another group.

File structure of data file group

Referring to fig. 7, an example of a file structure of a data file group is shown. The root directory DIR a0, indicated at 75, references the subdirectory group a1 of the object file 77. For the sake of simplicity, only the object files F1, F2, etc. of a single group related to the subdirectory a4 are shown in the figure. In practice, a plurality of sets of object files may be referred to by each of the sub-directories a1 to a 4.

Within each directory and subdirectory, a set of authentication steps is introduced for the files linked to the directory. Referring to the root directory 75, the subheader 63 includes a hash value obtained by applying a hashing algorithm to some or all of the data stored in the subdirectory files A1 through A4, denoted 76. The hashing algorithm used may be of any known type, such as the message digest algorithm MD 5.

In one implementation, the algorithm may be applied individually to each associated file or sub-directory, and to a table of hash values for each sub-directory 76 stored in the root directory 75 prior to transmission. However, although such a solution enables an increased degree of verification resolution in verifying each subdirectory, this solution is rather inadequate in terms of the processing time necessary for the decoder to calculate the corresponding signature. Thus, the subheaders 63 of the directory 79 preferably include cumulative hash values 79 calculated by applying the MD5 hashing algorithm to the payload segments 63, 64 of the combined subheader and subdirectory 76, i.e., without the header 62. In particular, a hash value 82 contained within the subdirectory 76 and relating to the file object layer 77 is included in this hash calculation.

In the case of subdirectory A4 shown in FIG. 7, this subdirectory itself is related to a group of object files F1-Fn, indicated at 77. In this case, the cumulative hash value 82 is generated for the combined contents of the object file 77. This value is included in the hashing process that results in the hash value 79. It is therefore not possible to change any object file 77 without changing the hash value 82 of the subdirectory 76, which in turn would change the hash value 79 of the directory 75.

In this example, the combined hash value is calculated for all subdirectories A1-A4 in the directory. This hash value is stored along with the identification number of the subdirectory group from which the data was taken. In other embodiments, a series of combined or individual hash values and corresponding identifiers may be stored in a subheading of the directory.

For example, a second group of subdirectories (which are also related to the root directory, but which refer to different groups of data or executable code) may also be grouped together, and the accumulated hash values computed for these subdirectories are computed and stored in the subheading root directory. A single hash value associated with a single directory may be stored equally in the subheading of the root directory.

Authentication of a group of data files or individual data files does not of course prevent the root directory (or indeed any other file) from also referring to unverified or unhashed data files, but for any run of this file the lack of verification of such files will need to be taken into account. In this respect, it is not necessary to authenticate the data stream object.

The use of a hash function in this case primarily enables the decoder to verify the integrity or completeness of the downloaded data file. In the event of a failure or corruption on transmission, the running of the cumulative hash algorithm on the received dependent files will not give the same result as the hash values of those files stored in the root directory. The decoder is then prompted to: there are possible errors in the downloaded data and faulty data files will be re-downloaded.

Signature values for root directory

For enhanced security, the signature value of the root directory 75 is computed. In this embodiment, using a private/public key algorithm, such as the Rivest, Shamir and Adleman or RSA algorithms, the broadcaster responsible for generating the data file has a private key value, and the public key value is maintained by the decoder. Alternatively, the secret key may correspond to a key derived by a symmetric key algorithm (such as the data encryption standard or the DES algorithm).

As shown in fig. 7, the root directory 75 includes a broadcaster identification number 80 which indicates to the decoder the public key to be used at the verification level together with a calculated signature value 81 generated by using the broadcaster's private key. In this case, the signature value 81 is generated by applying a private key maintained by the broadcaster to some or all of the data in the directory 75 (preferably including the payload 64 and/or the accumulated hash value 79). The decoder then verifies this signature value 81 by using the corresponding public key identified by the broadcaster identification number 80.

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

In either case, the generation of the signature value or cryptographic block used by the encryption key enables the decoder to verify the integrity and origin of the directory 75, i.e. the integrity and origin of the file linked by this root directory. Since the accumulated hash values of the linked files are included in the calculation of the signature 81, it is not possible to change these values if this is not detected in the verification stage. Since each hash value is typically unique to a given data set, it is not possible to change the contents of any dependent hash files, and thus the final signature value of the directory, without changing the hash value of the characteristics of those hash files.

As will be seen, it is possible to have a number of variations, particularly to reduce the amount of hashed or tagged data at each level. In particular, where a directory or subdirectory is used to verify the signature or hash value of a lower level data file, a directory signature or hash value may be generated using only the lower level hash value and no other data.

For example, the combined hash value 79 in the A0 directory 75 may be generated using the combined hash value of each A1-A4 subdirectory, denoted 76. Since these values are just as unique as the data in the payload of the subdirectory, the combined hash value 79 is still unique to the subdirectory in question. Furthermore, the integrity of the lower level object and directory files 77, 78 can still be assumed because the hash value 82 is still used in the calculation.

Broadcaster digital certificate

Referring to fig. 8, the public key 91 and the broadcaster identification number 80 are provided to the user of the decoder in a digital certificate, preferably in the form of the well-known International Standards Organization (ISO) x.509 standard, which is hard-coded into the memory of the decoder during manufacture. Such certificates are distributed to the manufacturer of the transcoder by a trusted third party, which are often referred to as Certificate Authorities (CA). The use of such certificates has become more widespread, primarily due to the Secure Socket Layer (SSL) secure transport protocol developed and standardized by Netscape Communications for securing credit card transactions over the World Wide Web (WWW).

In addition to the public key 91 and the broadcaster identification number 80, the broadcaster-related digital certificate, or broadcaster certificate 90, includes:

version number 92 of broadcaster certificate 90;

the serial number 93 of the broadcaster certificate 90;

the CA identification number 94 of the CA that distributes the broadcaster certificate 90;

validity period 95 of broadcaster certificate 90, indicating the start and end of the time period during which the certificate needs to be used; and

the signature value 96 of the broadcaster certificate 90.

As can be seen from the above, the broadcaster certificate comprises two different identification numbers: a first "distributor name" identifier corresponding to the identifier 94 of the distributor of the certificate, and a second "subject name" identifier corresponding to the identifier 80 identifying the public key 91.

The CA computes the signature value 96 of the broadcaster certificate 90 by applying the CA's private key, or the CA's private key, to at least some or all of the data in the broadcaster certificate. The translator may then verify this signature value 96 by processing the signature using the corresponding CA public key 101 identified by the CA identifier 94 to determine that the contents of the certificate have not been modified after being signed by the CA.

The transcoder may store a plurality of such certificates for different respective broadcasters.

Certificate authority digital certificate

Referring also to fig. 8, the corresponding CA public key 101 and CA identification number 94 are provided to the user of the transcoder in a CA certificate 100, which is also hard-coded into the transcoder during manufacture. The CA certificate 100 further includes:

the version number 102 of the CA certificate 100;

the serial number 103 of the CA certificate 100;

RCA identification number 104 of a Root Certificate Authority (RCA) such as European Telecommunications Standards Institute (ETSI) that distributes CA certificates 100;

the validity period 105 of the CA certificate 100; and

the signature value 106 of the CA certificate 100.

As can be seen from the above, the CA certificate also includes two different identification numbers: a first "issuer name" identifier corresponding to identifier 104 of the distributor of the certificate, and a second "recipient name" identifier corresponding to identifier 94 identifying public key 101.

The RCA calculates the signature value 106 of the CA certificate 100 by applying the RCA-specific key or RCA-specific key to at least some or all of the data within the CA certificate. The translator may then verify this signature value 106 by processing the signature using the corresponding RCA public key 111 identified by the RCA identifier 104 to determine that the contents of the certificate have not been modified following RCA signing.

The translator may store a plurality of such certificates for different respective CAs.

Root certificate authority digital certificate

The corresponding RCA public key 111 and RCA identifier 104 is provided to the user of the decoder in the RCA or root certificate 110, which is also hard coded into the memory of the decoder during manufacture. Each translator typically includes a set of two or more root certificates. Each root certificate 110 also includes:

the version number 112 of the root certificate 110;

the serial number 113 of the root certificate 110;

the validity period 114 of the root certificate 110; and

the signature value 115 of the root certificate 110.

As can be seen from the above, the root certificate comprises only a single identification number, i.e. the identification number 104 of the distributor of the certificate. This identifier 104 also identifies the public key 111. Thus, a root certificate may be defined as a certificate in which the issuer name is the same as the recipient name.

Since the root certificate is the final certificate in the chain of broadcaster certificate 90-CA certificate 100-root certificate 110, the root certificate is itself signed, i.e. the signature value is calculated using a private key equivalent to public key 111. Therefore, it is of concern that the content of the root certificate does not become publicly available.

It is of course possible that the RCA provides the broadcaster certificate 90 directly to the manufacturer of the transcoder, in which case the broadcaster certificate will contain the RCA identifier 111 and be signed using the RCA-specific key.

Certificate revocation list

If the private key corresponding to the public key stored in the certificate is leaked, any of the broadcaster certificate 90 and the CA certificate 100 can be revoked by deletion before the expiration time specified therein expires. Such revocation may be implemented by sending a certificate revocation list containing a list of the serial numbers 92, 102 of the certificates to be revoked to the transcoder. After revocation, the certificate is rendered inoperable, preferably by deleting it from the memory of the transcoder, thereby preventing the downloading of any unauthorized and possibly malicious data packets marked with a compromised private key.

The CRL is distributed by the CA or RCA to the broadcaster who sends the CRL to the decoder via modem return channel 17 or broadcasts the CRL via an MPEG transport stream. It is not important that the broadcaster inserts the CRL into all transport streams sent from the transmitter to the decoder; it is sufficient for the broadcaster to insert the CRL into those transport streams that are very likely to be tuned by the decoder. For example, a CRL may be inserted as a data file into a root directory 75 or subdirectory 76 of a group of data files broadcast from a transmitter to a transcoder.

Referring to fig. 9, a CRL typically includes:

identification numbers 94 or 104 of CA or RCA of the distributed CRL 120;

date 122 on which CRL 120 was published;

the date 124 on which the next CRL is expected to be published;

a list 125 of the serial numbers of the certificates to be revoked, including, for each revoked certificate, the time and date of revocation of that certificate; and

the signature value 126 of the CRL, which is calculated by using the private key of the CA or RCA issuing the CRL 120.

Upon receiving the CRL, the decoder compares the date 122 on which the CRL 120 was published with the date 124 on which the CRL was expected to be published as suggested by the previously received CRL. If the date 122 of the newly received CRL is not later than the date 124 on which the CRL is expected to be published, the CRL is ignored.

If the date 122 of the newly received CRL is later than the date 124 on which the CRL is expected to be issued, the signature of the CRL is verified using the public key of the issuer of the CA, which is identified using the identification number 94 or 104 contained in the CRL.

If the integrity of the CRL is so verified, the CRL is processed to append the date 124 and store the date 124 in persistent memory that the next CRL is expected to be issued, as well as store a list 125 of the string numbers of the revoked certificates. The received list of revoked certificates 125 is also stored in the permanent memory of the translator. For performance reasons, the CRL 120 is preferably cached in the memory of the decoder. Preferably, the decoder's cache memory stores the CRL 120 in a tree-like manner, with the CRL of the RCA at the top of the "tree" and the CRL of the RCA-distributed CA at the bottom of the "tree".

In the event that the broadcaster's private key is compromised in the event that the broadcaster's certificate 90 is revoked, the certificate authority for that broadcaster appends the serial number 93 of the broadcaster's certificate 90 to its CRL 120. The certificate authority then distributes the new CRL 120 to all broadcasters who also accept the distributed broadcaster certificates 90 for broadcasting. Whenever the transcoder downloads a new CRL 120, for example after a channel attack on the broadcaster, the CRL cache is updated and any certificates identified in the list 125 of CRLs 120 will be revoked.

The alternate broadcaster certificate 90 is generated by the certificate authority 100 and is broadcast to the user in the directory 75 or 76 of the file. The replacement broadcaster certificate will include a new public key 91, an updated version number 92, an updated validity period 95, and a new signature value 96 calculated by using the CA's private key. The broadcaster identification number 80 and the CA identification number 94 will remain unchanged. Upon receiving the substitute broadcaster certificate 90, the translator validates the certificate by processing the certificate using the corresponding CA public key contained in the CA certificate identified by the CA identification number 94.

After the CA certificate 100 is revoked, the CRL of the CA is removed from the memory of the translator. Therefore, if the size of the CRL of the CA becomes too large to be stored in the ultra-high-speed memory of the translator, it may be desirable to automatically revoke the CA certificate 100. In this case, the RCA distributing the CA certificate 100 to the CA will attach the serial number 103 of the CA certificate 100 to its CRL. The root certificate authority then distributes the new CRL to all broadcasters who also accept the CA certificate for broadcasting distributed by the RCA. Whenever the transcoder downloads a new CRL 120, for example, over the broadcaster's channel, the CRL cache is updated and any certificates identified in the manifest 125 of the CRL 120 are revoked.

After revocation of the CA certificate 100 of the certificate authority, in addition to storing a new CA certificate for the certificate authority to the transcoder, replacement of the broadcaster certificates 90 of all broadcasters who accept the certificate distributed by the certificate authority will be necessary, because by using the new broadcaster certificate 90 which is signed, since the private key for the certificate authority is no longer valid. The alternative CA certificate 100 is generated by the root certificate authority 110 and is broadcast to the user in the directory 75 or 76 of the file. Similar to the alternate broadcaster certificate, the alternate CA certificate will include a new CA public key 101, an updated version number 102, an updated validity period 105, and a new signature value 106 calculated by using the RCA's private key. CA identification number 94 and RCA identification number 104 will remain unchanged. Upon receiving the alternative CA certificate 100, the translator validates the certificate by processing the certificate using the corresponding RCA public key contained in the RCA certificate 110 identified by the RCA identifier 104.

Root certificate management messages

After the RCA certificate 110 of the root certificate authority is revoked, the revoked RCA certificate must be replaced with a new RCA. As mentioned above, the RCA certificate is itself signed, so it is undesirable to include the RCA certificate in the CRL, since it is possible that a hacker may possess the certificate if he knows the private key used to sign the CRL. So, the decoder must be returned to the manufacturer each time the RCA certificate is updated, for example when it has become obsolete or revoked.

To overcome this problem, Root Certificate Management Messages (RCMM) are generated by the root certificate authority for broadcast by the broadcaster to the decoders. As explained in more detail below, the RCMN, like the CRL, contains a list 125 of the serial numbers of root certificates to be revoked, including, for each revoked root certificate, the time and date that the certificate was revoked, along with one or more alternative root certificates to those that have become outdated or represented in the list 125.

As will be seen, it is important from the perspective of the RCMM's sensitive content (new root certificate) to ensure that the RCMM is received by the decoder "when it is issued" to the broadcaster, i.e. to ensure that the RCMM's content does not change between distribution and reception. It is also important to ensure that the RCMM is accessed only by the decoder to which the RCMM is addressed.

To enhance security, at least some (preferably all) of the data included therein is addressed. RCMM contains at least two signature values, unlike CRL. Each signature value is computed using a key of a corresponding cryptographic algorithm, such as a private key of a public/private key pair.

The RCMM includes at least two signature values when it is issued by a Root Certificate Authority (RCA) and includes a new root certificate 110. Each signature value is calculated using the corresponding private key of the certificate supplied by the RCA (although any key equivalent to the key stored by the decoder may be chosen). If one of those certificate authorities is unknown, its private key is compromised, it is possible for a "hacker" to intercept the broadcaster's broadcast, and if he knows the private keys of the broadcaster and the certificate authorities, he may change the content of the RCMM and the signature value of the RCMM calculated by using the private key of the certificate authority. However, it is impossible for a hacker to change the signature value calculated by using the private key of other certificate authorities because this key is not compromised. Therefore, after the signature value is verified by the decoder by using the public keys of the two certificate authorities, the two values calculated by the decoder by using the respective public keys will not be the same. Therefore, the decoder will be prompted to: lack of integrity of the RCMM's content, and will reject the RCMM, or not proceed with the RCMM's processing.

Thus, the root certificate is securely updated as long as the number of leaked certificates is lower than the number of signatures contained in the RCMM. Therefore, the number of signatures of RCMM is a variable determined by the root certificate authority that distributes RCMM.

The format of the RCMM is now described in more detail with reference to fig. 10.

The RCMM130 includes:

an identifier 132 for the RCA of the RCMM 130;

date 134 of issuance of RCMM 130;

the number of signature values that the subsequent RCMM will contain 136;

a field 138 containing one or more updated or replacement root certificates to be stored in the translator;

a list 140 of the serial numbers of root certificates to be revoked, including: for each revoked root certificate, the time and date of revocation of that certificate; and

at least two signature fields 142, each of which contains:

an identifier 144 of the certificate stored in the decoder, which contains the public key, to be used to verify the signature value contained in the signature field; and

the signature value of the RCMM, which is calculated using a private key equivalent to the public key contained in the certificate identified by identification number 144.

The number of signature fields 142 should be equal to or greater than the number of signature fields 136 as suggested in the previously received RCMM.

Preferably, the RCMM is sent over an MPEG transport stream because the modem return channel can be easily disconnected or may not exist at all. The RCMM is preferably inserted by the broadcaster as a data file into the root directory 75 to ensure that the RCMM is downloaded by the decoder.

Processing and generation of root certificate management messages

The reception and processing of RCMM by the decoder will now be described with reference to fig. 11.

Upon receiving the RCMM, the decoder compares the date 134 on which the RCMM130 was issued with the date of the previously issued RCMM at step 200. If the date 134 of the newly received RCMM is not later than the date of the previous RCMM's release, the RCMM is rejected.

If the date 134 of the newly received RCMM is later than the date of receipt of the previous RCMM, the number 136 of signature values to be included by the newly received RCMM (as suggested by the previously received RCMM) is compared to the number of signature values actually included in the newly received RCMM at step 202. If the number of signature values contained in the newly received RCMM is lower than expected, the RCMM is rejected. This may prevent the RCMM from being processed by a hacker erasing the signature associated with the uncompromised private/public key pair.

If the number of signature values contained in the newly received RCMM is equal to or greater than the expected number of signatures, then each signature value 146 contained in the RCMM is verified using the public key identified by the identifier 144 contained in the same signature field 142 as the signature value at step 204. In step 206, the decoder determines whether at least one value calculated using the public key is different from any other value calculated using a different public key. The RCMM is rejected if at least one of the calculated values differs from at least one other calculated value.

If the integrity of the RCMM is certified at step 206, the RCMM is processed, storing the list 140 of the serial numbers of the revoked root certificates in the permanent memory of the translator at step 208 so that these certificates can be deleted from the memory of the translator, storing each root certificate contained in the field 138 in the permanent memory of the translator at step 210, and storing the date 134 of the RCMM in the permanent memory at step 212. If the certificate of the root certificate authority is deleted, any CRL issued by that authority is also deleted.

Preferably, the integrity of the permanent storage of the data contained in the RCMMZ is maintained if the decoder is switched off during processing of the RCMM message. So, if the power is intended to be turned off during PCMM processing, the list 140 associated with the previously processed RCMM stored in the decoder is maintained as if the new received RCMM message was not processed at all.

As previously described, the Root Certificate Authority (RCA) typically has at least two RCA certificates RC0 and RC1, which are stored in each translator. In the event that one of these certificates, say RC0, is compromised, it is necessary to replace all CA certificates stored in the translator (which have been signed by using a private key equivalent to the public key stored in RC0) and to generate a new RCA certificate RC2 in place of RC 0.

Referring to fig. 12, in order to replace these CA certificates, first at step 300, an appropriate CRL message indicating the serial number of the CA certificate to be revoked is issued by the RCA. Next, at step 302, the alternate CA certificate signed by using the private key of the non-compromised certificate RC1 is issued to the broadcaster for broadcast to the transcoder.

The leaked RCA certificate RC0 is then deleted and this certificate is replaced with a new RCA certificate RC 2. At step 304, RCA generates a new public/private key pair, inserts the new public key into certificate RC2 and de-signs the certificate by using the new private key.

At step 306, RCA generates an RCMM, which contains the certificate RC2 in field 138, and the string number of RC0 in manifest 140. At step 308, the RCMM is distributed to the broadcaster for transmission to the translator for deletion of the leaked certificate RC0 and replacement thereof with a new certificate RC 2.

The RCA certificates RC1 and RC2 would then be provided to the decoder manufacturer for hard coding into the memory of the new decoder.

It will be appreciated that the invention has been described above purely by way of example, and that modifications of detail can be made within the scope of the invention.

For example, the RCMM may include a new CA certificate 100 and/or a new broadcaster certificate 90 in addition to the new RCA certificate, and the manifest 140 may include an identification number of the CA certificate and/or broadcaster certificate to be revoked. This may enable avoiding separate CRL messages generated by the RCA.

Each feature disclosed in the description and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claims (4)

1. A method of authenticating a root certificate management message transmitted in a digital transmission system, the root certificate management message being an update of a previously transmitted root certificate management message, the method comprising the steps of:

receiving the root certificate management message, the root certificate management message including a date (130) on which the root certificate management message was issued and at least two encrypted values determined for at least some of the data in the root certificate management message, each encrypted value determined for the same root certificate management message using a key of a corresponding encryption algorithm;

determining (200) whether the date (130) on which the root certificate management message was issued is later than the date on which a previously sent root certificate management message was issued;

if the date (130) on which the root certificate management message was issued is later than the date on which the previously sent root certificate management message was issued, determining (202) whether the root certificate management message includes at least the expected number of signatures, otherwise rejecting the root certificate management message;

verifying (204) each encrypted value using the stored key of the respective encryption algorithm if the root certificate management message comprises at least the expected number of signatures, otherwise rejecting the root certificate management message;

determining (206) whether at least one value calculated using the stored key is different from any other value calculated by using a different key; and

rejecting the root certificate management message if at least one value calculated using the stored key is different from any other value calculated using a different key, otherwise the root certificate management message is verified.

2. An apparatus for authenticating a root certificate management message transmitted in a digital transmission system, the root certificate management message being an update of a previously transmitted root certificate management message, the apparatus comprising:

means for receiving said root certificate management message, said root certificate management message including a date (130) on which the root certificate management message was issued and at least two encryption values determined for at least some of the data in said root certificate management message, each encryption value being determined for the same root certificate management message using a key of a corresponding encryption algorithm;

means for determining whether the date (130) on which the root certificate management message was issued is later than the date on which a previously sent root certificate management message was issued;

means for determining whether the root certificate management message includes at least an expected number of signatures if the date (130) on which the root certificate management message was issued is later than the date on which a previously sent root certificate management message was issued, and rejecting the root certificate management message otherwise;

means for verifying each encrypted value using the stored key of the corresponding encryption algorithm if the root certificate management message includes at least the expected number of signatures, and otherwise rejecting the root certificate management message;

means for determining whether at least one value calculated using the stored key is different from any other value calculated by using a different key; and

means for rejecting the root certificate management message if at least one value calculated using the stored key is different from any other value calculated using a different key, and otherwise validating the root certificate management message.

3. A method of authenticating (46, 60) a root certificate management message sent in a digital transmission system (1), characterized in that the method comprises, before transmission, the steps of:

determining at least two encryption values (146) for at least some of the data in the root certificate management message, each encryption value (146) being determined for the same root certificate management message using a key of a respective encryption algorithm;

determining a date (130) on which the root certificate management message was issued; and

outputting the at least two encrypted values (146) and date (130) in the root certificate management message.

4. An apparatus for authenticating root certificate management messages sent in a digital transmission system (1), characterized in that it comprises:

means for determining at least two encryption values for at least some of the data in the root certificate management message, each encryption value being determined for the same root certificate management message using a key of a respective encryption algorithm;

means for determining a date (130) on which the root certificate management message was issued; and

means for outputting the at least two encrypted values (146) and date (130) in the root certificate management message.