FR2888958A1 - Procede, systeme et produit de programme d'ordinateur d'execution de programmes d'ordinateurs surs, sur un terminal non sur - Google Patents

Abstract

Procédé d'exécution sûre d'une application par un ordinateur non sûr, consistant à télécharger (A) ladite application au moyen d'un programme de téléchargement non sûr, ladite application étant accompagnée d'une valeur de signature (Sig) établie par une entité de confiance, à exécuter (B) une vérification de cette valeur de signature (Sig), à exécuter (D) ladite application sûre par l'intermédiaire dudit ordinateur non sûr si la valeur de signature est vérifiée à la valeur vraie (C<+>), et à inhiber (E) l'exécution de ladite application par l'intermédiaire dudit ordinateur non sûr, sinon (C<->).

Description

PROCÉDÉ, SYSTÈME ET PRODUIT DE PROGRAMME D'ORDINATEUR

D'EXÉCUTION DE PROGRAMMES D'ORDINATEURS SêRS, SUR UN TERMINAL NON SêR La présente invention concerne la mise en oeuvre d'un procédé, d'un système et de produits de programme d'ordinateur permettant l'exécution de programmes d'ordinateurs sûrs, sur des ordinateurs ou terminaux non sûrs.

A l'heure actuelle, un ordinateur, en raison de la multiplication sans limite de fait des échanges de données, peut être considéré comme non sûr dès lors qu'il a pu être infesté par un virus informatique, envahi par un ou des programmes malveillants, substitués par exemple à des programmes classiques. Une telle machine, non sûre, peut permettre, par exemple, de récupérer les mots de passe qu'un utilisateur introduit pour accéder à des services en réseau, ou encore enregistrer les données consultées, quand bien même un protocole de sécurité, tel que le protocole SSL pour Secure Sockets Layer protocol en anglais, ou IPsec défini par l'association de sécurité IP, est mis en oeuvre.

Ce problème est particulièrement sérieux pour les utilisateurs qui se connectent sur le WEB depuis des ordinateurs ou terminaux en libreservice, tels que dans un cyber-café par exemple. Les utilisateurs, dans cette situation, n'ont pas de garantie quant au caractère de sérieux de la mise en oeuvre de l'administration des machines, de l'exécution et de la mise à jour d'un logiciel anti-virus, d'un pare-feu, de la gestion des droits en écriture laissée aux utilisateurs non valablement identifiés.

Dans le cas où l'utilisateur précité est un professionnel qui se connecte à son réseau d'entreprise (Intranet), ce dernier peut même craindre que des moyens de piratage aient été mis en oeuvre sur ce type d'ordinateur à des fins d'espionnage industriel ou de renseignement économique.

Les techniques actuelles pour l'exécution de programmes d'ordinateur sûrs visent avant tout à sécuriser et à fiabiliser l'exécution par la machine.

Le langage Java , par exemple, permet d'exécuter des programmes téléchargés sur Internet dans un autre programme, appelé machine virtuelle, ou VM.

Cette dernière contrôle en permanence les instructions exécutées par le programme Java , s'assurant ainsi que ce dernier est inoffensif pour l'ordinateur hôte et ses données.

L'environnement Java met aussi en oeuvre un mécanisme de signature de programmes, "applets" en anglais, qui permet au navigateur WEB de s'assurer, avant de les exécuter, que ces programmes ont été diffusés par une autorité digne de confiance. Le mécanisme précité repose sur un système classique de signature par cryptographie asymétrique, tel que le RSA ou autre. Les autorités de confiance sont nommément enregistrées dans le magasin de certificats.

L'approche précitée résout toutefois le problème inverse de celui que se propose de résoudre la présente invention. En effet, l'environnement Java part de l'hypothèse a priori que l'ordinateur hôte et la machine virtuelle sont fiables et que le programme téléchargé est douteux.

