Authentication of data transmitted in a digital transmission system

Authentication of data transmitted in a digital transmission system

The present invention refers to a method of authentication of the data transmitted in a system of digital transmission

The emission of digital data is well known in the scope of pay-TV systems, in which it is sent encoded audiovisual information, usually through a link via satellite or satellite / cable, to various subscribers, each of the which has a decoder capable of decoding the program transmitted for later viewing. Also known are ground transmission systems. Some recent systems they have also used the transmission link to transmit other data in addition to audiovisual data, such as programs computer or interactive applications to a decoder or PC that is connected

A special problem in data transmission of applications is in need of verifying the integrity and origin of such data. Since they can be used data of this type to reconfigure the decoder, as well as to carry out any number of interactive applications, it is It is essential that the data received is complete and identified as coming from a known source. Of what Otherwise, operational problems related to the download of incomplete data, as well as the risk that the decoder remain open to attacks by third parties or Similar.

Verification of the integrity of said data can be carried out by verifying the packet flow of data received directly by the decoder. Before to the transmission, the packages usually are signed by means of the application of a chopping algorithm to at least part of the package data. The resulting chopped value is stored in the package. Upon receiving the data packet, the decoder applies to the data the same slicing algorithm and compare the chopped value calculated by the decoder with the chopped value stored in the package received in order to verify the integrity of the data received For example, in case of failure or interruption of the transmission, the calculated chopped value will not be the same as the chopped value received. Then the decoder will be alerted about the presence of possible errors in the downloaded data package and the defective data packet will be reloaded.

A problem associated with the use of an algorithm well known chopper, such as the "Message Digest" algorithm MD5 ", is that the calculation of the chopped value is carried out in according to a series of publicly known calculation steps, with the result that anyone can calculate the chopped value of A packet of data. Therefore, it will not be possible to verify the origin of a data packet received by the decoder. This It may be especially important when the data received modify the operating data files of the decoder.

To overcome this problem, instead of using a chopping algorithm to calculate a chopped value for at least a part of the data, a signature value of a data packet using a known secret key value only by the issuer. This key can be obtained using an algorithm of symmetric key, such as the "Data Encryption Standard" algorithm [data encryption standard] "or DES algorithm, storing the decoder an equivalent key. However, it can be more convenient to use a public / private key algorithm asymmetric, such as the algorithm of Rivest, Shamir and Adleman, or RSA, in which public and private keys form components Complementary to a mathematical equation.

The transmitter responsible for developing The data packets stores the private key and calculates the value signature using the private key. The public key is stored in the decoders that will receive the data, encoding by hardware the public key in the decoder memory during the manufacturing process. Upon receiving the data packet, the decoder verifies the value of the signature using the key public stored by comparing the received data with the result of the application of the public key algorithm to Signature value received.

Even in these secure systems it is possible that the value of the private key is in danger, for example, of being publicly distributed illegally. In these cases, it is it is necessary for the transmitter to quickly revoke the use of the key public equivalent to prevent unauthorized receipt of data packets In addition it will also be necessary to use a new public / private key pair. Therefore, the issuer must replace the public key stored in the decoders of the legal users for a new public key. Depending on the public key sensitivity, this operation may require that the issuer must take care of organizing the expensive and problematic return of these decoders to the manufacturer for the hardware coding of the new public key in the memories of these decoders.

GB 2301919 describes a system of multi-stage signatures that uses multiple devices signature to stamp a single signature that can be verified using a single public verification key. Each signing device owns a part of the signature key and stamps a partial signature in response to the authorization of a plurality of agents of authorization. System security is enhanced by the distribution of the ability to stamp signatures between a plurality of signing devices and by distributing the authority to stamp a partial signature between a plurality of Authorization agents However, in the case of simulation of the private key, all recipients will have to update the public verification key, which can be expensive and tedious, especially when, as described above, the key is encoded by hardware, for example in a decoder

The present invention, at least in its preferred embodiments, try to solve these and other problems facilitating a solution resistant to the simulation of a key private

A first aspect of the present invention provides a method to authenticate the data transmitted in a digital transmission system, including said method, with prior to transmission, the following stages:

determination of at least two encrypted values for at least part of the data, determining each value encryption for the same data, using an algorithm key respective encryption, and

the output of at least said two values Encrypted with such data.

The present invention is especially applicable, without limitation, to situations in which it is desirable securely update sensitive data, such as a key that goes to be used in a new encryption algorithm, in order to ensure that the data is received as it has been sent. To facilitate such security, at least two encrypted values ​​are determined for at less a part, preferably most and more preferably The totality of the data. Each encrypted value is determined using a key of a respective encryption algorithm. Yes one of the keys is in danger, it can be a hacker may intercept the data and modify the content of the data and the encrypted value calculated using The key in danger. However, it will not be possible for the pirate change the encrypted value calculated using the key That is not in danger. Therefore, when verifying the values encrypted, using keys equivalent to the keys used to calculate the encrypted values, the two values ​​they use the equivalent keys will not be the same, which will indicate that the data has been corrupted.

Therefore, the present invention extends to a method of authentication of the data transmitted by means of a digital transmission system, including said method the following stages:

receipt of said data and at least two encrypted values ​​determined for at least part of the data, determining each encrypted value for the same data using a key of an encryption algorithm, respective;

storage of a plurality of keys;

processing of each encrypted value using a stored key of said respective encryption algorithm; and

comparison of each subsequent resulting value with at least that part of the data to authenticate at least That part of the data.

