FR3032846A1 - Procede de communication securisee entre un systeme d'exploitation d'un terminal et un dispositif distinct du terminal - Google Patents

Abstract

Procédé de communication sécurisée entre un système d'exploitation d'un terminal et un dispositif distinct du terminal Procédé de communication sécurisée entre un système d'exploitation d'un terminal et un dispositif distinct du terminal, le terminal comportant en outre un environnement d'exécution de confiance. Ce procédé comporte, préalablement à la communication sécurisée, une authentification dudit dispositif par ledit environnement d'exécution de confiance initiée par ledit système d'exploitation. L'invention concerne également un terminal et un système comprenant le terminal

Description

1 Arrière-plan de l'invention L'invention se rapporte au domaine général de la communication sécurisée, et en particulier entre un terminal et un dispositif distinct du terminal. Un terminal embarque généralement un système d'exploitation non sécurisé, dit « Rich OS », au sein duquel s'exécutent des applications. Des dispositifs distincts du terminal peuvent entrer en communication avec ce terminal. Par distinct, on entend tout type de dispositif séparé du terminal, et notamment les dispositifs qui peuvent être raccordés au terminal de manière réversible. A titre indicatif, ces dispositifs peuvent être des éléments sécurisés prenant la forme d'une carte micro SD (« Micro Secure Digital Card » en langue anglaise), d'une carte à microcircuit avec ou sans contact, ou encore d'un passeport électronique. A titre indicatif également, un terminal peut être un téléphone portable ou encore une tablette. Une application utilisant une communication entre un terminal et un dispositif est la vérification d'identité. Dans ces applications, on peut utiliser des clés ou des certificats stockés au sein des dispositifs. La communication de données entre un système d'exploitation non sécurisé, dit « Rich OS », et un dispositif distinct n'est actuellement pas suffisamment sécurisée. L'invention vise notamment à pallier cet inconvénient.

Objet et résumé de l'invention La présente invention répond à ce besoin en proposant un procédé de communication sécurisée entre un système d'exploitation d'un terminal et un dispositif distinct du terminal, le terminal comportant en outre un environnement d'exécution de confiance, le procédé comporte, préalablement à la communication sécurisée, une authentification dudit dispositif par ledit environnement d'exécution de confiance initiée par ledit système d'exploitation.

3032846 2 Ainsi, c'est en utilisant l'environnement d'exécution de confiance, qui embarque des fonctions d'authentification, que l'on sécurise de manière simple la communication entre le terminal et le dispositif.

5 Un environnement d'exécution de confiance est une portion sécurisée d'un terminal, qui peut être implémentée par le processeur principal d'un terminal de manière distincte du système d'exploitation non securisé. Cet environnement d'exécution de confiance permet de stocker des données secrètes et sécurisées telles que des clés ou des certificats.