Le système d'exploitation Windows met également en oeuvre un système de contrôle de l'origine des programmes lors de leur installation, semblable à celui de l'environnement Java . Mais par hypothèse, lorsque la machine et son système d'exploitation sont corrompus et ne sont plus dignes de confiance, le contrôle effectué est sans valeur pour l'utilisateur.

Une approche différente a été proposée par le Trusted Computing Group, laquelle permet un contrôle incrémental des programmes lancés par une machine dès son démarrage.

Une telle approche permet davantage à l'administrateur de la machine de s'assurer que l'utilisateur ne pourra pas introduire de programmes nuisibles ou piratés sur cette machine, qu'à l'utilisateur final d'avoir confiance en la machine qu'il utilise, comme en une machine sûre.

En effet, dans l'exemple précédemment cité, dans un cyber-café, le propriétaire indélicat est en mesure de remplacer sciemment tous les navigateurs WEB par des faux, contenant des sous-programmes malveillants, les faire valider par le Trusted Computing Group, et enregistrer toutes les pages HTML consultées, à l'insu de ses clients.

La présente invention a pour objet de résoudre le problème de l'exécution d'un programme sûr par une machine non sûre, lequel, à la connaissance des inventeurs, n'a pas de solution connue à ce jour.

Un tel constat apparaît dû au fait que, dans le passé, les utilisateurs, ou leur entreprise, étaient propriétaires des ordinateurs qu'ils utilisaient, ce qui, bien entendu, leur permettait d'assurer un contrôle et un suivi de ces machines beaucoup plus strict.

Aujourd'hui, au contraire, les utilisateurs nomades ont besoin de se connecter depuis des cyber-cafés ou à partir de machines d'emprunt, ce qui rend le problème de l'absence de sécurité de l'exécution de programmes sûrs par des machines non sûres particulièrement aiguë et dangereux pour les services de nomadisme offerts aux entreprises notamment.

La présente invention a pour objet de résoudre le problème technique précité en réduisant au minimum la contribution d'un ordinateur non sûr à la sécurité de l'exécution de programmes ou applications vérifiés et considérés comme sûrs, du fait de cette vérification.

En particulier, la présente invention a pour objet de répartir l'initiative et le contrôle de la valeur des paramètres de sécurité de toute application ou programme sûr entre l'utilisateur demandeur et une entité de confiance, l'exécution en tant que telle des procédures de sécurité et de l'application au programme sûr, étant toutefois dévolue à un ordinateur ou terminal non sûr, lequel n'est alors pas en mesure d'interférer de manière illicite sur l'exécution de cette application ou de ce programme sûr.

Le procédé d'exécution sûre d'une application par un terminal non sûr, objet de la présente invention, est remarquable en ce qu'il consiste au moins à télécharger cette application au moyen d'un programme de téléchargement de ce terminal non sûr, cette application étant accompagnée d'une valeur de signature établie par une entité de confiance, exécuter à partir d'un support de mémoire amovible sûre, un programme de vérification de cette valeur de signature. Sur vérification de cette valeur de signature à la valeur vraie, l'application étant issue d'un fichier sûr, on exécute l'application sûre par l'intermédiaire du terminal non sûr. Sinon, sur absence de vérification de cette valeur de signature à la valeur vraie, on inhibe l'exécution de cette application, issue d'un fichier non sûr.

L'invention a en outre pour objet un système d'exécution d'application sur un terminal non sûr, remarquable en ce qu'il comprend au moins un serveur d'applications et de leur signature établie par une entité de confiance, une mémoire amovible sûre associée à cet ordinateur non sûr, cette mémoire amovible sûre comportant au moins un programme de vérification de signature de cette application.

Le procédé et le système objets de l'invention trouvent application à la sécurisation et à la fiabilisation des transactions ou échanges de données en réseau exécutés à partir de terminaux ou postes de travail non sûrs.