The present invention also provides a apparatus for authentication of the data to be transmitted in a digital transmission system, including said apparatus:

means to determine at least two values encrypted for at least part of the data, being determined each value encrypted for the same data using a key of a respective encryption algorithm; and

means to obtain with said data at least said two encrypted values.

The present invention extends to a receiver / decoder that includes:

means for receiving a data file which includes data and at least two encrypted values ​​determined to at least part of the data, each value being determined encryption for such data using a key of an algorithm of respective encryption;

means for storing a plurality of keys;

means to process each encrypted value using a stored key of said encryption algorithm respective; and

means to compare each resulting value subsequent with at least part of the data to authenticate at least that part of the data.

The term "receiver / decoder" or "decoder" as used in this document may indicate a receiver for receiving coded signals or without encode, for example television and / or radio signals that can be issued or transmitted by some other means. Between the embodiments of said receivers / decoders can be included a decoder integrated in the receiver to decode the received signals, for example in a "home decoder", said decoder operating in combination with a receiver physically independent or a decoder that includes functions additional, such as a web browser, or that is integrated with others devices such as a video recorder or a television.

As used herein, the term "digital transmission system" includes any transmission system for transmission or emission, for example, of basically audiovisual or digital multimedia data. Although the This invention is especially applicable to a system of digital television, the invention may also be applicable to a fixed telecommunications network for multimedia applications to via the Internet, to a closed circuit television, etc.

As used herein, the term "digital television system" includes, for example, any satellite, terrestrial, cable transmission system and of another type.

Among the most appropriate algorithms to be used in this invention in order to generate keys private / public symmetric RSAs may be included, Fiat-Shamir or Diffie-Hellman, and between the appropriate symmetric key algorithms can DES algorithms are included, for example. However, to unless mandatory in context view or specified otherwise, no distinction is made in general between the keys associated with symmetric algorithms and those associated with public / private algorithms.

The terms "coded" and "encryption" as well as "control word" and "key" in various parts of the text for clarification purposes. However, it understand that no fundamental distinction is made between "encrypted data" and "encrypted data" or between "control word" and "password".

Additionally, the terms have been used "encrypted" and "signed" and "decrypted" and "verified" in various parts of the text for the purpose of clarification. However, it will be understood that no fundamental distinction between "encrypted data" and "data signed "or between" decrypted data "and" data verified. "

Similarly, the term "equivalent key" it is used to name an adapted key to decipher the data encrypted by a key mentioned first or vice versa.

The characteristics described above relating to aspects of the method of the present invention also They can be applied to material aspects and vice versa.

It will be described below, only by way of example, a preferred embodiment of the invention by making reference to the attached figures, in which:

Figure 1 shows the schematic diagram of a digital television system for use with this invention.

Figure 2 shows the structure of a system decoder of figure 1.

Figure 3 shows the structure of various MPEG emission transport flow components;

Figure 4 shows the division of an application of software in various MPEG tables.

Figure 5 shows the relationship between DSM-CC data files and MPEG tables eventually generated.

Figure 6 shows the relationship between customer, server and network manager as defined in the context of DSM-CC

Figure 7 shows the objects, directory, Authenticated subdirectory and file.

Figure 8 shows the formats of a issuer certificate, a certificate of certification authority and a certificate of root certification authority.

Figure 9 shows the format of a list of revocation of certifications.

Figure 10 shows the format of a message of root certificate management (RCMM).

Figure 11 shows the corresponding stages to the processing of an RCMM upon receipt by a decoder

Figure 1 shows the scheme of a digital television system 1 in accordance with this invention. The invention includes a basically conventional system of digital television 2 that uses the well-known system of MPEG-2 compression to transmit digital signals compressed In more detail, the MPEG-2 compressor 3 from a sending center receives a flow of digital signals (usually a chain of digital signals). Compressor 3 is connected to a multiplexer and encoder 4 via the connection 5.

The multiplexer 4 receives a plurality of signals digital input, assemble the transport stream and transmit compressed digital signals to a transmitter 6 of the center of emissions through connection 7, which of course you can adopt a wide variety of ways, including a link to telecommunications The transmitter 6 transmits signals electromagnetic through the uplink 8 towards a satellite transponder 9 where they are electronically processed and emitted through a notional downlink 10 to the receiver terrestrial 12, conventionally in the form of a satellite dish property of the end user or rented by it. The signs received by receiver 12 are transmitted to a integrated receiver / decoder 13 owned by the end user or rented by this and that is connected to television 14 of the end user. The receiver / decoder 13 decodes the signal compressed MPEG-2 on a television signal for the television set 14.

Of course, other channels of transport for data transmission, such as terrestrial emission, cable transmission, satellite / cable combo links, telephone networks, etc.

In a multichannel system, multiplexer 4 manages audio and video information received from various parallel sources and interacts with transmitter 6 to emit the information through the corresponding number of channels. further of audiovisual information, messages or applications or any other type of digital data can be entered in some or all of these channels intertwined with the transmitted digital audio and video information. In this case, the Compressor 3 will compress and package in MPEG format a flow of digital data in the form, for example, of messages and files of software in DSM-CC format (Digital Storage Media Command and Control [Control and storage media command digital]). The download of the software modules will be described at continuation in greater detail.

A conditional access system 15 connects to the multiplexer 4 and receiver / decoder 13 and is located partially in the issuing center and partially in the decoder Allows the end user to access broadcasts of digital television from one or more providers of emissions A smart card capable of decrypting messages relating to commercial offers (i.e. one or more programs TV sold by the broadcast provider) can Insert into receiver / decoder 13. Using the 13 decoder and smart card, the end user can acquire commercial offers either in the subscription mode or in a modality of payment by vision. In practice, the decoder can be configured to manage multiple access control systems, for example of the Simulcrypt or Multicrypt design.

