FR2854261A1 - Procede d'execution d'une application logicielle par l'intermediaire d'un programme d'amorce logicielle et architecture informatique pour la mise en oeuvre du procede - Google Patents

Abstract

L'invention concerne un procédé d'exécution d'une application logicielle par l'intermédiaire d'un programme d'amorce logicielle (PA) exécuté dans un système hôte (1) et une architecture informatique pour la mise en oeuvre du procédé. Selon l'invention, un programme client (PC) permettant l'exécution de l'application logicielle est stocké dans la mémoire non volatile (31 ) d'une carte à puce (3) ou similaire. Le programme d'amorce logicielle (PA) détecte l'insertion de la carte à puce (3) dans un lecteur de carte à puce (2) et charge le programme client (PC') dans le système hôte (1) pour son exécution. De façon préférentielle, le programme client (PC) comprend des instructions sécurisées exécutées dans la carte à puce (3) et des instructions non sécurisées exécutées dans le système hôte (1).

Description

L'invention concerne un procédé d'exécution d'une application

logicielle par l'intermédiaire d'un programme d'amorce logicielle.

Elle concerne également une architecture informatique pour la mise en oeuvre d'un tel procédé.

Dans le cadre de l'invention, le terme "application logicielle" doit être entendu dans son acceptation la plus générale: programme, pièce de logicielle, voire système d'exploitation, etc. On entend par "amorce logicielle" une pièce de programme de taille taille permettant de charger et d'exécuter un programme de taille importante.

Un processus de ce type, connu sous l'appellation anglo-saxonne de "bootstrap", voire de "boot", est couramment utilisé pour charger et installer le système d'exploitation d'un ordinateur. Le programme de "boot" est enregistré habituellement dans une mémoire de masse, tel un disque dur. Le secteur dit de "boot" du disque, ou "boot sector" selon l'appellation anglo-saxonne, est le 15 tout premier secteur de ce disque. Ce secteur peut contenir un "bootstrap", cette dernière pièce de logicielle étant de suffisamment faible taille pour être enregistrée dans une partie de ce secteur (celui-ci peut contenir d'autres données).

Dans le procédé selon l'invention, le terme "amorce logicielle" sera 20 entendu dans un cadre plus général. On appellera "amorce logicielle" tout programme ou pièce de logicielle, de faible taille, contenant au moins des données, descripteurs ou éléments équivalents permettant d'identifier un programme, une application logicielle ou une pièce de logicielle, et de le lancer.

Généralement, il est nécessaire aussi de charger ce programme en mémoire 25 vive à partir d'un support local ou éloigné (réseau), si celui-ci n'est pas déjà résident en mémoire vive: mémoire non volatile (par exemple du type "ROM", pour "Read Only Memory"), disque dur, disquette, disque optique, etc. Le programme d'amorce logicielle peut contenir des données permettant de localiser directement le programme à charger ou d'appeler un autre programme 30 permettant ce chargement.

En résumé de ce qui précède, un processus d'amorce logicielle est réalisée en deux étapes principales: - un programme déterminé, le programme d'amorce logicielle, est exécuté par un processeur, qu'il soit autonome ou fasse partie intégrante d'un système informatique complexe (réseau); et ce programme possède tous les moyens utiles pour identifier, charger, lancer et exécuter au moins un deuxième programme de taille importante.

Un tel procédé est aussi couramment utilisé pour intégrer dynamiquement des processus dans un système informatique. A titre d'exemple, le programme d'amorce logicielle peut être agencé de telle sorte qu'il détecte l'insertion d'un support de mémoire amovible (telle l'insertion d'une 10 disquette dans un lecteur de disquette ou d'un disque optique dans un lecteur approprié), et, sur cette détection, charge dans le système hôte un programme enregistré sur le support mobile, en vue de son exécution.

Le processus qui vient d'être décrit peut permettre l'installation d'une nouvelle application logicielle sur le système hôte. Il peut aussi, dans une 15 application intéressante, permettre l'entrée de donnés de configuration, par exemple la saisie de données de personnalisation identifiant un utilisateur et ses droits sur le système et/ou sur les applications logicielles qui y sont exécutées. Il s'agit là de besoins de liés à la sécurité informatique. Ce terme doit d'ailleurs être compris dans son sens le plus général et comporte plusieurs 20 aspects: identification, "non répudiation", confidentialité, intégrité, etc. Lorsqu'un utilisateur utilise un poste fixe, ou pour le moins un des postes d'un réseau local, on peut estimer que les processus qui viennent d'être décrits satisfont la plupart des besoins qui se font ressentir, y compris, dans une certaines mesure, ceux liés à la sécurité informatique. L'utilisateur a une 25 "vue" relativement exhaustive sur les données qu'il manipule et les différents organes du système auxquels il a accès. Sa propre identité et ses droits peuvent être contrôlés par des moyens internes au système (saisie d'un mot de passe, dispositifs biométriques, etc.) et/ou externes (lecteur de badge à l'entrée des locaux du système informatique, etc.).

Cependant, la tendance actuelle est à un "nomadisme" des utilisateurs de systèmes informatiques de plus en plus poussé. Ceci est permis notamment par la miniaturisation des dispositifs utilisés et la mise en oeuvre de moyens de communication de plus en plus sophistiqués. Les réseaux informatiques sont également de plus en plus vastes et dépassent le plus souvent largement des zones géographiques confinées à un seul bâtiment. Même en ce qui concerne les réseaux locaux, du fait que les transmissions font appel de plus en plus souvent au "non filaire" (par exemple, réseaux sans fil de type dit "Wi-Fi" aux 5 normes IEEE 802.11, 802.15, etc.), il devient possible de connecter des postes relativement éloignés à un réseau local principal qui peut rester filaire pour sa part. Les réseaux eux-mêmes peuvent être interconnectés par télécommunication, par un réseau intranet ou par le réseau Internet, par

exemple.

Le besoin se fait sentir notamment de pouvoir configurer et personnaliser des postes éloignés à l'aide des données d'identification d'un utilisateur nomade.

Or les procédés de l'art connu ne répondent que très partiellement aux besoins qui se font sentir, notamment en ce qui concerne la sécurité 15 informatique.

En effet, s'il est possible de "transporter" des données personnelles d'identification sur un support d'enregistrement mobile (disquette, disque optique, etc.), on doit tout d'abord remarquer que certains supports, telles les disquettes ne peuvent enregistrer qu'une quantité relativement faible de 20 données. Les supports de données de type disque optique ("CD-ROM", ou "DVD" par exemple), peuvent enregistrer une grande quantité de données. Il est cependant nécessaire que l'organe à personnaliser soit muni d'un lecteur compatible, ce qui n'est pas toujours le cas. En outre, même lorsqu'ils sont réinscriptibles, les supports de données sont relativement encombrants à 25 transporter et l'enregistrement de données personnalisées n'est pas toujours aisé, ce qui se traduit par un manque de souplesse.

Surtout, tous ces supports sont d'un type que l'on qualifiera de "passif', en ce sens qu'ils n'incorporent pas de moyens de traitement de données. Il s'ensuit que tous les traitements de données, calculs ou opérations d'un type 30 semblable ne peuvent être effectués que dans le dispositif hôte incorporant le programme d'amorce logicielle, même si des données et/ou programmes à charger et exécuter peuvent être enregistrés sur un support mobile.

Dans ces conditions, un niveau élevé de sécurité informatique, voire un niveau simplement suffisant pour une application donnée, ne peut pas être atteint.

L'invention vise à pallier les inconvénients des procédés et dispositifs de l'art connu, et dont certains viennent d'être rappelés.

L'invention se fixe pour but un procédé sécurisé d'exécution d'une application logicielle par l'intermédiaire d'un programme d'amorce logicielle et une architecture informatique pour sa mise en oeuvre.

Pour ce faire, le procédé selon l'invention met à profit le fait que la 10 taille des mémoires non volatiles permises par les technologies actuelles, par exemple celles du type dit "FLASH", atteignent aisément un mégaoctet, voire plus. Elles pourront atteindre dans un avenir proche des tailles beaucoup plus importantes en faisant appel à des technologies en cours de mise au point. On peut citer de façon non exhaustive les nanotechnologies, par exemple la 15 technologie "Millipede" de la société IBM (marques enregistrées). La densité visée par une telle technologie est de l'ordre de la centaine de GO par poucecarré. Cette technologie est décrite, par exemple, sur le site Internet de cette société à l'adresse suivante: http://www.zurich.ibm.com/stlstorage/millipede.htm. 20 De telles mémoires non volatiles sont mises en oeuvre notamment dans les cartes à puce, ces dernières incluant en outre, et notamment, des moyens de traitement de données, par exemple un microprocesseur ou un organe équivalent (microcontrôleur, par exemple), des moyens de mémoire vive ("RAM" par exemple) et divers registres, ainsi que des moyens d'entrée25 sortie de données, c'est-à-dire une interface de communication.

De façon semblable en soi à l'art connu, mais là s'arrête la ressemblance, le programme d'amorce logicielle est résident dans le système hôte. Il s'agit avantageusement d'un programme chargé et exécuté comme tâche dite de fond (connue sous le terme anglo-saxonne de "daemon") d'un 30 système d'exploitation propre au système hôte: UNIX, LINUX, WINDOWS, (marques déposées), etc. Ce programme est capable de détecter l'insertion dans le système hôte du système portable comportant des ressources informatiques: moyens de mémoire, notamment non volatile, moyens de traitement de données, et moyens de communication (interface ou port d'entrée-sortie), telle que par exemple une carte à puce ou tout autre dispositif présentant des caractéristiques similaires.

Selon le procédé de l'invention, on enregistre dans la mémoire non volatile du système portable, que l'on pourra appeler sécurisé, comprenant de tels moyens de traitement de données, préférentiellement une carte à puce sécurisée, outre éventuellement des programmes (micro- instructions ou similaires) nécessaires au bon fonctionnement du système, des données d'un 10 programme spécifique, que l'on appellera "programme client".

Le ou les système(s) hôte(s) destiné(s) à coopérer avec le système portable sécurisé précité est(sont) muni(s) d'un dispositif de couplage du système portable avec le système hôte. A titre d'exemple, si le système portable sécurisé est une carte à puce, le système hôte est muni d'un lecteur 15 de carte à puce. Il permet l'initialisation d'une session et l'établissement de communications bidirectionnelles entre ces deux systèmes, selon un protocole approprié, par exemple répondant au standard ISO 7816.

Le programme client embarqué dans la mémoire non volatile du système portable sécurisé comprend au moins des instructions d'un premier 20 type, que l'on appellera "sécurisé". Ces instructions sont destinées à être exécutées à l'intérieur du système portable, sous la commande et à l'aide des moyens de traitement de données propres au système portable sécurisé. Ces instructions peuvent également invoquer des procédures stockées dans la mémoire non volatile précitée.

Le programme client peut également comprendre d'autres instructions, d'un second type que l'on appellera "non sécurisées", en ce sens qu'elles peuvent être traitées sans précautions particulières à l'extérieur du système portable sécurisé, par exemple par le processeur hôte et/ou faire appel à divers programmes enregistrés dans des moyens de mémoire qui sont propres au 30 processeur hôte, y compris des moyens de mémoire de masse (disque dur, etc.) et exécutés a priori également dans ce dernier.

Généralement, la quantité de données et/ou d'instructions à sécuriser est relativement peu élevée. Ils s'agit de données dites sensibles: données d'indentification de l'utilisateur, c'est-à-dire du porteur de la carte à puce (identité, mot de passe, données de personnalisation, droits attachés à celuici), pour le moins de la carte à puce elle-même, clé secrète de chiffrage lorsque des opérations de chiffrage/déchiffrage sont réalisées, etc. Ces données ne 5 quittent pas la carte à puce ou, de façon plus générale, le système portable sécurisé.

A l'inverse, de façon habituelle, l'essentiel des données et/ou programmes ne présente pas de caractère sensible. De ce fait, ces données et/ou programmes peuvent non seulement être traités/exécutés dans le 10 système hôte, mais être éventuellement enregistrés dans celui-ci, en local (comme il a été indiqué précédemment) ou être recherché dans un serveur éloigné (par exemple un site Internet). Cette caractéristique avantageuse permet de "décharger" le système portable sécurisé d'une charge de travail importante. Cette caractéristique est avantageuse, car les moyens de mémoire 15 de ce dernier sont a priori plus réduits que ceux du système hôte ou du réseau informatique auquel il est raccordé. On peut admettre également que les moyens de traitement de données du système portable sont moins puissants que ceux dont dispose le système hôte.

Le procédé selon l'invention présente donc de nombreux avantages. 20 Le système portable est sécurisé et se présente, notamment dans le cas d'une carte à puce, sous un format réduit, voire très réduit si on sort d'un format du type "carte bancaire normalisé", et donc facile à transporter. Il s'ensuit que, pratiquement, n'importe quel dispositif électronique, même de faible taille (par exemple un téléphone mobile, un organiseur ou "PDA", etc.) peut être muni 25 d'un lecteur de carte à puce ou d'un organe équivalent (module électronique, etc.). On peut donc configurer et personnaliser une grande quantité d'appareils divers, ce sans qu'il soit nécessaire d'implémenter dans ceux-ci des programmes spécifiques à chaque utilisateur potentiel. Le procédé selon l'invention se révèle donc très souple.

D'autre part, on peut atteindre un haut degré de sécurité, du fait que les données sensibles restent confinées dans le système portable sécurisé et que les instructions également sensibles sont exécutées à l'intérieur de celui-ci, sous la commande des moyens de traitement de données qui lui sont propres.

Enfin, le système portable reste sous la garde de l'utilisateur.

L'invention a donc pour objet principal un Procédé d'exécution d'une application logicielle par l'intermédiaire d'un programme dit d'amorce logicielle 5 dans un système informatique dit hôte comprenant au moins des moyens de mémoire et de traitement de données numériques et un dispositif de couplage à un organe externe, caractérisé en ce que, ledit organe externe étant constitué par un système portable comprenant au moins des moyens autonomes de mémoire non volatile, de traitement de données numériques et des premiers 10 moyens de communication avec ledit système hôte et ledit dispositif de couplage étant constitué par des seconds moyens de communication avec ledit système portable, il comprend au moins les étapes suivantes: - une étape préliminaire consistant dans le stockage dans lesdits moyens autonomes de mémoire non volatile d'au moins un programme dit client 15 permettant ladite exécution d'application logicielle; - une première étape de chargement dudit programme d'amorce logicielle dans lesdits moyens de mémoire dudit système hôte et son exécution dans ce système en tant que tâche dite de fond; - une deuxième étape consistant dans la détection dudit couplage dudit 20 système portable avec ledit système hôte par ledit programme d'amorce logicielle; - une troisième étape de chargement de tout ou partie dudit programme client dans ledit système hôte, via lesdits premiers et seconds moyens de communication, selon un protocole de communication déterminé, ledit 25 programme client étant identifié en dépendance dudit protocole déterminé; et - une quatrième étape consistant en l'exécution dudit programme client en tout ou partie dans ledit système hôte.

L'invention a encore pour objet une architecture informatique pour la 30 mise en couvre de ce procédé.

L'invention va maintenant être décrite de façon plus détaillée en se référant aux dessins annexés, parmi lesquels: - la figure 1 illustre schématiquement un exemple de mode de réalisation préféré d'architecture informatique pour la mise en oeuvre du procédé d'exécution d'une application logicielle selon l'invention; et - la figure 2 est un organigramme illustrant les principales étapes du procédé selon l'invention.

Dans ce qui suit, sans en limiter en quoi que ce soit la portée, on se placera ci-après dans le cadre de l'application préférée de l'invention, sauf mention contraire, c'est-à-dire dans le cas de l'utilisation d'une carte à puce sécurisée en tant que système portable muni de moyens de mémoire non 10 volatile, de traitement de données et de communication.

On va tout d'abord décrire un exemple d'architecture informatique utilisant une telle carte à puce sécurisée pour la mise en oeuvre du procédé selon l'invention, par référence à la figure 1.

Sur cette figure 1, sans que cela soit limitatif en quoi que ce soit de la 15 portée de l'invention, pour en simplifier la description, il est supposé que le système informatique, côté hôte, ne comprend qu'un terminal autonome, par exemple un ordinateur personnel courant, référencé 1.

L'ordinateur personnel 1 comprend des circuits et dispositifs classiques tels qu'une unité centrale 10 comprenant entre autres un microprocesseur (non 20 explicitement représenté), une mémoire non volatile 11 stockant notamment le "BIOS" (pour "Basic Input Output System") qui permet le démarrage de l'ordinateur personnel 1, ainsi que d'autres microprogrammes classiques, une mémoire centrale 13, de type "RAM" (pour "Random Access Memory" ou "Mémoire accès aléatoire"), des circuits de communications avec l'extérieur 25 (ports d'entrée-sortie de différents types), regroupés sous la référence unique 12 (notés "1/0" sur la figure 1) et une mémoire de masse, a priori un ou plusieurs disques durs 15. D'autres circuits classiques (non représentés) sont prévus: dispositif de visualisation, organes de saisie de données (clavier, souris, etc.), alimentation en énergie, etc. Tous ces composants sont bien 30 connus de l'Homme de Métier. Il est donc inutile de les décrire plus avant.

Il doit d'ailleurs être noté que le terminal hôte, c'est-à-dire l'ordinateur personnel 1 reste entièrement compatible avec les systèmes comparables de l'art connu et cette caractéristique constitue un avantage supplémentaire de l'invention. Les communications entre ces différents organes s'effectuent principalement par l'intermédiaire de bus de transmission bidirectionnels, sous la référence unique 14, ainsi que par des liaisons spécialisées (non représentées).

La seule exigence matérielle est que l'ordinateur personnel 1 soit muni d'un lecteur de carte à puce 2, représenté comme un composant externe dans l'exemple illustré par la figure 1, mais naturellement qui peut être avantageusement intégré. Là encore, il s'agit d'un composant tout à fait classique en soi et également compatible avec l'art connu.

Le lecteur de carte à puce 2 permet d'accueillir des cartes à puce d'un type classique ou d'un type conforme à l'invention, référencé 3, qui va être précisé ci-après.

Il doit être clair cependant que, en ce qui concerne l'architecture matérielle interne de la carte à puce 3, celle-ci, en soi, est tout à fait semblable 15 à celle des cartes à puce de l'art connu, voire identique.

La carte à puce comprend, notamment et de façon classique, un processeur 30, microprocesseur ou microcontrôleur, une mémoire non volatile 31, une mémoire volatile 33 (par exemple du type "RAM" précité, et divers registres non représentés) et des moyens de communication 32 (notés "I/O" sur 20 la figure 1), formant interface avec l'extérieur, c'est-à-dire en l'occurrence le lecteur de carte à puce 2 dans lequel la carte à puce 3 peut être insérée.

Comme dans l'ordinateur personnel 1, les communications entre ces différents organes s'effectuent principalement par l'intermédiaire de bus de transmission bidirectionnels, sous la référence unique 34, ainsi que par des liaisons 25 spécialisées (non représentées).

Toujours de façon connue en soi, lorsque le système portable est une carte à puce 3, comme dans l'exemple décrit, les interfaces de communication 12 et 32 permettent l'établissement de session et des échanges de données bidirectionnelles entre la carte à puce 3 et le terminal 1, a priori conformément 30 à la norme ISO 7816, en faisant appel à des "APDU" (pour "Application Protocol Data Unit" ou "Unités de Données de Protocole d'Application").

On doit bien comprendre cependant que d'autres types de systèmes portables peuvent être utilisés dans le cadre de l'invention: par exemple des modules électroniques semblables aux modules "SIM" (pour "Subscriber Identification Module" ou "Module d'identification d'Abonné") utilisés dans les téléphone mobiles, etc. La seule exigence importante est que le système portable soit muni de moyens autonomes de traitement de données, de de mémoire non volatile et de communication.

Dans ce cas, et selon la nature du système portable, les principaux types d'interfaces mis en oeuvre seront les suivants: - Interfaces à port de transmission de type filaire: "RS232", "USB", etc. - Interfaces à port de transmission de type "sans fil" : "Bluetooth", "IEEE 10 802.1 1", "IEEE 802.15", "Ultra Wide Band" ("UWB"), etc. Ces différents types d'interfaces répondent à des normes ou standards bien connus de l'Homme de Métier, et il est inutile de les décrire plus avant.

Toujours de façon connue en soi, lors d'une phase préliminaire de démarrage de l'ordinateur personnel 1, le système d'exploitation OS (ou 15 "Operating System", selon la terminologie anglo-saxonne couramment utilisée) qui lui est propre est chargé dans la mémoire centrale 13, généralement à partir du disque dur 15. Il peut s'agir d'un système d'exploitation courant tel que UNIX, LINUX, WINDOWS, (marques déposées) ou de tout autre système d'exploitation approprié.

Un programme de petite taille, que l'on appellera programme d'amorce logicielle, référencé PA, est également chargé en mémoire centrale 13 et "tourne" dans celle-ci en tant que tâche de fond ("deamon").

Ce programme PA est capable de détecter l'insertion dans le lecteur de carte à puce 2 d'un dispositif comportant de la mémoire, un processeur 25 sécurisé, et une ressource de communication, en l'occurrence, dans l'exemple décrit, la carte à puce 3, de façon plus générale de tout autre dispositif présentant des caractéristiques similaires.

Si on considère par exemple le cas du système d'exploitation "WINDOWS" de la société MICROSOFT (marques déposées), une "API" (pour 30 "Application Programming Interface" ou "Interface de Programmation d'Application") standard appelée "PC/SC" (pour "Personal Computer/Smart Card" ou "Ordinateur Personnel/Carte Intelligente") permet de détecter la présence d'une carte à puce dans un lecteur de carte à puce. "PC/SC" est une il pièce de logiciel du type dit "Pilote" (ou "driver", selon la terminologie anglosaxonne).

Selon une caractéristique importante de l'invention, la mémoire non volatile 31 stocke dans une de ses zones, référencée arbitrairement 310, un 5 programme que l'on appellera "programme client" PC. Une ou plusieurs autres zones de la mémoire non volatile 31, référencée arbitrairement 311, peuvent stocker d'autres programmes ou micro-instructions, en tant que de besoin.

Sur détection de l'insertion de la carte à puce 3 par le programme d'amorce logicielle PA, le programme client PC, stocké dans la mémoire 31 est 10 chargé en tout ou partie dans l'ordinateur personnel hôte 1, référencé PC'. Le programme PC est identifié par des méthodes adaptées à l'interface de communication, telles q'un nom de fichier (pour le standard "ISO 7816") ou "URL" (pour "Uniform Ressource Locator" ou "Localisation Uniforme de Ressource", pour une interface de type "WEB").

Comme il a été indiqué, les tailles des mémoires non volatiles conformes aux technologies actuelles sont couramment de l'ordre du mégaoctet pour les cartes à puces (mémoire de type dit "FLASH"). Elles pourront atteindre des ordres de grandeurs beaucoup plus importants dans un futur proche en faisant appel à des nanotechnologies du type "Millipede" 20 précité de la société IBM (marques déposées). Il s'ensuit, que le programme PC enregistré dans la zone 310 de la mémoire non volatile 31 peut être d'une taille relativement importante.

Le programme client PC est une pièce de code mobile. Son contenu est compatible avec le système hôte, c'est-à-dire l'ordinateur personnel 1. A 25 titre d'exemple non limitatif, pour le système d'exploitation WINDOWS précité, il se comporte comme une "DLL" (pour "Dynamic Link Library" ou "Bibliothèque de Liaison Dynamique"), ou une "CLASS FILE java" (fichier "java" compilé) pour une plateforme "java" (marque déposée).

Le programme client PC embarque des éléments nécessaires pour 30 communiquer avec la carte à puce 3. En particulier, il est capable d'invoquer des procédures à exécuter à l'intérieur de la carte à puce 3, par le processeur 30.

Dans un mode de réalisation préféré, le programme client PC comporte deux types principaux d'instructions: - des instructions sécurisées, permettant l'exécution de procédure par le processeur 30, selon un paradigme du type "RPC" (pour "Remote Procedure Caîl", c'est-à-dire l'appel de fonctions situées sur une machine distante) ; et - des instructions non sécurisées exécutées par le processeur hôte 10.

Généralement, un processus de type "RPC" s'efforce de maintenir le plus possible la sémantique habituelle des appels de fonction. Pour que ce processus ressemble à un appel de fonction local, il existe dans le programme 10 client PC une fonction locale qui a le même nom que la fonction distante et qui, en réalité, appelle d'autres fonctions de la bibliothèque "RPC" qui prennent en charge les connexions (communications via le lecteur de carte à puce 2), le passage des paramètres et le retour des résultats. De même, côté serveur, c'est-à-dire l'ordinateur personnel hôte 1 dans le cas présent, il suffit 15 habituellement d'écrire une fonction ou un processus se chargeant d'attendre les connexions clientes et d'appeler la fonction avec des paramètres appropriés. Ce processus se charge ensuite de renvoyer les résultats à la carte à puce 3.

Le programme client PC permet donc de gérer la carte à puce 3, et de 20 façon plus générale, le système portable, en tant que système sécurisé. En effet, comme il vient d'être rappelé, les données sensibles sont et restent localisées à l'intérieur de la carte à puce 3. il en est de même des processus sensibles (instructions ou similaires) qui sont exécutées à l'intérieur de cette carte à puce 3, sous la commande directe du processeur 30.

Toutefois, l'ensemble "système hôte - système portable - programme client - programme d'amorce logicielle" constitue un système sécurisé de taille importante, que l'on peut appeler "carte à puce virtuelle".

En outre, comme il a été rappelé, une partie, "non sensible", du programme client pourrait être enregistrée dans l'ordinateur personnel 1, voir 30 sur un serveur distant (non représenté), si ce dernier est connecté à un réseau local, à un réseau intranet ou au réseau Internet, par exemple.

On va maintenant décrire les principales étapes du procédé d'exécution d'une application logicielle par l'intermédiaire d'un programme d'amorce logicielle selon l'invention, ce par référence plus particulière à l'organigramme 4 de la figure 2, mais également en référence à l'architecture de la figure 1.

Une première étape préliminaire, bloc4O, non spécifique à l'invention, 5 consiste à charger un système d'exploitation approprié OS dans la mémoire centrale 13 du système hôte, par exemple l'ordinateur personnel 1. Une deuxième étape, également préliminaire mais spécifique à l'invention,

bloc 41, consiste en l'enregistrement du programme client PC dans la mémoire non volatile du système portable (par exemple dans la mémoire 31 10 de la carte à puce 3).

Lors d'une troisième étape (qui peut être concomitance à la première étape), bloc42, le programme amorce PA est également chargé dans la mémoire 13 et exécuté sur le système hôte 1 en tant que tâche de fond.

Lors d'une quatrième étape, bloc43, lorsqu'un système portable, 15 comportant des moyens de traitement de données et de mémoire non volatile autonomes, est couplé au système hôte 1 (par exemple lorsque la carte à puce 3 est insérée dans le lecteur de carte à puce 2), le programme amorce PA détecte ce couplage (ou cette insertion: schématisé par des traits pointillés référencés d sur la figurel).

Lors d'une cinquième étape, bloc44, le programme client PC stocké dans la mémoire non volatile du système portable (par exemple dans une zone 310 de la mémoire 31 de la carte à puce 3) est chargé en tout ou partie dans le système hôte 1 (référencé PC' sur la figure 1), le programme client PC étant stocké sous un format approprié: "DLL", ".CLASS", etc., suivant le système 25 d'exploitation mis en oeuvre.

