Method of securing software updates

The present invention relates to a method of securing systems software updates for ensuring operation of the various more systems. More particularly, the method of the invention uses a digital signature mechanism with a private key of an asymmetric encryption algorithm.

A system is defined here as a device or set of devices whose operation depends on one or more software programs stored in a nonvolatile memory or a hard disk. When the system functionality needs to be improved or supplemented in order to adapt to the growing demands of the user, it is often necessary to update only the relevant software without changing the hardware of the system.

The update of a given software is usually done by replacing files of an already installed software or add new files to supplement those stored. The assembly then is a new version of the software already installed in the system and has the desired improvements.

Many devices such as computers and peripherals, sell robots, fixed and mobile phones, pay TV decoders, etc. are controlled by software adapted to the configuration and specific components functions.

For example, in a pay-TV decoder (Set Top Box), an operating system manages devices such as hard disk, a smart card reader, data reception interfaces and memories. In order to introduce changes either at the configuration, either in terms of functionality, it is sometimes necessary to replace the existing software or to make improvements to the one already installed in the decoder. This type of change is by means of software portions called updates or patches provided by the operator's management center to which a number of users are subscribed. These updates are provided regularly by the management center and downloaded into the decoders of each subscriber with the necessary rights.

The document <patcit id="pcit0001" dnum="WO9843431A"><text>WO98 / 43431</text></patcit> describes a method for downloading applications in a receiver / decoder. The application software is divided into modules and downloading modules is preceded by a search for a directory module to a specific local address. The modules are signed and the directory module is signed and encrypted so that only one encryption is applied to all modules forming the application. Several public encryption keys are stored in a read only memory (ROM) of the receiver / decoder. The applications can be created by different sources without requiring knowledge of each of their private keys. A directory of the signature can be concealed in a variable position in the arbitrary data block in the directory module. An application to be downloaded may be verified by comparison with an application validation bitmap stored in the receiver / decoder.

The document <patcit id="pcit0002" dnum="WO0135670A"><text>WO01 / 35670</text></patcit> describes a method of authentication information transmitted to a pay-TV decoder. A software object and a separate data structure containing authorization information is digitally signed with a global signature covering both objects. These are separately transmitted to the decoder. When the two objects are received by the decoder, the signature is verified.

Users of a decoder generally have a paid contract with an operator that guarantees regular maintenance service of the software installed in the decoder. To limit abuse by unauthorized copying and introduction of foreign software components, it is essential to secure updates of the decoder software. One known method is to use a coded mark with a key of an asymmetric encryption algorithm RSA type. The updated software is provided online with a print obtained by a one-way hash function (Hash). This fingerprint is a unique picture of the entire update and it is recognized that no two identical fingerprints on two very different sets of data. The hash is encrypted using a private key of the operator associated with a group of subscribers, which is a signature to the set. The software together with this signature is loaded into a RAM (Random Access Memory) decoder. A program part of decoder software calculates the hash function (Hash) an imprint of the software stored in RAM. The signature received is decrypted with a public key in the decoder and compared with the footprint of the previously calculated software. If the decrypted signature matches the footprint resulting hash, the signature accompanying the update stored in RAM is considered valid. The updated software will be installed in non-volatile memory of the decoder (Flash memory).

Security is thus carried out by verifying the signature with a public key in the decoder corresponding to the operator's private key.

The public key resides in the decoder must be fixed and the program that allows the verification of the signature. The authenticity of the signature is assured that the private key depends on the public key of the decoder. The signature can not be reproduced because the private key is known only to a particular operator. Moreover, the same signature is unusable for several different updates because it is a function of a specified update. A software update signed and whose content is changed in RAM give another impression that can not be validated by the signature decrypted by the public key. Indeed, the resulting hash mark after the update at the decoder and different from that obtained after decryption of the signature.

However, this method of securing includes a weak point which is the private key of the operator itself. Indeed, when it is discovered by a third party, he can sign any software and make improper changes to the system.