As mentioned above, the programs transmitted by the system are encoded in the multiplexer 4, the conditions and access codes being determined applied to a transmission given by the access control system 15. Thus, the transmission of encoded data is very known in the field of pay TV systems. Usually, encoded data is transmitted along with a word from control for the decoding of the data, meeting the own control word encrypted using the so-called key of exploitation, transmitted in encrypted format.

The encoded data and the control word Encrypted are received in decoder 13, which has access to a equivalent of the exploitation key stored on a card smart inserted into the decoder to decipher the word of encrypted control and subsequently decode the data transmitted. A subscriber who is up to date with payments you will receive, for example, in an EMM (Entitlement Management Message [authorization management message]) issued the password monthly of exploitation needed to decipher the control word encrypted to allow you to watch the stream. In addition to his use for decryption of television programs audiovisual, can generate and transmit keys of similar exploitation to verify other data, such as modules software, as will be described later.

An interactive system 16, which is also is connected to multiplexer 4 and receiver / decoder 13 and that is also partially located in the center of emissions and partially in the decoder, allows the user final interact with various applications through a channel of modem return 17. The modem return channel can also be used for communications used in the access system conditional 15. For example, an interactive system can be use to allow the viewer to immediately communicate with the transmission center to request authorization allow to see a specific event, download an application, etc.

Physical elements of the Receiver / Decoder

Referring to figure 2, the elements Physical receiver / decoder 13 or home decoder adapted for use in the present invention will be described briefly below. The elements shown in this figure are will describe by functional blocks.

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

The decoder is further adapted to receive inputs from a remote control of infrared 25 through a control unit 26 and through the switches 24 located in the central panel of the decoder. The decoder also has two card readers smart 27, 28 adapted to read smart cards, bank and credit 29,30, respectively. The entrance too It can be received via an infrared keyboard (not shown). The subscription smart card reader 28 interacts with a subscription card inserted 30 and with an access unit conditional 29 to supply the necessary control word to a demultiplexer / decoder 30 to allow decoding of the encrypted broadcast signal. The decoder also includes a Conventional tuner 31 and a demodulator 32 to receive and demodulate the satellite transmission before being filtered and demultiplexed by unit 30.

The data processing inside the decoder is usually managed by the central processor 20. The Central processor software architecture corresponds to a virtual machine that interacts with an operating system of lower level performed on the hardware components of the decoder

Package Structure of Transmitted Data

It will be described below, making reference to figures 3 and 4, the data package structure included in the MPEG transport stream sent from the Transmitter to decoder. As will be observed, although the description is going to focus on the tabulation format used in the MPEG standard, the same principles are equally applicable to other formats of packet data flows.

With particular reference to Figure 3, a MPEG bitstream includes a program access table ("PAT") 40 that has a package identifier ("PID") of 0. The PAT contains references to the PIDS of the program map tables ("PMTs") 41 of various programs. Each PMT contains a reference to the PIDs of the flows of the MPEG 42 audio tables and MPEG 43 video tables corresponding to said program. A package whose PID is zero is that is, the program access table 40 provides the point of access for all MPEG accesses.

In order to download applications and data for this, two new types of flows are defined, and the corresponding PMT also includes references to the PIDs of the MPEG tables of applications (or sections of these) and from MPEG data tables 45 (or sections thereof). From In fact, although in some cases it might be convenient to define types of independent streams for the executable software of applications and data for the processing of said software, this It is not essential. In other embodiments, the data and the code executable can be assembled in a single flow that is accessed through the PMT, as already described.

Referring to figure 4, to be able to download, for example, an application included in a stream 44, the application 46 is divided into modules 47, each of which is formed by an MPEG table. Some of these tables include a single section, while others may consist of a plurality of sections 48. A typical section 48 includes a header, which in turn includes a table identifier ("TID") of one octet 50, the section number 51 of said table section. The total number 52 sections of that table and a reference to the TID extension of two octets 53. Each section it also includes a data component 54 and a CRC 55. For a specific table 47, all sections 48 constituting said Table 47 has the same TID 50 and the same TID extension 53. For one specific application 46, all tables 47 constituting said application 46 have the same TID 50, but different TID extensions respective.

For each application 46, only one is used MPEG table as directory table 56. Directory table 56 it has in its header the same TID as the rest of the tables 47 that They constitute the application. However, the directory table has a default TID extension of zero, for the purpose of identification, and due to the fact that only one is necessary table for information in the directory. The rest of the others Tables 47 will normally have non-zero TID extensions, and they consist of several associated sections 48. The header of the directory table also includes a version number of the application to download.

Referring again to Figure 3, the PAT 40, PNTs 41 and application components and data flow 44, 45 are transmitted cyclically. Each application transmitted It has its respective default TID. To download one application, the MPEG table that has the appropriate TID and an extension Zero TIDs are downloaded to the receiver / decoder. This is the Directory table corresponding to the requested application. The data contained in the directory is then processed by the decoder to determine the TID extensions of the tables which constitute the required application. Later, you can download any required table that has the same TID that the directory table and a TID extension determined from of the directory.

The decoder is set to verify any update of the directory table. This operation can be carried out by periodically downloading the table of directories, for example, every thirty seconds, or every minute or every five minutes, and comparing the version number of the table of previously downloaded directories. If the version number that just downloaded corresponds to a later version, it delete the tables associated with the previous directory table and the tables associated with the new one will be downloaded and assembled version.