Ils seront mieux compris à la lecture de la description et à l'observation des dessins ci-après dans lesquels: - la figure 1 représente, à titre illustratif, un organigramme des étapes essentielles de mise en oeuvre du procédé d'exécution de programmes d'ordinateur ou applications sûrs, sur un ordinateur ou terminal non sûr; - la figure 2a représente, à titre illustratif, une variante de mise en oeuvre de l'étape de téléchargement d'une application ou d'un programme signé à l'initiative d'un utilisateur; - la figure 2b représente, à titre illustratif, une variante de mise en oeuvre préférentielle de l'étape de téléchargement illustrée en figure 2a; - la figure 2c représente, à titre illustratif, une variante de mise en oeuvre de l'étape de vérification de signature illustrée en figure 1; - la figure 3 représente, à titre illustratif, sous forme d'un schéma fonctionnel, un système d'exécution d'applications ou de programmes par un ordinateur ou terminal non sûr, conforme à l'objet de la présente invention.

Une description plus détaillée du procédé d'exécution sûr d'une application par un ordinateur ou terminal non sûr, conforme à l'objet de la présente invention, sera maintenant donnée en liaison avec la figure 1. Dans la présente description, la notion de terminal ou d'ordinateur non sûr est utilisée indifféremment.

En ce qui concerne la mise en oeuvre proprement dite du procédé objet de l'invention, on indique que l'ordinateur non sûr peut être constitué par un terminal informatique quelconque sur lequel l'utilisateur intéressé souhaite exécuter des programmes sûrs.

En particulier, on considère que l'ordinateur ou terminal non sûr précité est: configuré avec des programmes sans garantie de sécurité pour l'utilisateur; connecté en réseau, par exemple au réseau Internet et est doté de programmes ou logiciels de téléchargement de fichiers ftp, http ou autres; - à même de recevoir un élément de mémoire amovible tel qu'une mémoire sur port USB pour Universal Serial Bus en anglais, une disquette souple, un disque optique ou étiquette RFID active ou passive mais que toutefois ces supports de mémoire ne sont pas adaptés au stockage des applications que l'utilisateur souhaite pouvoir exécuter pour l'une des raisons suivantes, par exemple: - ces mémoires sont de taille insuffisante pour recevoir tous les programmes sûrs que l'utilisateur veut pouvoir exécuter; - ces mémoires sont trop lentes pour que l'utilisateur puisse les charger à chaque utilisation sur le terminal informatique; - les applications que l'utilisateur veut pouvoir exécuter ne sont pas connues à l'avance ou sont susceptibles d'évoluer entre leur dépôt sur ces mémoires et leur exécution.

On indique, en particulier, que le téléchargement de fichier sur un terminal concerne: - soit le téléchargement de fichiers exécutables, c'est-à-dire d'applications; soit le téléchargement d'applications signées permettant d'ouvrir l'application considérée, telles que traitement de texte, navigateur Internet ou autres.

En référence à la figure 1, on indique que le procédé objet de l'invention consiste au moins, en une étape A, à télécharger l'application au moyen d'un programme de téléchargement non sûr, implanté sur l'ordinateur non sûr, par exemple. L'application est accompagnée d'une valeur de signature établie par une entité de confiance, cette application signée étant notée F;_s, F désignant le fichier correspondant, support de cette application, i désignant une référence ou nom de cette application et S désignant la valeur de signature établie par l'entité de confiance ayant procédé à l'établissement de la valeur de signature de l'application considérée.

L'ordinateur non sûr est noté CNS et répond au présupposé précédemment

indiqué dans la description.

L'étape A est alors suivie d'une étape B consistant à exécuter à partir d'un support de mémoire amovible sûr, noté M, comportant un programme de vérification de signature et, par l'intermédiaire de l'ordinateur ou terminal non sûr CNS, une vérification de la valeur de signature précitée.