Lors d'une sixième étape, bloc45, le programme client, ou la parte de ce programme client PC', chargé dans le système hôte 1 est exécuté.

Lors d'une septième étape, bloc46, des procédures appelées (non explicitement représentées) par le programme client PC sont directement 30 exécutées dans le système portable (par exemple la carte à puce 3, sous la commande du processeur 30). Ces procédures sont également stockées dans la mémoire non volatile 31. On fait appel à des normes ou standards "Java RMI", "ISO 7816", "http" ("pour Hyper Text Transport Protocol" ou "Protocole de transmission Hyper Texte"), etc., selon les types d'interface de communication utilisés entre le système hôte 1 et le système portable (par exemple la carte à puce 3).

L'ordre relatif de certaines étapes peut être modifié sans sortir du 5 cadre de l'invention. Par exemple, les sixième et septième étapes peuvent être interverties. De même, certaines étapes peuvent être répétées de façon itérative, en particulier les dernières étapes.

Le procédé selon l'invention peut également comprendre des étapes supplémentaires.

A titres d'exemple, on peut prévoir une étape préliminaire de compression du programme client PC avant son enregistrement dans la mémoire non volatile 31, de manière à ce qu'il occupe moins de place. Pour ce faire, on peut faire appel à des algorithmes de compression bien connus en soi, tels "ZIP", "TAR", etc. Dans cette hypothèse, il sera nécessaire de procéder à une étape intermédiaire de décompression du programme client PC avant utilisation.