In an alternative configuration, the flow of Incoming bits are filtered using a mask corresponding to the TID, to the TID extension and to the version number, with values configured for the application TID, a TID extension of zero and a version number greater than the directory version number currently downloaded Therefore, the increase of the version number, and once detected, the directory is downloaded and The application is updated, as described above. Yes an application must be terminated, an empty directory is transmitted with the next version number, but without any module appearing listed in the directory. In response to receipt of said empty directory, the decoder 2020 will be programmed to erase the application.

In practice, software and programs software for the implementation of applications in the decoder can be entered through any of the decoder components, and especially in the data stream received through the satellite link, as already described, but also through the serial port, the smart card, etc. Such software may include high-level applications used. to implement interactive applications inside the decoder, such as Internet browsers, contest applications, guides programming, etc. The software can also be downloaded for change the working settings of the decoder software, for example, using "patches" or the like.

Applications can also be downloaded to through the decoder and sent to a PC or similar connected to the decoder In this case, the decoder acts as a router of communications for the software, which eventually runs on The connected device. In addition to this routing function, The decoder can also work to convert the data into MPEG packets before routing them to the PC as software formed by files organized, for example, according to the protocol DSM-CC (see below).

Organization of data in data files

Figure 5 shows the relationship between data organized in a set of data files DSM-CC-UU (user to user) 60, in an application assembled 46 and encapsulated in a series of MPEG tables 47. This relationship is described in the document WO99 / ​​49614, whose contents are incorporated into this document by reference

Prior to transmission, the files of data are assembled in application 46 and subsequently a MPEG compressor packages them in MPEG 47 boards or modules, as has been described above, including a specific header 49 of the MPEG packet flow and including the table ID, the number of version, etc. As you can see, there may not be a relationship fixed between the data organized in the data files 61 and the possible MPEG tables 47. Upon receipt and filtered by the decoder, packet headers 49 and the application 46 is reconstructed from the useful data of the tables 47.

The corresponding DSM-CC format to data files is a norm adapted in particular for your use in multimedia networks, and that defines a series of formats message and session commands for communication between a client user 70, a server user 71 and a resource manager network 72, as shown in Figure 6. The resource manager of network 72 can be considered as a logical entity that acts to manage the allocation of resources within a network.

Communication between a client and a server is established through a series of sessions, exchanging a first series of messages between a user (client 70 or server 71) and the network manager 72, in order to configure the client and / or the server for communications. These messages are formatted from according to the protocol called DSM-CC UN (user to network). It has specially defined a subset of this protocol for downloading data using issue.

Once a link has been established communications, messages are subsequently exchanged between the client 70 and server 71 according to the protocol DSM-CC UU. A sequence of messages of this type correspond to data files 60 of the Figure 5. In the case of DSM-CC messages UU, the data is organized in a series of messages 61 grouped according to the BIOP protocol (Broadcast InterOrb Protocol [Issuer InterOb protocol]).

Each message or object 61 includes a header 62, a sub-header 63 and some useful data 64, which They contain the data themselves. According to the BIOP protocol, the header 62 contains, among other things, an indication of the type of message and the BIOP version while the sub-header indicates the type of object and other information to be defined by the system architect.

The data objects 64 with the useful data of DSM-CC UU files can generally defined as belonging to one of three types: directory objects, archive objects and flow objects. The Directory objects define root directories or subdirectories used to serve as a reference to a series of objects of associated file containing the actual data of the application.

Flow objects can be used to activate a temporary relationship that is established between the data contained in the data files and in the package flow itself MPEG This can be used, for example, in the case of interactive applications contained in the data files and designed for synchronization with elementary video streams or audio received and processed by the decoder. How has it mentioned above, otherwise there may not be a Direct correlation between data in MPEG packets and files of data.

Unlike MPEG tables, when a single directory refers to a set of tables with a single level hierarchy, data files 60 can be organized in one hierarchical form much more complex. As in the case of files stored on a PC or server, a directory main or root can refer to one or more subdirectories, which in turn refer to a second level of data files. You can even refer to a second root directory associated with another set of application data.

File structure for a set of files data

Referring to figure 7, a Example file structure for a set of files. A root directory DIR A0 indicated with the number 75 establishes a relationship between a group of subdirectories A1 and object files 77. To offer greater clarity, only one is shown group of object files F1, F2, etc. associated to the subdirectory A4. In practice, reference can be made to various groups of object files through each of the subdirectories A1 to A4.

Within each directory and subdirectory is introduces a series of authentication steps for files linked to that directory. Referencing the directory root 75, subheading 63 includes a chopped value obtained by applying a slicing algorithm to a part or all the data stored in the archives of the subdirectory A1 to A4, indicated with reference 76. The algorithm Chopping used may be of any known type, such as for example, the "Message Digest MD5" algorithm.

In one embodiment, the algorithm can be applied. to each file or subdirectory associated individually, storing a ratio of the chopped values ​​for each subdirectory 76 in the root directory 75 before the transmission. However, although this solution allows a degree higher verification resolution, in relation to the verification of each subdirectory, this solution can be quite inefficient in terms of the processing time needed to have the decoder calculate the corresponding signatures. Thus, subhead 63 of directory 79 preferably comprises a cumulative chopped value 79, calculated by applying the MD5 chopping algorithm to the combination of subheadings and sections of useful data 63, 64 of subdirectories 76, that is, without the header 62. Specifically, the chop values ​​82 included in subdirectories 76 and that refer to the object layer File 77 are included in this chopping calculation.