Suite à l'étape B, sur vérification de la valeur de signature à la valeur vraie, cette opération étant symbolisée par la relation: Sig = vraie ? l'application est alors issue d'un fichier Fi sûr, l'on procède, en une étape D, à l'exécution de l'application Fi précitée par l'intermédiaire de l'ordinateur ou terminal non sûr.

Au contraire, en réponse négative au test C de la figure 1, sur absence de vérification de la valeur de signature à la valeur vraie, l'application est issue d'un fichier non sûr et l'on procède en une étape E en une inhibition de l'exécution de cette application par l'intermédiaire de l'ordinateur ou terminal non sûr. L'opération d'inhibition est notée Arrêt.

Pour la mise en oeuvre du test de l'étape C, on indique que le fichier signé Fi_s composé du fichier proprement dit Fi et de la valeur de signature Sig, peut être vérifié à partir de toute opération de vérification de signature, opération duale de l'opération de signature. Ces opérations peuvent être exécutées à partir de l'algorithme RSA par exemple, ou de tout algorithme approprié connu de l'état de la technique, à partir d'une clé privée pour l'opération de signature et d'une clé publique associée à cette clé privée pour l'opération de vérification de signature.

Une description plus détaillée de l'opération consistant à l'étape A à télécharger l'application, sera maintenant donnée en liaison avec la figure 2a.

Dans le mode de mise en oeuvre du procédé objet de l'invention, tel qu'illustré en figure 2a, l'opération consistant à télécharger l'application peut comprendre au moins, pour mettre en oeuvre l'étape A de la figure 2a, une sous-étape Ao d'insertion dans l'ordinateur ou terminal non sûr CNS du support de mémoire amovible M, lequel est noté M (mo, mi). Le support de mémoire amovible est réputé comporter non seulement le programme de vérification de signature ml, mais également un module de programme mo d'appel de téléchargement de l'application considérée.

L'opération d'insertion du support de mémoire amovible est alors suivie d'une sous-étape Al de lancement d'un appel de téléchargement de l'application, du support de mémoire amovible M (mo, mi) vers l'ordinateur non sûr CNS.

Une description plus détaillée d'une mise en oeuvre préférentielle de l'opération de téléchargement A de la figure 1 sera maintenant donnée en liaison avec la figure 2b.

En référence à la figure 2b, on indique que l'étape de téléchargement précitée peut avantageusement comporter les sous-étapes Ao et Al telles qu'illustrées en figure 2a et représentées pour cette raison en pointillé sur la figure 2b.

En outre, l'opération consistant à télécharger l'application considérée, comprend une sous-étape A2 de téléchargement de la valeur de signature Sig accompagnée d'un certificat d'authentification noté Cert(Cpub), ce certificat d'authentification pouvant avantageusement contenir la clé publique notée Cpub associée à la clé privée Cpriv, à partir de laquelle a été calculée la valeur de signature Sig.

Compte tenu des opérations réalisées à la sous-étape A2, l'application signée est notée F,_s = (Fi, Sig, Cert (Cpub)) La sous-étape A2 peut alors être suivie d'une sous-étape A3 préalablement à l'exécution de toute vérification de la valeur de signature Sig et consistant à effectuer une vérification de la validité du certificat d'authentification Cert (Cpub).

Cette opération peut être réalisée à partir d'un protocole de vérification de certificat d'authentification de type classique, en particulier lorsque le certificat d'authentification est établi à partir du protocole X 509 par exemple. Cette opération de vérification ne sera pas décrite en détail car elle est connue de l'état de la technique.

La sous-étape A3 de vérification du certificat d'authentification comporte une sous-étape de test A4 consistant par exemple à vérifier à la valeur vraie le certificat d'authentification, cette opération étant notée: Cert (Cpub)) = vraie ? Sur réponse négative au test de la sous- étape A4, c'est-à-dire en l'absence de vérification à la valeur vraie du certificat d'authentification, le procédé objet de l'invention est alors arrêté à la sous-étape A6.