Cette décompression peut être effectuée entièrement dans le système hôte 1, par exemple si seules les données "non sensibles" sont compressées, dans le système portable (par exemple la carte à puce 3) ou partiellement dans l'un et 20 l'autre.

La carte à puce 3 peut être également d'un type dit "multi-application", en ce sens qu'elle peut stocker plusieurs programmes clients distincts ou un programme client unique, mais permettant un choix entre plusieurs applications. Le choix entre les différentes applications peut être effectué, 25 après détection du couplage entre le système hôte 1 et le système portable (par exemple la carte à puce 3), par un processus interactif initié par le porteur du système portable. Ce processus peut se traduire, par exemple, par l'affichage d'un menu sur un dispositif de visualisation (non représenté)associé au système hôte 1, suivi de la saisie d'instructions de sélection par 30 l'intermédiaire d'un dispositif d'entrée de données (non représenté: clavier, souris, etc.). En fonction du choix effectué, une portion spécifique du programme client PC est chargé dans le système hôte 1 et/ou des procédures particulières sont appelées par le programme client PC et exécutées.

A la lecture de ce qui précède, on constate aisément que l'invention atteint bien les buts qu'elle s'est fixés.

Sans répéter intégralement les avantages de celle-ci, on constate que le procédé permet tout à la fois une très grande souplesse, un haut degré de 5 sécurité informatique et l'exécution de programmes de tailles importantes. Il reste cependant, pour l'essentiel entièrement compatible, notamment d'un point de vue matériel avec les architectures de l'art connu. En effet, il ne nécessite a priori aucune modification du matériel, tant du côté système hôte que du côté système portable, puisque ces derniers peuvent être constitués, dans un mode 10 de réalisation préféré, par des cartes à puce standards ou des modules similaires.