This discovery may take the form of iteration on the public key that the third party will be extracted at the decoder, until he found the right key pair. The parade of changing the behavior of the decoder software to refuse the signatures generated with the key discovery is insufficient because the third party can work around these changes with appropriate programs.

The document <patcit id="pcit0003" dnum="WO9949611A"><text>WO99 / ​​49611A</text></patcit> describes a method for securely transmitting data between a first device and a second device. Each device contains a sequence identical to encryption keys. A pointer indicates the same key in the sequence of the first and second device. The first device transmits to the second device data encrypted with the key referenced by the pointer. The second device receives the data and decrypts it with the key designated by the pointer in the sequence of said second device. After decryption of the data, the pointers of the sequences of the first and second device are incremented or move to a next key in a synchronized manner in order to prepare each device for a new transmission of encrypted data.

The purpose of the present invention is to significantly reduce the impact of the discovery of a private key with a systematic analysis of how the decoder software or to significantly increase the time and resources necessary to the process used for its determination.

The object is achieved by a method of securing data update method according to claim 1

Data from an update is transmitted by the management center as a patch and a control unit comprising a signature consisting of the patch footprint encrypted with a private key of the management center. The decoder stores this data in the RAM for processing. A public key associated with the private key known current key is selected from a list stored in a first non-volatile memory to decrypt the signature of the patch. If successful the decryption and verification, a command is executed resulting in the installation of the patch in a second non-volatile memory (Flash) decoder. The current key is disabled and used in the list which makes the following key available for the next update.

When the signature verification and decryption of an update of the decoder is performed with a public key from the list, it is deleted and becomes unusable for future updates. So every update, a new key is used and then removed from the list. The public keys of the list must be immutable as the program for the verification of the document<patcit id="pcit0004" dnum="WO0056009A"><text>WO00 / 56009</text></patcit> describes a security system and method for secure access from a remote terminal or computer to a host computer using very long passwords and / or a large database of identification key data. The method of controlling access to a resource accessible from a plurality of user units comprises steps of: generating a plurality of sets of long unique keys, creating a key database comprising a compilation of each set of keys, the key storage database in a storage medium connected to a host, a user programming unit to communicate with the host and to transmit or receive keys or from the host, the host programming to communicate with the user unit and to transmit or receive the keys to or from the user unit and distribution of one or more sets of keys user an authorized user of the resource, said set of user keys are recorded in a storage medium associated with the user unit before or after distribution of the set of user keys for the user authorized. The set of user keys is of the "one-time-pad" that is to say, each key of the set is used only once. Alternatively, the user unit storage medium comprises a writable memory in which the keys used for the set of user keys are erased or superimposed. signatures. The list is editable (elimination of used keys) that the verification program.

The method described above can significantly reduce the possibilities decoder changes by a third party discovered a private key. Since a key is used only once, the third party will make only one change. Therefore a modification of the decoder of the behavior to protect the effects of piracy becomes more efficient as the third party, with no valid private key is thus to an inaccessible device.

Because the private keys used are more numerous, a third must systematically address all the key so that it is not blocked in an update that matches the key he discovered. You should know that the evolution of software decoders is fast and it is considered that if a key is discovered, the following updates will close security holes that could have brought the third. If the third party is able to block any updates later, the functionality of the decoder will be quickly outdated and therefore without great injury to the operator.

The use of asymmetric keys is important in this context because extracting the public key in a decoder does not produce an updated acceptable since this update must be signed by the operator of the private key. It is common to place the private key in the secure part (the operator) and the public keys in the part in the public domain (the decoder). Nevertheless, it is possible to reverse these key without affecting the operation of the present invention.

A first embodiment of the invention provides the use of public keys taken in a predetermined order from the list. Thus, each key of the list is taken as soon as the previous key is used.

The invention will be better understood from the detailed description which follows and which refers to the attached figures for a non-limiting example, namely:<ul><li>The <figref idrefs="f0001">figure 1</figref> illustrates the sequence of an update step of a decoder of a N version to version N + 1.</li><li>The <figref idrefs="f0002">2</figref> shows an update of a version N to a version R</li></ul>

