FR 2895545 A1 20070629 FR 0513247 A 20051223 10 La présente invention concerne un procédé d'authentification d'applications d'un système informatique. On considère un système informatique dans lequel un certain nombre de services dits de confiance évoluent dans un environnement local sécurisé 15 ( Environnement de Confiance ). Ces services offrent des fonctionnalités qui peuvent être invoquées depuis l'extérieur de l'Environnement de Confiance. On souhaite donc pouvoir contrôler qui (quelle application) a le droit d'invoquer chaque fonctionnalité. 20 On peut, à titre d'exemple, prendre le cas d'un agent de gestion des droits numériques DRM ( Digital Rights Management ) s'exécutant dans l'Environnement de Confiance. Cet agent DRM gère l'autorisation de lecture de fichiers MP3 protégés par une licence DRM. Cette licence comporte, par exemple, un droit de lecture du fichier MP3 jusqu'à une date limite. L'agent 25 DRM est chargé de vérifier que les conditions de la licence sont respectées. Le fait d'évoluer dans un Environnement de Confiance l'aide à assurer sa mission : il dispose, par exemple, de garanties sur l'heure et la date du système local. Si les conditions sont respectées, l'agent DRM autorise la lecture du fichier MP3. Pour cela, il doit alors fournir à l'application standard "player 30 MP3" (qui s'exécute en zone dite standard, c'est-à-dire à l'extérieur de l'Environnement de Confiance) la clé de décodage du fichier MP3. De manière 1 évidente, l'agent DRM ne devrait pas fournir cette clé à une application "player MP3" inconnue (qui, par exemple, pourrait la poster sur Internet...). On voit bien dans cet exemple que le service sécurisé (agent DRM) doit authentifier l'application standard ("player MP3") qui invoque la fonctionnalité de lecture du fichier MP3. Par ailleurs, il est facile pour un service local d'authentifier une autre application locale dans des environnements fermés, que ce soit des systèmes d'exploitation fermés (c'est-à-dire dans lesquels toutes les applications sont installées initialement, sous le contrôle d'un administrateur, ou utilisateur habilité) ou des environnements d'exécution. En effet, s'il s'agit d'un système exploitation fermé, l'installation même de l'application représente une garantie de son authenticité puisque seules des personnes autorisées peuvent effectuer cette opération. S'il s'agit d'un environnement d'exécution (machine virtuelle), le problème n'est guère plus compliqué car le format de l'application est conçu pour fournir à la machine virtuelle les moyens de vérifier son authenticité ou son intégrité (par construction, une machine virtuelle manipule le code des applications qu'elle exécute). Le problème est autrement plus complexe dans le cas d'un système ouvert où de nouvelles applications peuvent être librement téléchargées et installées, et où il existe de nombreux outils pour développer, modifier, déboguer, tracer des applications. Pourtant, le besoin de trouver une solution est d'autant plus crucial que les systèmes ouverts sont de plus en plus utilisés y compris dans le domaine des systèmes informatiques embarqués (ou enfouis ) comme les téléphones portables, les lecteurs multimédia portatifs ou les PDA ( Personal Digital Assistant ). Certains systèmes ont en conséquence fait le choix d'intégrer des mécanismes de sécurité avancés au coeur du système d'exploitation. C'est par exemple le cas des capabilities que l'on trouve dans certains systèmes d'exploitation tels que "Linux", "SELinux" (marques déposées) en particulier, où le système d'exploitation intègre la notion d'autorisation (exemple d'autorisation : une application "player MP3" intègre est autorisée à utiliser les services d'un agent DRM ). Cette solution présente plusieurs inconvénients : • Elle est intrusive: tout le système d'exploitation ( Operating System ), doit être pensé et réécrit avec cette notion. Un système d'exploitation non prévu à cet effet doit donc subir de profondes modifications pour la mettre en oeuvre. • La configuration des autorisations est un casse-tête permanent pour l'administrateur système car il est nécessaire de faire de nombreuses exceptions au cas général ; de plus, les autorisations peuvent évoluer au cours du temps. • L'authentification de l'application est confiée au système d'exploitation, ce qui n'est pas son rôle. Le rôle d'un système d'exploitation est de gérer des tâches les unes par rapport aux autres, non pas d'effectuer des opérations de sécurité. On sait qu'il est de mauvaise pratique de confier les traitements sécuritaires à une entité généraliste. Il convient au contraire de les regrouper dans un module dédié et restreint. D'autres solutions, comme celle du modèle dit Trusted Computing , reposent sur la présence de matériel de sécurité particulier ( TPM ou "Trusted Platform Module") et d'un mécanisme d'attestation cryptographique. Dans ce cas, le TPM est chargé d'apporter à une entité extérieure des garanties sur l'authenticité du système local. Cependant, l'attestation cryptographique est conçue pour fournir des garanties sur un système global et non pas sur une application donnée (il n'existe pas de système utilisant un TPM pour authentifier une application locale) ; de plus, l'adjonction d'un matériel dédié n'est pas forcément réalisable dans toutes les situations (pour des raisons techniques et/ou commerciales). L'invention a donc plus particulièrement pour but de supprimer ces inconvénients grâce à un procédé permettant de fournir localement, sur un système d'exploitation ouvert, des garanties sur l'authenticité d'applications "standard" qui s'exécutent en dehors de l'Environnement de Confiance, à des services sécurisés évoluant dans l'Environnement de Confiance. Ce procédé permet l'authentification d'applications d'un système informatique comportant : une pluralité d'applications, - un système d'exploitation généraliste capable d'exécuter et de gérer lesdites applications, notamment d'associer à chaque identifiant d'application les informations nécessaires à son exécution, dites Informations d'Identification , - un Environnement de Confiance offrant des services auxdites applications. Selon l'invention, préalablement à tout accès aux services de l'Environnement de Confiance par une application, ce procédé comprend les phases opératoires suivantes : l'exécution d'une opération de "hashage" sur les Informations d'Identification de ladite application ; - la vérification par l'Environnement de Confiance de l'authenticité du résultat, dit Condensé, de ladite opération de "hashage". 25 Avantageusement, le procédé pourra comporter en outre un composant logiciel, dit Pilote , permettant l'accès à l'Environnement de Confiance à partir du système d'exploitation, et les opérations pourront alors être effectuées de la manière suivante : 30 - le Pilote fournit au système d'exploitation l'identifiant de l'application ; - le système d'exploitation fournit au Pilote les Informations d'Identification ; - le Pilote exécute l'opération de "hashage" sur les Informations d'Identification et transmet le Condensé à l'Environnement de Confiance. Avantageusement : Les susdites Informations d'Identification pourront comprendre le code exécutable de l'application ainsi, qu'éventuellement, certains noms de fichiers et certains fichiers utilisés par l'application. - La vérification de l'authenticité du Condensé par l'Environnement de Confiance peut être effectuée par recherche dans une liste de Condensés acceptables. Les opérations d'authentification pourront être effectuées au moment de la demande d'accès de l'application à un service de l'Environnement de 15 Confiance. - Les opérations d'authentification pourront être effectuées lors d'une phase préalable, dite de "login" (ou d'enregistrement) qui permet d'authentifier l'application préalablement à toute demande d'accès aux services de l'Environnement de Confiance. 20 Selon le résultat de la vérification du Condensé, l'Environnement de Confiance pourra accorder à l'application des droits d'accès différents à ses services. Les services offerts par l'Environnement de Confiance pourront comporter au moins l'accès à certaines ressources du système informatique. 25 Les ressources du système informatique contrôlées par l'Environnement de Confiance pourront comporter des moyens de chiffrement cryptographique. - Les ressources du système informatique contrôlées par l'Environnement de Confiance pourront comporter des droits d'utilisation de contenus (DRM). Avantageusement, l'Environnement de Confiance (EC) pourra s'exécuter dans un mode sécurisé du microprocesseur, qui apportera des garanties de sécurité accrues. L'invention concerne également un système d'authentification d'applications mettant en oeuvre le procédé précédemment défini et pouvant éventuellement s'exécuter sur un appareil portable tel qu'un téléphone portable, un lecteur audio ou vidéo, un assistant personnel PDA, etc. Un mode d'exécution de l'invention sera décrit ci-après, à titre d'exemple non limitatif, avec référence au dessin annexé dans lequel : La figure unique est une représentation schématique de l'architecture d'un système d'authentification selon l'invention. Dans cet exemple, le terminal 1 utilise : • un système d'exploitation ouvert OS2 (tel que, par exemple, "Linux", "Windows", "Solaris" ... (marques déposées)). Bien entendu, ce système d'exploitation OS2 doit être en mesure de gérer les applications que l'on souhaite authentifier. Les applications standard (non sécurisées) s'exécutent directement sur ce système d'exploitation. un Environnement de Confiance EC pour l'exécution des services de sécurité 4. Le passage du système d'exploitation OS2 à l' Environnement de Confiance EC est régi par un Pilote 5 ("driver"), c'est-à-dire un petit module (ou "plugin") qui s'exécute dans le noyau du système d'exploitation OS2. Ce Pilote est conçu de manière à intercepter les demandes d'accès par une application non sécurisée (s'exécutant sur le système d'exploitation OS2), à un service sécurisé 4 (s'exécutant dans 1' Environnement de Confiance EC). A la suite de l'interception d'une demande d'accès, le Pilote 5 envoie alors au système d'exploitation OS2 l'identifiant de l'application et lui demande le fichier qui correspond à son code exécutable. Habituellement, les systèmes d'exploitation maintiennent cette information au sein d'une structure de donnée dite "bloc de contrôle" (parfois appelée PCB "Process Control Block"). Le Pilote 5 exécute une opération de "hashage" (telle que, par exemple, SHA-1) sur le fichier fourni par le système d'exploitation OS2. Eventuellement, le système d'exploitation OS2 pourra en outre rechercher dans le répertoire du fichier, un fichier appelé "manifeste" qui contient le nom absolu de tous les fichiers importants que l'application utilise (par exemple un fichier de configuration, une librairie partagée, etc.) et fournir ces informations au Pilote 5. Le Pilote 5 exécutera alors l'opération de "hashage" à la fois sur l'exécutable au manifeste, et sur tous les fichiers référencés dans le manifeste (ou seulement certains d'entre eux). Dans tous les cas, le Condensé identifie de manière unique l'application non sécurisée (dans la mesure où la fonction de "hashage" permet d'éviter les collisions). Il est alors transmis à l'Environnement de Confiance qui vérifie son authenticité. A titre d'exemple, le Condensé pourra être comparé à une liste de Condensés acceptables. Si le Condensé est trouvé, l'accès aux services offerts par le service de sécurité 4 pourra être autorisé. Dans l'exemple précédemment décrit, le système d'exploitation OS2 n'intervient que pour identifier les fichiers correspondant à la demande d'accès à un service de l'Environnement de Confiance EC et pour rechercher les informations afférentes, ce qui est parfaitement du ressort d'un système d'exploitation, et non pas pour calculer le Condensé ou effectuer une vérification d'authenticité. Par ailleurs, l'Environnement de Confiance EC peut également ne pas reposer sur le système d'exploitation OS2 et être indépendant de lui, la figure unique ne représentant qu'un mode de mise en oeuvre possible. Sur le système d'exploitation "Linux" (marque déposée), le Pilote 5 peut obtenir la liste des fichiers relatifs à la demande de connexion conformément à la séquence opératoire suivante, en partant de la constatation que chaque processus est vu, au sein du noyau de "Linux" (marque déposée), comme une tâche ("struct task struct") : • A partir de la tâche correspondant au processus, on obtient les pages que cette tâche a mappées en mémoire ("get_task_mm(task)"). On obtient ainsi une "struct mm struct". • On parcourt chacune de ces pages à la recherche d'une page marquée exécutable (mm->mmap & VM_EXECUTABLE). On fait ici l'hypothèse (raisonnable) que cette page appartient à l'exécutable qui correspond au processus. • On récupère le fichier associé à cette page (mm->mmap->vm_file). Sous le 20 système d'exploitation Linux (marque déposée), il s'agit d'une "struct file". • On effectue un "hashage" du contenu du fichier ainsi trouvé. Si on implémente l'utilisation d'un manifeste, il est en outre nécessaire : 25 D'obtenir le chemin où se trouve ce fichier : il suffit de parcourir récursivement les"dentry" associés au fichier (vm_file->f dentry), - de localiser le manifeste dans ce répertoire, - de localiser chacun des fichiers référencés dans le manifeste, et de hacher tous les fichiers, y compris le manifeste. Revendications 1. Procédé d'authentification d'applications d'un système informatique comportant : un microprocesseur ; une pluralité d'applications ; un système d'exploitation généraliste (OS2) capable d'exécuter et de gérer lesdites applications, notamment d'associer à chaque identifiant d'application (3) les informations nécessaires à son exécution, dites Informations d'Identification ; un Environnement de Confiance (EC) offrant des services auxdites applications, caractérisé en ce que, préalablement à tout accès aux services de l'Environnement de Confiance par une application, il comprend les phases opératoires suivantes : -l'exécution d'une opération de "hashage" sur les Informations d'Identification de ladite application ; - la vérification par l'Environnement de Confiance de l'authenticité du résultat, dit Condensé, de l'opération de "hashage". 2. Procédé d'authentification d'applications d'un système informatique selon la revendication 1 comportant en outre un composant logiciel, dit Pilote (5), permettant l'accès à l'Environnement de Confiance (EC) à partir du système d'exploitation (OS2), et caractérisé en ce que : le Pilote (5) fournit au système d'exploitation (OS2) l'identifiant de l'application ; le système d'exploitation (OS2) fournit au Pilote (5) les Informations d'Identification ; - le Pilote (5) exécute l'opération de "hashage" sur les Informations d'Identification et transmet le Condensé à l'Environnement de Confiance ; 930-10- 3. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que les Informations d'Identification comprennent au moins le code exécutable de l'application. 4. Procédé selon la revendication 3, caractérisé en ce que les Informations d'Identification comprennent également certains noms de fichiers et certains fichiers utilisés par l'application. 5. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que la vérification de l'authenticité du Condensé par l'Environnement de Confiance (EC) est effectuée par recherche dans une liste de Condensés acceptables. 6. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que les vérifications d'authenticité sont effectuées au moment de la demande d'accès de l'application à un service de l'Environnement de Confiance (EC). 7. Procédé selon l'une des revendications 1 ou 2, caractérisé en ce que les vérifications d'authenticité sont effectuées lors d'une phase préalable, dite de login (ou d'enregistrement) qui permet d'authentifier l'application préalablement à toute demande d'accès à un service de l'Environnement de Confiance (EC). 8. Procédé selon l'une des revendications précédentes, caractérisé en ce que, selon le résultat de la vérification du Condensé, l'Environnement de Confiance (EC) accorde à l'application des droits d'accès différents à ses services.-11- 9. Procédé selon l'une des revendications précédentes, caractérisé en ce que les services offerts par l'Environnement de Confiance (EC) comportent au moins l'accès à certaines ressources du système informatique. 10. Procédé selon la revendication 9, caractérisé en ce que les ressources du système informatique dont l'accès est contrôlé par l'Environnement de Confiance (EC) comportent des moyens de chiffrement cryptographique. 11. Procédé selon la revendication 10, caractérisé en ce que les ressources du système informatique dont l'accès est contrôlé par l'Environnement de Confiance (EC) comportent des droits d'utilisation de contenus (DRM). 12. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'Environnement de Confiance (EC) s'exécute dans un mode sécurisé du microprocesseur. 20 13. Système d'authentification d'applications d'un système informatique comportant : une pluralité d'applications ; un système d'exploitation généraliste (OS2) capable d'exécuter et de gérer lesdites applications, notamment d'associer à chaque identifiant d'application (3) les informations nécessaires à son exécution; un Environnement de Confiance 25 (EC) offrant des services auxdites applications ; un composant logiciel, dit Pilote (5), permettant l'accès à l'Environnement de Confiance (EC) à partir du système d'exploitation (OS2), caractérisé en ce qu'il comprend : - des moyens pour la fourniture par le Pilote (5) au système d'exploitation 30 (OS2) de l'identifiant de l'application ; 10 15- 12 -des moyens pour la fourniture par le système d'exploitation au Pilote de certaines informations nécessaires à l'exécution de l'application, dites Informations d'Identification ; des moyens pour l'exécution par le Pilote (5) d'une opération de "hashage" sur les Informations d'Identification et pour la transmission du résultat, dit Condensé à l'Environnement de Confiance ; - des moyens pour la vérification de l'authenticité dudit Condensé par l'Environnement de Confiance. 14. Système d'authentification d'applications selon la revendication 13, caractérisé en ce qu'il s'exécute sur un appareil portable tel qu'un téléphone portable, ou un lecteur audio ou vidéo, ou un PDA.