Il doit être clair cependant que l'invention n'est pas limitée aux seuls exemples de réalisations explicitement décrits, notamment en relation avec les figures 1 et 2.

Comme il a été indiqué, le système portable peut être constitué par une carte à puce ou un module similaire, dans un mode de réalisation préféré.

Cependant, tout système portable"actif", c'est-à-dire muni de moyens de traitement de données, de moyens de mémoire non volatile pouvant stocker un programme dit client, et de moyens de communication avec un système hôte 20 autonome peut a priori convenir.

L'invention n'est pas limitée non plus à la seule application expressément décrite, c'est-à-dire la configuration et la personnalisation d'un système hôte en fonction de données propres à un porteur d'un système portable ou au système portable lui-même. Le procédé selon l'invention permet 25 de façon plus générale d'exécuter au moins une application logicielle déterminée à l'aide d'un programme d'amorce logicielle, tout en assurant un haut degré de sécurité informatique que ne permettent pas les procédés de l'art connu.

Claims (10)

REVENDICATIONS

1. Procédé d'exécution d'une application logicielle par l'intermédiaire d'un programme dit d'amorce logicielle dans un système informatique dit hôte comprenant au moins des moyens de mémorisation et de traitement de données numériques et un dispositif de couplage à un organe externe, 5 caractérisé en ce que, ledit organe mobile externe étant constitué par un système portable (3) comprenant au moins des moyens autonomes de mémoire non volatile (31), de traitement de données numériques (30) et des premiers moyens de communication (32) avec ledit système hôte (1) et ledit dispositif de couplage étant constitué par des seconds moyens de 10 communication (12, 2) avec ledit système portable (3), il comprend au moins les étapes suivantes: - une étape préliminaire (41) consistant dans le stockage dans lesdits moyens autonomes de mémoire non volatile (31) d'au moins un programme dit client (PC) permettant ladite exécution d'application 15 logicielle; - une première étape (42) de chargement dudit programme d'amorce logicielle (PA) dans lesdits moyens de mémoire (13) dudit système hôte (1) et son exécution dans ce système en tant que tâche dite de fond; - une deuxième étape (43) consistant dans la détection (d) dudit couplage 20 dudit système portable (3) avec ledit système hôte (1) par ledit programme d'amorce logicielle (PA); - une troisième étape de chargement (44) de tout ou partie dudit programme client (PC, PC') dans ledit système hôte (1), via lesdits premiers (32) et seconds (12, 2) moyens de communication, selon un 25 protocole de communication déterminé, ledit programme client (PC) étant identifié en dépendance de la nature dudit protocole déterminé ; et - une quatrième étape (45) consistant en l'exécution dudit programme client (PC, PC') en tout ou partie dans ledit système hôte (1).