In the example illustrated by the <figref idrefs="f0001">figure 1</figref>An initial version of the decoder is updated to version 1 with a patch P1. This patch P1 is transmitted with its signature (H (P1))_PK1 by the operator's management center to the decoder. The update step starts by loading the patch P1 in the RAM of the decoder.

The signature (H (P1))_PK1 is obtained by encryption of the digest H (P1) of P1 patch with the PK1 private key of the operator, operation performed in the management center. This footprint is calculated by the operator from the patch P1 with a hash function H one-way hash type.

The decoder then load the software to decrypt the signature (H (P1))_PK1 received with a public key K1 to obtain the patch digest H (P1)₁. Meanwhile, that same software calculates the digest H (P1)₂ P1 patch stored in RAM. The first impression after the decryption of the signature H (P1)₁ and the second H (P1)₂ resulting from the calculation by the hash function H are compared. If the two values ​​match, the P1 patch is installed in the nonvolatile memory Flash of the decoder FH thereby performing the update of the decoder software. The public key K1 used to decrypt the signature is crossed out of the list.

A second update from version 1 to version 2 transmitted by the form of a new patch management center P2 accompanied by his signature (H (P2))_PK2 goes through the same process of downloading and verification. A new public key K2 taken from the list will be used on the decoder side. All transmitted following updates are checked in the same way each time using a new public key taken from the list. The keys of previous updates are neutralized either by deletion or by adequate labeling.

By applying this method, an update of software from version 1 to version N is carried out in N-1 steps. The management center will transmit patches with N-1 N-1 corresponding signatures each encrypted by a private key to each version. The installation of different patches thus causes the neutralization of N-1 public key of the list.

The list of public keys can be stored eg in a non-volatile memory EEPROM (Electrically Erasable Programmable Read-Only Memory). After each use of a key during an update, it is definitely erased EEPROM allows access to the following key for the next update.

According to another embodiment, the list of public keys is not altered by erasing or marking of a key. After each installation of a software version in nonvolatile Flash memory, a counter is incremented or a pointer moves to indicate the rank of the key to select from the list at the next update. So when each update, only the key used to decrypt the signature of the patch is designated, the previous keys can not be selected because the counter or pointer can only progress in one direction, the increasing ranks.

Alternatively, the patch may be encrypted by the operator of the private key. A further step of decryption is thus added to the process described above. The patch P received and loaded into RAM can be decrypted with the public key before calculating the hash function H of the footprint for the signature verification. The calculation of the footprint can also be performed on patches in its encrypted form.

The installation of updates by third parties is made more difficult because each version change requires knowledge of the current key. The latter changes with every update forcing the others to know all the keys to follow the various updates.

The method described above can be a problem when the decoder has remained off the time when several updates to be performed. The transition from an older version of software to another whose number is not consecutive to that of the previous version is performed sequentially in several successive stages. Past using different public key taken from the list one by one and in order. It is recalled that the patch itself contains no order to select a different key for the current key. If that were the case, a third party could use this command to force the use of a key that would be known to him.

The <figref idrefs="f0002">2</figref> illustrates the case of a transition from a software version N to a version R where the difference RN between the new version and the previous exceed unity. The following example relates to a case where N = 2 and R = 5.

A decoder whose software is version 2 can not directly decrypt the signature (H (P))_PK5 the new version 5 because the key available in the public key list is that of the next higher version, namely the key K3. To install the new version 5, it needs access to the appropriate key to this version, that is the key K5.

The solution is to transmit a data stream containing the patch P for updating the decoder software to version 5 signed with the PK5 key plus a plurality of messages M1, M2, M3, M4 each encrypted with a private key PK1, PK2, PK3, PK4 drawn from the list of keys. RAM memory stores the messages and the patch P with its signature (H (P))_PK5. The version of the decoder being 2, the key to the updated version 1 to 2 is already turned off by the first update. The message M1 is ignored because the key K1 used to decrypt it is no longer available.