In the case of subdirectory A4 shown in the Figure 7, this subdirectory refers to a set of files from F1-Fn object indicated with reference 77. This value is included in the chopping process that gives rise to the value chopped 79. Therefore, it is not possible to change any of the object files 77 without changing the chopped value 82 of the subdirectory 76, which in turn will modify the value cut 79 from directory 75.

In the current case, a chopped value is calculated combined for all subdirectories A1-A4 at which is referenced in the directory. This chopped value is stores together with an identifier of the subdirectory group of the which data has been taken. In other embodiments, it may a series of values ​​of chopped combined or individual and corresponding identifiers

For example, a second series of directories, also associated to the root directory, but which refer to a different set of data or executable code can also grouped together, and a cumulative chopped value is calculated for these directories, being stored in the root directory of the subhead. A single chopped value associated with a single directory can also be stored in the subhead of the root directory.

Authorization of groups or data files individual does not prevent, of course, the root directory (or, of done, to any other file) that also refers to data files not validated or not submitted to the process of chopped, but the absence of validation of said file must be taken into account during any operation with said file. TO in this respect, it may not be necessary, for example, to authenticate The objects of the flow.

In this case, the use of the chopping function allows the decoder to verify the integrity or degree of Accuracy of downloaded data files. In the case, for example, of a transmission failure or interruption, the operation of a cumulative chop algorithm on Dependent files received will not yield the same results that the chopped value corresponding to these stored files in the root directory. The decoder will then be alerted about the presence of possible errors in the downloaded data and They will reload the defective data files.

Signature value for the root directory

For greater security, a value of signature for root directory 75. In this embodiment a private / public key algorithm such as Rivest, Shamir and Adleman, or RSA, being the issuer responsible for generating the data files that have the value of the private key, being The public key values ​​are stored in the decoders. Alternatively, the secret key may correspond to a key obtained by means of a symmetric key algorithm, such as the Data Encryption Standard or DES algorithm data).

As shown in Figure 7, the directory root 75 comprises an identifier of the issuer 80 that will identify the decoder the public key to be used during the stage of verification, together with the calculated signature value 81, generated using the sender's private key. In this case, the value of the Signature 81 is generated by applying the private key held by the issuer to a part or all of the data in directory 75, preferably including useful data 64 and / or the value or cumulative chop values ​​79. Next, the decoder can verify this signature value 81 using the corresponding public key identified by the identifier of the issuer 80.

In this example, the data found in the 75 directory is unencrypted and the public key is used simply to provide a verifiable signature value by the public key In alternative embodiments, a part or the All the contents of the directory can be encrypted by the private key and be decrypted later using the key correspondent.

In either case, the generation of a signature value or a block of encrypted code by using a secret key allows a decoder to verify the integrity and the origin of directory 75 and, by implication, integrity and source of the files to which this root directory refers. Because the cumulative chopping values ​​for the files of reference are included in the calculation of signature 81, it is not possible to alter these values ​​without it being detected in the verification stage Because each value cut is generally unique for a given set of data, therefore not it would be possible to modify the contents of any file dependent subject to slicing without changing its chopped value characteristic and, therefore, the signature value resulting from a directory.

As you can see, various possible variations, especially to reduce the amount of data that is They are chopped or signed at each stage. In particular, in the case of a signature or value cut into a directory or subdirectory used to verify a lower level data file, the signature of the directory or the value cut may be generated using only the lower level chopped value, and not others data.

For example, the combined chopped value 79 in the A0 75 directory can be generated using the chopped values combined 82, 83 of each of the subdirectories A1-A4 indicated in 76. Since these values ​​have the same uniqueness as the data included in the useful data of the subdirectory, the combined chopped value 79 will remain unique for the subdirectories in question. In addition, you can continue assuming the integrity of the lower level of the files of object and directory 77, 78, because the chop values ​​82 They are still used for calculation.

Issuer digital certificates

Referring to figure 8, the key public 91 and sender identifier 80 are provided to the user of the decoder in a digital certificate, preferably under the form of the well-known X.509 standard of the International Standards organization (ISO), coded by hardware in the memory of the decoder during its manufacture. These certificates are distribute among decoder manufacturers through trusted third parties, which are usually referred to as Certification Authorities (CAs). The use of these certificates is increasingly widespread, basically due to Secure Socket Layer (SSL) transport protocol [connection layer secure], developed by Netscape Communications to ensure credit card transactions through the World Wide Web (WWW)

Like public key 91 and the issuer identifier 80, the digital certificate associated with the issuer, or issuer certificate 90, also includes:

<dl><dt>?</dt><dd>A version number 92 of the issuer certificate 90;</dd></dl>

<dl><dt>?</dt><dd>A serial number 93 of issuer certificate 90;</dd></dl>

<dl><dt>?</dt><dd>A CA 94 identity of the CA that distributed issuer certificate 90;</dd></dl>

<dl><dt>?</dt><dd>The validity period 95 of the issuer certificate 90 to indicate the beginning and end of period of time during which it is intended to use the certificate; and</dd></dl>

<dl><dt>?</dt><dd>A signature value 96 of issuer certificate 90.</dd></dl>

As will be seen in the preceding paragraphs, the issuer certificate includes two different identifiers, a first identifier of the "name of the shipper", which corresponds to the identity 94 of the certificate distributor, and a second "argument name" identifier, corresponding to identifier 80 that identifies the public key 91.

