WO2004051983A1 - Méthode de sécurisation des mises à jour de logiciels - Google Patents

Méthode de sécurisation des mises à jour de logiciels Download PDF

Info

Publication number
WO2004051983A1
WO2004051983A1 PCT/IB2003/005655 IB0305655W WO2004051983A1 WO 2004051983 A1 WO2004051983 A1 WO 2004051983A1 IB 0305655 W IB0305655 W IB 0305655W WO 2004051983 A1 WO2004051983 A1 WO 2004051983A1
Authority
WO
WIPO (PCT)
Prior art keywords
key
list
patch
update
decoder
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/IB2003/005655
Other languages
English (en)
Inventor
Marco Sasselli
Nicolas Pican
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nagravision SARL
Original Assignee
Nagravision SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nagravision SA filed Critical Nagravision SA
Priority to AU2003286298A priority Critical patent/AU2003286298A1/en
Priority to EP03777041.9A priority patent/EP1570648B1/fr
Priority to MXPA05005695A priority patent/MXPA05005695A/es
Priority to CA2508424A priority patent/CA2508424C/fr
Priority to KR1020057009728A priority patent/KR101063076B1/ko
Priority to ES03777041.9T priority patent/ES2553985T3/es
Publication of WO2004051983A1 publication Critical patent/WO2004051983A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/235—Processing of additional data, e.g. scrambling of additional data or processing content descriptors
    • H04N21/2351—Processing of additional data, e.g. scrambling of additional data or processing content descriptors involving encryption of additional data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0891—Revocation or update of secret information, e.g. encryption key update or rekeying
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26291—Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for providing content or additional data updates, e.g. updating software modules, stored at the client
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/633—Control signals issued by server directed to the network components or client
    • H04N21/6332—Control signals issued by server directed to the network components or client directed to client
    • H04N21/6334—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key
    • H04N21/63345—Control signals issued by server directed to the network components or client directed to client for authorisation, e.g. by transmitting a key by transmitting keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8166—Monomedia components thereof involving executable data, e.g. software
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/60—Digital content management, e.g. content distribution

