FR 2880441 A1 20060707 FR 0414119 A 20041231 La présente invention concerne un procédé de chargement et d'exécution de logiciels, dénommés unités de chargement, ayant des niveaux de confiance différents par une unité de traitement informatique. Elle concerne également une unité de traitement informatique susceptible de charger et d'exécuter des logiciels ayant des niveaux de confiance différents sous forme d'unités de chargement, ladite unité de traitement informatique comportant, outre une unité centrale de traitement, un noyau sécurisé contenu dans la couche la plus basse du système d'exploitation et une zone physique sécurisée dans la partie la plus sûre de l'architecture matérielle de cette unité de traitement informatique. II est connu que la sécurité d'un système dépend d'une chaîne de mesures et qu'elle est aussi faible que le maillon le plus faible de cette chaîne. Pour un système informatique comportant une pluralité de logiciels, la sécurité du système dépend donc de la sécurité apportée ou non par chaque logiciel. Le tout premier élément de sécurité à prendre en compte dans un tel système est l'intégrité des logiciels destinés à s'exécuter sur ce système. Un logiciel est dit intègre quand il n'a pas été modifié par des éléments extérieurs, tels que, par exemple, un virus de façon à provoquer un fonctionnement différent de son fonctionnement normal tel que prévu par son concepteur. Pour assurer cette intégrité au niveau des systèmes d'exploitation, des solutions basées sur l'authentification de l'application au moment de son chargement ont été proposées. Ces solutions doivent s'accompagner d'un processus de validation et de certification de l'application avant son téléchargement. Par ailleurs, on connaît des systèmes de sécurité qui unifient les problématiques de spécification et d'interprétation des politiques de sécurité, de contrôle d'accès et d'autorisation. Ces systèmes sont connus de l'homme du 30 métier sous le nom de Système de Gestion de la Confiance . Un tel système est constitué d'un langage de description des opérations qui doivent être contrôlées par le système, d'un mécanisme d'identification des entités autorisées à effectuer ces opérations, d'un langage spécifiant les politiques des applications gouvernant les opérations que les 2880441 2 entités sont autorisées à effectuer, d'un langage pour les certificats d'autorisation permettant la délégation d'une opération d'une entité vers une autre entité, et enfin d'un interpréteur permettant de valider les requêtes d'opérations émises par les entités, à partir d'une politique donnée et d'un ensemble de certificats d'autorisation. Ces Systèmes de Gestion de la Confiance sont utilisés principalement dans les environnements distribués pour uniformiser les langages des politiques de sécurité et d'autorisation et pour décentraliser ces politiques. Grâce à ces systèmes, la politique de sécurité d'une application donnée n'est plus statique mais dynamique par l'utilisation et la modification des certificats d'autorisation. Cependant ces Systèmes de Gestion de la Confiance manquent de souplesse en ne répondant pas à des besoins importants des systèmes informatiques ouverts actuels. Ainsi, il n'est pas possible de mettre en oeuvre et d'assurer la cohérence des politiques de sécurité provenant des applications elles- mêmes, politiques de sécurité dites discrétionnaires , avec le même niveau de confiance que pour les politiques de sécurité fixées par le système d'exploitation, politiques de sécurité dites mandataires . Le but de l'invention est donc de remédier à cet inconvénient en proposant un procédé et un système capables de télécharger et d'exécuter des applications logicielles en assurant une politique de sécurité dynamique dans le temps et cohérente aussi bien pour Ile système informatique que pour les applications téléchargées. L'objet de l'invention est un procédé de chargement, d'installation et d'exécution de logiciels, dénommés unités de chargement, ayant des niveaux de confiance différents par une unité de traitement informatique, caractérisé en ce qu'il consiste au moins à associer à chaque unité de chargement au moins une structure de données d'information des besoins et caractéristiques de sécurité de cette unité de chargement et associer à ladite unité de traitement informatique une structure de données dynamique représentative de l'état de sécurité courant de l'unité de traitement informatique et valider les besoins et caractéristiques de sécurité de chaque unité de chargement vis-à-vis de l'état courant de l'unité de traitement informatique contenu dans ladite structure de données dynamique par 2880441 3 l'intermédiaire d'un module de sécurité autonome et si la validation est positive, autoriser par le module de sécurité le chargement, l'installation ou l'exécution de l'unité de chargement. D'autres caractéristiques sont:: - chaque unité de chargement est associée à - une structure de données d'information d'identification de cette unité de chargement; - une structure de données de contrainte d'installation; et - une structure de données constitutive d'un ensemble de règles de politique de sécurité, - ladite structure de données d'information d'identification de cette unité de chargement est formée par une liste d'attributs caractérisant cette unité de chargement comportant au moins une référence codée parmi la liste des références codées d'identité, de site d'origine, de certificat d'authentification, d'information d'intégrité, de type de fonctionnalité assurée, de niveau de sécurité, d'organisation responsable, - la structure de données de contrainte d'installation est formée par une liste d'attributs définissant les conditions d'installation de ladite unité de chargement, ladite liste d'attributs comportant au moins l'expression explicite des contraintes nécessaires à l'installation, - ladite structure de données constitutive d'un ensemble de règles de politique de sécurité comporte au moins:: - une référence d'accès à une ou plusieurs autres ressources; - une référence à une ou 1plusieurs unités de chargement, ladite structure de données, constitutive d'un ensemble de règles politiques de sécurité étant accessible en lecture tant au cours d'une étape de chargement qu'au cours d'une étape d'exécution, - ladite structure de données dynamique représentative de l'état courant de l'unité de traitement informatique comporte au moins des données représentatives d'informations absolues, telles qu'un niveau de confiance minimum, et des données représentatives d'informations relatives, telles que le niveau de sécurité courant lié à des applications natives ou non authentifiées, 2880441 4 - il consiste en outre à mettre à jour la structure de données dynamique par l'intermédiaire du module de sécurité après chaque changement de l'état interne de l'unité de traitement, - chaque unité de chargement est formée par un composant logiciel installable en mémoire, ledit composant logiciel installable désignant tout composant du système d'exploitation, autre que le noyau sécurisé, de l'unité de traitement informatique jusqu'à toute application exécutée par cette dernière. Un autre objet est une unité de traitement informatique susceptible de charger, d'installer et d'exécuter des logiciels, dénommés unités de chargement, ayant des niveaux de confiance différents, ladite unité de traitement informatique comportant, outre une unité centrale de traitement, un noyau sécurisé contenu dans la couche la plus basse du système d'exploitation et une zone physique sécurisée, partie la plus sûre de l'architecture matérielle de cette unité de traitement informatique, caractérisée en ce qu'elle comporte en outre un module de sécurité installé dans ladite zone physique sécurisée, ledit module de sécurité exécutant de manière autonome les fonctions: - d'installation de nouvelles unités de chargement, - de contrôle et mise en oeuvre des règles de politique de sécurité telles que attribution et contrôle des droits d'accès en fonction du niveau de 20 confiance de chaque unité de chargement, - de maintien de l'état courant et de l'intégrité du système en fonction des composants du système d'exploitation et des unités de chargement, et - de vérification des contraintes définies par une structure de données de contraintes d'installation, associée à chaque unité de chargement. D'autres caractéristiques de cet objet sont: - ledit module de sécurité, suite à l'installation de ce module, assure le contrôle autonome au moins des étapes: - de changement d'état interne du système; - de demande d'accès aux ressources du système; - de demande d'installation de chaque unité de chargement sur le système, - outre des informations absolues et des informations relatives, ledit module de sécurité gère tout nouvel événement répertorié dans une structure de données dynamique représentative de l'état courant de l'unité de système 2880441 5 d'exécution, ledit module de sécurité assurant la gestion et la mise à jour d'une variable de niveau de confiance courant du système en fonction d'événements survenus tels que détection d'une attaque, modification de l'état de confiance après installation ou désinstallation d'une unité de chargement, - sur requête d'installation d'une unité de chargement, ledit module de sécurité effectue une vérification des conditions sur l'identité de l'unité de chargement, à partir d'une structure de données d'information d'identification de cette unité de chargement, les opérations de vérification comportant au moins: - la vérification, à partir de son identifiant, que le site d'origine ].0 hébergeant ladite unité de chargement figure parmi les sites autorisés; -la vérification du certificat d'authentification de l'identité de l'unité de chargement; - la vérification de l'intégrité de l'unité de chargement; - la vérification, en référence à un niveau de confiance minimum, que le niveau de confiance associé à l'unité de chargement n'interdit pas l'installation de l'unité de chargement; - la vérification, en référence à une liste de fonctionnalités proscrites, que la fonctionnalité de l'unité de chargement n'appartient pas à cette liste et n'interdit pas l'installation de cette unité de chargement; - la vérification, à partir de son identifiant de site d'origine hébergeant ladite unité de chargement, que l'identité du distributeur de l'unité de chargement n'interdit pas l'installation de l'unité de chargement, - sur requête d'installation d'une unité de chargement et en présence d'une liste de contraintes d'installation non vide, ledit module de sécurité effectue en outre: - un appel au point d'entrée de l'unité de chargement pour faire exécuter une pluralité de vérifications spécifiques à l'unité de chargement, telles que vérification d'intégrité de données ou de parties du code de l'unité de chargement, initialisation de données spécifiques de l'unité de chargement; - une vérification de la présence de composants dans le système ou dans l'unité de chargement correspondant à des attributs positifs et de l'absence de composants ou unité de chargement correspondant à des attributs négatifs, - la vérification en présence d'une liste de contraintes d'installation non vide comprend la vérification directe des contraintes d'installation à partir d'une 2880441 6 ou plusieurs listes de contraintes attachées à différentes unités de chargement et/ou la vérification indirecte à partir d'une délégation d'autorisation des règles de contraintes d'installation obtenues par résolution, - sur requête d'installation d'une unité de chargement et en présence d'une structure de données constitutive d'un ensemble de règles de politique de sécurité non vide, ledit module de sécurité effectue une vérification de l'acceptabilité des demandes de l'unité de chargement, lesdites demandes pouvant comporter des demandes d'accès à des ressources du système et la liste des unités de chargement susceptibles d'appeler au moins l'un des points d'entrée correspondants, lorsque la vérification des contraintes d'installation est exécutée par la vérification indirecte à partir d'une délégation d'autorisation de traduction, ledit module de sécurité effectue la résolution des règles relatives à l'unité de chargement soumise à condition, et à vérification indirecte, pour déterminer l'acceptabilité des demande de ladite unité de chargement soumise à condition, - suite à la vérification à la valeur vraie de l'ensemble des vérifications précédentes, ledit module de sécurité autorise l'installation de ladite unité de chargement, sous l'autorité de l'unité centrale de traitement de ladite unité de traitement informatique, sinon, suite à l'absence de vérification à la valeur vraie de l'une des vérifications précédentes, ledit module de sécurité inhibe l'installation de ladite unité de chargement, le refus d'installation pouvant faire l'objet d'une signalisation au niveau de l'interface homme-machine associée à ladite unité de traitement, et - le module de sécurité est installé dans ladite zone physique sécurisée par l'intermédiaire du noyau sécurisé dudit système d'exploitation, ledit module de sécurité installé étant vérifié du point de vue de son intégrité par un mécanisme de vérification d'intégrité durant la séquence de démarrage de ladite unité de traitement. L'invention sera mieux comprise à la lecture de la description qui va 30 suivre, donnée uniquement à titre d'exemple et faite en se référant aux dessins annexés, dans lesquels: - la figure 1 est un schéma synoptique d'un système de traitement informatique selon un mode de réalisation de l'invention représenté dans sa structure en couche; 2880441 7 - la figure 2 est un ordinogramme des flux de gestion de la sécurité ; et - la figure 3 est un ordinogramme du chargement et de l'installation d'un logiciel. En référence à la figure 1, une unité 1 de traitement informatique est destinée à exécuter différents logiciels 2, 3 ayant des besoins de sécurité différents. Cette unité 1 est, par exemple, une station de travail ou un terminal de paiement ou encore un téléphone mobile Les logiciels exécutables sur cette unité 1 sont chargés à demeure tel le logiciel 2 ou bien sont téléchargeables par l'intermédiaire d'un moyen 4 de communication de données tel le logiciel 3. L'unité 1 comporte, dans son architecture matérielle, une unité centrale 5 de traitement chargée de l'exécution des instructions des logiciels et une zone physique sécurisée 6 de stockage. Cette zone sécurisée 6 est au minimum une zone de stockage ayant des conditions d'accès restreint et contrôlé. Afin de renforcer la sécurité de la zone 6, des mécanismes matériels de contrôle d'accès bien connus de l'homme du métier peuvent de plus être implémentés. Elle est la partie la plus sûre de l'architecture matérielle Pour assurer le fonctionnement de l'unité 1, un système d'exploitation 7 est installé pour piloter les ressources matérielles de l'unité 1. Ce système d'exploitation 7 comporte, en particulier, dans sa couche la plus basse, un noyau sécurisé 8. Celui-ci est chargé d'assurer la sécurité de l'unité de traitement 1 et en particulier d'assurer le respect des conditions d'accès de la zone sécurisée 6. Dans un mode de fonctionnement normal de l'unité 1, le noyau sécurisé 8 s'exécute dès le début du lancement du système d'exploitation afin d'éviter toute interférence dangereuse pour la sécurité du système pendant cette phase de démarrage. Un module de sécurité 9 est installé dans la zone sécurisée 6. Ce module de sécurité 9, une fois installé, est en charge de la sécurité de l'unité 1 et en particulier d'assurer Iles vérifications de sécurité nécessaires avant l'installation d'un nouveau composant et de vérifier le respect des règles de la politique de sécurité de l'unité 1. 2880441 8 Ce module de sécurité 9 comporte une structure de données 10 appelée Etat Courant du Système , ou ECS, destinée à recevoir des informations relatives à l'état sécuritaire de l'unité 1. L'Etat Courant du Système 10 correspond à l'état de sécurité interne de l'unité 1 tel que maintenu par le module de sécurité 9. Il inclut des informations absolues comme, par exemple, un niveau de confiance minimum et des informations relatives au niveau de sécurité courant comme, par exemple, la présence de logiciels natifs ou non authentifiés installés dans l'unité 1. Cette structure de données ECS 10 est donc dynamique en ce qu'elle évolue dans le temps avec l'évolution de l'état de la sécurité de l'unité 1 de traitement. Les logiciels 2 et 3 ainsi que les composants du système d'exploitation 7 autres que le noyau sécurisé 8 sont appelés dans la suite de cette description, et de façon indifférenciée, des Unités de Chargement . Ce sont donc des composants logiciels installés ou installables dans la mémoire de l'unité 1 de traitement. Dans la suite de ce texte, on appelle installation, l'ensemble des trois phases suivantes, seules ou en combinaison: - le (télé)chargement qui consiste à transférer l'Unité de Chargement sur l'unité 1 de traitement, l'installation proprement dite qui consiste à mettre l'unité 1 de traitement et l'Unité de Chargement en condition pour que cette dernière puisse s'exécuter, - l'exécution de l'Unité de Chargement sur l'unité 1 de traitement. Chaque Unité de Chargement 2, 3, 7 est associée à trois structures de données qui définissent les informations de sécurité de cette Unité de Chargement en terme de besoins et de caractéristiques. Ainsi chaque Unité de Chargement 2, 3, 7 est associée à une structure de données 11 appelée Informations d'Identification de l'Unité , ou IIU, et qui contient une liste d'attributs caractérisant cette Unité de Chargement 2, 3, 7. Par exemple, cette structure de données IIU 11 contient, sous forme de référence codée, l'identité, le site d'origine, le certificat d'authentification, une information d'intégrité, le type de fonctionnalités assurées, le niveau de sécurité, l'organisation responsable, ou toute autre information pertinente pour caractériser l'Unité de Chargement 2, 3, 7. 2880441 9 Chaque Unité de Chargement 2, 3, 7 est également associée à une deuxième structure de données 12 appelée Liste des Contraintes d'Installation , ou LCI; Cette structure de données LCI 12 définit l'expression non ambiguë des contraintes nécessaires au chargement, à l'installation proprement dite et à l'exécution de l'Unité de Chargement. Autrement dit, le changement, l'installation ou l'exécution de l'Unité de Chargement n'est effectué que si chaque contrainte est validée par le module de sécurité 9. Ces contraintes peuvent être exprimées au moyen d'un langage d'expression dédié ou prendre, plus simplement, la forme d'une liste d'attributs associés à un signe négatif ou positif. Par exemple, une Unité de Chargement associée à la LCI 12 [+ nom VM; - type natif; + niveau TOP] ne peut être installée que s'il existe sur l'unité 1 un composant de nom VM, que s'il n'existe pas, par ailleurs, de composants natifs et que le niveau de sécurité courant de l'unité 1 est TOP. Lorsque les conditions de la LCI 12 sont remplies, le module de sécurité 9 autorise le chargement, l'installation ou l'exécution de l'Unité de Chargement. Cependant ces contraintes doivent être respectées même lors de chargement ultérieur de nouveaux composants, c'est-à-dire pendant toute la période pendant laquelle l'Unité de Chargement est installée sur l'unité 1. La structure de données LCI 12 peut également, mais de façon optionnelle, comporter un point d'entrée correspondant à un traitement qui doit être effectué par l'Unité de Chargement elle-même au moment de son installation proprement dite. Enfin, chaque Unité de Chargement 2, 3, 7 est également associée à une troisième structure de données 13 appelée Règles de Politique de Sécurité , ou RPS. Cette structure de données RPS 13 définit les demandes d'une Unité de Chargement, telles que les accès souhaités à certaines ressources ou à d'autres Unités de Chargement. Cette structure de données RPS 13 est utilisée au moment du chargement et de l'installation proprement dite pour détecter des demandes d'accès impossibles à satisfaire, ainsi qu'au moment de l'exécution en faisant intervenir le module de sécurité 9 dans les échanges entre Unités de Chargement. 2880441 10 Les structures de données IIU 11, LCI 12 et RPS 13 se présentent sous la forme de fichiers contenant des règles et des informations de sécurité saisies par un administrateur de sécurité de l'unité 1 et/ou des tiers de confiance. Le fonctionnement de l'unité 1 va maintenant être décrit en référence à la figure 2. Lors de l'installation proprement dite de l'unité 1, le module de sécurité 9 est installé en 20 dans la zone sécurisée 6 par le noyau sécurisé 8. De plus, le noyau sécurisé 8 vérifie l'intégrité du module de sécurité 9. Ce processus d'installation sécurisée est bien connu de l'homme du métier en ce qu'il est basé sur des processus d'installation hiérarchisés et/ou chaînés dans lesquels chaque niveau n'est installé qu'après vérification du niveau immédiatement inférieur. A partir de cette installation, le module de sécurité 9 est considéré comme le composant logiciel de confiance dans l'unité 1 et qui met en oeuvre la sécurisation de celle-ci. Ainsi il valide les besoins et caractéristiques de sécurité de chaque Unité de Chargement 2, 3, 7 avant d'autoriser leur chargement, installation ou exécution. Puis, à chaque changement d'état interne de l'unité 1, le module de sécurité 9 actualise en 21 de manière sûre la structure de données Etat Courant du Système 10. Un changement d'état peut, en particulier, correspondre à un événement affectant le niveau de confiance courant de l'unité 1. Par exemple, la détection d'une attaque dégrade le niveau de confiance. De même, l'installation proprement dite d'une nouvelle Unité de Chargement 2, 3, 7 déclenche un nouveau calcul par le module de sécurité 9 du niveau de confiance, ce calcul pouvant être, par exemple, le minimum des niveaux de confiance associés aux Unités de Chargement 2, 3, 7 installées. Le module de sécurité 9 réceptionne et valide également en 22 les demandes d'accès aux ressources sensibles de l'unité 1. Il vérifie en particulier que chaque demande effectuée par une Unité de Chargement est valide au vu des règles énoncées dans la structure de données RPS 13 correspondant à cette Unité de Chargement. Dans le cas d'un refus de la demande, celui-ci peut être silencieux ou bien signalé à l'utilisateur de l'unité 1 par tout moyen approprié. 2880441 11 Le module de sécurité 9 est également appelé en 23 à chaque demande d'installation d'une nouvelle Unité de Chargement. Lors d'une installation, le module de sécurité 9 effectue des opérations de vérification et de validation, figure 3. II vérifie en 30 que les conditions sur l'identité de l'Unité de Chargement contenues dans la structure de données IIU 11 sont remplies. A titre d'exemple, et selon les informations contenues dans 1'11U 1 1, le module de sécurité 9 vérifie: - que le site d'origine figure parmi les sites autorisés, - que le certificat d'authentification de l'Unité de Chargement est valide, - que l'Unité de Chargement est intègre, - que son niveau de confiance est compatible avec le niveau de confiance général de l'unité 1 et/ou avec les niveaux de confiance minimaux des Unités de Chargement déjà installées, - que l'Unité de Chargement ne nécessite pas de fonctionnalités interdites, - que l'entité responsable de l'Unité de Chargement ne figure pas en une liste d'entités interdites, - ... Puis, le module de sécurité 9 vérifie en 31 que les conditions définies dans la structure de données Liste des Contraintes d'Installation 12 sont remplies par l'état courant de l'unité 1 contenue dans la structure de données ECS 10. Cette vérification n'est, bien;sûr, effectuée que si cette structure de données est non vide. Si la structure de données LCI 12 contient un point d'entrée, étape 32, alors celui-ci est appelé en 33 pour permettre l'exécution des vérifications programmées par le développeur de l'Unité de Chargement. Un cas particulier de vérification des contraintes contenues dans la structure de données LCI 12 concerne des Unités de Chargement dites conditionnelles. Ce sont des Unités de Chargement dont les règles d'installation dépendent de règles appartenant à d'autres Unités de Chargement. Par exemple, une contrainte concernant une telle Unité de Chargement A pourrait être 2880441 1 2 l'installation de l'Unité de Chargement A n'est autorisée que si l'Unité de Chargement B est installée et que celle-ci autorise l'installation de l'Unité A . Ces contraintes conditionnelles sont résolues par le module de sécurité 9 qui analyse donc si ces conditions sont remplies. Puis le module de sécurité 9 vérifie en 34 l'acceptabilité des demandes de l'Unité de Chargement contenues dans sa structure de données Règles de Politique de Sécurité 13. Dans le cas particulier où cette structure est vide, c'est-à-dire ne contient pas de demandes, cette étape 34 n'est pas mise en oeuvre. En particulier, il vérifie que les demandes d'accès aux ressources ou à d'autres Unités de Chargement peuvent être satisfaites. Dans le cas de demandes conditionnelles liées à une délégation d'autorisation d'une ou plusieurs structures de données RPS 13 appartenant à d'autres Unités de Chargement, le module de sécurité 9 résout ces conditions pour déterminer l'acceptabilité de ces demandes. Si toutes les vérifications précédentes se sont révélées positives, étape 35, alors le module de sécurité 9 accepte en 36 le chargement, l'installation et/ou l'exécution de l'Unité de Chargement. Sinon, ce chargement et/ou cette installation et/ou cette exécution sont 20 refusés par le module de sécurité 9. Ce refus peut être signalé au demandeur par tout moyen. On a ainsi décrit un procédé de chargement, d'installation et d'exécution de logiciels, dénommés unités de chargement, ayant des niveaux de confiance différents par une unité 1 de traitement informatique, et qui consiste au moins à : - associer à chaque unité de chargement 2, 3, 7 une structure de données 11 d'information d'identification de cette unité de chargement; - une structure de données 12 de contrainte d'installation; et 30 - une structure de données 13 constitutive d'un ensemble de règles de politique de sécurité ; et - associer à ladite unité 1 de traitement informatique une structure de données 10 dynamique représentative de l'état de sécurité courant de l'unité de traitement informatique; 2880441 13 - appliquer les contraintes d'installation et les règles de politique de sécurité, contrôler et actualiser la structure de données 10 dynamique et établir un dialogue interactif entre chaque unité de chargement 2, 3, 7 et ladite structure de données 10 dynamique par l'intermédiaire d'un module de sécurité 9 autonome, après installation. Le procédé ainsi décrit permet avantageusement de télécharger et d'exécuter des applications logicielles en assurant une politique de sécurité dynamique dans le temps et cohérente aussi bien pour le système informatique que pour les applications téléchargées. En effet, toutes les demandes de chargement, ainsi que les communications entre composants, sont réalisées par le truchement du module de sécurité. Les politiques de sécurité discrétionnaires des Unités de Chargement sont donc traitées de manière aussi sûre que les politiques mandataires du système d'exploitation. De plus, les facteurs liés à l'état du système au moment de l'installation d'une Unité de Chargement sont pris en compte à travers les structures de données LCI et, de manière optionnelle, fournis à cette Unité de Chargement au moyen de la structure de données ECS. Ainsi, les facteurs liés à l'état du système tels que le niveau de sécurité courant, les autres applications présentes, ... sont pris en compte lors du chargement, de l'installation et de l'exécution de chaque Unité de Chargement. Un autre avantage de l'invention est de permettre à chaque application chargée, c'est-à-dire à chaque Unité de Chargement, d'être garantie que le système qui la reçoit, c'est-à-dire l'unité de traitement, est dans un état de sécurité adéquat par rapport à ses besoins. Par exemple, une application sensible manipulant des clés cryptographiques a besoin de connaître l'état de sécurité du système avant de télécharger ou d'utiliser ses clés cryptographiques. 2880441 14 REVENDICATIONS 1. Procédé de chargement, d'installation et d'exécution de logiciels, dénommés unités de chargement, ayant des niveaux de confiance différents par une unité (1) de traitement informatique, caractérisé en ce qu'il consiste au moins à: - associer à chaque unité de chargement (2, 3, 7) au moins une structure de données (11, 12, 13) d'information des besoins et caractéristiques de sécurité de cette unité de chargement; et - associer à ladite unité (1) de traitement informatique une structure de données (10) dynamique représentative de l'état de sécurité courant de l'unité (1) de traitement informatique; et - valider les besoins et caractéristiques de sécurité de chaque unité de chargement (2, 3, 7) vis- à-vis de l'état courant de l'unité (1) de traitement informatique contenu dans ladite structure de données (10) dynamique par l'intermédiaire d'un module de sécurité (9) autonome; et - si la validation est positive, autoriser par le module de sécurité (9) le chargement, l'installation ou l'exécution cle l'unité de chargement (2, 3, 7). 2. Procédé selon la revendication 1, caractérisé en ce que chaque unité de chargement (2, 3, 7) est associée à - une structure de données (11) d'information d'identification de cette unité de chargement; - une structure de données (12) de contrainte d'installation; et - une structure de données (13) constitutive d'un ensemble de règles de politique de sécurité. 3. Procédé selon la revendication 2, caractérisé en ce que ladite structure de données (11) d'information d'identification de cette unité de chargement est formée par une liste d'attributs caractérisant cette unité de chargement comportant au moins une référence codée parmi la liste des références codées d'identité, de site d'origine, de certificat d'authentification, d'information d'intégrité, de type de fonctionnalité assurée, de niveau de sécurité, d'organisation responsable. 4. Procédé selon l'une des revendication 2 à 3, caractérisé en ce que la structure de données (12) de contrainte d'installation est formée par une liste d'attributs définissant les conditions d'installation de ladite unité de chargement, 2880441 15 ladite liste d'attributs comportant au moins l'expression explicite des contraintes nécessaires à l'installation. 5. Procédé selon l'une des revendications 2 à 4, caractérisé en ce que ladite structure de données (13) constitutive d'un ensemble de règles de politique 5 de sécurité comporte au moins: - une référence d'accès à une ou plusieurs autres ressources; - une référence à une ou plusieurs unités de chargement, ladite structure de données, constitutive d'un ensemble de règles politiques de sécurité étant accessible en lecture tant au cours d'une étape de chargement qu'au cours d'une étape d'exécution. 6. Procédé selon l'une des revendications 1 à 5, caractérisé en ce que ladite structure de données (10) dynamique représentative de l'état courant de l'unité de traitement informatique (1) comporte au moins des données représentatives d'informations absolues, telles qu'un niveau de confiance minimum, et des données représentatives d'informations relatives, telles que le niveau de sécurité courant lié à des applications natives ou non authentifiées. 7. Procédé selon l'une quelconque des revendications précédentes, caractérisé en qu'il consiste en outre à mettre à jour la structure de données dynamique (10) par l'intermédiaire du module de sécurité (9) après chaque changement de l'état interne de l'unité de traitement (1). 8. Procédé selon l'une quelconque des revendications précédentes, caractérisé en ce que chaque unité de chargement (2, 3, 7) est formée par un composant logiciel installable en mémoire, ledit composant logiciel installable désignant tout composant du système d'exploitation, autre que le noyau sécurisé, de l'unité de traitement informatique jusqu'à toute application exécutée par cette dernière. 9. Unité de traitement informatique (1) susceptible de charger, d'installer et d'exécuter des logiciels, dlénommés unités de chargement, ayant des niveaux de confiance différents, ladite unité de traitement informatique (1) comportant, outre une unité centrale (5) de traitement, un noyau sécurisé (8) contenu dans la couche la plus basse du système d'exploitation (7) et une zone physique sécurisée (6), partie la plus sûre de l'architecture matérielle de cette unité de traitement informatique, caractérisée en ce qu'elle comporte en outre un 2880441 16 module de sécurité (9) installé dans ladite zone physique sécurisée (6), ledit module de sécurité exécutant de manière autonome les fonctions: d'installation de nouvelles unités de chargement (2, 3, 7) ; - de contrôle et mise en oeuvre des règles de politique de sécurité 5 telles que attribution et contrôle des droits d'accès en fonction du niveau de confiance de chaque unité de chargement; - de maintien de l'état courant et de l'intégrité du système en fonction des composants du système d'exploitation et des unités de chargement; - de vérification des contraintes définies par une structure de données de contraintes d'installation, associée à chaque unité de chargement (2, 3, 7). 10. Unité de traitement informatique selon la revendication 9, caractérisée en ce que ledit module de sécurité (9), suite à l'installation de ce module, assure le contrôle autonome au moins des étapes: - de changement d'état interne du système; - de demande d'accès aux ressources du système; - de demande d'installation de chaque unité de chargement sur le système. 11. Unité de traitement informatique selon la revendication 10, caractérisée en ce que, outre des informations absolues et des informations relatives, ledit module de sécurité (9) gère tout nouvel événement répertorié dans une structure de données dynamique représentative de l'état courant de l'unité de système d'exécution, ledit module de sécurité (9) assurant la gestion et la mise à jour d'une variable de niveau de confiance courant du système en fonction d'événements survenus tels que détection d'une attaque, modification de l'état de confiance après installation ou désinstallation d'une unité de chargement. 12. Unité de traitement informatique selon la revendication 10 ou 11, caractérisée en ce que, sur requête d'installation d'une unité de chargement, ledit module de sécurité effectue une vérification des conditions sur l'identité de l'unité de chargement, à partir d'une structure de données d'information d'identification de cette unité de chargement, les opérations de vérification comportant au moins: - la vérification, à partir de son identifiant, que le site d'origine hébergeant ladite unité de chargement figure parmi les sites autorisés; 2880441 17 - la vérification du certificat d'authentification de l'identité de l'unité de chargement; - la vérification de l'intégrité de l'unité de chargement; - la vérification, en référence à un niveau de confiance minimum, que le niveau de confiance associé à l'unité de chargement n'interdit pas l'installation de l'unité de chargement; - la vérification, en référence à une liste de fonctionnalités proscrites, que la fonctionnalité de l'unité de chargement n'appartient pas à cette liste et n'interdit pas l'installation de cette unité de chargement; - la vérification, à partir de son identifiant de site d'origine hébergeant ladite unité de chargement, que l'identité du distributeur de l'unité de chargement n'interdit pas l'installation de l'unité de chargement. 13. Unité de traitement informatique selon l'une des revendications 10 à 12, caractérisée en ce que, sur requête d'installation d'une unité de chargement et en présence d'une liste de contraintes d'installation non vide, ledit module de sécurité effectue en outre: - un appel au point d'entrée de l'unité de chargement pour faire exécuter une pluralité de vérifications spécifiques à l'unité de chargement, telles que vérification d'intégrité de données ou de parties du code de l'unité de chargement, initialisation de données spécifiques de l'unité de chargement; - une vérification de la présence de composants dans le système ou dans l'unité de chargement correspondant à des attributs positifs et de l'absence de composants ou unité de chargement correspondant à des attributs négatifs. 14. Unité de traitement informatique selon la revendication 13, caractérisée en ce que la vérification en présence d'une liste de contraintes d'installation non vide comprend la vérification directe des contraintes d'installation à partir d'une ou plusieurs listes de contraintes attachées à différentes unités de chargement et/ou la vérification indirecte à partir d'une délégation d'autorisation des règles de contraintes d'installation obtenues par résolution. 15. Unité de traitement informatique selon l'une des revendications 10 à 14, caractérisée en ce que, sur requête d'installation d'une unité de chargement et en présence d'une structure de données constitutive d'un ensemble de règles de politique de sécurité non vide, ledit module de sécurité effectue une 2880441 18 vérification de l'acceptabilité des demandes de l'unité de chargement, lesdites demandes pouvant comporter des demandes d'accès à des ressources du système et la liste des unités de chargement susceptibles d'appeler au moins l'un des points d'entrée correspondants. 16. Unité de traitement informatique selon l'une des revendications 14 ou 15, caractérisée en ce que, lorsque la vérification des contraintes d'installation est exécutée par la vérification indirecte à partir d'une délégation d'autorisation de traduction, ledit module de sécurité effectue la résolution des règles relatives à l'unité de chargement soumise à condition, et à vérification indirecte, pour déterminer l'acceptabilité des demande de ladite unité de chargement soumise à condition. 17. Unité de traitement informatique selon l'une des revendications 9 à 16, caractérisée en ce que, suite à la vérification à la valeur vraie de l'ensemble des vérifications précédentes, ledit module de sécurité autorise l'installation de ladite unité de chargement, sous l'autorité de l'unité centrale de traitement de ladite unité de traitement informatique, sinon, suite à l'absence de vérification à la valeur vraie de l'une des vérifications précédentes, ledit module de sécurité inhibe l'installation de ladite unité de chargement, le refus d'installation pouvant faire l'objet d'une signalisation au niveau de l'interface homme-machine associée à ladite unité de traitement. 18. Unité de traitement informatique selon l'une quelconque des revendications 9 à 17, caractérisée en ce que le module de sécurité (9) est installé dans ladite zone physique sécurisée (6) par l'intermédiaire du noyau sécurisé dudit système d'exploitation, ledit module de sécurité (9) installé étant vérifié du point de vue de son intégrité par un mécanisme de vérification d'intégrité durant la séquence de démarrage de ladite unité de traitement.