FR 2872933 A1 20060113 FR 0407496 A 20040706 La présente invention concerne un procédé et un système de partage du temps d'exécution d'un processeur physique unique entre au moins deux logiciels. La sécurité des logiciels est devenue un enjeu majeur de l'industrie 5 avec la mise en réseau de machines de plus en plus nombreuses et de plus en plus puissantes. Cet enjeu n'est pas limité aux ordinateurs classiques mais existe également pour les téléphones portables, les systèmes embarqués, ... qui intègrent de plus en plus de fonctions. Les systèmes d'exploitation sont particulièrement vulnérables à cause de leur complexité. L'énorme volume de code d'un système d'exploitation moderne rend en effet la vérification du code, pour le rendre invulnérable, impossible. Pour améliorer la sécurité des systèmes, il a été proposé d'isoler les 15 fonctions de sécurité du reste du logiciel. Cependant, cette isolation ne peut pas être purement logicielle sous peine d'être défaite par un code malicieux exécuté par les parties non protégées du système d'exploitation. Une première réponse a été apportée par les fabricants de 20 microprocesseurs en créant un mode privilégié qui a accès à plus de ressources que le mode normal de l'utilisateur. Dans le fonctionnement normal d'un système informatique, le mode privilégié n'est utilisé que par le système d'exploitation. Cependant, il apparaît que, pour différentes raisons, et en particulier pour l'accès aisé aux périphériques, des parties de code de plus en plus importantes sont exécutées dans ce mode privilégié , et donc le problème de l'audit de sécurité de ce code devient difficile à résoudre. La société ARM Ltd (Cambridge, UK) propose une nouvelle extension de sécurité pour son architecture de microprocesseur ARMv6 qu'elle appelle 30 TrustZone (marque déposée de ARM Ltd). Cette extension est décrite dans une note de cette société intitulée A new Foundation for CPU Systems Security par Richard York (Mai 2003) ainsi que dans un article ARM Dons Armor par Tom R. Halfhill (Microprocessor Report/In-Stat, 25 août 2003). 2872933 2 Cette extension ajoute un domaine de permission spécial complémentaire aux modes privilégié et normal déjà existants. Pour entrer dans ce domaine, le système d'exploitation doit invoquer une instruction spéciale qui n'est accessible qu'en mode privilégié . Cette instruction exécute alors un changement de contexte pour donner accès au logiciel de sécurité de ce domaine et met un bit spécial à 1. Certaines parties de la mémoire, ou certains périphériques, sélectionnés au moment de l'initialisation du système, ne sont accessibles que quand ce bit spécial est positionné à 1. Cela permet d'isoler ainsi les éléments utilisés par le logiciel de sécurité et donc d'interdire à un logiciel malveillant exécuté par le système d'exploitation non sécurisé d'y avoir accès. Or, dans ce mode de fonctionnement, le logiciel de sécurité est l'esclave du système d'exploitation non sécurisé puisque c'est celui-ci qui l'appelle. Ceci peut être un inconvénient majeur puisque un logiciel malveillant qui prendrait le contrôle de la machine pourrait décider de ne jamais exécuter le logiciel de sécurité et l'empêcher ainsi de remplir ses fonctions. De plus, cela nécessite de modifier le système d'exploitation pour qu'il prenne en compte le logiciel de sécurité. Or, comme indiqué précédemment, les systèmes d'exploitation sont des logiciels complexes sur lesquels il est difficile d'intervenir et qui, de plus, sont souvent propriété d'un éditeur qui n'a pas obligatoirement la volonté ou le désir d'effectuer des modifications. Le but de l'invention est de résoudre ces inconvénients. L'objet de l'invention est donc un procédé de partage du temps d'exécution d'un processeur physique entre au moins deux logiciels, ledit processeur comportant une pluralité de modes d'exécution et accédant à une pluralité de ressources, chacun desdits modes d'exécution garantissant des droits d'accès spécifiques auxdites ressources, et, parmi la pluralité des modes d'exécution, au moins un mode d'exécution particulier, dit mode sécurisé, ayant un accès exclusif sur certaines ressources, caractérisé en ce que, au moins un logiciel, dit de sécurité, étant exécuté exclusivement dans un des modes d'exécution sécurisés, et au moins un logiciel, dit non sûr, étant exécuté dans au moins un mode d'exécution autre que les modes d'exécution sécurisés, le procédé comprend les étapes suivantes, exécutées en mode sécurisé : a) définition d'un cycle périodique d'exécution des logiciels par le processeur, b) découpage de ce cycle en deux parties, l'une pour l'exécution du logiciel de sécurité, et l'autre pour l'exécution du logiciel non sûr. Un second objet est un système de partage du temps d'exécution d'un processeur physique entre au moins deux logiciels, ledit processeur comportant une pluralité de modes d'exécution et accédant à une pluralité de ressources, chacun desdits modes d'exécution garantissant des droits d'accès spécifiques auxdites ressources, et parmi la pluralité des modes d'exécution, au moins un mode d'exécution particulier, dit mode sécurisé, ayant un accès exclusif sur certaines ressources, caractérisé en ce que, au moins un logiciel, dit de sécurité, étant exécuté exclusivement dans 15 un des modes d'exécution sécurisés, et au moins un logiciel, dit non sûr, étant exécuté dans au moins un des modes d'exécution autre que le mode d'exécution sécurisés, le système comporte: - une horloge apte à déclencher un événement de façon régulière, celle-ci n'étant accessible qu'en mode sécurisé, - des moyens de changement de contexte, appelé moniteur, fonctionnant en mode sécurisé, permettant de transférer l'exécution du premier logiciel vers le second et réciproquement, ces moyens de changement de contexte étant actionnés par l'évènement déclenché par l'horloge, et lesdits moyens de changement de contexte comportant au moins un compteur de temps total périodique et un compteur de temps d'exécution du logiciel sécurisé sur chaque période et des moyens de comparaison de ces compteurs avec une valeur prédéterminée tels que si le temps d'exécution du logiciel sécurisé sur la période est inférieure à la valeur prédéterminée alors les moyens de changement de contexte basculent le contexte vers l'exécution du logiciel sécurisé. D'autres avantages de l'invention sont: - le cycle est découpé en un nombre entier prédéfini d'intervalles de temps dont une première fraction est affectée au logiciel de sécurité et dont le reliquat est affecté au logiciel non sûr; - il comprend en outre les étapes de: a) configuration d'une interruption pour qu'elle se déclenche au début de chaque intervalle prédéfini du cycle, b) calcul du temps d'exécution, sous forme de nombre d'intervalles, du logiciel de sécurité pendant le cycle, c) si le nombre d'intervalle ainsi calculé est inférieur à la première fraction prédéfinie alors exécution du logiciel de sécurité sinon exécution du logiciel non sûr. - le temps d'exécution du logiciel pendant le cycle s'exprime sous la forme du modulo du numéro d'ordre de l'interruption par le nombre d'intervalles du cycle. - l'interruption est déclenchée par une horloge accessible uniquement en mode sécurisé. - on configure une interruption pour qu'elle se déclenche à la fin de chaque partie du cycle afin de transférer le temps d'exécution du logiciel en cours d'exécution vers l'autre logiciel. - le déclenchement est provoqué par une horloge de surveillance, accessible uniquement en mode sécurisé. - l'interruption est exécutée dans le mode sécurisé. - l'un au moins des logiciels non sûrs est un système d'exploitation multi-tâches utilisant une interruption temporelle régulière de changement de 25 tâches. - le système d'exploitation multi-tâches ne configurant pas d'horloge pour déclencher son interruption temporelle régulière, on utilise l'interruption de transfert d'un logiciel vers l'autre pour exécuter la fonction d'interruption liée à l'interruption temporelle régulière de changement de tâches. - le système d'exploitation multi-tâches configurant sa propre horloge pour déclencher son interruption temporelle régulière, ledit procédé comporte en outre les étapes de détection des interruptions du système d'exploitation multitâches puis de temporisation de l'exécution du logiciel de sécurité de façon à ce que celui-ci s'exécute en dehors des interruptions temporelles régulières du système d'exploitation multitâches; et - le logiciel de sécurité comporte une machine virtuelle; et le logiciel de sécurité comporte un environnement STIP ou tout autre 5 environnement programmatique interprété destiné à l'exécution de programmes sécurisés ou bancaires; et - le logiciel sécurisé comporte des moyens de protection de l'intégrité des logiciels, ou de protection d'identifiants, ou de protection d'accès à un réseau de données, ou de service cryptographique, ou de gestion de données confidentielles, ou de signature électronique, ou de gestion des droits d'auteurs, ou d'administration à distance d'un dispositif de paiement. Le procédé et le système sont utilisables dans un téléphone cellulaire, un assistant numérique personnel, un terminal de paiement bancaire ou un terminal de paiement portatif. L'invention sera mieux comprise à la lumière de la description qui va suivre, donnée uniquement à titre d'exemple, et faite en référence aux dessins annexés et dans lesquels: - la figure 1 est un schéma d'un système comportant un processeur, des ressources sécurisées et des ressources non sécurisées, - la figure 2 est un ordinogramme de la gestion des temps entre un logiciel non-sûr et un logiciel de sécurité, - la figure 3 est un ordinogramme d'une fonction de calcul de temps de répartition, - la figure 4 est un chronogramme de répartition du temps entre un 25 logiciel de sécurité et un logiciel non sûr, - la figure 5 est un ordinogramme d'une deuxième implémentation de la gestion des temps entre un logiciel non sûr et un logiciel de sécurité, et - les figures 6, 7, 8 et 9 sont des chronogrammes de répartition du temps entre un logiciel non sûr et un logiciel de sécurité dans différents modes d'interruption. Bien qu'il ait été fait référence au système de sécurité de la société ARM, la description qui va suivre n'est pas limitée à ce système et l'homme du métier pourra sans difficulté adapter cet enseignement à une autre architecture de microprocesseur disposant d'un environnement de sécurité similaire. On entend par environnement sûr, un environnement qui garantit une exécution conforme du logiciel. Un processeur 1 est représenté figure 1. Il comporte une pluralité de modes d'exécution ainsi que des ressources diverses comme de la mémoire 2, 2a des unités arithmétiques et logiques et des périphériques. Ces ressources peuvent être internes au processeur comme les unités arithmétiques et logiques ou externes comme certains périphériques ou la mémoire Comme il est bien connu de l'homme du métier, chaque mode 10 d'exécution permet d'accéder ou non à une ressource particulière. Le processeur 1 possède un mode particulier d'exécution, dit mode sécurisé, tel que certaines ressources ne sont accessibles que dans ce mode d'exécution. Ces ressources particulières sont symbolisées sur la figure 1 par un angle inférieur droit noirci. Ainsi, par exemple, la mémoire programme 2 du processeur est découpée en zones 3, 3a, 4, 5, 6 et 7 correspondant chacune à un programme particulier. Le programme résidant dans la zone 3, 3a sécurisée s'exécute uniquement en mode sécurisé et lui seul a accès aux ressources 8 et 9 qui sont définies comme sécurisées. Pour la clarté de la description, et sans que cela nuise à la généralité de celle-ci, un seul logiciel est supposé fonctionner en mode non sécurisé, ce logiciel sera défini comme non sûr. Il est ainsi supposé que le processeur 1 doit faire fonctionner un logiciel de sécurité en utilisant la zone mémoire 3, 3a de sécurité, et un logiciel non sûr, en utilisant la zone mémoire 4 non sécurisée. Le processeur 1 comporte également une horloge 8 fonctionnant en mode sécurisé et capable de déclencher une interruption 9 à intervalle régulier et/ou prédéterminé. Afin de garantir au logiciel de sécurité un temps d'exécution minimum, on définit un cycle périodique et régulier d'exécution des logiciels par le processeur, et on découpe ce cycle en deux parties, l'une pour l'exécution du logiciel de sécurité et l'autre pour l'exécution du logiciel non sûr. A cette fin, lors de l'initialisation du processeur, celui-ci démarre en mode sécurisé afin de permettre une initialisation de l'ensemble sans risque de compromission en provenance du logiciel non sûr. Ainsi, un environnement, ou contexte, est défini pour le logiciel de 5 sécurité et un environnement différent, correspondant à des modes d'exécution non sécurisés, est défini pour le logiciel non sûr. Puis l'horloge 8 est configurée pour déclencher une interruption TICKIRQ 9 à intervalle régulier d'une durée TICK, cette durée étant choisie pour découper le cycle d'exécution en un nombre entier d'intervalles. La fonction d'interruption correspondante, nommée TICK-HANDLER, est toujours appelée en mode sécurisé. Pour mémoire, on rappelle qu'une fonction d'interruption est la fonction exécutée par le processeur à la réception de l'interruption correspondante. Pendant le fonctionnement normal du processeur, figure 2, et au bout 15 d'une durée TICK, l'horloge déclenche en 10 l'interruption TICK-IRQ qui appelle en 11 la fonction TICK-HANDLER. Celle-ci appelle en 12 une fonction TRATIO-SELECTION (x) qui détermine la répartition du temps processeur entre le logiciel de sécurité et le logiciel non sûr. Si cette répartition est telle que le logiciel de sécurité a bénéficié de moins de temps que prévu, la fonction retourne une valeur 1 et 0 sinon. La valeur 1, étape 13, indique ainsi à TICK-HANDLER que le logiciel de sécurité doit continuer à bénéficier du temps processeur en 14 s'il était en train de s'exécuter lors de l'interruption ou bien que le contexte doit être basculé pour que le logiciel de sécurité soit exécuté si c'était le logiciel non sûr qui était en train de s'exécuter lors de l'interruption. Réciproquement, la valeur 0, étape 13, indique à TICK-HANDLER que c'est le logiciel non sûr qui doit désormais bénéficier, en 15, du temps processeur, et donc, comme dans la situation précédente, soit la fonction retourne sans rien faire, soit elle effectue un changement de contexte en fonction de l'état avant l'interruption. Comme il est bien connu de l'homme du métier, un changement de contexte consiste à sauvegarder le contexte courant puis à rétablir le contexte sauvegardé correspondant au logiciel à exécuter. La fonction TRATIO-SELECT permet donc de répartir le temps processeur entre le logiciel de sécurité et le logiciel non sûr, ou autrement dit, d'affecter certains intervalles au logiciel de sécurité et les autres intervalles au logiciel non sûr. Un fonctionnement possible, donné à titre d'exemple, est le suivant, figure 3. Soit TRATIO le rapport désiré entre le temps donné au logiciel sûr et le temps total d'exécution du processeur. TRATIO-SELECT prend en entrée un entier x croissant à chaque appel de la fonction. Par exemple x est le numéro d'ordre chronologique de l'interruption TICK-IRQ. Deux entiers N et P sont choisis tels que P est inférieur ou égal à N et la division de P par N est égale à TRATIO. Alors si x modulo N est strictement inférieur à P, TRATIO-SELECT retourne 1 et 0 sinon. Il doit être noté que pour limiter le nombre d'interruptions afin de minimiser l'impact de ces interruptions sur le fonctionnement global du système, N et P doivent être choisis le plus petit possible. Un exemple avec N = 5 et P = 2 est donné figure 4 sous la forme d'un chronogramme de répartition des temps entre les deux logiciels. La ligne TOS représente le temps du logiciel de sécurité et la ligne NTOS le temps du logiciel non sûr. Dans l'exemple de fonctionnement présenté, aucun des logiciels n'est un système multi-tâches préemptif par interruption temporelle. Pour mémoire, on rappelle qu'un système multi-tâches préemptif par interruption temporelle utilise une interruption temporelle régulière, d'une durée NTTICK, telle que, à chaque interruption NTTICK-IRQ, une fonction NTTICKHANDLER est appelée dont le rôle est d'effectuer un basculement entre les tâches. Dans un deuxième exemple de réalisation, le logiciel non sûr est donc un système multi-tâches préemptif par interruption temporelle. Le procédé est alors similaire à celui décrit précédemment mais les durées TICK et NTTICK sont choisies de façon à ce que NTTICK soit un multiple de TICK. Par exemple, NTTICK est égal à L fois TICK, L étant un entier. Dans ce deuxième mode de réalisation, le logiciel non sûr positionne un vecteur d'interruption pour NTTICK-HANDLER mais ne configure pas d'horloge pour déclencher les interruptions NTTICK-IRQ. La fonction TICK-HANDLER est alors utilisée pour appeler la fonction 5 NTTICK-HANDLER. Elle exécute les opérations suivantes, figure 5. - incrémentation en 20 du numéro d'ordre de l'interruption TICK- COUNT de 1, - appel en 21 de la fonction TRATIO-SELECT (TICK-COUNT) qui retourne CI, - calcul en 22 de TICK-COUNT modulo L, désigné C2. Ainsi C2 est égal à o à chaque durée NTTICK. - si CI est nul, cela veut dire que le logiciel non sûr doit s'exécuter en 23, ou continuer à s'exécuter. ^ Si C2 est également nul, NTTICK-HANDLER est appelé, étape 24, en restant dans le contexte non sûr. - si CI est non nul, alors le logiciel de sécurité doit être exécuté, ou doit continuer de s'exécuter. ^ Si C2 est également nul, la fonction NTTICK-HANDLER est appelée en 25 dans le contexte non sûr, mais à son retour, le contexte sûr est rétabli en 26 et le contrôle est donné en 27 au logiciel de sécurité. La figure 6 est un chronogramme illustrant le fonctionnement précédent avec TRATIO = 40% et L = 5. On constate que la contrainte NTTICK=L*TICK induit que NTTICKHANDLER est appelée avec un intervalle de NTTICK comme attendu par le 25 logiciel non sûr. Dans un troisième exemple de fonctionnement, le logiciel non sûr est un système multi-tâches préemptif par interruption temporelle qui configure une horloge qui lui est propre pour générer les interruptions NTTICK, et appeler ainsi la fonction NTTICK-HANDLER. Cette interruption peut avoir lieu pendant le déroulement normal du logiciel non sûr comme pendant le déroulement du logiciel de sécurité. Si la période de déclenchement de cette horloge est identique à la période d'accès du logiciel de sécurité, alors l'interruption intervient avec un retard constant par rapport à la préemption du logiciel non sûr par le logiciel de sécurité. Si la contrainte NTTICK=L*TICK est toujours respectée, cette périodicité commune peut s'écrire TRATIO-SELECT(x) = TRATIO-SELECT (x modulo L). La figure 7 illustre cette périodicité dans le cas où l'interruption NTTICK-IRQ intervient pendant le déroulement du logiciel non sûr. Cependant, ce retard constant peut être tel que l'interruption NTTICKIRQ intervienne pendant le déroulement du logiciel de sécurité. Dans ce cas, figure 8, la préemption du logiciel de sécurité par la fonction NTTICKHANDLER nécessite de passer de l'environnement sûr à l'environnement non sûr puis de passer au contexte d'exécution de la fonction d'interruption NTTICK-HANDLER pour, finalement, retourner à l'environnement sûr. Ces opérations répétées à intervalles réguliers peuvent engendrer des problèmes de performance. De plus, figure 9, certaines implémentations de système d'exploitation multi-tâches préemptif sont telles que la fonction d'interruption NTICKHANDLER ne retourne jamais: elle procède au changement de contexte de tâche du logiciel non sûr et passe directement à l'exécution de cette nouvelle tâche. Ainsi, dans un tel système, le contrôle est rendu en fin d'interruption au logiciel non sûr et non au logiciel de sécurité. Dans cette situation, le temps d'exécution affecté au logiciel de sécurité est fortement diminué. Pour corriger ce problème, il est nécessaire que le logiciel de sécurité puisse intervenir sur l'interruption matérielle avant que la fonction d'interruption 25 NTTICK-HANDLER soit appelée. II suffit alors d'examiner si l'environnement courant, lors de l'interruption, était l'environnement de sécurité ou l'environnement non sûr. Si c'est l'environnement de sécurité, un indicateur est positionné en mémoire pour indiquer le problème. Puis la fonction NTTICK-HANDLER est appelée normalement. La fonction TICK-HANDLER est modifiée pour que l'incrémentation de numéro d'ordre de l'interruption TICK-COUNT n'ait lieu que si l'indicateur précédent n'est pas positionné. Sinon, l'incrémentation n'a pas lieu et l'indicateur est remis à zéro. Cela provoque un décalage d'une unité TICK du basculement de l'environnement non sûr vers l'environnement de sécurité, et réciproquement. Et ainsi, progressivement, l'interruption NTTICK-IRQ est calée pour se déclencher pendant la phase d'exécution du logiciel non sûr. Le procédé ainsi décrit s'applique également quand le logiciel de sécurité est un système multi-tâches utilisant une interruption temporelle dont la durée est régulière. Dans une variante du procédé, on peut avantageusement remplacer le déclenchement des interruptions TICK-IRQ à intervalle régulier par le déclenchement d'une interruption seulement quand le temps imparti pour un logiciel donné est écoulé. En prenant l'exemple illustré sur la figure 4, cela veut dire que l'interrogation TICK-IRQ ne sera déclenchée que alternativement, tous les deux ou trois TICK. Comme le procédé décrit permet au logiciel de sécurité d'avoir accès aux ressources du processeur et, en particulier, à certains vecteurs d'interruption et aux paramètres de la protection mémoire, le logiciel non sûr peut être un système d'exploitation standard. En particulier, le logiciel de sécurité peut s'exécuter même si le logiciel non sûr a été conçu sans tenir compte de la présence d'autres environnements. On conçoit que le logiciel de sécurité peut prendre différentes formes. Il peut comporter une machine virtuelle sécurisée comme une machine virtuelle JAVA ou C# ou comme un environnement STIP (Small Terminal Interoperability Platform). Ce dernier, spécifiant un environnement et une machine virtuelle dédiée aux terminaux de paiement, a typiquement besoin d'être exécuté dans un environnement de sécurité. Le logiciel sécurisé peut également comporter des moyens de protection de l'intégrité des logiciels, ou de protection d'identifiants, ou de protection d'accès à un réseau de données, ou de service cryptographique, ou de gestion de données confidentielles, ou de signature électronique, ou de gestion des droits d'auteurs, ou d'administration à distance d'un dispositif de paiement. Cette exécution est possible grâce à l'interception et à la manipulation des vecteurs d'interruption et des paramètres de protection mémoire du logiciel. Le procédé et le système ainsi décrits peuvent être mis en oeuvre sur de nombreuses architectures. On conçoit donc qu'on a ainsi un procédé de partage de temps d'exécution d'un processeur physique 1 entre au moins deux logiciels, ledit processeur comportant une pluralité de modes d'exécution et accédant à une pluralité de ressources 3, 4, 5, 6, 7, 8, et 9, chacun desdits modes d'exécution garantissant des droits d'accès spécifiques auxdites ressources, et, parmi la pluralité des modes d'exécution, au moins un mode d'exécution particulier, dit mode sécurisé, ayant un accès exclusif sur certaines ressources 3, 8, et 9, et au moins un premier logiciel, dit de sécurité, étant exécuté exclusivement dans le mode d'exécution sécurisé, et au moins un second logiciel, dit non sûr, étant exécuté dans au moins un mode d'exécution autre que les modes d'exécution sécurisés. Ce procédé comprend les étapes suivantes: a) on définit un cycle périodique et régulier d'exécution des logiciels par le processeur, b) on découpe ce cycle en deux parties, l'une pour l'exécution du logiciel de sécurité, et l'autre pour l'exécution du logiciel non sûr. Le cycle périodique définit dans ce procédé est découpé en un nombre 20 entier prédéfini d'intervalles de temps dont une première fraction est affectée au logiciel de sécurité et dont le reliquat est affecté au logiciel non sûr. Pour ce faire, a) on déclenche une interruption au début de chaque intervalle prédéfini du cycle, b) on calcule le temps d'exécution, sous forme de nombre d'intervalles, du logiciel de sécurité pendant le cycle, c) si le nombre d'intervalle ainsi calculé est inférieur à la première fraction prédéfinie alors le logiciel de sécurité est exécuté sinon le logiciel non sûr est exécuté. Comme indiqué précédemment, le temps d'exécution du logiciel pendant le cycle s'exprime sous la forme du modulo du numéro d'ordre de l'interruption par le nombre d'intervalles du cycle. Dans un autre mode de réalisation, on déclenche une interruption à la fin de chaque partie du cycle afin de transférer le temps d'exécution du logiciel en cours d'exécution vers l'autre logiciel. Dans tous les cas, l'interruption est exécutée dans le mode sécurisé. Elle peut, par exemple, être déclenchée par une horloge accessible uniquement en mode sécurisé. Concernant le logiciel non sûr, il peut être un système d'exploitation multi-tâches utilisant une interruption temporelle régulière de changement de tâches. Si il ne configure pas d'horloge pour déclencher son interruption temporelle régulière, on utilise l'interruption de transfert d'un logiciel vers l'autre pour exécuter la fonction d'interruption liée à l'interruption temporelle régulière de changement de tâches. Si, par contre, il configure sa propre horloge pour déclencher son interruption temporelle régulière, le procédé comporte en outre les étapes de détection des interruptions du système d'exploitation multi- tâches puis de temporisation de l'exécution du logiciel sécurisé de façon à ce que celui-ci s'exécute en dehors des interruptions temporelles régulières du système d'exploitation multi-tâches. On a également décrit un système de partage de temps d'exécution d'un processeur physique entre au moins deux logiciels, ledit processeur comportant une pluralité de modes d'exécution et accédant à une pluralité de ressources, chacun desdits modes d'exécution garantissant des droits d'accès spécifiques auxdites ressources, et parmi la pluralité des modes d'exécution, un mode d'exécution particulier, dit mode sécurisé, ayant un accès exclusif sur certaines ressources, et un premier logiciel, dit de sécurité, étant exécuté exclusivement dans le mode d'exécution sécurisé, et un second logiciel, dit non sûr, étant exécuté dans au moins un mode 30 d'exécution autre que le mode d'exécution sécurisé, qui comporte: - unehorloge apte à déclencher une interruption de façon régulière, celle-ci n'étant accessible qu'en mode sécurisé, - des moyens de changement de contexte, fonctionnant en mode sécurisé, permettant de transférer l'exécution du premier logiciel vers le second et réciproquement, ces moyens de changement de contexte étant déclenchés par l'interruption de l'horloge, et lesdits moyens de changement de contexte comportant au moins un compteur de temps total périodique et un compteur de temps d'exécution du logiciel sécurisé sur chaque période et des moyens de comparaison de ces compteurs avec une valeur prédéterminée tels que si le temps d'exécution du logiciel sécurisé sur la période est inférieure à la valeur prédéterminée alors les moyens de changement de contexte basculent le contexte vers l'exécution du logiciel sécurisé. Ainsi, grâce au procédé et au système décrits, il est, de façon avantageuse, possible de garantir un temps d'exécution à un logiciel de sécurité. De plus, on constate aisément que les systèmes d'exploitation, ou plus généralement les logiciels, résidents en zone non sécurisée n'ont pas besoin d'être modifiés pour permettre cette exécution de logiciel sécurisé. Ceci permet d'utiliser le procédé et le système décrit dans des téléphones cellulaires, des assistants numériques personnels, des terminaux de paiement bancaires ou portatifs afin d'y installer et de garantir le fonctionnement de fonctions de sécurité. REVENDICATIONS 1. Procédé de partage du temps d'exécution d'un processeur physique (1) entre au moins deux logiciels, ledit processeur comportant une pluralité de modes d'exécution et accédant à une pluralité de ressources (3, 4, 5, 6, 7, 8, 9), chacun desdits modes d'exécution garantissant des droits d'accès spécifiques auxdites ressources, et, parmi la pluralité des modes d'exécution, au moins un mode d'exécution particulier, dit mode sécurisé, ayant un accès exclusif sur certaines ressources (3, 8, 9), caractérisé en ce que, au moins un logiciel, dit de sécurité, étant exécuté exclusivement dans un des modes d'exécution sécurisés, et au moins un logiciel, dit non sûr, étant exécuté dans au moins un mode d'exécution autre que les modes d'exécution sécurisés, le procédé comprend les étapes suivantes, exécutées en mode sécurisé : a) définition d'un cycle périodique d'exécution des logiciels par le processeur, b) découpage de ce cycle en deux parties, l'une pour l'exécution du logiciel de sécurité, et l'autre pour l'exécution du logiciel non sûr. 2. Procédé de partage du temps d'exécution d'un processeur selon la 20 revendication 1, caractérisé en ce que le cycle est découpé en un nombre entier prédéfini d'intervalles de temps dont une première fraction est affectée au logiciel de sécurité et dont le reliquat est affecté au logiciel non sûr. 3. Procédé de partage du temps d'exécution d'un processeur selon la revendication 2, caractérisé en ce qu'il comprend en outre les étapes de: a) configuration d'une interruption pour qu'elle se déclenche au début de chaque intervalle prédéfini du cycle, b) calcul du temps d'exécution, sous forme de nombre d'intervalles, du logiciel de sécurité pendant le cycle, c) si le nombre d'intervalle ainsi calculé est inférieur à la première fraction prédéfinie alors exécution du logiciel de sécurité sinon exécution du logiciel non sûr. 4. Procédé de partage du temps d'exécution d'un processeur selon la revendication 3, caractérisé en ce que le temps d'exécution du logiciel pendant le cycle s'exprime sous la forme du modulo du numéro d'ordre de l'interruption par le nombre d'intervalles du cycle. 5. Procédé de partage du temps d'exécution d'un processeur selon l'une des revendications 3 ou 4, caractérisé en ce que l'interruption est déclenchée par une horloge accessible uniquement en mode sécurisé. 6. Procédé de partage du temps d'exécution d'un processeur selon la revendication 1, caractérisé en ce qu'on configure une interruption pour qu'elle se déclenche à la fin de chaque partie du cycle afin de transférer le temps d'exécution du logiciel en cours d'exécution vers l'autre logiciel. 7. Procédé de partage du temps d'exécution d'un processeur selon la revendication 6, caractérisé en ce que le déclenchement est provoqué par une horloge de surveillance, accessible uniquement en mode sécurisé. 8. Procédé de partage du temps d'exécution d'un processeur selon l'une quelconque des revendications 3 à 7, caractérisé en ce que l'interruption est 15 exécutée dans le mode sécurisé. 9. Procédé de partage du temps d'exécution d'un processeur selon l'une quelconque des revendications précédentes, caractérisé en ce que l'un au moins des logiciels non sûrs est un système d'exploitation multi-tâches utilisant une interruption temporelle régulière de changement de tâches. 10. Procédé de partage du temps d'exécution d'un processeur selon la revendication 9, caractérisé en ce que le système d'exploitation multitâches ne configurant pas d'horloge pour déclencher son interruption temporelle régulière, on utilise l'interruption de transfert d'un logiciel vers l'autre pour exécuter la fonction d'interruption liée à l'interruption temporelle régulière de changement de tâches. 11. Procédé de partage du temps d'exécution d'un processeur selon la revendication 9, caractérisé en ce que le système d'exploitation multitâches configurant sa propre horloge pour déclencher son interruption temporelle régulière, ledit procédé comporte en outre les étapes de détection des interruptions du système d'exploitation multi-tâches puis de temporisation de l'exécution du logiciel de sécurité de façon à ce que celui-ci s'exécute en dehors des interruptions temporelles régulières du système d'exploitation multi-tâches. 12. Procédé de partage du temps d'exécution d'un processeur selon l'une quelconque des revendications précédentes, caractérisé en ce que le logiciel de sécurité comporte une machine virtuelle. 13. Procédé de partage du temps d'exécution d'un processeur selon la revendication 12, caractérisé en ce que le logiciel de sécurité comporte un environnement programmatique interprété destiné à l'exécution de programmes sécurisés ou bancaires tel qu'un environnement STIP. 14. Système de partage du temps d'exécution d'un processeur physique entre au moins deux logiciels, ledit processeur comportant une pluralité de modes d'exécution et accédant à une pluralité de ressources, chacun desdits modes d'exécution garantissant des droits d'accès spécifiques auxdites ressources, et parmi la pluralité des modes d'exécution, au moins un mode d'exécution particulier, dit mode sécurisé, ayant un accès exclusif sur certaines ressources, caractérisé en ce que, au moins un logiciel, dit de sécurité, étant exécuté exclusivement dans un des modes d'exécution sécurisés, et au moins un logiciel, dit non sûr, étant exécuté dans au moins un des modes d'exécution autre que le mode d'exécution sécurisés, le système comporte: - une horloge apte à déclencher un événement de façon régulière, celle-ci n'étant accessible qu'en mode sécurisé, - un moyen de changement de contexte, appelé moniteur, fonctionnant en mode sécurisé, permettant de transférer l'exécution du premier logiciel vers le second et réciproquement, ce moyen de changement de contexte étant actionné par l'évènement déclenché par l'horloge, et ledit moyen de changement de contexte comportant au moins un compteur de temps total périodique et un compteur de temps d'exécution du logiciel de sécurité sur chaque période et des moyens de comparaison de ces compteurs avec une valeur prédéterminée tels que si le temps d'exécution du logiciel de sécurité sur la période est inférieure à la valeur prédéterminée alors le moyen de changement de contexte bascule le contexte vers l'exécution du logiciel de sécurité. 15. Système de partage du temps d'exécution d'un processeur physique entre au moins deux logiciels suivant la revendication 14, caractérisé en ce que le logiciel de sécurité comporte une machine virtuelle. 16. Système de partage du temps d'exécution d'un processeur physique entre au moins deux logiciels suivant la revendication 15, caractérisé en ce que le logiciel de sécurité comporte un environnement programmatique interprété destiné à l'exécution de programmes sécurisés ou bancaires tel qu'un environnement STIP. 17. Système de partage du temps d'exécution d'un processeur physique entre au moins deux logiciels suivant l'une des revendications 14, 15 ou 16, caractérisé en ce que le logiciel de sécurité comporte des moyens de protection de l'intégrité des logiciels, ou de protection d'identifiants, ou de protection d'accès à un réseau de données, ou de service cryptographique, ou de gestion de données confidentielles, ou de signature électronique, ou de gestion des droits d'auteurs, ou d'administration à distance d'un dispositif de paiement. 18. Utilisation du procédé selon l'une quelconque des revendications 1 à 13, ou de système selon l'une quelconque des revendications 14 ou 17, dans un téléphone cellulaire, un assistant numérique personnel, un terminal de paiement bancaire ou un terminal de paiement portatif.