2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend une première étape supplémentaire (46) consistant en l'invocation de procédures prédéterminée stockées dans ladite mémoire non volatile (31) et en son exécution dans ledit système portable (3), sous la commande desdits moyens de traitement de données autonomes (30).

3. Procédé selon les revendications 1 ou 2, caractérisé en ce qu'il comprend une deuxième étape supplémentaire consistant à appliquer un algorithme de compression de données déterminé à tout ou partie des instructions constituant ledit programme client (PC), avant son stockage dans lesdits 10 moyens de mémoire non volatile (31) et une troisième étape supplémentaire consistant en la décompression desdites instructions compressées.

4. Procédé selon l'une quelconque des revendications 2 à 3, caractérisé en ce que ledit programme client (PC) comprend un premier type d'instructions, dites sécurisées, permettant l'invocation et l'exécution desdites procédures 15 stockées dans lesdits moyens de mémoire non volatile (31) et sous la commande desdits moyens de commande (30) dudit système portable (3) et un second type d'instructions, dites non sécurisées, destinées à être exécutées par lesdits moyens de traitement de données numériques (10) dudit système hôte (1).

5. Architecture informatique pour la mise en oeuvre du procédé d'exécution d'une application logicielle par l'intermédiaire d'un programme dit d'amorce logicielle selon l'une quelconque des revendications précédentes, caractérisée en ce qu'elle comprend au moins un système hôte (1) comprenant au moins lesdits moyens de mémoire (11, 13, 15) et de 25 traitement de données numériques (10), et lesdits seconds moyens de communication (12, 2), et un système portable (3) comprenant au moins lesdits moyens autonomes de mémoire non volatile (31), de traitement de données numériques (30), et lesdits premiers moyens de communication (32) avec ledit système hôte (1), en ce que ledit programme d'amorce 30 logicielle (PA) est stocké dans lesdits moyens de mémoire (11, 13, 15) dudit système hôte (1) et en ce que chacun desdits programmes clients (PC) est stocké dans lesdits moyens de mémoire non volatile (31) dudit système