Au contraire, sur réponse positive à la sous-étape A4, le certificat d'authentification ayant été vérifié à la valeur vraie, une sous-étape A5 est appelée, laquelle consiste à effectuer une extraction de la valeur de la clé publique Cpub. Cette clé publique a pu être passée comme paramètre avec et/ou dans le certificat d'authentification.

Les sous-étapes Ao à A6 de la figure 2b constitutives en fait de l'étape A de la figure 1, peuvent alors être suivies de l'étape B de vérification de la valeur de signature Sig dans les conditions qui seront décrites maintenant en liaison avec la figure 2c.

Ainsi que mentionné précédemment dans la description, la valeur de signature précitée Sig a été établie par l'entité de confiance au moyen d'une clé privée Cpriv, laquelle par définition est maintenue secrète.

Pour la mise en oeuvre de l'étape B de vérification de signature de la figure 1 et en référence à la figure 2c, on dispose alors de l'application signée F;_s vérifiant la relation: F;_s = (Fi, Sig (F;, Cpriv)) Par la relation précédente, on indique que la valeur de signature précitée a été obtenue à partir d'un algorithme de signature, ainsi que mentionné précédemment dans la description et de la clé privée Cpriv. Cette valeur de signature est alors spécifique au fichier F; support de l'application considérée que l'utilisateur souhaite exécuter.

Ainsi, l'on dispose au niveau de la mémoire de masse de l'ordinateur ou terminal non sûr par exemple, du fichier signé Fi_s précédemment mentionné.

On dispose également dans le support de mémoire amovible d'un programme de vérification m1 et au moins d'une clé publique Cpub associée à la clé privée Cpriv avec laquelle la valeur de signature précédente a été établie par l'entité de confiance.

Dans ces conditions, les éléments disponibles dans le support de mémoire amovible M à l'étape B1 de la figure 2c, sont alors chargés dans l'ordinateur ou terminal non sûr à la sous-étape B2 de la figure 2c pour exécuter la vérification de la valeur de signature à la sous-étape B3 représentée à la figure 2c précitée.

Bien entendu, l'opération de vérification de signature est alors exécutée par l'ordinateur non sûr CNS, cette opération étant représentée par la relation: verif (Fi, Sig (Fi, Cpriv), Cpub) On comprend bien sûr qu'à la sous-étape B3 de la figure 2c, l'on procède en référence à la relation symbolique précédemment indiquée, à la vérification de la valeur de signature établie par l'entité de confiance avec la clé privée Cpriv sur le fichier Fi support de l'application souhaitée par l'utilisateur, par l'intermédiaire de la clé publique Cpub.

En ce qui concerne la mise en oeuvre du procédé objet de l'invention, on indique que celui-ci peut être mis en oeuvre à partir d'au moins une clé publique, laquelle peut alors être soit mémorisée directement dans le support de mémoire amovible sûre M, soit au contraire téléchargée par l'intermédiaire du certificat d'authentification, puis récupérée après vérification de l'authenticité du certificat d'authentification précité.

Bien entendu, le procédé objet de la présente invention peut être mis en oeuvre à partir d'une pluralité de clés publiques et, de manière non limitative, à partir d'une clé publique racine mémorisée dans le support de mémoire amovible par exemple et de clés publiques diversifiées associées d'une part à la clé privée Cpriv et d'autre part à la clé publique racine, chaque clé publique diversifiée pouvant être associée à une application ou fichier Fi support de cette application spécifique. La combinaison de la clé publique racine et d'une clé diversifiée permet d'engendrer une clé publique pertinente associée à la clé privée Cpriv avec laquelle l'entité de confiance a procédé à l'établissement de la valeur de signature de l'application ou du fichier support de celle-ci Fi.

Une description plus détaillée d'un système d'exécution d'application sur un ordinateur non sûr, conforme à l'objet de la présente invention, sera maintenant donnée en liaison avec la figure 3.