The following messages M2, M3 and M4 are used to disable one after another public keys K2, K3, and K4 corresponding to each intermediate version from version 2 to version 4 before version 5. So to install Version 5 in nonvolatile Flash memory, each public key K2, K3, and K4 of the list is used then neutralized or deleted. During the decryption of the message with the correct key, the content of this message is recognized and causes the neutralization of the current key operation. If the message is not recognized, this means that the encryption key of this message is not the current key.

After successive and successful décryptions messages M2, M3, M4, K5 key needed to decrypt the signature of the patch (H (P))_PK5 (And the patch P) becomes the current key. The latter will also be expunged from the list after installing the patch and K6 key will be present in the list for the next update from version 5 to version 6.

Such flows may have to update all a decoder base regardless of software version through the key change messages accompanying the patch. Each decoder has a public key in the list able to decrypt an update of the current version after neutralization of old keys.

During an update of a decoder software from a version N to a version R where the difference RN becomes large, for example greater than 10, it becomes tedious for a decoder which has an R-1 version of decrypt systematically all messages to check off orders. This decoder will apply its current key (R-1) to each of these messages to find that it can not interpret its content.

One solution is to introduce clear in the corresponding header of the message index to the numbers of different versions. This index is only used to prevent the decryption of messages that were encrypted by a different key from the current key. This index does not select the rank of the current key, only the successful decryption of a message with said current key causes advance one position in the key list.

According to a second solution, the footprint of the update patch is encrypted successively by all private keys of previous updates. This method requires use of each public key from the list, one after another, to decrypt the signature. In this case encryption chain, unlike the previous, all public keys should remain available in the EEPROM memory of the decoder. For example, for a day of version 1 update to version N, the footprint of the patch P is encrypted with a private key of version N. The assembly is then encrypted with the private key of the N-1 release then with the key to the N-2 version, and so on until version 1. decryption therefore requires the successive use public keys K1 to KN-1 corresponding to updates from version 1 to version N. stopping this iterative mechanism is through the recognition of an appropriate mark in the result of the decryption.

If one wishes to protect the update data, a way to proceed is to use a session key SK randomly generated by the management center for example. For operational reasons of speed, the key is symmetrical type. The management center encrypts the patch with the session key SK and composes a data set comprising the session key SK and the footprint of the update patch. This set is encrypted by the common private key of the operator to form the control block.

The encrypted patch and the control block are loaded into the RAM of the decoder. The block is decrypted by the current public key in the list which gives the impression of the patch and the session key SK. The latter is applied to the patch loaded into RAM for its decryption. Then the footprint of the patch is checked and when matched the patch is installed in non-volatile Flash memory.

The session key can be introduced as an additional security means in one or the other variants described above, for example:<ul><li>simple update of a version 1 to version N in stages</li><li>updating a version N R using a patch and key deactivation messages.</li></ul>

In a decoder has been updated many times, the number of public keys available decreases as the number of disabled keys simultaneously increases that made successful day. To reconstruct a list of keys to enable future updates, a new list of public keys can be sent to the decoder by the management center. This list may be incorporated into the data stream and accompanied by a signature as to an update patch. It is stored in the EEPROM and replaces the old list containing key deactivated.

According to a variant of the method of the invention, the management center and decoders respectively have a private and public key sets list. With each update, the management center randomly selects a set of private keys among those listed and encrypts the footprint of the patch successively with each key of the whole. The center comprises a data block comprising the encrypted fingerprint (signature) and a sequence of numbers corresponding to the ranks of the key chosen before. This suite can be transmitted unencrypted or encrypted with a session key. The decoder receiving the sequence numbers selected in the list of public keys, according to their rank, the keys necessary to decrypt the imprint of the patch. The list may not include more than once the same key number and the length of this list (number of keys used) is known and not editable. In this variant, the key lists are fixed and are not altered following a successful installation of a patch. With each update, a new combination of keys taken from the list is used for the signature of the patch. A third will therefore always have a set of keys to introduce an update to a device, which requires greater resources than the determination of a single key.

The update protection method according to the invention is independent of the transmission method between a supplier and a user. Indeed, the method can also be applied to patches distributed on CD-ROM, diskette or any other medium of digital data.