Definitions

  • the present invention relates to a method for securing updates to operating software ensuring the operation of the most diverse 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 a set of devices whose operation depends on one or more software stored in a non-volatile memory or a hard disk.
  • the updating of a given software is generally carried out by replacing files of software already installed or by adding new files to supplement those which are stored.
  • the assembly then constitutes a new version of the software previously installed in the system which thus benefits from the desired improvements.
  • a Set Top Box decoder operating software manages peripherals such as a hard disk, a smart card reader, interfaces for receiving data and memories.
  • peripherals such as a hard disk, a smart card reader, interfaces for receiving data and memories.
  • This type of development is carried out using portions of software known as updates or patches supplied by the operator's management center to which a certain number of users are subscribed. These updates are provided regularly by the management center and downloaded to the decoders of each subscriber having the necessary rights.
  • WO98 / 43431 describes a method of downloading applications to a receiver / decoder.
  • the application software is divided into modules and the download of the modules is preceded by a search for a directory module at a determined local address.
  • the modules are signed and the directory module is signed and encrypted so that a single encryption is applied to all the modules forming the application.
  • Several public encryption keys are stored in a read-only memory (ROM) of the receiver / decoder. Applications can thus be created by different sources without requiring knowledge of each of their private keys.
  • a directory signature can be hidden at a variable position in an arbitrary data block in the directory module.
  • An application to be downloaded can be checked by comparison with an application validation bitmap stored in the receiver / decoder.
  • Document WO01 / 35670 describes a method of authenticating information transmitted to a pay television decoder.
  • a software object and a separate data structure containing authorization information is digitally signed with a global signature covering the two objects. These are transmitted separately to the decoder. When these two objects are received by the decoder, the signature is verified.
  • the users of a decoder generally have a paid contract with an operator which guarantees them a regular maintenance service for the software installed in the decoder.
  • a fingerprint coded with a key of an asymmetric encryption algorithm of the RSA type The update software is supplied online with a fingerprint obtained by a one-way hash function (Hash). This fingerprint constitutes a single image representing the whole of the update and it is recognized that there are no two identical fingerprints on two same different sets of data.
  • This fingerprint is encrypted using a private key of the operator associated with a set of subscribers, which constitutes a signature specific to this set.
  • the software accompanied by this signature is loaded into a RAM memory
  • a program that is part of the software decoder calculates with the hash function (Hash) a fingerprint of the software stored in the RAM memory.
  • the signature received is decrypted with a public key contained in the decoder and then compared with the footprint of the software previously calculated. If the decrypted signature corresponds to the resulting fingerprint of the hash, the signature accompanying the update stored in the RAM memory is considered to be valid.
  • the update software will be installed in the non-volatile memory of the decoder (Flash memory).
  • Securing is thus achieved by verifying the signature with a public key in the decoder corresponding to the operator's private key.
  • the public key residing in the decoder must be fixed as well as the program which allows the verification of the signature.
  • the authenticity of the signature is ensured by the fact that the private key depends on the public key of the decoder.
  • the signature cannot be reproduced because the private key is known only to a determined operator.
  • the same signature cannot be used for several different updates because it is a function of a well-defined update. Updating software signed and whose content is modified in the RAM memory will give another imprint which cannot therefore be validated by the signature decrypted by the public key. Indeed, the resulting fingerprint after hashing the update at the decoder and different from that obtained after decryption of the signature.
  • this security method has a weak point which is the private key of the operator itself.
  • a third party When it is discovered by a third party, they can sign any software and make abusive modifications to the system.
  • This discovery can be done in the form of an iteration on the public key that this third party has extracted from the decoder, until it discovers the right pair of keys.
  • the solution consisting in modifying the behavior of the decoder software so that it refuses the signatures generated with the discovered key is insufficient because the third party can bypass these modifications with suitable programs.
  • the aim of the present invention is to considerably reduce the impact of the discovery of a private key by a systematic analysis of the operation of the decoder software or significantly increase the time and resources required for the process used to determine it.
  • the object is achieved by a method for securing the updating of data from a plurality of devices, each device receiving updates from a management center, these updates comprising data called a patch accompanied by a control block encrypted by an asymmetric private key taken from a list of keys contained in the management center, characterized by the following steps:
  • the data of an update are transmitted by the management center in the form
  • the decoder stores this data in the RAM memory for processing.
  • a public key, associated with this private key called the current key, is selected from a list stored in a first non-volatile memory in order to decrypt the signature of the patch. If the decryption and verification are successful, a command is executed leading to the installation of the patch in a second non-volatile memory (Flash) of the decoder. The current key thus used is deactivated in the list which makes the next key available for the next update.
  • the method described above makes it possible to considerably reduce the possibilities of modifications of the decoder by a third party having discovered a private key. Since a key can only be used once, the third party will only make one modification. Consequently, a modification of the behavior of the decoder to protect it from the effects of hacking becomes more effective because the third party, no longer having a valid private key, is thus in front of an inaccessible device.
  • asymmetric keys is important in this context because the extraction of public keys in a decoder does not allow an acceptable update to be made since this update must be signed by the operator's private key. It is common to place the private keys in the secure part (the operator) and the public keys in the part in the public domain (the decoder). However, it is possible to reverse these keys without harming the operation of the present invention.
  • a first embodiment of the invention proposes the use of public keys taken in a predetermined order from the list. Thus, each key in the list is taken as soon as the previous key is used.
  • FIG. 1 shows the progress of a step of updating a decoder from an N version to an N + 1 version.
  • FIG. 2 shows an update from an N version to an R version
  • an initial version decoder is updated to version 1 with a patch P1.
  • This patch P1 is transmitted with its signature (H (P1)) p ⁇ by the operator's management center to the decoder.
  • the update step begins with the loading of the P1 patch in the RAM memory of the decoder.
  • the signature (H (P1)) P ⁇ is obtained by encryption of the imprint H (P1) of the patch P1 with the operator's private key PK1, an operation carried out in the management center. This fingerprint is calculated by the operator from the P1 patch with a hash H hash function.
  • the decoder software then takes care of decrypting the signature (H (P1)) P ⁇ received with a public key K1 in order to obtain the imprint of the patch H (P1) ⁇ .
  • this same software calculates the imprint H (P1) 2 of the patch P1 stored in the RAM memory.
  • the first imprint from the decryption of the signature H (P1) ⁇ and the second H (P1) 2 resulting from the calculation by the hash function H are compared. If the two values match, the P1 patch is installed in the non-volatile Flash FH memory of the decoder, thereby updating the decoder software.
  • the public key K1 used to decrypt the signature is crossed out from the list.
  • a second update from version 1 to version 2 transmitted by the management center in the form of a new P2 patch accompanied by its signature (H (P2)) PK2 goes through the same download and verification process.
  • a new public key K2 taken from the list will then be used on the side of the decoder. All subsequent updates transmitted are checked in the same way, each time using a new public key taken from the list.
  • the keys of the previous updates are neutralized either by erasure, or by an adequate marking.
  • N-1 steps a software update from version 1 to version N is performed in N-1 steps.
  • the management center will transmit N-1 patches with N-1 corresponding signatures, each encrypted by a private key specific to each version. Installing the various patches therefore neutralizes N-1 public keys from the list.
  • the list of public keys can be stored, for example, in a non-volatile memory of the EEPROM (Electrically Erasable Programmable Read-Only Memory) type.
  • EEPROM Electrically Erasable Programmable Read-Only Memory
  • the list of public keys is not altered by erasing or marking a key.
  • a counter is incremented or a pointer moves to indicate the rank of the key to select from the list during the next update.
  • the previous keys can no longer be selected because the counter or the pointer can only progress in one direction, that of increasing ranks.
  • the patch can be encrypted by the operator's private key.
  • An additional decryption step is therefore added to the method described above.
  • the patch P received and loaded in the RAM memory can be decrypted with the public key before the calculation by the hash function H of the fingerprint used for the verification of the signature.
  • the fingerprint can also be calculated on the patches in its encrypted form.
  • FIG. 2 illustrates the case of a passage of software from a version N to a version R where the difference RN between the new version and the previous one exceeds unity.
  • the solution consists in transmitting a data stream containing the patch P for updating the software of the decoder to version 5 signed with the key PK5 to which is added a plurality of messages M1, M2, M3, M4 each encrypted with a private key PK1, PK2, PK3, PK4 taken from the list of keys.
  • the RAM memory stores these messages as well as the patch P with its signature (H (P)) p ⁇ 5 .
  • the version of the decoder is 2, the key for updating version 1 to 2 is already deactivated by the first update. The message M1 is then ignored because the key K1 used to decrypt it is no longer available.
  • each public key K2, K3 and K4 in the list is used and then neutralized or crossed out.
  • the content of this message is recognized and causes the operation to neutralize the current key. If the message is not recognized, this means that the encryption key for this message is not the current key.
  • the key K5 necessary for the decryption of the signature of the patch (H (P)) P 5 (and of the patch P) becomes the current key.
  • the latter will also be deleted from the list after the installation of the patch and the K6 key will be present at the top of the list for the next update from version 5 to version 6.
  • Such a flow can therefore update a whole set of decoders whatever their software version thanks to the key change messages accompanying the patch.
  • Each decoder has a public key in the list capable of decrypting an update of the current version after neutralization of the old keys.
  • a first solution consists in introducing in the header messages of the indexes corresponding to the numbers of the different versions. This index is only used to avoid decryption of messages that have been encrypted by a key different 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 the advance of a rank in the list of keys.
  • the imprint of the update patch is successively encrypted by all the private keys of the previous updates.
  • This process requires the use of each public key in the list, one after the other, to decrypt the signature.
  • all public keys must remain available in the EEPROM memory of the decoder.
  • the imprint of patch P is encrypted with a private key from version N.
  • the set is then encrypted with the private key from version N-1 , then with the key of version N-2 and so on until version 1.
  • Decryption therefore requires the successive use of public keys K1 to KN-1 corresponding to updates from version 1 to version N. Stopping this iterative mechanism is done by recognizing an appropriate mark in the result of the decryption.
  • one way of proceeding consists in using a session key SK randomly generated by the management center for example.
  • this key is of symmetric type.
  • the management center encrypted the patch with the SK session key and composes a data set comprising the session key SK and the imprint of the update patch. This set is encrypted by the operator's current private key to constitute 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 patch imprint and the SK session key.
  • the latter is applied to the patch loaded in the RAM memory allowing its decryption.
  • the imprint of the patch is checked and if it matches, the patch is installed in the non-volatile Flash memory.
  • the session key can be introduced as an additional security means in one or other of the variants described above, for example:
  • a new list of public keys can be sent to the decoder by the management center. This list can be incorporated into the data flow and accompanied by a signature as for an update patch. It is stored in EEPROM memory and replaces the old list containing deactivated keys.
  • the management center and the decoders respectively have a fixed list of private and public keys.
  • the management center randomly chooses a set of private keys from those in the list and encrypted the imprint of the patch successively with each key in the set.
  • the center composes a data block comprising the encrypted imprint (signature) and a series of numbers corresponding to the ranks of the keys chosen previously.
  • This suite can be transmitted in clear or encrypted with a session key.
  • the decoder receiving the sequence of numbers selects from the list of public keys, according to their rank, the keys necessary for decrypt the imprint of the patch.
  • the list cannot include the same key number more than once and the length of this list (number of keys used) is known and cannot be modified.
  • the key lists remain fixed and are not altered following a successful installation of a patch. At each update, a new combination of keys taken from the list is used for signing the patch.
  • a third party will therefore always need to have a set of keys to introduce an update in a device, which requires more substantial resources than for determining a single key.
  • the update security method according to the invention is independent of the transmission mode used between a supplier and a user. Indeed, the method can also be applied to patches distributed on CD-ROM, on floppy disk or on any other digital data medium.

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Storage Device Security (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

La présente invention propose une méthode de sécurisation de mise à jour de logiciels d'une pluralité de décodeurs basée sur la génération d'une signature au moyen d'une clé privée asymétrique. La mise à jour d'un décodeur étant effectuée par le téléchargement, à partir d'un centre de gestion, d'un bloc de données comprenant un patch et sa signature, ledit bloc est stocké dans une mémoire vive RAM. La signature est décryptée avec une clé publique courante d'une liste contenue dans une première mémoire non volatile du décodeur, puis vérifiée et en cas de concordance, une commande provoque l'installation du patch dans une seconde mémoire non volatile Flash et la désactivation de la clé courante. Le but de la présente invention est de réduire considérablement l'impact de la découverte d'une clé privée par une analyse systématique du fonctionnement du logiciel du décodeur ou d'accroître notablement le temps et les moyens nécessaires au processus utilisé pour sa détermination.

Description

METHODE DE SECURISATION DES MISES A JOUR DE LOGICIELS
La présente invention concerne une méthode de sécurisation des mises à jour de logiciels d'exploitation assurant le fonctionnement de systèmes les plus divers. Plus particulièrement, la méthode de l'invention utilise un mécanisme de signature numérique avec une clé privée d'un algorithme d'encryptage asymétrique.
Un système est défini ici comme un appareil ou un ensemble d'appareils dont le fonctionnement dépend d'un ou plusieurs logiciels stockés dans une mémoire non volatile ou un disque dur. Lorsque les fonctionnalités du système doivent être améliorées ou complétées afin de s'adapter aux exigences croissantes de l'utilisateur, il est souvent nécessaire de mettre à jour uniquement le logiciel concerné sans pour autant changer le matériel constituant le système.
La mise à jour d'un logiciel donné s'effectue en général par remplacement de fichiers d'un logiciel déjà installé ou par ajout de nouveaux fichiers venant compléter ceux qui sont stockés. L'ensemble constitue alors une nouvelle version du logiciel préalablement installé dans le système qui bénéficie ainsi des améliorations souhaitées.
De nombreux appareils tels que des ordinateurs et leurs périphériques, des automates de vente, des téléphones fixes et portables, des décodeurs de télévision à péage, etc. sont pilotés par des logiciels adaptés à leur configuration et aux fonctions de composants spécifiques.
Par exemple, dans un décodeur de télévision à péage (Set Top Box), un logiciel d'exploitation gère des périphériques tels qu'un disque dur, un lecteur de cartes à puce, des interfaces de réception de données et des mémoires. Afin d'introduire des changements soit au niveau de la configuration, soit au niveau des fonctionnalités, il est parfois nécessaire de remplacer le logiciel existant ou d'apporter des améliorations à celui déjà installé dans le décodeur. Ce type d'évolution s'effectue au moyen de portions de logiciels que l'on appelle mises à jour ou patchs fournis par le centre de gestion de l'opérateur auquel un certain nombre d'utilisateurs sont abonnés. Ces mises à jour sont fournies régulièrement par le centre de gestion et téléchargées dans les décodeurs de chaque abonné possédant les droits nécessaires. Le document WO98/43431 décrit une méthode de téléchargement d'applications dans un récepteur/décodeur. Le logiciel de l'application est divisé en modules et le téléchargement des modules est précédé par une recherche d'un module répertoire à une adresse locale déterminée. Les modules sont signés et le module répertoire est signé et encrypté de sorte qu'une seule encryption est appliquée à tous les modules formant l'application. Plusieurs clés publiques d'encryption sont stockées dans une mémoire à lecture seule (ROM) du récepteur/décodeur. Les applications peuvent être ainsi créées par différentes sources sans nécessiter la connaissance de chacune de leurs clés privées. Une signature du répertoire peut être dissimulée à une position variable dans un bloc de données arbitraires dans le module répertoire. Une application à télécharger peut être vérifiée par comparaison avec un bitmap de validation d'application stocké dans le récepteur/décodeur.
Le document WO01/35670 décrit une méthode d'authentification d'informations transmises à un décodeur de télévision à péage. Un objet logiciel et une structure de données séparée contenant des informations d'autorisation sont signées numériquement avec une signature globale couvrant les deux objets. Ces derniers sont transmis séparément au décodeur. Lorsque ces deux objets sont reçus par le décodeur, la signature est vérifiée.
Les utilisateurs d'un décodeur possèdent en général un contrat payant chez un opérateur qui leur garantit un service de maintenance régulier du logiciel installé dans le décodeur. Afin de limiter les abus par copies non autorisées et par introduction de composants logiciels étrangers, il devient indispensable de sécuriser les mises à jour du logiciel du décodeur. Une méthode connue consiste à utiliser une empreinte codée avec une clé d'un algorithme d'encryptage asymétrique du type RSA. Le logiciel de mise à jour est fourni en ligne avec une empreinte obtenue par une fonction de hachage à sens unique (Hash). Cette empreinte constitue une image unique représentant l'ensemble de la mise à jour et il est admis qu'il n'existe pas deux empreintes identiques sur deux mêmes ensembles de données différentes.
Cette empreinte est encryptée à l'aide d'une clé privée de l'opérateur associée à un ensemble d'abonnés, ce qui constitue une signature propre à cet ensemble. Le logiciel accompagné de cette signature est chargé dans une mémoire vive RAM
(Random Access Memory) du décodeur. Un programme faisant partie du logiciel du décodeur calcule avec la fonction de hachage (Hash) une empreinte du logiciel stocké dans la mémoire RAM. La signature reçue est décryptée avec une clé publique contenue dans le décodeur puis comparée avec l'empreinte du logiciel calculée auparavant. Si la signature décryptée correspond à l'empreinte résultante du hachage, la signature accompagnant la mise à jour stockée dans la mémoire RAM est considérée comme valide. Le logiciel de mise à jour sera installé dans la mémoire non volatile du décodeur (mémoire Flash).
La sécurisation est ainsi réalisée par la vérification de la signature avec une clé publique dans le décodeur correspondant à la clé privée de l'opérateur.
La clé publique résidant dans le décodeur doit être fixe ainsi que le programme qui permet la vérification de la signature. L'authenticité de la signature est assurée du fait que la clé privée dépend de la clé publique du décodeur. La signature ne peut pas être reproduite car la clé privée n'est connue que d'un opérateur déterminé. De plus, une même signature est inutilisable pour plusieurs mises à jour différentes car elle est une fonction d'une mise à jour bien définie. Un logiciel de mise à jour signé et dont le contenu est modifié dans la mémoire RAM donnera une autre empreinte qui ne peut donc pas être validée par la signature décryptée par la clé publique. En effet, l'empreinte résultante après hachage de la mise à jour au niveau du décodeur et différente de celle obtenue après décryptage de la signature.
Cependant, cette méthode de sécurisation comporte un point faible qui est la clé privée de l'opérateur elle-même. En effet, lorsque celle-ci est découverte par un tiers, il peut signer un logiciel quelconque et apporter des modifications abusives au système.
Cette découverte peut se faire sous forme d'itération sur la clé publique que ce tiers aura extraite au décodeur, jusqu'à ce qu'il découvre la bonne paire de clés. La parade consistant à modifier le comportement le logiciel du décodeur pour qu'il refuse les signatures générées avec la clé découverte est insuffisante car le tiers peut contourner ces modifications avec des programmes adéquats.
Le but de la présente invention est de réduire considérablement l'impact de la découverte d'une clé privée par une analyse systématique du fonctionnement du logiciel du décodeur ou d'accroître notablement le temps et les moyens nécessaires au processus utilisé pour sa détermination.
Le but est atteint par une méthode de sécurisation de mise à jour de données d'une pluralité d'appareils, chaque appareil recevant les mises à jour d'un centre de gestion, ces mises à jour comprenant des données appelées patch accompagnées d'un bloc de contrôle encrypté par une clé privée asymétrique prise dans une liste de clés contenue dans le centre de gestion, caractérisée par les étapes suivantes:
- sélection par l'appareil d'une clé courante dans une liste de clés publiques,
- réception du patch de mise à jour et stockage en mémoire, - réception du bloc de contrôle encrypté,
- décryption dudit bloc par la clé publique courante,
- vérification que le bloc de contrôle décrypté corresponde audit patch,
- installation du patch reçu,
- désactivation de la clé courante et sélection de la clé suivante dans la liste.
Les données d'une mise à jour sont transmises par le centre de gestion sous forme
-d'un patch et d'un bloc de contrôle comprenant une signature constituée par l'empreinte du patch encryptée avec une clé privée du centre de gestion. Le décodeur stocke ces données dans la mémoire vive RAM en vue de leur traitement.
Une clé publique, associée à cette clé privée appelée clé courante, est sélectionnée à partir d'une liste stockée dans une première mémoire non volatile afin de décrypter la signature du patch. En cas de succès de la décryption et de la vérification, une commande est exécutée aboutissant à l'installation du patch dans une seconde mémoire non volatile (Flash) du décodeur. La clé courante ainsi utilisée est désactivée dans la liste ce qui rend la clé suivante disponible pour la prochaine mise à jour.
Lorsque la vérification de la signature et la décryption d'une mise à jour du décodeur est effectuée avec une clé publique de la liste, celle-ci est biffée et devient inutilisable pour de prochaines mises à jour. Donc, à chaque mise à jour, une nouvelle clé est utilisée puis éliminée de la liste. Les clés publiques de la liste doivent être non modifiables tout comme le programme servant à la vérification des signatures. La liste n'est modifiable (élimination des clés utilisées) que par le programme de vérification.
La méthode décrite ci-dessus permet de réduire considérablement les possibilités de modifications du décodeur par un tiers ayant découvert une clé privée. Puisqu'une clé n'est utilisable qu'une seule fois, le tiers n'effectuera qu'une seule modification. Par conséquent une modification du comportement du décodeur pour le protéger des effets du piratage devient plus efficace car le tiers, ne disposant plus de clé privée valable, se trouve ainsi devant un appareil inaccessible.
Du fait que les clés privées utilisables sont plus nombreuses, un tiers doit donc attaquer systématiquement toutes les clés pour qu'il ne soit pas bloqué à une mise à jour qui correspond à la clé qu'il a découverte. Il faut savoir que l'évolution du logiciel des décodeurs est rapide et que l'on considère que si une des clés est découverte, les mises à jour suivantes vont refermer les failles de sécurité que le tiers aurait pu introduire. Si ce tiers est capable de bloquer toute mise à jour postérieure, les fonctionnalités du décodeur seront rapidement obsolètes et donc sans grand préjudice pour l'opérateur.
L'utilisation de clés asymétriques est importante dans ce contexte car l'extraction des clés publiques dans un décodeur ne permet pas de fabriquer une mise à jour acceptable puisque cette mise à jour doit être signée par la clé privée de l'opérateur. II est commun de placer les clés privées dans la partie sécurisée (l'opérateur) et les clés publiques dans la partie dans le domaine public (le décodeur). Néanmoins, il est possible d'inverser ces clés sans nuire au fonctionnement de la présente invention.
Un premier mode de réalisation de l'invention propose l'utilisation de clés publiques prises dans un ordre prédéterminé à partir de la liste. Ainsi, chaque clé de la liste est prise dès que la clé précédente est utilisée.
L'invention sera mieux comprise grâce à la description détaillée qui va suivre et qui se réfère aux figures annexées servant d'exemple nullement limitatif, à savoir:
- La figure 1 représente le déroulement d'une étape de mise à jour d'un décodeur d'une version N à une version N+1.
- La figure 2 montre une mise à jour d'une version N vers une version R Dans l'exemple illustré par la figure 1 , un décodeur de version initiale est mis à jour vers la version 1 avec un patch P1. Ce patch P1 est transmis avec sa signature (H(P1))pκι par le centre de gestion de l'opérateur vers le décodeur. L'étape de mise à jour débute par le chargement du patch P1 dans la mémoire RAM du décodeur.
La signature (H(P1 ))Pκι est obtenue par encryption de l'empreinte H(P1) du patch P1 avec la clé privée PK1 de l'opérateur, opération effectuée dans le centre de gestion. Cette empreinte est calculée par l'opérateur à partir du patch P1 avec une fonction de hachage H à sens unique de type Hash.
Le logiciel du décodeur se charge ensuite de décrypter la signature (H(P1 ))Pκι reçue avec une clé publique K1 afin d'obtenir l'empreinte du patch H(P1)ι. Parallèlement, ce même logiciel calcule l'empreinte H(P1 )2 du patch P1 stockée dans la mémoire RAM. La première empreinte issue de la décryption de la signature H(P1)ι et la seconde H(P1 )2 résultante du calcul par la fonction de hachage H sont comparées. Si les deux valeurs concordent, le patch P1 est installé dans la mémoire non volatile Flash FH du décodeur réalisant ainsi la mise à jour du logiciel du décodeur. La clé publique K1 utilisée pour décrypter la signature est biffée de la liste.
Une seconde mise à jour de la version 1 vers la version 2 transmise par le centre de gestion sous forme d'un nouveau patch P2 accompagné de sa signature (H(P2))PK2 passe par le même procédé de téléchargement et de vérification. Une nouvelle clé publique K2 prise dans la liste sera alors utilisée du côté du décodeur. Toutes les mises à jour suivantes transmises sont vérifiées de la même manière en utilisant chaque fois une nouvelle clé publique prise dans la liste. Les clés des mises à jour précédentes sont neutralisées soit par effacement, soit par un marquage adéquat.
En appliquant ce procédé, une mise à jour d'un logiciel de la version 1 vers une version N s'effectue en N-1 étapes. Le centre de gestion transmettra N-1 patchs avec N-1 signatures correspondantes encryptées chacune par une clé privée propre à chaque version. L'installation des différents patchs entraîne donc la neutralisation de N-1 clés publiques de la liste.
La liste des clés publiques peut être stockée par exemple dans une mémoire non volatile du type EEPROM (Electrically Erasable Programmable Read-Only Memory).
Après chaque utilisation d'une clé lors d'une mise à jour, celle-ci est effacée définitivement de l'EEPROM autorisant l'accès à la clé suivante pour la prochaine mise à jour.
Selon un autre mode de réalisation, la liste des clés publiques n'est pas altérée par un effacement ou un marquage d'une clé. Après chaque installation d'une version de logiciel dans la mémoire non volatile Flash, un compteur est incrémenté ou un pointeur se déplace pour indiquer le rang de la clé à sélectionner dans la liste lors de la prochaine mise à jour. Ainsi lors de chaque mise à jour, seule la clé qui servira à décrypter la signature du patch est désignée, les clés précédentes ne pouvant plus être sélectionnées car le compteur ou le pointeur ne peut progresser que dans un seul sens, celui des rangs croissants.
Selon une variante, le patch peut être encrypté par la clé privée de l'opérateur. Une étape supplémentaire de décryption s'ajoute donc au procédé décrit ci-dessus. Le patch P reçu et chargé dans la mémoire RAM peut être décrypté avec la clé publique avant le calcul par la fonction de hachage H de l'empreinte servant à la vérification de la signature. Le calcul de l'empreinte peut également être effectué sur les patchs sous sa forme encryptée.
L'installation de mises à jour par des tiers est rendue plus difficile car chaque changement de version exige la connaissance de la clé courante. Cette dernière change à chaque mise à jour ce qui oblige le tiers à connaître toutes les clés pour suivre les différentes mise à jour.
Le procédé décrit précédemment peut poser un problème lorsque le décodeur est resté hors service le temps où plusieurs mises à jour devaient être effectuées. Le passage d'une ancienne version d'un logiciel à une nouvelle dont le numéro n'est pas consécutif à celui de la précédente version s'effectue séquentiellement en plusieurs étapes successives. Ces dernières utilisant des clés publiques différentes prises dans la liste l'une après l'autre et dans l'ordre. Il est rappelé que le patch en lui-même ne contient pas d'ordre permettant de sélectionner une clé différente de la clé courante. Si tel était le cas, un tiers pourrait utiliser cette commande pour forcer l'utilisation d'une clé qu'il lui serait connue. La figure 2 illustre le cas d'un passage d'un logiciel d'une version N à une version R où la différence R-N entre la nouvelle version et la précédente excède l'unité. L'exemple qui suit se rapporte à un cas où N=2 et R=5.
Un décodeur dont le logiciel est de version 2 ne peut pas décrypter directement la signature (H(P))P«5 de la nouvelle version 5 car la clé disponible dans la liste des clés publiques est celle de la version immédiatement supérieure, à savoir la clé K3. Pour l'installation de la nouvelle version 5, il doit pouvoir accéder à la clé correspondante à cette version, c'est à dire la clé K5.
La solution consiste à transmettre un flux de données contenant le patch P pour la mise à jour du logiciel du décodeur à la version 5 signé avec la clé PK5 auquel s'ajoute une pluralité de messages M1 , M2, M3, M4 encryptés chacun avec une clé privée PK1 , PK2, PK3, PK4 tirée de la liste de clés. La mémoire vive RAM stocke ces messages ainsi que le patch P avec sa signature (H(P))pκ5. La version du décodeur étant 2, la clé de la mise à jour de la version 1 à 2 est déjà désactivée par la première mise à jour. Le message M1 est alors ignoré car la clé K1 servant à le décrypter n'est plus disponible.
Les messages suivants M2, M3 et M4 servent à désactiver l'une après l'autre les clés publiques K2, K3, et K4 correspondantes à chaque version intermédiaire depuis la version 2 jusqu'à la version 4 précédant la version 5. Ainsi pour installer la version 5 dans la mémoire non volatile Flash, chaque clé publique K2, K3, et K4 de la liste est utilisée puis neutralisée ou biffée. Lors de la décryption du message par la bonne clé, le contenu de ce message est reconnu et provoque l'opération de neutralisation de la clé courante. Si le message n'est pas reconnu, ceci signifie que la clé d'encryption de ce message n'est pas la clé courante.
Après les décryptions successives et réussies des messages M2, M3, M4, la clé K5 nécessaire à la décryption de la signature du patch (H(P))P 5 (et du patch P) devient la clé courante. Cette dernière sera aussi biffée de la liste après l'installation du patch et la clé K6 sera présente en tête de liste pour la prochaine mise à jour de la version 5 vers la version 6.
Un tel flux peut donc mettre à jour tout un parc de décodeurs quelle que soit leur version de logiciel grâce aux messages de changement de clé accompagnant le patch. Chaque décodeur dispose d'une clé publique dans la liste capable de décrypter une mise à jour de la version courante après neutralisation des anciennes clés.
Lors d'une mise à jour du logiciel d'un décodeur d'une version N à une version R où la différence R-N devient grande, par exemple supérieure à 10, il devient fastidieux pour un décodeur qui a une version R-1 de décrypter systématiquement tous les messages afin de vérifier les ordres de désactivation. Ce décodeur va appliquer sa clé courante (R-1 ) à chacun de ces messages pour constater qu'il ne peut pas interpréter son contenu.
Une première solution consiste à introduire en clair dans l'en-tête des messages des index correspondant aux numéros des différentes versions. Cet index sert uniquement à éviter la décryption des messages qui ont été encryptés par une clé différente de la clé courante. Cet index ne sélectionne pas le rang de la clé courante, seul la décryption réussie d'un message avec ladite clé courante provoque l'avance d'un rang dans la liste de clés.
Selon une deuxième solution, l'empreinte du patch de mise à jour est encryptée successivement par toutes les clés privées des mises à jour précédentes. Ce procédé oblige une utilisation de chaque clé publique de la liste, l'une après l'autre, pour décrypter la signature. Dans ce cas d'encryption en chaîne, contrairement au précédent, toutes les clés publiques doivent rester disponibles dans la mémoire EEPROM du décodeur. Par exemple, pour une mise à jour de la version 1 vers la version N, l'empreinte du patch P est encryptée avec une clé privée de la version N. L'ensemble est ensuite encrypté avec la clé privée de la version N-1 , puis avec la clé de la version N-2 et ainsi de suite jusqu'à la version 1. La décryption nécessite donc l'utilisation successive des clés publiques K1 à KN-1 correspondantes aux mises à jour de la version 1 à la version N. L'arrêt de ce mécanisme itératif se fait par la reconnaissance d'une marque appropriée dans le résultat de la décryption.
Si l'on souhaite protéger les données de mise à jour, une manière de procéder consiste à utiliser une clé de session SK générée aléatoirement par le centre de gestion par exemple. Pour des raisons opérationnelles de rapidité, cette clé est de type symétrique. Le centre de gestion encrypté le patch avec la clé de session SK et compose un ensemble de données comprenant la clé de session SK et l'empreinte du patch de mise à jour. Cet ensemble est encrypté par la clé privée courante de l'opérateur pour constituer le bloc de contrôle.
Le patch crypté et le bloc de contrôle sont chargés dans la mémoire vive RAM du décodeur. Le bloc est décrypté par la clé publique courante dans la liste ce qui donne l'empreinte du patch et la clé de session SK. Cette dernière est appliquée au patch chargé dans la mémoire RAM permettant sa décryption. Puis l'empreinte du patch est vérifiée et en cas de concordance le patch est installé dans la mémoire non volatile Flash.
La clé de session peut être introduite comme moyen de sécurisation supplémentaire dans l'une ou l'autre des variantes décrites plus haut, par exemple:
- la mise à jour simple d'une version 1 à une version N en plusieurs étapes,
- la mise à jour d'une version N à R à l'aide d'un patch et des messages de désactivation des clés.
Dans un décodeur ayant été mis à jour à de nombreuses reprises, le nombre de clés publiques à disposition diminue tandis que le nombre de clés désactivées augmente en même temps que les mises à jour réussies. Afin de reconstituer une liste de clés pour permettre les futures mises à jour, une nouvelle liste de clés publiques peut être envoyée au décodeur par le centre de gestion. Cette liste peut être incorporée dans le flux de données et accompagnée d'une signature comme pour un patch de mise à jour. Elle est stockée dans la mémoire EEPROM et remplace l'ancienne liste contenant des clés désactivées.
Selon une variante de la méthode de l'invention, le centre de gestion et les décodeurs disposent respectivement d'une liste de clés privées et publiques fixe. A chaque mise à jour, le centre de gestion choisit aléatoirement un ensemble de clés privées parmi celles de la liste et encrypté l'empreinte du patch successivement avec chaque clé de l'ensemble. Le centre compose un bloc de données comprenant l'empreinte encryptée (signature) et une suite de numéros correspondant aux rangs des clés choisies auparavant. Cette suite peut être transmise en clair ou encryptée avec une clé de session. Le décodeur recevant la suite de numéros sélectionne dans la liste des clés publiques, d'après leur rang, les clés nécessaires pour décrypter l'empreinte du patch. La liste ne peut pas comprendre plus d'une fois le même numéro de clé et la longueur de cette liste (nombre de clés utilisées) est connue et non modifiable. Dans cette variante, les listes de clés restent fixes et ne sont pas altérées suite à une installation réussie d'un patch. A chaque mise à jour, une nouvelle combinaison de clés prises dans la liste est utilisée pour la signature du patch. Un tiers devra donc toujours disposer d'un ensemble de clés pour introduire une mise à jour dans un appareil, ce qui nécessite des moyens plus conséquents que pour la détermination d'une seule clé.
Le procédé de sécurisation de mise à jour selon l'invention est indépendant du mode de transmission utilisé entre un fournisseur et un utilisateur. En effet, le procédé peut aussi s'appliquer sur des patchs distribués sur CD-ROM, sur disquette ou sur tout autre support de données numériques.