Ainsi que représenté sur la figure précitée, le système objet de l'invention comporte par exemple une entité de confiance assurant l'établissement des valeurs de signature d'application en signant ces dernières avec la clé privée Cpriv à laquelle est associée la clé publique Cpub précitée. L'entité de confiance PUB procède à la diffusion des applications signées Fi_s en plaçant ces dernières par exemple sur un serveur S directement accessible par l'intermédiaire d'une connexion en réseau, tel le réseau Internet par exemple.

Bien entendu, le serveur S est accessible par tout terminal et en particulier par tout ordinateur non sûr CNS, par simple connexion en réseau distant.

L'ordinateur non sûr CNS est connecté au réseau et satisfait au présupposé précédemment mentionné dans la description.

Enfin, le support de mémoire amovible M comporte un programme de vérification de signature, le module de programme mi, et au moins une clé publique Cpub, associée à la clé privée Cpriv avec laquelle a été établie la valeur de signature du fichier signé Fi_s.

En fonctionnement, après insertion du support de mémoire amovible M dans l'ordinateur CNS non sûr, le programme de vérification de signature mi et la clé publique Cpub associée à ce dernier, sont chargés dans l'ordinateur non sûr CNS pour exécuter l'opération de vérification de la valeur de signature, ainsi que décrit précédemment dans la description, conformément au procédé objet de la présente invention décrit en liaison avec la figure 2c.

Ainsi que décrit également précédemment dans la description, la clé publique Cpub peut n'être pas présente dans la mémoire amovible M ab initio, mais transmise par téléchargement avec un certificat d'authentification par exemple.

Ainsi que représenté en outre en figure 3, la mémoire amovible sûre M comporte en outre un programme ou un module de programme d'appel de téléchargement de l'application sûre, ce module étant noté mo sur la figure 3 précitée.

De préférence, la mémoire amovible sûre M peut être formée par un disque dur externe, un dongle USB protégé en écriture, par un disque optique ou par une étiquette RFID active ou passive par exemple, ces éléments pouvant être facilement introduits dans l'ordinateur ou terminal non sûr CNS.

En référence aux différents éléments susceptibles de constituer la mémoire amovible sûre précédemment mentionnée, on indique que le caractère sûr de cette mémoire amovible résulte d'une part du média de mémorisation utilisé, disque optique non réinscriptible par exemple, dongle USB protégé en écriture ou disque dur externe protégé, et, d'autre part, de la titularité de cette mémoire amovible sûre réservée à l'utilisateur de l'application que ce dernier souhaite exécuter sur l'ordinateur non sûr CNS.

En outre, on indique que le programme de vérification de signature, module mi représenté en figure 3, respectivement le programme d'appel de téléchargement de l'application, module mo représenté à la figure précitée, permet soit le téléchargement direct de l'application F; accompagnée de la valeur signée de cette application Sig, soit le téléchargement en mémoire de masse de l'ordinateur non sûr CNS, puis le chargement à partir de la mémoire de masse par exemple.

Dans l'hypothèse où le fichier F; est un fichier contenant le code exécutable d'un programme ou de l'application considérée, l'utilisateur peut alors lancer l'exécution de cette dernière.

Ainsi, le module de programme ml de vérification de signature peut luimême, dans une première étape, aller chercher l'application signée F;_S sur le serveur S. Le module de programme ml précité peut alors stocker en mémoire sur le disque dur de l'ordinateur ou même sur la mémoire amovible M, l'application signée - 12 - précédemment mentionnée si l'espace mémoire est suffisant et lancer la vérification de signature correspondante. La variante précitée présente l'avantage d'automatiser le démarrage de l'exécution de l'application Fi, mais présente l'inconvénient de nécessiter une mémoire de stockage M plus importante.

Lorsque la taille de l'application F, est inférieure à la taille mémoire de la mémoire M amovible, il peut alors être envisagé de stocker directement le fichier signé sur la mémoire amovible M précitée.