The CA calculates the signature value 96 of the issuer certificate 90, applying a private CA key, or a private CA key, at least part or all of the data included in the issuer certificate. Then the decoder can verify this signature value 96 through the signature processing using the corresponding key CA 101 public identified by the identity of CA 94, in order to determine that the contents of the certificate have not been modified after signing by the CA.

The decoder can store a plurality of said certificates for the different respective issuers.

Digital Certificates of the Certification Authority

Referring again to Figure 8, the corresponding CA public key 101 and the CA 94 identifier are provide the decoder user with a CA 100 Certificate, which it is also hardware coded in the decoder during its manufacturing. The CA 100 Certificate also includes:

<dl><dt>?</dt><dd>A version number 102 of the CA 100 certificate;</dd></dl>

<dl><dt>?</dt><dd>A serial number 103 of the CA 100 certificate;</dd></dl>

<dl><dt>?</dt><dd>An RCA identity 104 of the Root Certificate Authority (RCA), such as the European Telecommunications Standard Institute (ETSI), which distributes the CA 100 certificate</dd></dl>

<dl><dt>?</dt><dd>The validity period 105 of the CA 100 certificate; and</dd></dl>

<dl><dt>?</dt><dd>A signature value 106 of CA 100 certificate.</dd></dl>

As can be seen from the foregoing, a CA certificate also includes two different identifiers, a first identifier "issuer name" that corresponds with the identity 104 of the certificate distributor, and a second "argument name" identifier corresponding to identifier 94 that identifies the public key 101.

The RCA calculates the signature value 106 of the CA 100 certificate applying an RCA private key, or key private RCA, at least part or all of the data included in the CA certificate. Then the decoder You can verify this signature value 106 by processing the certificate by using a corresponding RCA public key 111 identified by identity RCA 104, in order to determine yes the contents of the certificate have not been modified with after signing by the RCA.

The decoder can store a plurality of said certificates for different respective CAs.

Root Certification Authority digital certificates

The corresponding public key RCA 111 and the RCA identifier 104 is provided to the user of the decoder in an RCA, or root certificate 110, which is also encoded via hardware in the decoder's memory during its manufacturing. Normally, each decoder includes a set of Two or more root certificates. Each root certificate 110 also It includes:

<dl><dt>?</dt><dd>A version number 112 of root certificate 110;</dd></dl>

<dl><dt>?</dt><dd>A serial number 113 of root certificate 110;</dd></dl>

<dl><dt>?</dt><dd>The period of validity 114 of root certificate 110; and</dd></dl>

<dl><dt>?</dt><dd>A signature value 115 of root certificate 110.</dd></dl>

As can be seen from the foregoing, the root certificate only includes a unique identifier, namely Identity 104 of the certificate distributor. This identity 104 also identifies the public key 111. In this way, it can define a root certificate as a certificate in which the Issuer name is the same as the name of the argument.

As the root certificate is the final certificate in the chain formed by the issuer certificate 90 -certified CA 100- root certificate 110, the root certificate is self-signed, that is, the signature value is Calculate using the private key equivalent to the public key 111. Therefore, it is very important that the contents of a root certificate.

Of course, the RCA may facilitate directly issuer certificates 90 to the manufacturer of the decoder, in which case the issuer certificate will contain the RCA 111 identifier and will be signed using the private key RCA

Certificate revocation list

Any of the issuer certificates 90 and of CA 100 certificates can be revoked, for example, by deleted, prior to the end of the period of validity specified in them yes, for example, a private key corresponding to the public key stored in the certificate. Such revocation can be done through the transmission to the decoder of a revocation list of Certificates (CRL) containing a list of serial numbers 92, 102 of the certificates to be revoked. When it is done revocation, the certificate is no longer usable, which prevents downloading any unauthorized data packet, and possibly malicious, that has been generated using the key Private in danger.

CRLs are distributed through a CA or RCA to the sender, which transmits the CRLs to the decoders well via the modem return channel or by issuing the CRLs through the MPEG transport stream. It is not essential that the sender insert CRLs in all transport flows sent from the sender to the decoder; it is enough that the issuer insert CRLs into transport flows that are very likely to are going to be tuned by the decoders. For example, you can insert a CRL as a data file in a root directory 75 or subdirectory 76 of a set of issued data files from the transmitter to the decoder.

In relation to Figure 9, a CRL 120 normally includes:

<dl><dt>?</dt><dd>The identity 94 or 104 of the CA or of the RCA that distributed the CRL 120;</dd></dl>

<dl><dt>?</dt><dd>The date 122 on which issued CRL 120;</dd></dl>

<dl><dt>?</dt><dd>The date 124 on which expects the following CRL to be issued;</dd></dl>

<dl><dt>?</dt><dd>A list 125 of the numbers of series of certificates to be revoked, including for each certificate revoked the date and time of the revocation of said certificate; and</dd></dl>

<dl><dt>?</dt><dd>A signature value 126 of the CRL, calculated using the private key of the CA or RCA that distributed CRL 120.</dd></dl>

Upon receipt of a CRL, the decoder compares the date 122 on which CRL 120 was issued with date 124 on the which said CRL 120 was expected, as notified by the CRL previously received. If the CRL date 122 just received is not later than date 124 on which said expected CRL, the CRL is ignored.

If the CRL date 122 received recently is later than date 124 on which the CRL was expected, it verify the signature of the CRL using the issuer's public key of the CA identified by identity 94 or 104 contained in the CRL