Claims

REVENDICATIONS
1. Méthode de sécurisation de mise à jour de données d'une pluralité d'appareils, chaque appareil recevant les mises à jour d'un centre de gestion, ces mises à jour comprenant des données appelées patch accompagnées d'un bloc de contrôle encrypté par une clé privée asymétrique prise dans une liste de clés contenue dans le centre de gestion, caractérisée par les étapes suivantes:
- sélection par l'appareil d'une clé courante dans une liste de clés publiques,
- réception du patch de mise à jour et stockage en mémoire,
- réception du bloc de contrôle encrypté,
- décryption dudit bloc par la clé publique courante,
- vérification que le bloc de contrôle décrypté corresponde audit patch,
- installation du patch reçu,
- désactivation de la clé courante et sélection de la clé suivante dans la liste.
2. Méthode selon la revendication 1 caractérisée en ce que le bloc de contrôle comprend une signature sur les données du patch, cette signature étant le résultat d'une fonction de hachage, et en ce que la vérification du bloc comprend l'étape d'établissement de la signature sur le patch reçu et la comparaison avec la signature décryptée dans le bloc de contrôle.
3. Méthode selon la revendication 1 ou 2, caractérisée en ce que le bloc de contrôle comprend une clé de session symétrique (SK) déterminée par le centre de gestion, cette clé étant utilisée pour encrypter les données du patch.
4. Méthode selon la revendication 1 ou 2, caractérisée en ce qu'à chaque mise à jour une nouvelle clé publique, issue de la liste, est utilisée par l'appareil.
5. Méthode selon les revendications 1 à 4, caractérisée en ce que la clé publique est détruite de la liste après son utilisation, ladite clé devenant inutilisable pour des mises à jour postérieures.
6. Méthode selon les revendications 1 à 5, caractérisée en ce que les clés publiques de la liste sont utilisées séquentiellement dans un ordre prédéterminé lors de chaque mise à jour.
7. Méthode selon les revendications 1 à 6, caractérisée en ce que la liste des clés publiques est stockée dans une mémoire non volatile, une clé utilisée pour une mise à jour est effacée définitivement de la mémoire autorisant l'accès à la clé suivante pour la prochaine mise à jour.
8. Méthode selon les revendications 1 à 7 caractérisée en ce que, pour la mise à jour du logiciel d'un appareil d'une version N à une version R, avec une différence R- N entre la nouvelle version et la précédente excédant l'unité, au moins un message Mn encrypté avec une clé privée PKn est ajouté permettant de changer la clé courante Kn à la clé suivante Kn+1 dans la liste, la décryption réussie dudit message provoquant la désactivation de la clé courante Kn et la sélection de la clé suivante Kn+1.
9. Méthode selon la revendication 8, caractérisée en ce que le nombre de messages M correspond au nombre de mise à jour séparant la version initiale de l'appareil et la version finale de la mise à jour.
10. Méthode selon les revendications 1 et 2, caractérisée en ce qu'une installation d'une mise à jour est suivie par une incrémentation d'un compteur ou un déplacement d'un pointeur indiquant le rang de la clé à sélectionner dans la liste lors de la prochaine mise à jour, la liste des clés étant inchangée.
11. Méthode selon les revendications 1 à 4, caractérisée en ce que le bloc de contrôle est encrypté successivement par les clés des mises à jour précédentes, chaque clé de la liste étant utilisée l'une après l'autre pour décrypter la signature.
12. Méthode selon les revendications 1 à 10, caractérisée en ce que les appareils consistent en des décodeurs de télévision à péage, la mise à jour d'un décodeur étant effectuée par le téléchargement, à partir d'un centre de gestion, d'un patch accompagné d'un bloc de contrôle, ledit bloc est stocké dans une mémoire vive (RAM), et est décrypté avec une clé publique courante d'une liste contenue dans une première mémoire non volatile du décodeur, puis vérifié et en cas de concordance, une commande provoque l'installation du patch dans une seconde mémoire non volatile et la désactivation de la clé courante.
13. Méthode selon la revendication 12, caractérisée en ce qu'une nouvelle liste de clés publiques est transmise au décodeur, ladite liste remplace la liste contenue dans la première mémoire contenant des clés désactivées par des mises à jour réussies précédemment.
PCT/IB2003/005655 2002-12-03 2003-12-01 Méthode de sécurisation des mises à jour de logiciels Ceased WO2004051983A1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
AU2003286298A AU2003286298A1 (en) 2002-12-03 2003-12-01 Method of securing software updates
EP03777041.9A EP1570648B1 (fr) 2002-12-03 2003-12-01 Méthode de sécurisation des mises à jour de logiciels
MXPA05005695A MXPA05005695A (es) 2002-12-03 2003-12-01 Metodo para proteccion de actualizaciones de software.
CA2508424A CA2508424C (fr) 2002-12-03 2003-12-01 Methode de securisation des mises a jour de logiciels
KR1020057009728A KR101063076B1 (ko) 2002-12-03 2003-12-01 소프트웨어 업데이트 보안 방법
ES03777041.9T ES2553985T3 (es) 2002-12-03 2003-12-01 Método de protección de actualizaciones de software

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CH20432002 2002-12-03
CH2043/02 2002-12-03