10 Le standard Global Platform décrit de tels environnements d'exécution de confiance. A titre indicatif, un environnement d'exécution de confiance peut au moins mettre en oeuvre des fonctions cryptographiques telles que définies par le standard Global Platform. En particulier, le procédé comporte une authentification mutuelle du 15 dispositif et de l'environnement d'exécution de confiance, comprenant ladite authentification dudit dispositif par ledit environnement d'exécution de confiance et une authentification de l'environnement d'exécution de confiance par ledit dispositif. Une authentification mutuelle est une authentification dans 20 laquelle l'environnement d'exécution de confiance authentifie le dispositif, et le dispositif authentifie l'environnement d'exécution de confiance. On peut noter que pour la mise en oeuvre de l'authentification mutuelle, le dispositif peut mettre en oeuvre au moins ces fonctions cryptographiques selon le standard Global Platform. Ceci peut être réalisé 25 au moyen d'une application (« applet ») chargée sur une plateforme JAVA. En particulier, ladite authentification mutuelle comporte un échange à travers ledit système d'exploitation de cryptogrammes entre ledit dispositif et ledit environnement d'exécution de confiance, 30 l'authentification étant obtenue sur la base d'une vérification par ledit dispositif et d'une vérification par ledit environnement d'exécution de confiance dans lesquelles le dispositif et l'environnement d'exécution de confiance vérifient que les deux cryptogrammes sont identiques. Dans ce mode particulier de réalisation, un secret est généré dans 35 le dispositif et l'environnement sécurisé. Ceux ci génèrent chacun un cryptogramme calculé à partir de données et du secret commun. Ces 3032846 3 cryptogrammes sont échangés entre le dispositif et l'environnement sécurisé de confiance et vérifiés. Ceci permet d'obtenir de manière simple l'authentification mutuelle. En particulier, l'élaboration de chacun des cryptogrammes est 5 mise en oeuvre sur la base d'une donnée fournie par ledit environnement d'exécution de confiance, d'une donnée fournie par ledit dispositif, et d'une clé de chiffrement élaborée à la fois par ledit dispositif et par ledit environnement d'exécution de confiance. Ces données peuvent être des données aléatoires élaborées lors 10 de l'initialisation du procédé. Le dispositif élabore lui-même cette donnée aléatoire, et l'environnement d'exécution de confiance élabore également lui-même cette donnée aléatoire, ces données sont échangées préalablement à l'élaboration des cryptogrammes. On peut noter qu'en utilisant des cryptogrammes, on peut vérifier 15 que la même clé de chiffrement a été utilisée et donc en déduire l'authentification mutuelle du dispositif et de l'environnement d'exécution de confiance. En particulier, ladite clé de chiffrement est élaborée par ledit dispositif sur la base d'une clé dérivée propre audit dispositif, et ladite clé 20 de chiffrement est élaborée par ledit environnement d'exécution de confiance sur la base d'une clé dérivée obtenue à partir d'une clé maître et de données supplémentaires dudit dispositif. Dans ce mode particulier de réalisation, la clé dérivée peut être une clé KENC obtenue à partir d'une clé maître et stockée dans le 25 dispositif et la clé de chiffrement peut être une clé S-ENC qui est une clé de session, en d'autres termes elle est élaborée à chaque mise en oeuvre du procédé. A cet effet, on peut utiliser les données fournies respectivement par le dispositif et par ledit environnement d'exécution de confiance pour l'élaboration de la clé de chiffrement. Les clés KENC et S- 30 ENC sont définies par le standard Global Platform. Au sein de l'environnement d'exécution de confiance, on dérive une clé maître stockée préalablement dans cet environnement d'exécution de confiance. Cette dérivation est mise en oeuvre à partir des données supplémentaires fournies par le dispositif, ces données pouvant être les 35 données de diversification DIV définies par le standard Global Platform et qui comprennent notamment des numéros de séries, des numéros de lot, 3032846 4 des données de fabrication, des identifiants d'applications. La clé dérivée obtenue est la clé KENC, et l'élaboration de la clé de chiffrement peut alors se faire de manière analogue à l'élaboration de cette clé au sein du dispositif.

5 En particulier, lequel ladite communication sécurisée utilise au moins ladite clé de chiffrement. On peut noter que cette clé de chiffrement est élaborée à chaque fois que le système d'exploitation souhaite mettre en oeuvre une communication sécurisée.

10 En particulier, ladite communication sécurisée comporte en outre une communication d'un code pour authentifier ladite communication de données, l'élaboration du code utilisant une clé d'élaboration de code obtenue préalablement au sein dudit dispositif et dudit environnement 15 d'exécution de confiance. Ce code peut être un code connu par l'homme du métier sous l'acronyme anglo-saxon MAC (« Message Authentication Code »). Ce code 20 permet notamment de garantir l'intégrité des échanges. En particulier, ladite communication sécurisée comporte une communication de données personnelles d'un utilisateur. Notamment, lesdites données personnelles sont obtenues au moyen d'une 25 interface utilisateur de confiance exécutée par ledit environnement d'exécution de confiance. Un environnement d'exécution de confiance embarque une interface utilisateur de confiance permettant notamment de saisir des codes de type numéro d'identification personnel ou encore de récupérer 30 des données biométriques de manière sécurisée. En particulier, ladite authentification ou l'authentification mutuelle est mise en oeuvre sur requête d'une application exécutée par ledit système d'exploitation.