If the integrity of the CRL, the CRL will be processed to add the date 124 in order to store in permanent memory the date 124 on which the issuance of the following CRL, and to store list 125 of the serial numbers of revoked certificates. The list received 125 revoked certificates are also stored in memory Permanent decoder. For performance reasons, it prefer that the CRL 120 remain in the cache of the decoder It is also preferred that the cache of the decoder store the CLRs 120 in an arborescent manner, while located the CRL of the RCA at the top of the tree and the CRLs of the CAs to which the RCA distributes certificates in the part lower tree.

In the case of a revocation of a certificate of Issuer 90, for example, if the issuer's private key were in danger, the Certification Authority of said issuer will add the serial number 93 of the issuer's certificate 90 to its CRL 120. The Certification Authority subsequently distributes the new CRL 120 to all issuers to which it distributes certificates of transmitter 90 for transmission. As soon as the decoder has downloaded the new CRL 120, for example, when zapped by the channel of a sender, the CRL of the cache is updated and taken to revoke any certificates identified as such in list 125 of CRL 120.

The replacement issuer certificates 90 are generated by the Certification Authority 100 and transmitted to user in a 75 or 76 directory of a file. The certificate of replacement issuer will include, among other things, a new key public 91, an updated version number 92, a period of updated validity 95, and a new signature value 96 calculated using the private key of the CA. The issuer identifier 80 and the identifier of CA 94 will remain unchanged. Upon receiving the replacement issuer certificate 90, the decoder verify the certificate by processing it through the corresponding CA public key contained in the CA certificate identified by the identity CA 94.

When you revoke a CA 100 certificate, the CRL of said AC of the decoder memory. Thus, it may be desirable to voluntarily revoke a CA 100 certificate if, for example, the CRL size of that CA is too long for storage in the decoder cache. In In this case, the RCA that distributes the CA 100 certificate to that CA add serial number 103 of said CA 100 certificate to your CRL. The Root Certification Authority subsequently distributes the new CRL to all issuers to which the CAs to which distributes CA certificates said RCA distribute in turn issuer certificates for transmission. As soon as a decoder has downloaded the new CRL, for example, when zapping by the channel of a sender, the CRL cache is updated and the revocation of CA certificates identified as such in the CRL list 125 120.

Upon revocation of a CA certificate 100 of a Certification Authority, in addition to the storage of a new CA certificate for said Certification Authority in the decoder, it is necessary to replace the issuer certificates 90 for all issuers among which said Authority of Certification distributes certificates since, having ceased to be valid the pair of private keys corresponding to said Authority of Certification, new issuer certificates 90 will be required, signed by a different or updated private key of the Certification Authority The Root Certification Authority 110 generates a replacement CA 100 certificate and sends it to the user in a 75 or 76 directory of a file. Like a certificate of replacement issuer, the replacement CA certificate will include, among other things, a new public key CA 101, a number of updated version 102, an updated validity period 105 and a new signature value 106 calculated using the private key of the RCA The identifier CA 94 and the identifier RCA 104 will remain without changes. Upon receiving the replacement CA 100 certificate, the decoder verifies the certificate, processing it through the corresponding RCA public key contained in the RCA certificate 110 identified by RCA identity 104.

Root Certificate Management Message

When you revoke an RCA 110 certificate from a Root Certification Authority, it is necessary to replace the RCA certificate revoked with a new RCA. As described previously, RCA certificates are self-signed and, therefore therefore, it is not desirable to include an RCA certificate in a CRL, since it is possible that a hacker comes into possession of the certificate if you know the private key used to sign the CRL. Therefore, until now it has been necessary to return the decoder to the manufacturer each time a RCA certificate, for example when it had expired or had expired revoked

To overcome this problem, the Authority of Root Certification generates a Root Certificate Management Message (RCMM) for transmission to decoders through the emitters As explained in more detail below, an RCMM, at Like a CRL, it contains a list 125 of the serial numbers of the root certificates to be revoked, including for each root certificate revoked the date and time of revocation of said certificate, together with one or more replacement root certificates corresponding to those certificates that have expired or are They are identified in list 125.

As can be seen, due to sensitivity of the content (new root certificates) of the RCMM, it is very important ensure that the decoder receives an RCMM as it has been issued to the issuer, that is to ensure that the contents of the RCMM have not changed between its distribution and its reception. It is also important ensure that only decoders can access the RCMM at which is addressed by the RCMM.

In order to improve security, an RCMM, to Unlike a CRL, it contains at least two signature values ​​for at least a part, and preferably all, of the data included in it. Each signature value is calculated using a key of a respective encryption algorithm, as a private key of a public / private key pair.

When a Root Certification Authority (RCA) issues an RCMM and includes a new 110 root certificate, the RCMM includes at least two signature values. Each signature value is calculates using the respective private key of, for example, a Certification Authority to which the RCA provides certificates (although you can select any key for which the decoder stores an equivalent key). Yes, inadvertently For one of these Certification Authorities, your private key will be found in danger, it might be possible for a hacker the transmission of the transmitter is intercepted and, in case of knowing the private keys of the issuer and the Certification Authority, change the content of the RCMM and the signature value of the RCMM calculated using the private key of the Authority of Certification However, the hacker will not be possible change the value of the signature calculated using the private key of the other Certification Authority, since this key is not It is in danger. Therefore, when the decoder verifies the signatures using the public keys of the two Authorities of Certification, the two values ​​calculated by the decoder using the respective public keys will not be the same. By therefore, the decoder will be alerted to the lack of integrity of the content of the RCMM and will be rejected or will not continue processing the RCMM