Toutefois, le procédé objet de l'invention et le système permettant la mise en oeuvre de ce dernier, permettent de n'utiliser qu'un volume de stockage fixe et de réduire la taille mémoire nécessaire de la mémoire amovible M à la taille du programme plus la taille de la clé publique Cpub par exemple. Toute zone mémoire disponible de la mémoire amovible M permet alors à l'utilisateur de stocker des données personnelles par exemple. Il est aussi possible de vérifier autant de programmes téléchargeables à partir du serveur S que souhaité, ce que ne permet en général pas le stockage direct des programmes précités sur la mémoire amovible M. Lorsque, ainsi que mentionné précédemment dans la description, la clé publique Cpub est envoyée vers la mémoire M amovible de l'utilisateur en même temps que le fichier signé F,_s, cette clé publique étant contenue dans un certificat d'authentification du type X509 par exemple, alors le certificat d'authentification est délivré par une autorité de confiance AC, distincte de l'entité de confiance PUB par exemple, dont la clé publique est stockée dans la mémoire amovible M à la place de la clé publique Cpub.

Lors de l'utilisation, un programme de vérification de la validité du certificat m2 vérifie la validité du certificat et en déduit la valeur de la clé publique Cpub, laquelle sera alors utilisée ainsi que mentionné précédemment dans la description. L'opération de vérification de l'authenticité du certificat d'authentification peut alors être exécutée à partir de la clé publique de l'autorité de confiance AC, laquelle peut être stockée à la place de la clé Cpub permettant de procéder à la vérification de signatures, c'est-à-dire la valeur Sig.

- 13 - Ce mode opératoire permet d'utiliser des entités de publication, c'est-à-dire entité de confiance PUB et autorité de confiance AC différentes, avec toutefois le même support de mémoire amovible M. En outre, le module de programme mi de vérification de signature peut alors faire confiance à plusieurs clés publiques d'autorité AC, selon la politique de sécurité fixée par l'utilisateur ou par l'entreprise de ce dernier. Le support de mémoire amovible M contient alors toutes les clés publiques de ces entités ou une clé publique racine notée RCpub sur la figure 3. Enfin, les entités de confiance PUB et le serveur S peuvent le cas échéant être confondus.

Le procédé et le système objet de l'invention permettent ainsi d'exécuter des applications sûres sur un ordinateur ou terminal non sûr, ces applications pouvant être de tout type et en particulier des navigateurs, des programmes propriétaires de courriers électroniques, des applications métiers ou analogues.

Les modules de programme mo, mi, m2 sont capables de fonctionner en bimodes, c'est-à-dire téléchargement de l'application signée Fi ou chargement depuis le disque dur.

Enfin, l'invention couvre également un produit de programme d'ordinateur enregistré sur un support de mémorisation pour exécution par un ordinateur, ce programme d'ordinateur correspondant au module de programme ml de la figure 3 et permettant la mise en oeuvre des étapes de vérification de signature selon le procédé objet de l'invention tel que décrit en liaison avec les figures 1 et 2a à 2c.

Il couvre en outre un produit de programme d'ordinateur enregistré sur un support de mémorisation pour exécution par un ordinateur ou un terminal,ce produit de programme correspondant au module mo de la figure 3 et permettant le téléchargement d'application Fi_s accompagnés de leur valeur de signature Sig, ainsi

que décrit précédemment dans la description.

Enfin, l'invention couvre également un produit de programme d'ordinateur enregistré sur un support de mémorisation pour exécution par un ordinateur, ce produit de programme correspondant au module m2 représenté en figure 3 et permettant d'exécuter une étape de vérification de la validité d'un certificat - 14 - d'authentification, puis une étape d'extraction de la valeur d'une clé publique permettant l'exécution d'une vérification de signature, ainsi que décrit précédemment dans la description en liaison avec la figure 2b.

- 15 -

Claims (12)

REVENDICATIONS

