FR 3158376 A1 20250718 FR 2400289 A 20240112 L’invention concerne un procédé de gestion d’accès à une application sécurisée d’un environnement sécurisé d’un système informatique comprenant les étapes suivantes : - sur réception (502) d’une première requête issue d’une application client identifiant l’application sécurisée d’un environnement non sécurisé, obtention (506) d’une information identifiant de manière unique l’application client ; - génération (530) d’un nombre aléatoire dans l’environnement sécurisé ; - détermination (531) d’un identifiant unique de l’application client en fonction du nombre aléatoire généré et de l’information identifiant de manière unique l’application client ; - stockage de l’identifiant unique de l’application client en tant que métadonnée de l’application client, dans l’environnement non sécurisé. Suite à cela, et sur une réception d’une deuxième requête pour établir une session courante, le procédé comprend la vérification de l’identifiant unique de l’application client préalablement à l’établissement de la session courante. FIG. 5 Gestion d’accès à une application sécurisée dans un système informatique La présente invention appartient au domaine des systèmes informatiques, et notamment des systèmes comprenant un environnement sécurisé apte à exécuter au moins une application sécurisée, séparé d’un environnement non sécurisé apte à exécuter au moins une application client. L’invention concerne en particulier la gestion des accès à des applications sécurisées d’un environnement sécurisé du système informatique. Il est connu de stocker des données sensibles dans des composants matériels sécurisés d’un système informatique. C’est le cas notamment de systèmes informatiques selon une architecture ARM TM , tel qu’un système sur une puce, aussi appelé SoC, pour « System on Chip ». Une SoC est un système intégrant, sur une seule puce, un microprocesseur, un processeur graphique GPU, pour « Graphical Processing Unit » en anglais, un processeur de signal numérique, DSP pour « Digital Signal Processing » en anglais, ainsi que d’autres composants. La SoC ARM, notamment celle basée sur un microprocesseur Cortex, prévoit de séparer un environnement sécurisé, appelé environnement d’exécution de confiance, ou TEE pour « Trusted Execution Environment », aussi appelé « monde sécurisé », soit « Secure World » en anglais, d’un environnement non sécurisé, appelé environnement non fiable, soit « Untrusted Environment », aussi appelé « monde normal », soit « Normal World » en anglais. L’environnement TEE a pour objet de protéger des données sensibles telles que des clés privées ou des informations personnelles, telles que des informations personnellement identifiables, ou PII, pour « Personally Identifiable Information » en anglais, en limitant leur accès par des applications clients de l’environnement non sécurisé. Le système d’exploitation de l’environnement TEE, appelé système d’exploitation sécurisé, héberge un ensemble d’applications sécurisées, notées TA, pour « Trusted Applications » en anglais, qui ont des fonctions variées, telles que la gestion du stockage sécurisé de donnés, le stockage de données sécurisées, le calcul de clés secrètes, la mise en œuvre d’opérations cryptographiques, etc. Les applications sécurisées rendent ces fonctions disponibles à des applications clients exécutées dans l’environnement non sécurisé, ou monde normal. L’environnement non sécurisé est exécuté sur un système d’exploitation distinct du système d’exploitation sécurisé de l’environnement TEE. Le système d’exploitation de l’environnement non sécurisé peut être appelé système d’exploitation « riche » ou « principal », soit « Rich Operation System » en anglais. Par exemple, dans le contexte d’un système informatique utilisé pour des applications automobiles, le système d’exploitation principal peut être Android Automotive OS TM , ou encore Automotive Grade Linux TM . La FIG. 1 illustre un système informatique 100 selon l’art antérieur. Le système informatique 100 est par exemple basé sur une architecture ARM de type ARM SoC 101. Un moniteur sécurisé 102 est apte à assurer un rôle d’interface entre un environnement non sécurisé 110 et un environnement sécurisé 120. L’environnement non sécurisé 110 est basé sur un système d’exploitation riche, ayant un noyau de système d’exploitation riche 111, apte à exécuter un ensemble d’applications clients, comprenant par exemple une première application client 112.1 et une deuxième application client 112.2. L’environnement sécurisé 120 est basé sur un système d’exploitation sécurisé, ayant un noyau sécurisé 121, apte à exécuter un ensemble d’applications sécurisées, comprenant par exemple une première application sécurisée 122.1 et une deuxième application sécurisée 122.2. Les applications clients 112.1 et 112.2 peuvent requérir des services mis en œuvre par les applications sécurisées 122.1 et 122.2, par l’intermédiaire du moniteur sécurisé 102. Toutefois, les applications clients 112.1 et 112.2 étant exécutées dans un environnement non sécurisé, il est important, voire critique, de pouvoir assurer que l’application client souhaitant accéder à un service d’une application sécurisée, est bien légitime, et n’est pas corrompue par un attaquant souhaitant accéder à des données auxquelles il n’a légitimement pas le droit d’accéder, les données étant stockées dans l’environnement sécurisé 120. En effet, en remplaçant une application client légitime par une application client corrompue, un attaquant peut accéder à des données stockées dans l’environnement sécurisé 120. Une telle attaque peut causer la fuite de données sensibles, telles que des PII ou l’utilisation frauduleuse de données cryptographiques, par exemple pour s’authentifier auprès d’un serveur tiers. A titre d’exemple, une application client légitime stocke des données sensibles qui lui sont propres, telles que des informations PII, dans une mémoire sécurisée gérée par une application sécurisée de l’environnement sécurisé. Si l’application client légitime est remplacée par une application client corrompue, par un attaquant, l’application client corrompue peut se faire passer pour l’application client légitime lors de l’émission d’une requête en lecture des données sensibles gérées par l’application sécurisée. Dans un tel exemple, il n’est pas possible pour l’application sécurisée de détecter que la requête en lecture des données sensibles provient d’une application client corrompue. Un autre problème survient lorsqu’une application client a un droit d’accès global pour requérir des services de toutes les applications sécurisées de l’environnement sécurisé 120. Un attaquant peut dans ce cas, en cas de corruption d’une application client, accéder à l’ensemble des données de l’environnement sécurisé 120. Par exemple, une application sécurisée peut générer une donnée cryptographique en réponse à une requête d’une application client légitime. La donnée cryptographique peut être utilisée par l’application client légitime pour établir un accès sécurisé à un serveur tiers distant. Une autre application client, qui a été corrompue par un attaquant, peut requérir auprès de l’application sécurisée, la même donnée cryptographique, et établir un accès prétendument sécurisé avec le serveur distant. Dans ce cas, il n’est pas possible, ni pour l’application sécurisée, ni pour le serveur distant, de détecter que l’autre application client n’est pas l’application client légitime, et qu’elle est corrompue. Par conséquent, il est nécessaire de contrôler la légitimité d’une application client exécutée dans un environnement sécurisé, lorsqu’elle requiert l’accès à un service fourni par une application sécurisée de l’environnement sécurisé. Une première solution connue à ce problème est décrite dans le document « An Effective Authentication for Client Application Using ARM TrustZone », Hang Jiang et Al, décembre 2017, Lecture Notes in Computer Science, Information Security Practive and Experience, pages 802 à 813. Cette première solution propose d’authentifier une application client de l’environnement non sécurisé afin de lui permettre l’accès à une application sécurisée exécutée dans l’environnement TEE. A cet effet, une valeur de hachage, ou « hash », est calculée à partir de l’application client, lorsqu’elle est exécutée, et la valeur de hachage obtenue est comparée à une valeur de hachage stockée au préalable dans l’environnement TEE. Si la vérification de la valeur de hachage calculée est positive, une session est autorisée à être établie entre l’application client et l’application sécurisée requise. Dans le cas contraire, la session avec l’application sécurisée n’est pas établie. Si une nouvelle application client est installée dans l’environnement non sécurisé, via une mise à jour logicielle par exemple, alors une valeur de hachage est calculée pendant l’exécution de la nouvelle application client, et la valeur de hachage calculée est stockée dans l’environnement TEE pour une authentification ultérieure. Une deuxième solution connue est issue d’un standard technique développée par Global Platform, destiné à aider le développement de services et systèmes sécurisés pour assurer la sécurité et la confidentialité des données sensibles d’utilisateurs. Global Platform définit des spécifications d’interface de programmation d’interface, ou API, pour « Application Programming Interface », à destination de clients de l’environnement TEE, par exemple les applications clients 112.1 et 112.2 de la FIG. 1 , pour l’établissement de sessions de communications avec les applications sécurisées 122.1 et 122.2 et avec les services associés dans l’environnement sécurisé TEE. Par exemple, la publication « TEE Client API Specification », GlobalPlatform Device Technology, Version 1.0, Juillet 2010, définit, dans sa section 4.4.5 intitulée « Session Login Methods », des méthodes optionnelles qui peuvent être implémentées par le système d’exploitation sécurisé 121 pour vérifier l’identité d’une application client 112.1-112.2 lors de l’établissement d’une session avec une application sécurisée 122.1-122.2. Certaines de ces méthodes sont basées sur la fourniture de données d’identification, ou login, telles que des données identifiant l’utilisateur sous lequel l’application client est exécutée, ou le groupe d’utilisateurs sous lequel l’application client est exécutée, ou des données identifiant l’application client elle-même. En fonction des données fournies pour l’identification, l’application sécurisée 122.1-122.2 peut décider de fournir ou de refuser l’accès à ses services, à l’application client. Toutefois, les deux solutions précitées présentent les inconvénients suivants. Concernant la première solution mentionnée précédemment, bien que l’application client soit authentifiée par le calcul d’une valeur de hachage sur le code source exécutable de l’application client, afin de vérifier que le code source exécutable n’est pas corrompu par un attaquant, il n’est pas permis de vérifier qu’une application client donnée est bien autorisée à utiliser les services de l’application sécurisée pour laquelle l’établissement d’une session est requise. Etant donné qu’une application sécurisée dans l’environnement TEE peut fournir des services en réponse à des requêtes de plusieurs applications client différentes de l’environnement non sécurisé, il est important de vérifier qu’une application client donnée est bien autorisée à accéder à l’application sécurisée. Par exemple, en se référant à l’exemple illustré sur la FIG. 1 , lorsque la deuxième application client 112.2 requiert l’accès à un service de la première application sécurisée 122.1 dans l’environnement sécurisé 120, seule l’intégrité du code source de la deuxième application client 112.2 est vérifié selon la première solution connue. Il n’est ainsi aucunement prévu de vérifier que la deuxième application client 112.2 est bien autorisée à requérir un service auprès de la première application sécurisée 122.1. En outre, dans la première solution connue, une nouvelle application client peut être installée lors d’une mise à jour logicielle, du système 100, et une valeur de hachage de la nouvelle application est calculée lors de son exécution. Durant cette période, un attaquant peut installer une application client corrompue, si le mécanisme de mise à jour sécurisée est compromis. Dans ce cas, la première solution connue prévoit de calculer la valeur de hachage pour l’application client corrompue, qui est alors considérée comme légitime pour l’établissement futur de sessions de communication avec des applications sécurisées. L’application client corrompue peut ainsi accéder à des données privées/confidentielles stockées dans l’environnement TEE 120. Enfin, la première solution connue requiert le stockage de valeurs de hachage calculées à l’avance, dans l’environnement TEE. Cela requiert une synchronisation stricte lors du stockage des valeurs de hachage calculées à l’avance pour les applications clients, dans l’environnement TEE. En cas d’erreur lors de la fourniture ou du chargement des valeurs de hachage calculées à l’avance, les authentifications futures basées sur ces valeurs de hachage peuvent être erronées. Concernant la deuxième solution connue, le document de spécifications précité ne mentionne aucun standard pour la vérification de la légitimité d’une application client. Il appartient, lors de l’implémentation de la sécurité du système d’exploitation riche 111, d’assurer le maintien de la sécurité des applications client et de la détection de toute modification faite dans une application client. Un attaquant peut alors mener l’attaque suivante: en considérant un environnement sécurisé 120 utilisant une méthode d’identification basée sur un identifiant utilisateur, méthode appelée « TEEC_LOGIN_USER » dans le document précité correspondant à la deuxième solution, une application client indiquant l’identifiant utilisateur peut accéder au service d’une application sécurisée. Si l’application sécurisée détermine que l’application client qui requiert le service, appartient à l’utilisateur correspondant à l’identifiant utilisateur, alors elle autorise l’accès au service. Lorsqu’une application client est corrompue par un attaquant, elle peut néanmoins conserver son association avec l’identifiant utilisateur lui permettant d’accéder au service de l’application sécurisée. Ainsi, la deuxième solution connue pose des problèmes de sécurité. En outre, la spécification précitée correspondant à la deuxième solution connue, identifie l’application client par l’utilisateur ou le groupe d’utilisateurs à laquelle elle appartient. Aucune restriction n’est toutefois définie dans la spécification concernant l’accès d’une autre application client, appartenant au même utilisateur ou groupe d’utilisateurs, à cette même application sécurisée. Par conséquent, au sein des applications clients appartenant au même utilisateur ou groupe d’utilisateurs, il n’existe aucun cloisonnement des accès à des applications sécurisées. Par exemple, en se référant à la FIG. 1 décrite précédemment, et en considérant que la première application client 112.1 et la deuxième application 112.2 appartiennent au même premier utilisateur, mais qu’une troisième application client, non représentée sur la FIG. 1 , appartient à un deuxième utilisateur différent du premier utilisateur, alors : - la première application client 112.1 peut créer et posséder des données cryptographiques dans un module de stockage sécurisé de l’environnement sécurisé 120, via la première application sécurisée 122.1 ; - la troisième application client, qui n’appartient pas au premier utilisateur possédant la première application client 112.1, ne peut pas accéder aux données cryptographiques stockées dans le module de stockage sécurisé ; - toutefois, la deuxième application client 112.2 peut bien accéder aux données cryptographiques car elle appartient au même utilisateur que la première application client 112.1. Ainsi, la première application sécurisée 122.1 ne dispose d’aucun mécanisme de contrôle d’accès permettant d’empêcher la deuxième application client 112.2 d’accéder à des données cryptographiques qui appartiennent à la première application client 112.1. Par conséquent, aucune des solutions connues ne permet une gestion sécurisée de l’accès d’une application client à un service d’une application sécurisée dans un environnement sécurisé, tel que l’environnement TEE, assurant que chaque application client, et seulement elle, a accès à des données sensibles telles que des données PII ou des données cryptographiques par exemple. Il existe ainsi un besoin d’améliorer la sécurité associée à l’accès d’une application client au service d’une application sécurisée exécutée dans un environnement sécurisée, tel que l’environnement TEE par exemple. La présente invention améliorer la situation. A cet effet, un premier aspect de l’invention concerne un procédé de gestion d’accès à une application sécurisée d’un environnement sécurisé d’un système informatique, pour l’établissement d’une session de communication courante entre une application client d’un environnement non sécurisé du système informatique, et l’application sécurisée, le procédé comprenant les étapes suivantes : - sur réception d’une première requête issue de l’application client, la première requête identifiant l’application sécurisée auprès de laquelle une vérification est requise, obtention d’une information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - génération d’un nombre aléatoire dans l’environnement sécurisé ; - détermination d’un identifiant unique de l’application client, par l’application sécurisée, en fonction du nombre aléatoire généré et de l’information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - stockage de l’identifiant unique de l’application client en tant que métadonnée de l’application client, dans l’environnement non sécurisé ; - suite au stockage de l’identifiant unique dans l’environnement non sécurisé, et à une réception d’une deuxième requête pour établir une session courante entre l’application client et l’application sécurisée, vérification de l’identifiant unique de l’application client préalablement à l’établissement de la session de communication courante entre l’application client et l’application sécurisée. Ainsi, l’invention propose la création d’un identifiant unique de l’application client matérialisant un lien unique entre l’application client et l’application sécurisée. La caractère unique de ce lien est lié à la génération d’un nombre aléatoire dans l’environnement sécurisé. L‘identifiant unique est ensuite utilisé comme donnée de vérification pour l’établissement d’une session courante de communication entre l’application client et l’application sécurisée. Par conséquent, une application client donnée, ne peut pas accéder à des données issues de la mise en œuvre de service entre une application sécurisée et une autre application client. En outre, la solution proposée ne requiert pas de stockage préalable de métadonnées relatives à une application client dans l’environnement sécurisé. Cela évite ainsi une mise à jour de l’environnement sécurisé lors de l’installation d’une nouvelle application client dans l’environnement non sécurisé. Selon des modes de réalisation, l’information identifiant de manière unique l’application client dans l’environnement non sécurisé peut être un chemin de l’application client dans un système de fichier de l’environnement non sécurisé. Un tel chemin dans un système de fichier permet bien une identification unique dans un environnement non sécurisé, et est vérifiable par une entité tierce de confiance exécutée sur un noyau de l’environnement non sécurisé. Selon des modes de réalisation, l’obtention de l’information identifiant de manière unique l’application client et le stockage de l’identifiant unique dans l’environnement non sécurisé peuvent être mis en œuvre par une passerelle de confiance de l’environnement non sécurisé, le procédé comprenant une phase préalable de démarrage sécurisé du système informatique durant laquelle la passerelle de confiance et chaque application sécurisée de l’environnement sécurisé sont signées par un ensemble de clés d’une racine de confiance. Ainsi, les entités mettant en œuvre l’invention communiquent de manière sécurisée et sont mutuellement authentifiées avant la mise en œuvre de l’invention, ce qui renforce la sécurité associée à la gestion d’accès selon l’invention. Selon des modes de réalisation, une structure de données de l’application client peut comprendre un code source binaire, une liste d’au moins une application sécurisée légitime pour l’application client et une signature obtenue à partir du code source binaire et ladite liste, et le procédé peut comprendre, préalablement à la génération du nombre aléatoire, une vérification que l’application sécurisée identifiée dans la première requête fait partie de la liste d’au moins une application sécurisée légitime de la structure de données de l’application client. Ainsi, un contrôle préalable de la légitimité de l’accès à l’application sécurisée peut être mise en oeuvre. Il est en outre rendu possible par la signature de vérifier que la liste d’au moins une application sécurisée légitime n’a pas été modifiée par l’application client. L’intégrité de la liste est ainsi assurée. Selon des modes de réalisation, l’identifiant unique de l’application client peut être stocké en tant que métadonnée qui est non modifiable par ladite application client. Ainsi, une application client corrompue n’est pas en mesure de modifier l’identifiant unique de l’application client. En complément, l’identifiant unique de l’application client peut être stocké en tant qu’attribut étendu d’un code source binaire de l’application client. L’attribut étendu est une fonctionnalité offerte par certains systèmes de fichiers. Qui plus est, une telle fonctionnalité peut empêcher l’application client de pouvoir modifier l’attribut étendu, comme expliqué dans la description détaillée qui suit. Selon des modes de réalisation, l’identifiant unique de l’application client peut être stocké en tant que métadonnée en association avec un identifiant de l’application sécurisée. Ainsi, des liens uniques peuvent être créés, de manière sécurisée, entre l’application client et une pluralité d’applications sécurisées de l’environnement sécurisé. Selon des modes de réalisation, suite à la détermination de l’identifiant unique de l’application client, le procédé peut comprendre en outre le stockage, dans l’environnement sécurisé, d’une association entre le nombre aléatoire généré et une valeur de hachage obtenue à partir de l’information identifiant de manière unique l’application client dans l’environnement non sécurisé, et la vérification de l’identifiant unique de l’application client préalablement à l’établissement de la session de communication courante entre l’application client et l’application sécurisée peut comprendre les étapes suivantes : - obtention d’une valeur de hachage courante de l’information identifiant de manière unique l’application sécurisée, par une passerelle de confiance de l’environnement non sécurisé ; - transmission, par la passerelle de confiance, de la valeur de hachage courante et de l’identifiant unique de l’application client, à l’application sécurisée ; - obtention, par l’application sécurisée, du nombre aléatoire stocké en association avec la valeur de hachage courante dans l’environnement sécurisé ; - vérification que l’identifiant unique de l’application client reçu de la passerelle de confiance a été obtenue à partir du nombre aléatoire obtenu et à partir de la valeur de hachage courante. Ainsi, il est permis d’assurer que l’entité disposant de l’identifiant unique est bien l’application client pour laquelle les étapes précédentes ont été mises en œuvre. L’établissement de la session de communication courante est ainsi conditionnée par une telle vérification préalable, ce qui renforce la sécurité associée à l’accès à l’application sécurisée. Un deuxième aspect de l’invention concerne un programme informatique comportant des instructions pour la mise en œuvre du procédé selon le premier aspect de l’invention, lorsque ces instructions sont exécutées par un processeur. Un troisième aspect de l’invention concerne un système informatique comprenant un environnement non sécurisé apte à exécuter au moins une application client, et un environnement sécurisé apte à exécuter au moins une application sécurisée, dans lequel : - l’environnement non sécurisé comprend un noyau riche apte à, sur réception d’une première requête issue d’une application client, la première requête identifiant une application sécurisée auprès de laquelle une vérification est requise, obtenir une information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - l’application sécurisée est apte à générer un nombre aléatoire dans l’environnement sécurisé, et à déterminer un identifiant unique de l’application client en fonction du nombre aléatoire généré et de l’information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - le noyau riche est configuré pour stocker l’identifiant unique de l’application client en tant que métadonnée de l’application client dans l’environnement non sécurisé; et - suite au stockage de l’identifiant unique dans l’environnement non sécurisé, et à une réception par le noyau riche d’une deuxième requête pour établir une session courante entre l’application client et l’application sécurisée, l’application sécurisée est apte à vérifier l’identifiant unique de l’application client préalablement à l’établissement de la session de communication courante entre l’application client et l’application sécurisée. D’autres caractéristiques et avantages de l’invention apparaîtront à l’examen de la description détaillée ci-après, et des dessins annexés sur lesquels : FIG. 1 illustre un système informatique comprenant un environnement sécurisé et un environnement non-sécurisé, selon l’art antérieur; FIG. 2 illustre un système informatique comprenant un environnement sécurisé et un environnement non-sécurisé, selon des modes de réalisation de l’invention ; FIG. 3 illustre une structure de données d’une application client, dans un système informatique selon des modes de réalisation de l’invention; FIG. 4 illustre les étapes d’une phase préalable de création de structure de données selon la FIG. 3 , dans un procédé de gestion d’accès à une application sécurisée selon des modes de réalisation de l’invention ; FIG. 5 illustre les étapes d’une phase de vérification d’une application client auprès d’une application sécurisée, d’un procédé de gestion d’accès à l’application sécurisée selon des modes de réalisation de l’invention ; FIG. 6 illustre les étapes d’une phase d’attribution d’un identifiant unique à une application client, d’un procédé de gestion d’accès à une application sécurisée selon des modes de réalisation de l’invention FIG. 7 illustre les étapes d’une phase d’établissement d’une session courante d’un procédé de gestion d’accès à une application sécurisée selon des modes de réalisation de l’invention. La FIG. 1 illustre un système informatique 200 comprenant un environnement sécurisé 220 et un environnement non sécurisé 210, selon des modes de réalisation de l’invention. Le système informatique 200 est par exemple basé sur une architecture ARM de type SoC ARM 201. Un moniteur sécurisé 202 est apte à assurer un rôle d’interface entre l’environnement non sécurisé 210 et l’environnement sécurisé 220. Le moniteur sécurisé 202 est un firmware sécurisé, par exemple un firmware sécurisé ARM, exécuté sur les composants matériels SoC ARM 201. L’environnement non sécurisé 210 est basé sur un système d’exploitation riche, ayant un noyau de système d’exploitation riche 211, tel qu’un noyau Linux TM par exemple, apte à exécuter un ensemble d’applications clients, comprenant par exemple une application client 212, et pouvant comprendre d’autres applications client non représentées sur la FIG. 2 . L’environnement sécurisé 220 est basé sur un système d’exploitation sécurisé, ayant un noyau sécurisé 221, apte à exécuter un ensemble d’applications sécurisées, comprenant par exemple une application sécurisée 222, et pouvant comprendre d’autres applications sécurisées non représentées sur la FIG. 2 . L’environnement non sécurisé 210 est exécuté sur un système d’exploitation distinct du système d’exploitation sécurisé de l’environnement sécurisé 220, qui peut être un environnement TEE. Le système d’exploitation de l’environnement non sécurisé peut être appelé système d’exploitation « riche » ou « principal », soit « Rich Operation System » en anglais. Par exemple, dans le contexte d’un système informatique utilisé pour des applications automobiles, le système d’exploitation principal peut être Android Automotive OS TM , ou encore Automotive Grade Linux TM . L’environnement non sécurisé 210 peut être implémenté par un premier ensemble de composants matériels et logiciels, du système sur puce SoC ARM 201 et l’environnement non sécurisé 220 peut être implémenté par un deuxième ensemble de composants matériels et logiciels, du système sur puce SoC ARM 201. Aucune restriction n’est attachée aux composants matériels et logiciels des premier et deuxième ensembles. L’application client 212 peut requérir des services mis en œuvre par l’application sécurisée 222, par l’intermédiaire du moniteur sécurisé 202, et comme décrit dans ce qui suit. Dans le cadre de tels services sécurisés, des données sensibles propres à l’application client 212 peuvent être stockées dans une base de données sécurisée 223 de l’environnement sécurisé 220, dont l’accès est géré par l’application sécurisée 222. Les données sensibles peuvent être n’importe quelle donnée issue ou utilisée par l’application client 212, telles que des clés privées ou des informations personnelles, telles que des informations personnellement identifiables PII. Comme expliqué précédemment, l’application client 212 étant exécutée dans un environnement non sécurisé 210, il est préférable de pouvoir assurer que l’application client souhaitant accéder à un service d’une application sécurisée, est légitime, et n’est pas corrompue par un attaquant souhaitant accéder aux données sensibles auxquelles il n’a légitimement pas le droit d’accéder et qui sont stockées dans la base de données sécurisée 223. Selon des modes de réalisation de l’invention, le noyau riche 211 implémente une passerelle 213, dite passerelle de confiance, entre l’environnement non sécurisé 210, comprenant l’application client 212, et l’environnement sécurisé 220. Les fonctionnalités mises en œuvre par la passerelle de confiance 213 seront mieux comprises dans ce qui suit. La passerelle de confiance peut être considérée comme une API permettant d’accéder à la zone de confiance que constitue l’environnement sécurisé 220. Le système informatique 200 selon l’invention peut être intégré dans un véhicule automobile, pour l’exécution d’une application client 212 ayant une fonction dans le véhicule automobile. Aucune restriction n’est attachée à la fonction, ou aux fonctions, réalisée par l’application client 212. Le système informatique 200 peut initialiser un démarrage sécurisé, ou « secure boot » en anglais, qui est une procédure de démarrage connue, et qui permet de créer une plateforme d’exécution sécurisée de logiciels automobiles. La procédure de démarrage sécurisé assure que les composants logiciels impliqués dans le processus de démarrage, tels que le firmware sécurisé 202, le noyau sécurisé 221 et l’application sécurisée 222, le noyau riche 211 et une unité de chargement du démarrage, sont signés par cryptographie en utilisant un ensemble de clés qui sont liées par une racine de confiance, appelée « root of trust » en anglais, du système sur puce matériel 201. Une racine de confiance est une ressource de confiance permanente au sein d’un système cryptographique. Les composants logiciels initialisés lors du processus de démarrage sécurisés, y compris le noyau riche 211, sont ainsi vérifiés les uns après les autres. Toutefois, les composants logiciels de l’espace utilisateur, ou environnement non sécurisé 210, dans lequel l’application client 212 est exécutée, ne font pas partie de la chaîne de démarrage sécurisé et ne peuvent par conséquent pas être considérés comme fiables ou de confiance. L’invention permet toutefois de surmonter une telle limitation. La FIG. 3 illustre une structure de données 300 du fichier de l’application client 212, dans un système informatique 200 selon des modes de réalisation de l’invention. La structure de données 300 est une image du fichier binaire, ou fichier exécutable, de l’application client 212. La structure de données comprend le code source binaire 301, ou exécutable, de l’application client 212, et comprend en outre des sections additionnelles selon l’invention. Une première section additionnelle peut être une valeur de hachage 302 obtenue à partir d’une fonction de hachage appliquée au code source binaire 301 de l’application client 212, aucune restriction n’étant appliquée à la fonction de hachage considérée. Une deuxième section additionnelle 303 peut être comprendre au moins un identifiant d’application sécurisée, par exemple sous la forme d’une liste d’identifiants d’application sécurisée, chaque identifiant d’application sécurisée identifiant une application sécurisée pour laquelle l’application client 212 est autorisée à requérir un service. La liste peut ainsi comprendre une liste d’identifiants d’application sécurisée correspondant à un sous-ensemble des applications sécurisées hébergées par l’environnement sécurisé 220. Dans l’exemple simplifié de la FIG. 2 , l’application client 212 requiert l’accès au service de l’application sécurisée 222 à laquelle elle a légitimement accès, et le fichier correspondant à la structure de données 300 comprend donc un identifiant de l’application sécurisée 222 dans la deuxième section additionnelle. Aucune restriction n’est attachée au format de l’identifiant de l’application sécurisée 222 stocké dans la deuxième section additionnelle 303, qui peut être tout identifiant apte à identifier de manière unique l’application sécurisée 222 dans l’environnement sécurisé 220. Par exemple, l’identifiant de l’application sécurisée 222 peut être un identifiant universellement unique, aussi appelé UUID, pour « Universally Unique IDentifier » en anglais, qui est un identifiant de 128 bits défini par le standard RFC 4122. Une troisième section additionnelle 304 peut comprendre une valeur de hachage signée, obtenue par signature d’une valeur obtenue à partir du code source binaire 301 et de la liste d’au moins un identifiant d’application sécurisée 303. Par exemple, une fonction « ou exclusif » ou XOR, est appliquée à la valeur de hachage 302 du code source binaire 301 et à la liste 303. La sortie de l’opération XOR peut être passée à une fonction de hachage sécurisée de manière cryptographique, pour déterminer une deuxième valeur de hachage, aussi appelée « empreinte numérique » ou « message digest » en anglais. L’empreinte numérique est signée pour obtenir la valeur de hachage signée, en utilisant une clé privée d’une paire de clés asymétriques. L’environnement sécurisé 220 dispose de la clé publique associée, et est ainsi apte à vérifier la valeur de hachage signée. La FIG. 4 présente les étapes 400 à 408 d’une phase préalable d’un procédé de gestion d’accès à une application sécurisée, selon des modes de réalisation de l’invention. La phase préalable peut être mise en œuvre avant les phases courantes décrites dans ce qui suit, et vise à déterminer et stocker la structure de données 300 de chaque application client 212 de l’environnement non sécurisé 210. Aucune restriction n’est attachée à l’entité matérielle ou logicielle en charge de la construction de la structure de données 300 pour chaque application client. La structure de données peut notamment être construite à la suite de l’élaboration du code source de l’application, notamment lors de la compilation du code source de l’application client 212. La phase préalable peut ainsi être mise en œuvre par l’entité en charge de la compilation du code source de l’application client 212. A une étape 400, le code source de l’application client 212 est obtenu. A une étape 401, le code source de l’application client 212 est compilé pour obtenir le code source binaire de l’application client 212. A une étape 402, une première valeur de hachage est calculée à partir du code source binaire de l’application client 212. A une étape 403, mise en œuvre en parallèle de l’étape 402, ou mise en œuvre avant ou après l’étape 403, la liste d’au moins une application sécurisée 222 pour laquelle l’application client 212 est autorisée à requérir un service, est obtenue. A une étape 404, la fonction XOR est appliquée à la première valeur de hachage et à la liste d’au moins une application sécurisée 222, pour obtenir une empreinte numérique. A une étape 405, la fonction de hachage sécurisée de manière cryptographique est appliquée à l’empreinte numérique pour obtenir la deuxième valeur de hachage. A une étape 406, mise en œuvre en parallèle de l’étape 405, ou mise en œuvre avant ou après l’étape 405, la clé privée de la paire de clés asymétrique précitée est obtenue. Comme indiqué précédemment, la clé publique est ensuite rendue accessible dans l’environnement sécurisé 220, par exemple stockée dans une mémoire de l’environnement sécurisé 220. A une étape 407, la deuxième valeur de hachage est signée à partir de la clé privée de la paire de clés asymétrique. A une étape 408, la première valeur de hachage est ajoutée au code source binaire de l’application client 212 dans la première section additionnelle 302, la liste d’au moins une application sécurisée 222 est ajoutée dans la deuxième section additionnelle 303 et la deuxième valeur de hachage signée est ajoutée dans la troisième section additionnelle 304. La structure de données 300 est ainsi construite pour l’application client 212. A une étape 409, la structure de données 300 est stockée dans l’environnement non sécurisé 110, en association avec un chemin du système de fichiers, à partir duquel la structure de données 300 est accessible par le noyau riche 211. La FIG. 5 présente les étapes d’une phase de vérification d’une application client, la phase de vérification faisant partie d’un procédé de gestion d’accès à une application sécurisée, selon des modes de réalisation de l’invention. La phase de vérification vise à vérifier qu’une application client 212, ayant la structure de données 300 décrite précédemment, est légitime pour accéder à l’application sécurisée 222 de l’environnement sécurisé 220 et vise à créer un identifiant matérialisant un lien unique entre l’application sécurisée et l’application client. La phase de vérification peut être mise en œuvre dans la situation suivante : - le noyau riche 211, dont la passerelle de confiance 213, le noyau sécurisé 221 et les applications sécurisées qu’il supporte, dont l’application sécurisée 222, ainsi que le firmware 202, ont été signés et vérifiés lors d’une procédure de démarrage sécurisée, ou « secure boot », décrite précédemment ; - la clé publique de la paire de clés asymétrique comprenant la clé privée avec laquelle la troisième section additionnelle 304 de la structure de données 300 de l’application client 212 est obtenue, est stockée dans l’environnement sécurisé 220, et mise à disposition de l’application sécurisée 222, par exemple dans une mémoire de l’environnement sécurisé 220 ; - la passerelle de confiance 213 est apte à ajouter un attribut associé à une application client 212 dans l’environnement non sécurisé 210, sans que cette application client 212 soit autorisée à modifier l’attribut ajouté par la passerelle 213. Un tel attribut peut être un attribut étendu, ou « extended attribute » en anglais, qui peut être associé au code source binaire 301 de l’application client. Par exemple, une fonctionnalité POSIX de type CAP_SYS_ADMIN est désactivée, de manière à empêcher l’application client 212 de modifier l’attribut étendu qui est affecté à son code source binaire 301. POSIX est un ensemble de normes de l’IEEE, pour « Institute of Electrical and Electronics Engineers » en anglais ; - le système de fichiers de l’environnement non sécurisé 210 accepte l’ajout d’attributs aux applications clients, tels que les attributs étendus précités. A une étape 501 de la phase de vérification, l’application client 212 est chargée dans une mémoire volatile de l’environnement non sécurisé 210, par le noyau riche 211, puis exécutée. En particulier, le code source binaire exécutable 301 de l’application client 212 est exécutée. A une étape 502, suite à son exécution, l’application client 212 transmet une requête comprenant un identifiant d’application sécurisée, tel que l’identifiant UIDD de l’application sécurisée 222 avec laquelle l’application client 212 requiert une vérification pour accéder ensuite à un service de l’application sécurisée 222, à la passerelle de confiance 213. A une étape 503, la passerelle de confiance 213 reçoit la requête comprenant l’identifiant de l’application sécurisée 222. A une étape 504, la passerelle de confiance 213 transmet l’identifiant de l’application sécurisée 212 au noyau sécurisé 221, pour chargement de l’application sécurisée 212 correspondant à l’identifiant reçu. A une étape 505, la passerelle de confiance 213 peut confirmer l’initiation de la phase de vérification auprès de l’application client 212, et générer un identifiant de session, ou « session handle » en anglais. A une étape 506, la passerelle de confiance 213 obtient une information qui identifie de manière unique, dans l’environnement riche 210 ou dans l’absolu, la structure de données 300, de l’application client 212 ayant émis la requête. Une telle information peut être un chemin dans le système de fichier de l’environnement riche 210, ou en variante un numéro d’inode. Dans ce qui suit, il est considéré, à titre illustratif uniquement, que l’information identifiant de manière unique le fichier de l’application client 212 est le chemin dans le système de fichier de l’environnement non sécurisé 210. Ainsi, à l’étape 506, la passerelle de confiance 213 obtient le chemin du système de fichier identifiant le code binaire source de l’application client 212, depuis lequel l’application client 212 est chargée et exécutée. A une étape 507, la passerelle de confiance 213 calcule une première valeur de hachage courante notée H CAL , qui est une valeur de hachage du code source binaire 301 de l’application client 212 correspondant au chemin du système de fichier obtenu à l’étape précédente. A une étape 508, la passerelle de confiance calcule une deuxième valeur de hachage courante, qui est une valeur de hachage de l’information identifiant de manière unique l’application client 212 dans l’environnement non sécurisé 210, c’est-à-dire, dans l’exemple considéré, une valeur de hachage du chemin du système de fichier vers le code binaire source 301 de l’application client 212, obtenu à l’étape 506. A une étape 509, la passerelle de confiance 213 extrait les informations suivantes de la structure de données 300 à laquelle elle accède à partir du chemin du système de fichier obtenu à l’étape 506 : - la valeur de hachage, noté H CA , qui est stockée dans le premier segment additionnel 302 de la structure de données 300 de l’application client 212, obtenue par hachage du code source binaire 301 ; - la liste 303 stockée dans le deuxième segment additionnel de la structure de données 300 de l’application client 212 ; - la valeur de hachage signée 304 stockée dans le troisième segment additionnel de la structure de données 300 de l’application client 212. A noter que les étapes 506 à 509 peuvent être mises en œuvre en parallèle ou séquentiellement mais dans un ordre différent de celui représenté sur la FIG. 5 . A une étape 510, la passerelle de confiance 213 compare la première valeur de hachage courante H CAL et la valeur de hachage H CA stockée dans le premier segment additionnel 302 de la structure de données 300. Si les deux valeurs de hachage H CAL et H CA sont différentes, la passerelle de confiance 213 interrompt la phase de vérification, et renvoie un message d’erreur à l’application client 212, à une étape 511. Ainsi, la comparaison de l’étape 510 permet d’assurer que le code source binaire 301 n’a pas été modifié après la détermination et le stockage de la structure de données 300. Si les deux valeurs de hachage H CAL et H CA sont identiques, la passerelle de confiance 213 transmet les informations suivantes, à une étape 512, au noyau sécurisé 221 : - la valeur de hachage H CA L ou H CA , qui sont identiques, qui correspond à la valeur de hachage du code source binaire de l’application client 212 ; - la liste 303 comprenant au moins un identifiant d’application sécurisé, dont l’identifiant de l’application sécurisée 222 à laquelle l’application client 212 souhaite accéder ; - la valeur de hachage signée 304 obtenue de la structure de données 300 ; - la deuxième valeur de hachage courante, qui est la valeur de hachage de l’information identifiant de manière unique l’application client 212 dans l’environnement non sécurisé 210, c’est-à-dire, dans l’exemple considéré, la valeur de hachage du chemin du système de fichier vers le code binaire source 301 de l’application client 212. A une étape 520, le noyau sécurisée 221 transmet les informations reçues à l’étape 511, à l’application sécurisée 222, qui a été précédemment exécutée suite à l’étape 504. A une étape 521, l’application sécurisée 222 obtient la clé publique disponible dans l’environnement sécurisée 120, associée à la clé privée à partir de laquelle la valeur de hachage signée 304 a été obtenue. A une étape 522, l’application sécurisée 222 vérifie la signature de la valeur de hachage signée 304 reçue à l’étape 520, à partir de la clé publique obtenue à l’étape 521. Si la vérification est positive suite à l’étape 522, c’est-à-dire si la valeur de hachage signée 304 reçue a bien été signée avec une clé privée correspondant à la clé publique obtenue à l’étape 521, le procédé passe à l’étape 526 décrite ensuite. Dans le cas contraire, en cas de vérification négative à l’étape 522, un message d’erreur est envoyé à la passerelle de confiance 213, via le noyau sécurisé 221, à une étape 523. La passerelle de confiance 213 peut ensuite transmettre le message d’erreur à l’application client 212 et la phase de vérification est interrompue. L’étape 522 permet ainsi de vérifier que la valeur de hachage signée est bien issue d’une entité de confiance. En parallèle des étapes 521 et 522, ou en variante avant ou après les étapes 521 et 522, l’application sécurisée 222 calcule une troisième valeur de hachage courante, ou empreinte numérique courante, à des étapes 524 et 525, pour comparaison avec la valeur de hachage signée 304 reçue à l’étape 520. Le calcul de la valeur de hachage signée courante peut comprendre : - l’application, à une étape 524, d’une opération XOR à la valeur de hachage H CA ou H CAL et à la liste 303, toutes deux reçues à l’étape 520 ; - le calcul, à une étape 525, de la troisième valeur de hachage courante, aussi appelée empreinte numérique courante, par application d’une fonction de hachage au résultat de l’opération XOR. A une étape 526, l’application sécurisée 222 compare la troisième valeur de hachage courante obtenue à l’étape 525 avec la valeur de hachage signée 304 reçue à l’étape 520 et dont la signature a été vérifiée à l’étape 522. En cas de comparaison négative, c’est-à-dire si la troisième valeur de hachage courante obtenue à l’étape 525 ne correspond pas à la valeur de hachage signée 304 reçue à l’étape 520, alors l’application sécurisée 222 peut transmettre un message d’erreur à la passerelle de confiance 213, via le noyau sécurisé 221, à une étape 527. La passerelle de confiance 213 peut transmettre le message d’erreur à l’application client 212 et la phase de vérification est interrompue. Au contraire, en cas de comparaison positive à l’étape 526, l’application sécurisée 222 vérifie, à une étape 528, que son propre identifiant d’application sécurisée est présent dans la liste 303 reçue à l’étape 520. En cas de vérification négative à l’étape 528, si l’identifiant de l’application sécurisée 222 est absent de la liste 303 reçue à l’étape 520, alors l’application sécurisée 222 transmet un message d’erreur à la passerelle de confiance 213, via le noyau sécurisé 221, à une étape 528. Au contraire, en cas de vérification positive, ce qui est le cas dans l’exemple considéré ici dans lequel l’application client 212 requiert de manière légitime l’accès à l’application sécurisée 222, l’application sécurisée 222 génère un nombre aléatoire à une étape 529. A cet effet, l’application sécurisée 222 peut utiliser un générateur de nombre aléatoire sécurisé de manière cryptographique dans l’environnement sécurisé 220. A une étape 530, l’application sécurisée 222 peut générer un identifiant unique de l’application client 212, à partir du nombre aléatoire généré à l’étape 529 et à partir de la deuxième valeur de hachage courante, qui est, pour rappel, une valeur de hachage de l’information identifiant de manière unique l’application client 212 dans l’environnement non sécurisé 210. Par exemple, l’identifiant unique de l’application client 212 peut être obtenu par application d’une opération ou exclusif, ou XOR, à la deuxième valeur de hachage courante et au nombre aléatoire généré. L’identifiant unique de l’application client 212 ainsi généré est noté CA ID dans ce qui suit. A une étape 531, l’application sécurisée 222 stocke la nombre aléatoire généré en association avec la deuxième valeur de hachage courante, qui est la valeur de hachage de l’information identifiant de manière unique l’application client 212 dans l’environnement non sécurisé 210. Le stockage peut être mis en œuvre dans la base de données sécurisée 223 de l’environnement sécurisé 220 par exemple. A une étape 532, l’application sécurisée 222 transmet à la plateforme de confiance 213, l’identifiant CA ID généré à l’étape 530, peut confirmer la vérification de l’application client 212 par l’application sécurisée 222 ainsi que l’identifiant de session, ou « session handle ». La FIG. 6 présente les étapes d’une phase d’attribution de l’identifiant unique à l’application client 212, suite à la phase de vérification de la FIG. 5 , selon des modes de réalisation de l’invention. La phase d’attribution peut être mise en œuvre par la passerelle de confiance 213 précédemment décrite. A une étape 600, la passerelle de confiance 213 reçoit les informations transmises par l’application sécurisée à l’étape 532 décrite précédemment, à savoir l’identifiant CA ID, la confirmation de vérification de l’application client 212 et l’identifiant de session. A une étape 601, la passerelle de confiance 213 associe une paire comprenant l’identifiant unique de l’application sécurisée 222 et l’identifiant CA ID, en tant que paire clé-valeur par exemple, avec la structure de données 300 de l’application client 212. A cet effet, la paire clé-valeur peut être insérée comme attribut étendu de l’inode du code source binaire 301 de l’application client 212. Comme précédemment décrit, l’attribut étendu est une fonctionnalité permise dans des systèmes de fichiers tels que EXT3 et EXT4 supportés de manière classique par des systèmes d’exploitation basés sur Linux, notamment dans le cadre d’applications automobiles. La fonctionnalité d’attribut étendu permet de stocker de manière sécurisée des métadonnées d’un fichier. Dans la présente invention, la métadonnée stockée est la paire précitée, comprenant l’identifiant unique de l’application sécurisée 222 et l’identifiant CA ID généré. Il convient de noter que la phase de vérification décrite en référence à la FIG. 5 peut être itérée pour plusieurs applications sécurisées auxquelles l’application client 212 requiert légitimement d’accéder. Dans ce cas, plusieurs paires clé-value sont obtenues, chaque paire identifiant comme clé l’identifiant unique de l’une des applications sécurisées avec laquelle la phase de vérification a été mise en œuvre, et chaque paire ayant une valeur CA ID différente des valeurs des autres paires clé-valeur : ainsi, un identifiant unique CA ID est généré pour chaque vérification auprès d’une application sécurisée donnée. Si l’application client 212 requiert une session auprès d’une première application sécurisée lors d’une première phase de vérification, un premier identifiant unique CA ID est obtenu puis stocké dans une première paire clé-valeur en association avec l’identifiant unique de la première application sécurisée. Ensuite, si la même application client 212 requiert une session auprès d’une deuxième application sécurisée lors d’une deuxième phase de vérification, un deuxième identifiant unique CA ID est obtenu puis stocké dans une deuxième paire clé-valeur en association avec l’identifiant unique de la deuxième application sécurisée. Ainsi, plusieurs paires clé-valeur peuvent être stockées en tant qu’attributs étendus du code source binaire 301 de l’application client 212. Selon l’invention, il est avantageux que l’application client 212 ne soit pas en mesure de modifier l’attribut étendu qui lui est attribué par la passerelle de confiance 213. Ainsi, une application client 212 corrompue ne peut pas modifier la paire clé-valeur stockée. Comme indiqué précédemment, la capacité POSIX CAP_SYS_ADMIN peut à cet effet être désactivée, de manière à ce qu’une application client corrompue ne puisse par modifier les attributs étendus. A une étape 602, la passerelle de confiance 213 peut transmettre la confirmation de vérification ainsi que l’identifiant de session, à l’application client 212. L’invention permet ainsi de créer un lien unique, et non modifiable, entre une application client et une application sécurisée avec laquelle elle requiert d’établir une session. Suite à la création d’un tel lien, l’application client 212 peut ensuite établir d’autres sessions, de manière ultérieure, entre l’application client 212 et l’application sécurisée 222, comme décrit en référence à la FIG. 7 . La FIG. 7 présente les étapes d’une phase d’établissement d’une session courante entre une application sécurisée et une application client, suite à la phase d’attribution présentée en référence à la FIG. 6 , selon des modes de réalisation de l’invention. A une étape 701, l’application client 212 est chargée dans une mémoire volatile de l’environnement non sécurisé 210, par le noyau riche 211, puis exécutée. En particulier, le code source binaire exécutable 301 de l’application client 212 est exécutée. A une étape 702, suite à son exécution, l’application client 212 transmet une requête comprenant un identifiant d’application sécurisée, tel que l’identifiant UIDD de l’application sécurisée 222 avec laquelle l’application client 212 requiert l’établissement d’une session pour accéder à un service de l’application sécurisée 222, à la passerelle de confiance 213. A une étape 703, la passerelle de confiance 213 reçoit la requête comprenant l’identifiant de l’application sécurisée 222. A une étape 704, la passerelle de confiance 213 transmet l’identifiant de l’application sécurisée 212 au noyau sécurisé 221, pour chargement de l’application sécurisée 212 correspondant à l’identifiant reçu. A une étape 705, la passerelle de confiance 213 peut confirmer l’initiation de la phase de vérification auprès de l’application client 212. A une étape 706, la passerelle de confiance 213 obtient l’information qui identifie de manière unique, dans l’environnement riche 210 ou dans l’absolu, la structure de données 300 de l’application client 212 ayant émis la requête. Comme déjà décrit précédemment, une telle information peut être le chemin dans le système de fichier de l’environnement riche 210, ou en variante le numéro d’inode. Dans l’exemple considéré, l’information identifiant de manière unique le fichier de l’application client 212 est le chemin dans le système de fichier. Ainsi, à l’étape 706, la passerelle de confiance 213 obtient le chemin du système de fichier identifiant le code binaire source de l’application client 212, depuis lequel l’application client 212 est chargée et exécutée Les étapes 701 à 706 sont ainsi identiques aux étapes 501 à 506 précédemment décrites, à la différence près que les étapes 701 à 706 sont mises en œuvre après la phase de vérification comprenant les étapes 501 à 532. A une étape 707, la passerelle de confiance 213 vérifie qu’au moins une paire clé-valeur est contenue dans les attributs étendus du code source binaire 301 correspondant à l’information identifiant de manière unique l’application client 212, obtenue à l’étape précédente. Si le code source binaire 301 de l’application client 212 ne comprend aucun attribut étendu, ou si l’attribut étendu ne comprend aucune paire clé-valeur, alors la phase de vérification précédemment décrite est mise en œuvre à partir de l’étape 507. Si le code source binaire 301 de l’application client 212 comprend au moins un attribut étendu correspondant à une paire clé-valeur, alors la passerelle de confiance 213 vérifie, à une étape 708 si une paire clé-valeur des attributs étendus comprend l’identifiant de l’application sécurisée 222 reçu à l’étape 703, en tant que clé. En cas de vérification négative, c’est-à-dire si aucune paire clé-valeur des attributs étendus de l’application client 212 ne comprend l’identifiant de l’application sécurisée 222 reçu à l’étape 703, en tant que clé, alors la phase de vérification précédemment décrite est mise en œuvre à partir de l’étape 507. Au contraire, en cas de vérification positive à l’étape 708, la passerelle de confiance 213 obtient l’identifiant unique CA ID appairé à l’identifiant de l’application sécurisée 222 dans les attributs étendus, et calcule, à une étape 709 une valeur de hachage courante de l’information identifiant de manière unique l’application client 212 dans l’environnement non sécurisé 210, c’est-à-dire, dans l’exemple considéré, une valeur de hachage du chemin du système de fichier vers le code binaire source 301 de l’application client 212, obtenu à l’étape 706. A noter que la vérification positive de l’étape 708 indique que l’application client 212 a été précédemment vérifiée par l’application sécurisée 222 avec laquelle elle requiert l’établissement d’une session courante. A une étape 710, la passerelle de confiance 213 transmet les informations suivantes au noyau sécurisé 221 : - l’identifiant de l’application sécurisée 222 obtenue de la requête à l’étape 703 ; - la valeur de hachage courante déterminée à l’étape 709 ; - l’identifiant unique CA ID appairé à l’identifiant de l’application sécurisée 222 dans les attributs étendus de l’application client 212, obtenu à l’étape 709. A une étape 720, le noyau sécurisé 221 transmet les informations reçues à l’étape 710 de la passerelle de confiance 213, à l’application sécurisée 222 correspondant à l’identifiant d’application sécurisée reçu dans les informations. A une étape 721, l’application sécurisée 222 vérifie si l’identifiant d’application sécurisée compris dans les informations reçues à l’étape 720 correspond à son propre identifiant. En cas de vérification négative, c’est-à-dire si l’identifiant d’application sécurisée reçu ne correspond pas à l’identifiant de l’application sécurisée 222, alors l’application sécurisée 222 envoie un message d’erreur, à une étape 722, à la passerelle de confiance 213, via le noyau sécurisé 221, et la phase d’établissement de session courante est interrompue, sans qu’une session courante ne soit établie. La passerelle de confiance 213 peut transmettre le message d’erreur à l’application client 212. Au contraire, en cas de vérification positive à l’étape 721, l’application sécurisée 222 vérifie, à une étape 723, si la valeur de hachage courante comprise dans les informations reçues à l’étape 720, est stockée dans la base de données sécurisée 223 en association avec un nombre aléatoire. Pour rappel, la valeur de hachage courante comprise dans les informations reçues à l’étape 720, est la valeur de hachage déterminée à l’étape 709 à partir de l’information identifiant de manière unique l’application client 212 dans l’environnement non sécurisé 210, c’est-à-dire, dans l’exemple considéré, une valeur de hachage du chemin du système de fichier vers le code binaire source 301 de l’application client 212, obtenu à l’étape 706. En cas de vérification négative à l’étape 723, c’est-à-dire si l’application sécurisée 222 détermine que la base de données sécurisée 223 ne comprend pas la valeur de hachage courante reçue à l’étape 720, l’application sécurisée 222 envoie un message d’erreur, à une étape 724, à la passerelle de confiance 213, via le noyau sécurisé 221, et la phase d’établissement de session courante est interrompue, sans qu’une session courante ne soit établie. La passerelle de confiance 213 peut transmettre le message d’erreur à l’application client 212. Au contraire, en cas de vérification positive à l’étape 723, l’application sécurisée 222 obtient de la base de données sécurisée 223 le nombre aléatoire associé à la valeur de hachage courante et vérifie que l’identité unique CA ID comprise dans les informations reçues à l’étape 720, a bien été obtenue à partir de la valeur de hachage courante et du nombre aléatoire obtenu. A cet effet, l’application sécurisée 222 peut appliquer une opération de « ou exclusif », ou XOR, au nombre aléatoire obtenu et à l’identité unique CA ID reçue à l’étape 720, et le résultat de l’opération est comparé avec la valeur de hachage courante comprise dans les informations reçues à l’étape 720. En cas d’égalité entre le résultat de l’opérateur et la valeur de hachage courante, l’application sécurisée 222 détermine que l’identité unique CA ID comprise dans les informations reçues à l’étape 720, a bien été obtenue à partir de la valeur de hachage courante et du nombre aléatoire obtenu. Dans le cas contraire, l’application sécurisée 222 détermine que l’identité unique CA ID comprise dans les informations reçues à l’étape 720, n’a pas été obtenue à partir de la valeur de hachage courante et du nombre aléatoire obtenu, et un message d’erreur est généré à l’étape 727 et transmis à la passerelle de confiance 213. La phase d’établissement de session courante est interrompue sans qu’une session courante n’ait été établie. Si l’application sécurisée 222 détermine à l’étape 726 que l’identité unique CA ID comprise dans les informations reçues à l’étape 720, a bien été obtenue à partir de la valeur de hachage courante et du nombre aléatoire obtenu, alors l’application sécurisée 222 valide l’établissement de session avec l’application client 212, qui est considérée comme légitime, et envoie un message de confirmation d’établissement de session à la passerelle de confiance 213 à une étape 728. Le message de confirmation peut comprendre : - un identifiant de session courante généré par l’application sécurisée 222 et le noyau sécurisé 221 ; - un statut de confirmation de vérification que l’application client 212 est légitime pour l’établissement de la session courante avec l’application sécurisée 222. A une étape 730, la passerelle de confiance 213 reçoit le message de confirmation. A une étape 731, la passerelle de confiance 213 transmet l’identifiant de session courante à l’application client 212, et la session courante est établie entre l’application client 212 et l’application sécurisée 222. Ainsi, l’invention permet avantageusement : - d’assurer l’intégrité du code source binaire 301 et des métadonnées de l’application client 212 qui requiert l’établissement d’une session courante avec une application sécurisée 222 ; - d’assurer l’établissement de liens uniques entre applications sécurisées et applications clients, de manière à ce qu’une application client donnée, ne puisse pas accéder à des données issues de la mise en œuvre de service entre une application sécurisée et une autre application client. En outre, la solution proposée ne requiert pas de stockage préalable de métadonnées relatives à une application client dans l’environnement sécurisé 220. Cela évite ainsi une mise à jour de l’environnement sécurisé 220 lors de l’installation d’une nouvelle application client dans l’environnement non sécurisé 210. La présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d’exemples ; elle s’étend à d’autres variantes. Procédé de gestion d’accès à une application sécurisée (222) d’un environnement sécurisé (220) d’un système informatique (200), pour l’établissement d’une session de communication courante entre une application client (212) d’un environnement non sécurisé (210) du système informatique, et l’application sécurisée, le procédé comprenant les étapes suivantes : - sur réception (502) d’une première requête issue de l’application client, la première requête identifiant l’application sécurisée auprès de laquelle une vérification est requise, obtention (506) d’une information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - génération (530) d’un nombre aléatoire dans l’environnement sécurisé ; - détermination (531) d’un identifiant unique de l’application client, par l’application sécurisée, en fonction du nombre aléatoire généré et de l’information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - stockage (601) de l’identifiant unique de l’application client en tant que métadonnée de l’application client, dans l’environnement non sécurisé ; - suite au stockage de l’identifiant unique dans l’environnement non sécurisé, et à une réception (702) d’une deuxième requête pour établir une session courante entre l’application client et l’application sécurisée, vérification (703-731) de l’identifiant unique de l’application client préalablement à l’établissement de la session de communication courante entre l’application client et l’application sécurisée. Procédé selon la revendication 1, dans lequel l’information identifiant de manière unique l’application client (212) dans l’environnement non sécurisé (222) est un chemin de l’application client dans un système de fichier de l’environnement non sécurisé. Procédé selon l’une des revendications précédentes, dans lequel l’obtention (506) de l’information identifiant de manière unique l’application client et le stockage (601) de l’identifiant unique dans l’environnement non sécurisé sont mis en œuvre par une passerelle de confiance (213) de l’environnement non sécurisé (210), le procédé comprenant une phase préalable de démarrage sécurisé du système informatique (200) durant laquelle la passerelle de confiance et chaque application sécurisée (222) de l’environnement sécurisé sont signés par un ensemble de clés d’une racine de confiance. Procédé selon l’une des revendications précédentes, dans lequel une structure de données (300) de l’application client (212) comprend un code source binaire (301), une liste (303) d’au moins une application sécurisée légitime pour l’application client et une signature (304) obtenue à partir du code source binaire et ladite liste, et dans lequel, préalablement à la génération (530) du nombre aléatoire, le procédé comprend une vérification (528) que l’application sécurisée identifiée dans la première requête fait partie de la liste d’au moins une application sécurisée légitime de la structure de données de l’application client. Procédé selon l’une des revendications précédentes, dans lequel l’identifiant unique de l’application client (212) est stocké en tant que métadonnée qui est non modifiable par ladite application client. Procédé selon la revendication 5, dans lequel l’identifiant unique de l’application client (212) est stocké en tant qu’attribut étendu d’un code source binaire (301) de l’application client. Procédé selon l’une des revendications précédentes, dans lequel l’identifiant unique de l’application client (212) est stocké en tant que métadonnée en association avec un identifiant de l’application sécurisée (222). Procédé selon l’une des revendications précédentes, dans lequel, suite à la détermination (531) de l’identifiant unique de l’application client, le procédé comprend en outre le stockage (532), dans l’environnement sécurisé (220), d’une association entre le nombre aléatoire généré et une valeur de hachage obtenue à partir de l’information identifiant de manière unique l’application client dans l’environnement non sécurisé, et dans lequel la vérification (703-731) de l’identifiant unique de l’application client préalablement à l’établissement de la session de communication courante entre l’application client (212) et l’application sécurisée comprend les étapes suivantes : - obtention (709) d’une valeur de hachage courante de l’information identifiant de manière unique l’application sécurisée, par une passerelle de confiance (713) de l’environnement non sécurisé ; - transmission (710), par la passerelle de confiance, de la valeur de hachage courante et de l’identifiant unique de l’application client, à l’application sécurisée ; - obtention (723), par l’application sécurisée, du nombre aléatoire stocké en association avec la valeur de hachage courante dans l’environnement sécurisé ; - vérification (726) que l’identifiant unique de l’application client reçu de la passerelle de confiance a été obtenue à partir du nombre aléatoire obtenu et à partir de la valeur de hachage courante. Programme informatique comportant des instructions pour la mise en œuvre du procédé selon l’une des revendications précédentes, lorsque ces instructions sont exécutées par un processeur (201). Système informatique (200) comprenant un environnement non sécurisé (210) apte à exécuter au moins une application client (212), et un environnement sécurisé (220) apte à exécuter au moins une application sécurisée (222), dans lequel : - l’environnement non sécurisé comprend un noyau riche (211) apte à, sur réception d’une première requête issue d’une application client, la première requête identifiant une application sécurisée auprès de laquelle une vérification est requise, obtenir une information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - l’application sécurisée est apte à générer un nombre aléatoire dans l’environnement sécurisé, et à déterminer un identifiant unique de l’application client en fonction du nombre aléatoire généré et de l’information identifiant de manière unique l’application client dans l’environnement non sécurisé ; - le noyau riche est configuré pour stocker l’identifiant unique de l’application client en tant que métadonnée de l’application client dans l’environnement non sécurisé; et - suite au stockage de l’identifiant unique dans l’environnement non sécurisé, et à une réception par le noyau riche d’une deuxième requête pour établir une session courante entre l’application client et l’application sécurisée, l’application sécurisée est apte à vérifier l’identifiant unique de l’application client préalablement à l’établissement de la session de communication courante entre l’application client et l’application sécurisée.