3032846 5 Notamment ladite application communique avec ledit environnement d'exécution de confiance au moyen d'une couche transport. La couche transport définit une couche de communication entre le 5 système d'exploitation non sécurisé (ou une application fonctionnant sur ce système d'exploitation) et un environnement d'exécution de confiance, c'est-à-dire avec un élément sécurisé qui est dans le terminal. Cette couche est notamment définie par la norme OMAPI (Open Mobile API) 10 En particulier, le dispositif est un élément sécurisé. L'invention propose également un terminal embarquant un système d'exploitation et un environnement d'exécution de confiance, l'environnement d'exécution de confiance comporte un module 15 d'authentification d'un dispositif distinct du terminal sur requête du système d'exploitation. L'invention propose également un système comprenant ce terminal et un dispositif distinct du terminal, dans lequel le dispositif 20 comporte un module d'authentification de l'environnement d'exécution de confiance du terminal sur requête du système d'exploitation. Le terminal et le dispositif de ce système peuvent comporter des modules pour mettre en oeuvre tous les modes de réalisations particuliers 25 du procédé tel que défini ci-avant. L'invention propose également un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de communication sécurisé entre un terminal et un dispositif distinct du terminal tel que décrit ci dessus, lorsque ledit programme est exécuté par 30 un processeur du terminal. L'invention propose également un support d'enregistrement lisible par un processeur, sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de 35 communication sécurisé entre un terminal et un dispositif distinct du terminal tel que décrit ci-dessus.

3032846 6 Brève description des dessins 5 D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple dépourvu de tout caractère limitatif. Sur les figures : - la figure 1 représente de façon schématique un système comprenant un 10 terminal et un dispositif selon un mode de réalisation de l'invention, - la figure 2 illustre schématiquement des étapes d'un procédé selon un mode de mise en oeuvre de l'invention, - la figure 3 illustre de manière plus détaillée des étapes d'un procédé selon un mode de mise en oeuvre de l'invention.

15 Description détaillée d'un mode de réalisation On va maintenant décrire un système et un procédé de 20 communication sécurisé, dans lesquels une authentification mutuelle d'un dispositif et d'un environnement d'exécution de confiance est mise en oeuvre. On peut noter qu'il n'est pas obligatoire de mettre en oeuvre une authentification mutuelle, et qu'il est possible d'obtenir une 25 authentification en utilisant un environnement d'exécution de confiance authentifiant un dispositif distinct du terminal embarquant l'environnement d'exécution de confiance. Sur la figure 1, on a représenté un système comportant un terminal 1, par exemple un téléphone ou une tablette, et un dispositif 2, 30 par exemple un élément sécurisé sous la forme d'une carte micro SD ou d'une carte à microcircuit. Le terminal 1 et le dispositif 2 peuvent interagir lorsque le dispositif 2 est raccordé dans le terminal 1, ou encore en approchant le dispositif 2 du téléphone s'il est possible de mettre en oeuvre une 35 communication en champ proche.

3032846 7 L'invention vise à sécuriser les communications entre le dispositif 2 et le terminal 1, en particulier lorsque des informations personnelles d'un utilisateur transitent entre les deux éléments. En effet, on peut utiliser un dispositif distinct du terminal pour mettre en oeuvre une authentification 5 d'un utilisateur, le dispositif comportant des certificats et des clés utilisables à ces fins. Le terminal 1 embarque un système d'exploitation 3, par exemple un système d'exploitation non sécurisé du type Android, et également un environnement d'exécution de confiance 4.

10 Lorsque le système d'exploitation requiert la mise en oeuvre d'une communication sécurisée avec le dispositif 2, le système d'exploitation 3 requiert l'utilisation à la fois du dispositif 2 et de l'environnement d'exécution de confiance 4. L'environnement d'exécution de confiance 4 comporte à cet effet 15 un module d'authentification 5 pour authentifier ledit dispositif sur requête du système d'exploitation 3, et le dispositif comporte un module d'authentification 6 pour authentifier ledit environnement d'exécution de confiance 4 dispositif sur requête du système d'exploitation 3. Dans l'exemple illustré sur la figure 1, c'est une application 7 20 exécutée par le système d'exploitation 3 qui initie la mise en oeuvre de l'authentification mutuelle. A titre indicatif, cette application peut être un navigateur de type « firefox », et elle peut requérir une authentification pour mettre en oeuvre une signature électronique ou sécurisée une connexion avec un serveur en ligne.

25 Dans les solutions selon l'art antérieur, les communications entre le dispositif 2 et l'application 7 ne sont pas sécurisées, et il est possible de récupérer des données personnelles en changeant l'interface utilisateur de l'application 7, ou encore en utilisant un enregistreur de frappe. Pour mettre en oeuvre des communications entre l'application 7 du 30 système d'exploitation 3 et l'environnement d'exécution de confiance 4, on utilise une couche 8 selon la norme OMAPI. La couche 8 permet également de mettre en oeuvre des communications entre l'application 7 et le dispositif 2. Bien que cela ne soit pas obligatoire, il est possible d'utiliser une 35 couche inter logiciel 9 (« middleware » en langue anglaise) entre l'application (7) et la couche transport.