1. Procédé d'exécution sûre d'une application par un terminal non sûr, caractérisé en ce que ledit procédé consiste au moins à : -télécharger ladite application au moyen d'un programme de téléchargement non sûr dudit terminal non sûr, ladite application étant accompagnée d'une valeur de signature établie par une entité de confiance; - exécuter, à partir d'un support de mémoire sûre, comportant un programme de vérification de signature, par l'intermédiaire dudit terminal non sûr, une vérification de ladite valeur de signature; et, sur vérification de ladite valeur de signature à la valeur vraie, ladite application étant issue d'un fichier sûr; - exécuter ladite application sûre par l'intermédiaire dudit terminal non sûr; sinon, sur absence de vérification de ladite valeur de signature à la valeur vraie de ladite application, issue d'un fichier non sûr; inhiber l'exécution de ladite application par l'intermédiaire dudit terminal non sûr.

2. Procédé selon la revendication 1, caractérisé en ce que l'opération consistant à télécharger ladite application comprend au moins: l'insertion dans ledit terminal non sûr dudit support de mémoire, comportant en outre un module de programme d'appel de téléchargement de ladite application; le lancement d'un appel de téléchargement de ladite application, dudit support de mémoire vers ledit terminal non sûr.

3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que ladite valeur de signature établie par une entité de confiance étant calculée à partir d'un programme de calcul de signature et d'une clé privée, ledit support de mémoire comporte un programme de vérification de signature correspondant et au moins une clé publique associée à ladite clé privée, ledit programme de vérification de signature et ladite clé publique associée étant chargés dans ledit terminal non sûr pour exécuter ladite vérification de ladite valeur de signature.

- 16 -

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que ladite opération consistant à télécharger ladite application comprend le téléchargement de ladite valeur de signature accompagnée d'un certificat d'authentification contenant la clé publique associée à la clé privée à partir de laquelle a été calculée ladite signature.

5. Procédé selon la revendication 4, caractérisé en ce que celui-ci consiste à mémoriser, dans ledit support, au moins une clé publique, constituant une clé racine d'un ensemble de clés publiques, respectivement une pluralité de clés publiques.

6. Système d'exécution d'application sur un ordinateur non sûr, caractérisé en ce que ledit système comprend au moins: - un serveur d'applications et de leur signature établie par une entité de confiance, une mémoire sûre associée audit ordinateur non sûr, ladite mémoire sûre comportant au moins un programme de vérification de signature de ladite application.

7. Système selon la revendication 6, caractérisé en ce que ladite mémoire sûre comporte en outre un programme d'appel de téléchargement de ladite application sûre.

8. Système selon la revendication 6 ou 7, caractérisé en ce que ladite mémoire sûre est formée par un élément appartenant au groupe comprenant un disque dur externe, un dongle USB protégé en écriture ou un disque optique non réinscriptible.

9. Système selon l'une des revendications 6 à 8, caractérisé en ce que ledit programme de vérification de signature respectivement d'appel de téléchargement de ladite application permet, soit le téléchargement direct de ladite application et de la valeur signée de ladite application, soit le téléchargement en mémoire de masse dudit terminal non sûr puis le chargement à partir de ladite mémoire de masse.

10. Produit de programme d'ordinateur enregistré sur un support de mémorisation pour exécution par un ordinateur, caractérisé en ce que ledit programme permet la mise en oeuvre des étapes de vérification de signature selon le

procédé selon l'une des revendications 1 à 5.

11. Produit de programme d'ordinateur enregistré sur un support de mémorisation pour exécution par un ordinateur, caractérisé en ce que ledit programme permet le téléchargement d'applications accompagnées d'une valeur de signature.

12. Produit de programme d'ordinateur enregistré sur un support de mémorisation pour exécution par un ordinateur, caractérisé en ce qu'il permet d'exécuter: une étape de vérification de la validité d'un certificat d'authentification; puis une étape d'extraction de la valeur d'une clé publique permettant l'exécution d'une vérification de signature.