portable (3).

6. Architecture selon la revendication 5, caractérisée en ce que ledit système portable est constitué par une carte à puce sécurisée (3) comprenant au 5 moins une mémoire non volatile (31) du type dit "FLASH", stockant au moins un programme client (PC), un processeur (30) et des moyens de d'entréesortie (32) permettant des communications avec ledit système hôte (1).

7. Architecture selon la revendication 6, caractérisée en ce que ledit système hôte (1) est associé à un lecteur de carte à puce (2) dans lequel ladite carte 10 à puce (3) peut être insérée et en ce que ledit programme d'amorce logicielle (PA) détecte l'insertion de ladite carte à puce (3) dans ledit lecteur de carte à puce (2) lors de ladite étape de détection, de manière à pouvoir réaliser ladite étape subséquente de chargement de tout ou partie dudit programme client (PC, PC').

8. Architecture selon l'une des revendications 6 ou 7, caractérisée en ce que lesdits moyens de communication (12, 2, 32) sont dotés d'une interface conforme à la norme ISO 7816 et en ce que chacun desdits programmes clients (PC) est identifié par ledit programme d'amorce (PA) par un nom de fichier.

9. Architecture selon la revendication 5, caractérisée en ce que lesdits moyens de communication sont dotés d'une interface comportant un port de transmission de type filaire.

10. Architecture selon la revendication 5, caractérisée en ce que lesdits moyens de communication sont dotés d'une interface comportant un port de 25 transmission de type sans fil.