3032 846 8 Enfin, l'environnement d'exécution de confiance comporte ici une interface utilisateur de confiance 10, qui peut permettre de récupérer des données personnelles saisies par un utilisateur (numéro d'identification personnel, données biométriques...).

5 Sur la figure 2, on a représenté de manière schématique différentes étapes d'un procédé selon un mode de mise en oeuvre de l'invention. L'exemple de la figure 2 peut être mis en oeuvre par le système décrit en référence à la figure 1. Par ailleurs, sur la figure 2, les étapes représentées à gauche sur 10 la figure sont mises en oeuvre au sein du dispositif, et les étapes représentées à droite sur la figure sont mises en oeuvre au sein de l'environnement d'exécution de confiance. Dans une première étape E01, une donnée aléatoire est élaborée par le dispositif. On peut noter que la génération de données aléatoires 15 fait partie des fonctions cryptographiques prévues par le standard Global Platform et qui sont implémentés dans les éléments sécurisés. L'étape E01 est mise en oeuvre après une requête initiale provenant du système d'exploitation et d'une de ses applications. Cette donnée aléatoire peut avoir une taille de l'ordre de 8 Octets.

20 De la même manière, une donnée aléatoire est élaborée par l'environnement d'exécution de confiance dans une étape E02. Cette donnée aléatoire peut également avoir une taille de l'ordre de 8 Octets. La donnée élaborée au cours de l'étape E02 est transmise au dispositif (flèche C1), pour que ce dernier mette en oeuvre une étape E03 25 d'élaboration d'une clé de chiffrement et d'élaboration d'un cryptogramme. L'élaboration de la clé de chiffrement peut être mise en oeuvre par le dispositif sur la base d'une clé dérivée propre au dispositif de type KENC, c'est-à-dire une clé ayant été dérivée d'une clé maître sur la base de données de dérivations.

30 Pour obtenir une clé de chiffrement (c'est-à-dire une clé de session pour le chiffrement), on peut utiliser les données aléatoires du dispositif et de l'environnement d'exécution de confiance pour créer des données de dérivation de clé de session en concaténant ces données aléatoires. On peut ensuite utiliser la clé KENC et ces données de 35 dérivation de clé de session pour créer une clé SENC (la clé de chiffrement) en suivant la méthode bien connue de l'homme du métier 3032846 9 sous l'acronyme anglo-saxon AES (« Advanced Encryption Standard) utilisant une constante ayant pour valeur 0182. La clé S-ENC peut avoir une taille de 16 octets ou encore de 32 octets. On peut noter qu'une autre clé peut être obtenue de manière 5 analogue lors de l'étape E03, en particulier une clé pour l'élaboration de codes d'authentification de messages (clé S-MAC). A cet effet, on utilise une clé dérivée KMAC et une constante ayant pour valeur 0101. L'élaboration du cryptogramme est mise en oeuvre en concaténant les données aléatoires du dispositif et de l'environnement d'exécution de 10 confiance, puis en utilisant la clé de chiffrement notée S-ENC sur les données concaténées. De manière quasi-analogue, au cours d'une étape E04, l'environnement d'exécution de confiance élabore une clé de chiffrement et un cryptogramme.

15 Ici, l'élaboration de la clé de chiffrement comporte en outre l'élaboration de la clé dérivée KENC. Aussi, la clé dérivée KMAC est élaborée. Pour élaborer la clé de chiffrement et un cryptogramme, la donnée aléatoire du dispositif, et des données supplémentaires de type 20 données de diversifications sont transmises à l'environnement d'exécution de confiance (flèche C2). Ensuite, dans une étape E05, l'environnement d'exécution de confiance compare le cryptogramme qu'il a élaboré au cryptogramme élaboré par le dispositif qui lui a été transmis (flèche C3).

25 De la même manière, le dispositif peut comparer le cryptogramme de l'environnement d'exécution de confiance qui lui a été transmis (flèche C4) avec le cryptogramme qu'il a élaboré (étape E06). Si les deux comparaisons indiquent que les cryptogrammes sont identiques, alors on obtient une authentification mutuelle et l'on peut 30 mettre en oeuvre une communication sécurisée utilisant les clés élaborées aux étapes E03 et E04. Sur la figure 3, on a représenté de manière plus détaillée différentes étapes du procédé de la figure 2. De la même manière, ce procédé peut être mis en oeuvre par le système décrit en référence à la 35 figure 1.

3032846 10 Sur cette figure, on a représenté par quatre colonnes les éléments ou couches au sein desquelles les étapes sont mises en oeuvre. En allant de la gauche vers la droite, on a représenté : - L'application exécutée par le système d'exploitation non sécurisé, - La couche selon la norme OMAPI, - L'environnement d'exécution de confiance, et - Le dispositif. La succession des étapes est représentée sur cette figure par des flèches se suivant dans un ordre allant de haut en bas sur la figure.

10 L'application émet tout d'abord une requête pour mettre en oeuvre une communication sécurisée, en ouvrant une session OMAPI, et la couche OMAPI ouvre une session (étape E11) de communication avec le dispositif qui reçoit la requête (étape E12). La confirmation de cette ouverture est renvoyée à la couche OMAPI puis à l'application. On peut 15 ainsi communiquer avec le dispositif. On peut noter que dans ce qui suit, les messages échangés par l'OMAPI, l'environnement d'exécution de confiance, et le dispositif, sont des messages de type APDU (« Application Protocol Data Unit ») selon la norme ISO 7816.

20 Ensuite, une donnée aléatoire est élaborée (étape E13) par l'environnement d'exécution de confiance, cette étape est analogue à l'étape E02 décrite en se référant à la figure 2. La couche OMAPI émet ensuite une requête comportant la donnée aléatoire élaborée à l'étape E13 vers le dispositif, dans une étape E14.

25 Dans une étape E15, on élabore une donnée aléatoire, une clé de chiffrement et un cryptogramme, cette étape est analogue aux étapes E01 et E03 de la figure 2. La donnée aléatoire et le cryptogramme sont retransmis à l'application qui les fournit à l'environnement d'exécution de confiance.

30 Dans une étape E16, l'environnement d'exécution de confiance élabore une clé de chiffrement (en utilisant la donnée aléatoire du dispositif), et un cryptogramme. L'étape E16 est analogue à l'étape E04 de la figure 2. L'étape suivante E17 est mise en oeuvre par l'environnement d'exécution de confiance et elle comporte la comparaison des deux 35 cryptogrammes par l'environnement d'exécution de confiance.

3032846 11 Un message comprenant le cryptogramme élaboré par l'environnement d'exécution de confiance est ensuite transmis si le résultat de la comparaison indique que les cryptogrammes sont identiques.

5 Ce message est retransmis vers le dispositif par la couche OMAPI (étape E18), et dans une étape E19 le dispositif compare le cryptogramme reçu avec le cryptogramme qu'il a élaboré. Si le résultat indique que les cryptogrammes sont identiques alors on peut mettre en oeuvre une communication sécurisée.

10 Cela est indiqué à l'environnement d'exécution de confiance qui, en utilisant son interface utilisateur de confiance, récupère des données personnelles de l'utilisateur (par exemple un numéro d'identification personnel ou des données biométriques) dans une étape E20. Ces données personnelles sont ensuite chiffrées au moyen de la 15 clé de chiffrement élaborée lors de l'étape E16, dans une étape E21. Ce chiffrement peut être mis en oeuvre en utilisant la clé de chiffrement et la méthode AES. En outre, on peut élaborer un code pour authentifier la transmission des données personnelles de type message MAC, en utilisant 20 une clé élaborée (de type SMAC) également lors de l'étape E16. On peut transmettre le message élaboré à l'étape E21 au dispositif, lequel comporte la clé de chiffrement ainsi que la clé pour élaborer des messages codés. Dans une étape E22, le dispositif vérifie l'intégrité du message 25 reçu, et peut comparer les données personnelles avec des données personnelles mémorisées dans le dispositif. Si le résultat de l'étape E22 est positif, l'utilisateur est authentifié. Après cette étape, il est possible de mettre fin à communication sécurisée entre l'application et le dispositif. Une requête d'arrêt de la 30 session sécurisée peut être élaborée dans une étape E23, et le dispositif peut recevoir cette requête dans une étape E24. L'utilisateur ayant été authentifié, il est possible de mettre en oeuvre d'autres fonctions utilisant le dispositif. Notamment, après l'authentification, l'utilisateur peut utiliser les clefs contenues dans le 35 dispositif.

3032846 12 Cette étape est mise à titre d'exemple. Dans ce cas, l'application envoie à la carte un champ de données en clair. La carte effectue une signature sur les données réçues. Enfin, dans une étape E27, l'application peut requérir à la couche 5 OMAPI la fin de la session OMAPI. Dans l'exemple, la communication utilisée est une communication par contact mais on peut également envisager de passer par une communication sans contact tel que NFC (« Near Field Communication »), Bluetooth... 10

Claims (16)

1. REVENDICATIONS1. Procédé de communication sécurisée entre un système d'exploitation (3) d'un terminal (1) et un dispositif (2) distinct du terminal, le terminal comportant en outre un environnement d'exécution de confiance, caractérisé en ce qu'il comporte, préalablement à la communication sécurisée, une authentification dudit dispositif par ledit environnement d'exécution de confiance initiée par ledit système d'exploitation.
2. 2. Procédé selon la revendication 1, comportant une authentification mutuelle du dispositif et de l'environnement d'exécution de confiance, comprenant ladite authentification dudit dispositif par ledit environnement d'exécution de confiance et une authentification de l'environnement d'exécution de confiance par ledit dispositif.
3. 3. Procédé selon la revendication 2, dans lequel ladite authentification mutuelle comporte un échange à travers ledit système d'exploitation de cryptogrammes entre ledit dispositif et ledit environnement d'exécution de confiance, l'authentification étant obtenue sur la base d'une vérification (E06) par ledit dispositif et d'une vérification (E05) par ledit environnement d'exécution de confiance dans lesquelles le dispositif et l'environnement d'exécution de confiance vérifient que les deux cryptogrammes sont identiques.
4. 4. Procédé selon la revendication 3, dans lequel l'élaboration de chacun des cryptogrammes est mise en oeuvre sur la base d'une donnée fournie par ledit environnement d'exécution de confiance, d'une donnée fournie par ledit dispositif, et d'une clé de chiffrement élaborée (E03, E04) à la fois par ledit dispositif et par ledit environnement d'exécution de confiance.
5. 5. Procédé selon la revendication 4, dans lequel ladite clé de chiffrement est élaborée (E03) par ledit dispositif sur la base d'une clé dérivée propre audit dispositif, et ladite clé de chiffrement est élaborée (E04) par ledit environnement d'exécution de confiance sur la base d'une clé dérivée obtenue à partir d'une clé maître et de données supplémentaires dudit dispositif. 3032 846 14
6. 6. Procédé selon l'une quelconque des revendications 4 ou 5, dans lequel ladite communication sécurisée (E21) utilise au moins ladite clé de chiffrement.
7. 7. Procédé selon l'une quelconque des revendications 1 à 6, dans 5 lequel ladite communication sécurisée (E21) comporte en outre une communication d'un code pour authentifier ladite communication de données, l'élaboration du code utilisant une clé d'élaboration de code obtenue préalablement au sein dudit dispositif et dudit environnement d'exécution de confiance. 10
8. 8. Procédé selon l'une des revendications 6 ou 7, dans lequel ladite communication sécurisée (E21) comporte une communication de données personnelles d'un utilisateur.
9. 9. Procédé selon la revendication 8, dans lequel lesdites données personnelles sont obtenues au moyen d'une interface utilisateur de 15 confiance exécutée par ledit environnement d'exécution de confiance.
10. 10. Procédé selon l'une des revendications 1 à 9, dans lequel ladite authentification ou l'authentification mutuelle est mise en oeuvre sur requête d'une application exécutée par ledit système d'exploitation.
11. 11. Procédé selon la revendication 10, dans lequel ladite 20 application communique avec ledit environnement d'exécution de confiance au moyen d'une couche transport.
12. 12. Procédé selon l'une quelconque des revendications 1 à 11, dans lequel le dispositif est un élément sécurisé.
13. 13. Terminal embarquant un système d'exploitation (3) et un 25 environnement d'exécution de confiance (4), caractérisé en ce que l'environnement d'exécution de confiance comporte un module (5) d'authentification d'un dispositif (2) distinct du terminal sur requête du système d'exploitation.
14. 14. Système comprenant un terminal (1) selon la revendication 13 30 et un dispositif (2) distinct du terminal, dans lequel le dispositif comporte un module (6) d'authentification de l'environnement d'exécution de confiance du terminal sur requête du système d'exploitation.
15. 15. Programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de communication sécurisé entre un 35 terminal et un dispositif distinct du terminal selon l'une quelconque des 3032846 15 revendications 1 à 12, lorsque ledit programme est exécuté par un processeur du terminal.
16. 16. Support d'enregistrement lisible par un processeur, sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes d'un procédé de communication sécurisé entre un terminal et un dispositif distinct du terminal selon l'une quelconque des revendications 1 à 12.