Consequently, root certificates can be updated safely, provided the number of certificates in danger is less than the number of signatures that the RCMM contains. By therefore, the number of signatures of the RCMM is a variable of terminated by the Root Certification Authority that distributes the RCMMs.

The following will describe in more detail the format of an RCMM referring to figure 10.

RCMM 130 includes:

<dl><dt>?</dt><dd>The identity 132 of the RCA that distributed RCMM 130;</dd></dl>

<dl><dt>?</dt><dd>The date 134 on which issued RCMM 130;</dd></dl>

<dl><dt>?</dt><dd>The number 136 of values ​​of signature that contains the following RCMM;</dd></dl>

<dl><dt>?</dt><dd>A field 138 containing one or more updated or replacement root certificates for your storage in the decoder;</dd></dl>

<dl><dt>?</dt><dd>A list 140 with the numbers of series of root certificates to be revoked, including for each root certificate revoked the date and time of the revocation of said certificate; and</dd></dl>

<dl><dt>?</dt><dd>At least two signature fields 142, containing each of them</dd></dl>

<dl>&lt;dt /&gt;<dd>An identifier 144 of the certificate stored in the decoder containing the public key to be used to verify the signature value content in said signature field; and</dd></dl>

<dl>&lt;dt /&gt;<dd>A value of signature 146 of the RCMM, calculated using the private key equivalent to the public key contained in the certificate identified by identifier 144.</dd></dl>

<pre listing-type="other">\ newpage</pre>

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

It is preferable that the RCMMs be transmitted to through the MPEG transport stream, since the return channel of the modem can be disconnected easily or it may simply not be present. It is also preferred that RCMMs be inserted by the sender as a data file in a root directory 75 to in order to ensure that the RCMM has been downloaded by the decoder

Processing and Generation of Management Messages Root Certificates

Next, the reception and the processing of an RCMM by a decoder referring to Figure 11

Upon receiving an RCMM at stage 200, the decoder compares the date 134 on which said RCMM was issued 130 with the date of issue of the previous RCMM. If the date 134 of the recently received RCMM is not later than the date in the which the previous RCMM was issued, the RCMM is rejected.

If the date 134 of the recently received RCMM It is after the date of receipt of the previous RCMM, the number 136 of signature values ​​that the received RCMM must contain recently, as notified by the RCMM received previously, it is compared in step 202 with the number of values signature actually contained in the RCMM recently received. Yes the number of signatures contained in the recently received RCMM is lower than expected, the RCMM is rejected. This way you can prevent an RCMM from being processed as a result of deletion by part of a hacker of signatures associated with pairs of private / public keys that are not in danger.

If the number of signatures contained in the RCMM recently received is equal to or greater than the number of signatures expected, in step 204 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 said signature value. In step 206, the decoder determines whether at least one of the values ​​calculated using a public key is different from any of the other calculated values using a different public key. If at least one value calculated is different from at least one of the other values calculated, the RCMM is rejected.

If the integrity of the RCMM has been demonstrated in step 206, the RCMM is processed in step 208 to store list 140 of the serial numbers of the root certificates revoked in the permanent memory of the decoder in step 212 to store each of the root certificates contained in the field 138 in the permanent memory of the decoder and in the stage 212 to store the date 134 of the RCMM in permanent memory. If a certificate from a Root Certification Authority is deleted, any CRLs issued by such will also be deleted Authority.

It is preferable that the integrity of the permanent storage of the data contained in the RCMM if the decoder is disconnected during message processing RCMM Therefore, if the power is disconnected during RCMM processing, list 140 associated with the RCMM previously processed that is stored in the decoder is preserved as if the RCMM message had not been processed recently received.

As mentioned above, a Root Certification Authority (RCA) normally has at least two RCA certificates, RC0 and RC1, stored in each decoder. In the event that one of these certificates, for example RC0, goes to being in danger, it will be necessary to replace all CA certificates stored in the decoder that have been signed using the private key equivalent to the public key stored in RC0, and generate a new RCA RC2 certificate that replaces RC0.

Referring to figure 12, for replace these CA certificates, first in step 300 the RCA issues an appropriate CRL message in which the serial numbers of the CA certificates to be revoked. In second, in step 302, the replacement CA certificates signed using the private key of the RC1 certificate that is not is in danger, they are transmitted to the transmitter for transmission to the decoder.

You just need to delete the RCA RC0 certificate that is is in danger and replace said certificate with a new one RCA RC2 certificate. In step 304, the RCA generates a new partner of public / private keys, insert the new public key in the RC2 certificate and sign the certificate using the new key private

In step 306, the RCA generates an RCMM that it contains, in field 138, an RC2 certificate and, in list 140, the RC0 serial number. The RCMM is distributed among issuers for transmission, in step 308, to the decoders, for delete the RC0 certificate that is in danger and replace it for the new RC2 certificate.

RCA certificates RC1 and RC2 will be supplied subsequently to the decoder manufacturer for coding through hardware in the memory of the new decoders.

<pre listing-type="other">\ newpage</pre>

It will be understood that the present invention has been described above just as an example and that can introduce modifications of detail within the scope of the invention.

For example, the RCMM may include, in addition to the new RCA 110 certificates, new CA 100 certificates and / or new issuer certificates 90, and list 140 may include CA certificate identifiers and / or issuer certificates that They must be revoked. This may allow the generation of CRL independent messages by an RCA.

All the features included in the description, and (if applicable) the claims and figures may be provided independently or in any combination adequate.