Publications (1)

Publication Number Publication Date
WO2004051983A1 true WO2004051983A1 (fr) 2004-06-17

Family

ID=32331835

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2003/005655 Ceased WO2004051983A1 (fr) 2002-12-03 2003-12-01 Méthode de sécurisation des mises à jour de logiciels

Country Status (12)

Country Link
US (1) US7440571B2 (fr)
EP (1) EP1570648B1 (fr)
KR (1) KR101063076B1 (fr)
CN (1) CN100342713C (fr)
AU (1) AU2003286298A1 (fr)
CA (1) CA2508424C (fr)
ES (1) ES2553985T3 (fr)
MX (1) MXPA05005695A (fr)
MY (1) MY140368A (fr)
PL (1) PL376560A1 (fr)
TW (1) TWI309379B (fr)
WO (1) WO2004051983A1 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100401309C (zh) * 2006-04-24 2008-07-09 南京熊猫电子股份有限公司 税控设备软件版本智能升级加密验证方法
WO2011086286A1 (fr) 2009-12-23 2011-07-21 Viaccess Procédé de mise à jour d'un processeur de sécurité, système, programme d'ordinateur et processeur de sécurité correspondants

Families Citing this family (55)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6880086B2 (en) * 2000-05-20 2005-04-12 Ciena Corporation Signatures for facilitating hot upgrades of modular software components
EP1536606A1 (fr) 2003-11-27 2005-06-01 Nagracard S.A. Méthode d'authentification d'applications
EP1607821A1 (fr) * 2004-06-17 2005-12-21 Nagracard S.A. Méthode de mise à jour sécurisée de logiciel dans un mobile de sécurité
US9489496B2 (en) * 2004-11-12 2016-11-08 Apple Inc. Secure software updates
EP1662788A1 (fr) * 2004-11-24 2006-05-31 Nagravision SA Unité de traitement de données audio/vidéo numériques et méthode de contrôle d'accès audites données
US8272058B2 (en) 2005-07-29 2012-09-18 Bit 9, Inc. Centralized timed analysis in a network security system
US7895651B2 (en) 2005-07-29 2011-02-22 Bit 9, Inc. Content tracking in a network security system
US8984636B2 (en) 2005-07-29 2015-03-17 Bit9, Inc. Content extractor and analysis system
US8495389B2 (en) * 2005-12-16 2013-07-23 Safenet, Inc. Locking changing hard disk content to a hardware token
KR100659510B1 (ko) * 2006-02-16 2006-12-20 삼성전기주식회사 캐비티가 형성된 기판 제조 방법
KR20080052943A (ko) * 2006-12-08 2008-06-12 엘지전자 주식회사 이동통신단말기의 소프트웨어 업데이트방법
US8254568B2 (en) 2007-01-07 2012-08-28 Apple Inc. Secure booting a computing device
US8239688B2 (en) 2007-01-07 2012-08-07 Apple Inc. Securely recovering a computing device
KR101425224B1 (ko) * 2007-11-19 2014-07-31 삼성전자주식회사 펌웨어 업그레이드를 위해 펌웨어를 복호화하는 장치 및방법
US8150039B2 (en) * 2008-04-15 2012-04-03 Apple Inc. Single security model in booting a computing device
EP2294529B1 (fr) * 2008-06-23 2012-01-04 ST-Ericsson SA Dispositif électronique et procédé de mise à jour de logiciel ou de micrologiciel d un dispositif électronique
KR101029758B1 (ko) * 2008-12-31 2011-04-19 노틸러스효성 주식회사 펌웨어의 원격 업데이트 방법
US9417865B2 (en) * 2010-05-28 2016-08-16 Red Hat, Inc. Determining when to update a package manager software
CN102262549B (zh) * 2011-03-02 2014-10-15 奇智软件（北京）有限公司 补丁安装方法与系统
WO2013091162A1 (fr) * 2011-12-19 2013-06-27 华为技术有限公司 Procédé, dispositif et système de récupération de données de stockage distribuées
US8707454B1 (en) 2012-07-16 2014-04-22 Wickr Inc. Multi party messaging
US9715591B2 (en) * 2012-07-30 2017-07-25 Hewlett-Packard Development Company, L.P. Code validation
CN103595530B (zh) * 2012-08-17 2017-04-26 华为技术有限公司 软件密钥更新方法和装置
US10567349B2 (en) 2013-06-25 2020-02-18 Wickr Inc. Secure time-to-live
US10129260B1 (en) 2013-06-25 2018-11-13 Wickr Inc. Mutual privacy management
US9866591B1 (en) 2013-06-25 2018-01-09 Wickr Inc. Enterprise messaging platform
US9830089B1 (en) 2013-06-25 2017-11-28 Wickr Inc. Digital data sanitization
CN104468153B (zh) * 2013-09-13 2018-10-30 华为技术有限公司 一种集群系统中的告警方法、设备及集群系统
US9270469B2 (en) * 2014-02-20 2016-02-23 Xilinx, Inc. Authentication using public keys and session keys
US9698976B1 (en) 2014-02-24 2017-07-04 Wickr Inc. Key management and dynamic perfect forward secrecy
CN104980410A (zh) * 2014-04-14 2015-10-14 领步科技集团有限公司 一种电能质量在线监测设备软件远程升级的加密方法
US9584530B1 (en) 2014-06-27 2017-02-28 Wickr Inc. In-band identity verification and man-in-the-middle defense
CN105306505A (zh) * 2014-07-11 2016-02-03 腾讯科技（深圳）有限公司 数据更新方法、终端及服务器
US9830479B2 (en) * 2014-09-16 2017-11-28 Nxp Usa, Inc. Key storage and revocation in a secure memory system
US9910655B1 (en) * 2014-11-06 2018-03-06 Accellion, Inc. Secure content platform software developer kit
US9654288B1 (en) 2014-12-11 2017-05-16 Wickr Inc. Securing group communications
GB2538773A (en) * 2015-05-28 2016-11-30 Vodafone Ip Licensing Ltd Device key security
CN105207802B (zh) * 2015-08-13 2018-09-21 华为技术有限公司 节点的版本升级方法、装置和系统
US10191728B2 (en) * 2015-10-12 2019-01-29 Samsung Electronics Co., Ltd. System and method to reduce storage area usage of android application
US10033534B2 (en) 2015-12-01 2018-07-24 Intel Corporation Methods and apparatus to provide for efficient and secure software updates
US9584493B1 (en) 2015-12-18 2017-02-28 Wickr Inc. Decentralized authoritative messaging
US10291607B1 (en) 2016-02-02 2019-05-14 Wickr Inc. Providing real-time events to applications
US9591479B1 (en) 2016-04-14 2017-03-07 Wickr Inc. Secure telecommunications
US9590958B1 (en) 2016-04-14 2017-03-07 Wickr Inc. Secure file transfer
EP3532926A1 (fr) * 2016-10-31 2019-09-04 Harman Becker Automotive Systems GmbH Mécanisme de mise à jour de logiciel pour systèmes critiques de sécurité
CN106412128B (zh) * 2016-12-07 2019-06-04 北京奇虎科技有限公司 补丁下载的方法、装置、文件打包服务器以及客户端
US11449331B2 (en) * 2018-01-25 2022-09-20 Lg Electronics Inc. Vehicular update system and control method thereof
US10997297B1 (en) * 2019-12-06 2021-05-04 Western Digital Technologies, Inc. Validating firmware for data storage devices
CN113094060A (zh) * 2019-12-23 2021-07-09 瑞昱半导体股份有限公司 电子装置与软体更新方法
CN111491272B (zh) * 2020-04-01 2022-04-19 支付宝(杭州)信息技术有限公司 一种车辆解锁方法及系统
CN113840262A (zh) 2020-06-23 2021-12-24 京东方科技集团股份有限公司 空中下载更新方法、更新服务器、终端设备和物联网系统
KR102818101B1 (ko) 2020-09-18 2025-06-11 삼성전자주식회사 전자 장치 및 그 제어 방법
US20220329577A1 (en) * 2021-04-13 2022-10-13 Biosense Webster (Israel) Ltd. Two-Factor Authentication to Authenticate Users in Unconnected Devices
CN113434165A (zh) * 2021-06-02 2021-09-24 武汉天喻信息产业股份有限公司 一种嵌入式操作系统的补丁更新方法及系统
US20250379730A1 (en) * 2024-06-07 2025-12-11 Microsoft Technology Licensing, Llc Key refresh utilizing tamper-resistant public key commitment

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998043431A1 (fr) * 1997-03-21 1998-10-01 Canal+ Societe Anonyme Procede pour telecharger des donnees vers un recepteur/decodeur mpeg et systeme de transmission mpeg pour appliquer ce procede
WO2000056009A1 (fr) 1999-03-17 2000-09-21 Newton, Farrell Internet, intranet et autres systemes de securite pour communication en reseau utilisant des cles d'entree et de sortie
WO2001035670A2 (fr) * 1999-11-12 2001-05-17 General Instrument Corporation Mise en oeuvre de la securite d'un objet
US20020029347A1 (en) * 2000-09-01 2002-03-07 Edelman Martin S. System and method for preventing unauthorized access to electronic data

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5901225A (en) * 1996-12-05 1999-05-04 Advanced Micro Devices, Inc. System and method for performing software patches in embedded systems
US6952823B2 (en) * 1998-09-01 2005-10-04 Pkware, Inc. Software patch generator using compression techniques
DE19850665A1 (de) * 1998-11-03 2000-05-04 Siemens Ag Verfahren und Anordnung zur Authentifikation von einer ersten Instanz und einer zweiten Instanz
FR2792789B1 (fr) * 1999-04-20 2001-08-31 Bull Cp8 Procede de verification de signature ou d'authentification
US7120251B1 (en) * 1999-08-20 2006-10-10 Matsushita Electric Industrial Co., Ltd. Data player, digital contents player, playback system, data embedding apparatus, and embedded data detection apparatus
CN1338841A (zh) * 2000-08-11 2002-03-06 海南格方网络安全有限公司 计算机安全认证智能密钥
US7174017B2 (en) * 2002-03-04 2007-02-06 Lenovo Singapore Pte, Ltd Decryption system for encrypted audio
US20030196096A1 (en) * 2002-04-12 2003-10-16 Sutton James A. Microcode patch authentication

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998043431A1 (fr) * 1997-03-21 1998-10-01 Canal+ Societe Anonyme Procede pour telecharger des donnees vers un recepteur/decodeur mpeg et systeme de transmission mpeg pour appliquer ce procede
WO2000056009A1 (fr) 1999-03-17 2000-09-21 Newton, Farrell Internet, intranet et autres systemes de securite pour communication en reseau utilisant des cles d'entree et de sortie
WO2001035670A2 (fr) * 1999-11-12 2001-05-17 General Instrument Corporation Mise en oeuvre de la securite d'un objet
US20020029347A1 (en) * 2000-09-01 2002-03-07 Edelman Martin S. System and method for preventing unauthorized access to electronic data

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100401309C (zh) * 2006-04-24 2008-07-09 南京熊猫电子股份有限公司 税控设备软件版本智能升级加密验证方法
WO2011086286A1 (fr) 2009-12-23 2011-07-21 Viaccess Procédé de mise à jour d'un processeur de sécurité, système, programme d'ordinateur et processeur de sécurité correspondants

Also Published As

Publication number Publication date
MY140368A (en) 2009-12-31
US20040107349A1 (en) 2004-06-03
US7440571B2 (en) 2008-10-21
EP1570648A1 (fr) 2005-09-07
TW200419444A (en) 2004-10-01
TWI309379B (en) 2009-05-01
CA2508424C (fr) 2014-09-30
CN1720715A (zh) 2006-01-11
KR20050088091A (ko) 2005-09-01
KR101063076B1 (ko) 2011-09-07
CN100342713C (zh) 2007-10-10
PL376560A1 (pl) 2006-01-09
MXPA05005695A (es) 2005-08-16
EP1570648B1 (fr) 2015-09-02
ES2553985T3 (es) 2015-12-15
AU2003286298A1 (en) 2004-06-23
CA2508424A1 (fr) 2004-06-17

Similar Documents

Publication Publication Date Title
EP1570648B1 (fr) Méthode de sécurisation des mises à jour de logiciels
EP1055203B1 (fr) Protocole de controle d'acces entre une cle et une serrure electronique
WO2004107283A1 (fr) Methode de generation d’une cle de securite
EP3665609B1 (fr) Procédé et serveur de certification d'un document électronique
EP2052539A1 (fr) Méthode de révocation de modules de sécurité utilisés pour sécuriser des messages diffusés
CA2623430A1 (fr) Systeme et procede de detection de tripatouillage d'un logiciel
EP1412926A1 (fr) Procede de gestion d'achat de contenus numeriques diffuses et moyens de telechargement de tels contenus
EP1494460A1 (fr) Procédé et dispositif d'authentification de données numériques par module d'extension d'authentification
WO2016102833A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
FR3121524A1 (fr) Procédé et système informatique de stockage decentralisé et de partage de fichiers numériques certifiés
EP1546866A2 (fr) Logiciel embarque et procede d'authentification de celui-ci.
WO2009053605A2 (fr) Systeme traçable de chiffrement/dechiffrement de donnees numeriques diffusees
CA2988357A1 (fr) Procede de chiffrement, procede de chiffrement, dispositifs et programmes correspondants
WO2020065185A1 (fr) Procédé cryptographique de comparaison sécurisée de deux données secrètes x et y
EP1756696B1 (fr) Methode de mise a jour securisee de logiciel embarque dans un module de securite
WO2008084154A2 (fr) Traitement de donnee relative a un service numerique
FR2829645A1 (fr) Protocole d'authentification a verification d'integrite de memoire
EP2661841A1 (fr) Dispositif et procede de tracage
EP1494461B1 (fr) Procédé et dispositif d'authentification de données numériques à partir d'un module d'extension d'authentification
EP2153575B1 (fr) Obtention de valeurs dérivées dépendant d'une valeur maîtresse secrète
EP2294750B1 (fr) Procede et systeme tracables de diffusion de donnees numeriques
FR2899409A1 (fr) Dispositif de restitution d'un contenu numerique, entite electronique securisee, systeme comprenant ces elements et procede de restitution d'un contenu numerique
WO2024083849A1 (fr) Encodage en boite blanche
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
WO2024213673A1 (fr) Procédé et dispositif de déploiement d'une fonction de sécurité pour au moins un dispositif client

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IT LU MC NL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: PA/a/2005/005695

Country of ref document: MX

WWE Wipo information: entry into national phase

Ref document number: 1020057009728

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 2319/DELNP/2005

Country of ref document: IN

Ref document number: 376560

Country of ref document: PL

WWE Wipo information: entry into national phase

Ref document number: 2508424

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 20038A4959X

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2003777041

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 1020057009728

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 2003777041

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Ref document number: JP