Brevet FR3037686A1 — publié le 20161223

La présente invention concerne l'exécution sécurisée d'application dans un terminal mobile de communication pour par exemple utiliser le terminal mobile comme un moyen d'authentification à des fins notamment d'accomplissement d'une opération de paiement, d'accès à un lieu ou bien encore de preuve de l'identité du propriétaire du mobile. ETAT DE LA TECHNIQUE Il est connu d'utiliser des terminaux mobiles de télécommunication, comme des téléphones mobiles, pour ef- fectuer des opérations sensibles nécessitant une authentification, telles que des opérations de paiement. Dans de telles opérations, le téléphone mobile joue le rôle d'une carte de paiement ou de crédit et échange des don- nées avec le terminal de paiement des commerçants par une technologie sans fil de type communication par champ proche ou NEC (« Near Field Communication »). Le téléphone exécute une application de paiement mobile qui va assurer l'authentification de l'utilisateur comme le fait une carte de paiement ou de crédit classique. On comprend que la faisabilité de ces opérations repose sur la certitude que les données et les applications de paiement mobiles ne peuvent être altérées ou modifiées par un fraudeur. A cette fin, les données et ap- plications sensibles sont stockées, traitées ou exécutées par un élément sécurisé contenu dans le téléphone. Un élément sécurisé (sa désignation anglaise « secure element » étant plus couramment utilisée) est un circuit électronique agencé pour contenir de manière sé- curisée des applications et des données, exécuter les ap- plications, et assurer un transfert sécurisé des données. L'élément sécurisé comprend un processeur et des moyens de mémorisation qui sont agencés pour résister à des manipulations en vue d'accéder sans autorisation aux appli- cations et aux données. L'élément sécurisé est ainsi par 3037686 2 exemple une carte à circuit intégré amovible (comme une carte SIM ou une carte SD) ou un circuit dédié soudé sur une carte électronique du téléphone mobile (ou l'élément sécurisé est dit « embedded » selon l'appellation an- 5 glaise la plus courante). L'élément sécurisé peut égale- ment être obtenu de manière logicielle en définissant au sein du processeur du téléphone une zone sécurisée (chiffrée) accessible au moyen d'une clé de déchiffrement. Deux types d'entités doivent donc coopérer pour 10 garantir cette sécurisation : - le fournisseur (ou propriétaire) de l'élément sécurisé (couramment identifié par l'abréviation SEI de l'anglais « secure element issuer ») qui détient toutes les informations 15 techniques permettant d'intervenir sur l'élément sécurisé et en assure le bon fonctionnement, - les fournisseurs de service (couramment identifiés par l'abréviation SP de l'anglais « ser- 20 vice provider »), tels que des organismes ban- caires ou de crédit, qui fournissent les applications de paiement mobile et en assurent le bon fonctionnement, initie des requêtes de changement ou de mise à jour des applications, 25 et commande le blocage définitif ou la suspen- sion de leur utilisation. L'élément sécurisé peut contenir plusieurs applications de paiement mobile, ou autres applications, associées chacune à un fournisseur de service ou à un 30 compte de l'utilisateur auprès d'un fournisseur de service. Pour que le fonctionnement soit sûr pour tous les acteurs, il est important de garantir que le fournisseur de l'élément sécurisé ne peut accéder directement à 35 l'élément sécurisé et donc aux applications et données 3037686 3 des fournisseurs de service. De la même manière, il est important de garantir que les fournisseurs de service ne peuvent accéder directement à l'élément sécurisé et donc aux applications et données des autres fournisseurs de 5 service. A cette fin, le fournisseur de l'élément sécuri- sé interagit avec l'élément sécurisé via un premier serveur de confiance exécutant un premier programme gestionnaire et les fournisseurs de services interagissent avec l'élément sécurisé via un deuxième serveur de confiance 10 exécutant un deuxième programme gestionnaire. Les pro- grammes gestionnaires sont élaborés par des tiers de confiance et communiquent entre eux et, pour le premier, avec le fournisseur de l'élément sécurisé et, pour le deuxième, avec les fournisseurs de service. Le premier 15 programme gestionnaire est agencé pour assurer la gestion des accès et de l'allocation des espaces mémoires et droits vis-à-vis de l'élément sécurisé (on parle de l'allocation d'un domaine sécurisé au sein de l'élément sécurisé). Le deuxième programme gestionnaire gère 20 l'installation et le fonctionnement des applications dans les domaines sécurisés alloués par le premier programme gestionnaire. La sécurisation repose sur des procédés de chif- frement et des échanges de clés entre les applications et 25 les programmes gestionnaires. L'utilisateur peut disposer de plusieurs applications de paiement mobile dans son élément sécurisé. Il est prévu un programme d'appel des applications de paiement mobile (ce programme d'appel forme une interface 30 entre l'utilisateur et l'application de paiement mobile). Ce programme d'appel, par exemple celui proposé sous l'appellation GOOGLE WALLET par la société américaine GOOGLE, est exécuté par le processeur du téléphone, hors de l'élément sécurisé, et permet à l'utilisateur du télé- 35 phone de sélectionner l'application de paiement mobile à 3037686 4 utiliser pour le paiement. Le programme d'appel est autorisé à lancer l'exécution des applications de paiement mobile par l'élément sécurisé mais également à émettre vers les 5 fournisseurs de service des requêtes de demande d'installation de nouvelles applications de paiement mobile à la demande de l'utilisateur du téléphone. A la réception d'une telle requête, le fournis- seur de service, la banque dans le présent exemple, véri- 10 fie l'éligibilité de l'utilisateur à ce service, c'est-à- dire qu'elle détermine si l'utilisateur dispose des ressources financières suffisantes pour disposer d'une application de paiement mobile. Le cas échéant, la banque renvoie au deuxième programme gestionnaire un accord 15 d'éligibilité et les données nécessaires à la configura- tion de l'application de paiement mobile. Le deuxième programme gestionnaire envoie alors au premier programme gestionnaire une requête demandant le déploiement d'une application de paiement mobile dans 20 l'élément sécurisé. Le premier programme gestionnaire vé- rifie alors la compatibilité technique de l'application de paiement mobile avec l'élément sécurisé du téléphone en question. Le cas échéant, le premier programme gestionnaire envoie une confirmation de compatibilité au 25 deuxième programme gestionnaire qui renvoie une requête de création d'un domaine sécurisé dans l'élément sécurisé du téléphone en question. Une fois le domaine sécurisé créé, le premier programme gestionnaire en informe le deuxième programme gestionnaire et lui envoie une clé 3u d'accès audit domaine sécurisé. Ln parallèle de la créa- tion du domaine sécurisé, le programme d'installation de l'application de paiement mobile est préparé par le deuxième programme gestionnaire et envoyé au premier programme gestionnaire qui en vérifie le contenu technique. 35 Le programme d'installation de l'application de paiement 3037686 5 mobile est ensuite chargé, exécuté et personnalisé dans le domaine sécurisé de l'élément sécurisé. Une fois l'application de paiement mobile installée et configurée, le deuxième programme gestionnaire en informe la banque 5 et l'utilisateur peut exécuter, via le programme d'appel, l'application de paiement mobile nouvellement installée. L'ensemble des procédures de chargement, d'installation et de fonctionnement des applications sur les éléments sécurisés a été définie par une association 10 dénommée GLOBALPLATFORM regroupant des industriels du secteur. La mise en oeuvre de ces procédures demande de nombreux échanges de données successifs entre les différents acteurs impliqués, et l'élément sécurisé du télé- 15 phone. Il est ainsi formé une chaîne de transmission des données. Le programme d'appel n'intervient lui qu'au début du processus pour demander l'installation d'une application puis à la fin du processus pour lancer l'application. Comme tout échange de données entre les 20 programmes gestionnaires, le fournisseur de services et le fournisseur d'éléments sécurisés demande l'ouverture d'un canal privé de communication (également appelé canal VPN), la division et la multiplication des échanges engendrent une lourdeur importante ralentissant le déploie- 25 ment des applications de paiement mobile car il est né- cessaire que tous les acteurs de la chaîne soient dispo- nibles en même temps sans quoi les données sont bloquées, le canal privé de communication est fermé et devra être ultérieurement rouvert. Il en résulte que la mise en 30 oeuvre de l'ensemble du processus est longue et coûteuse, l'avancement du processus étant conditionné par l'acteur le plus lent. OBJET DE L'INVENTION Un but de l'invention est de proposer un procédé 35 d'installation d'application dans un élément sécurisé qui 3037686 6 soit plus simple et rapide tout en étant fiable et sécurisé. BREF EXPOSE DE L'INVENTION A cet effet, on prévoit, selon l'invention, un 5 procédé de déploiement d'une application dans un élément sécurisé d'un terminal de communication comportant une unité de traitement non sécurisé exécutant un programme d'appel des applications dans l'élément sécurisé. Le procédé comprend l'étape de transférer via au moins un ré- 10 seau de communication des données entre un premier ser- veur de confiance associé à un fournisseur de l'élément de sécurité pour exécuter un premier programme de gestion de l'élément sécurisé, un deuxième serveur de confiance associé à au moins un fournisseur d'applications 15 d'authentification pour exécuter un programme de gestion d'applications de l'élément sécurisé, et le terminal de communication, pour créer dans l'élément sécurisé un domaine sécurisé et y installer l'application. Le procédé comprend les étapes de : 20 - établir un premier échange de données entre le fournisseur d'application et le programme d'appel pour obtenir une autorisation d'installation de l'application, - établir un deuxième échange de données entre le premier programme de gestion et le programme d'appel pour 25 créer le domaine sécurisé dans l'élément sécurisé et transférer au programme d'appel une clé d'accès au domaine sécurisé, - établir un troisième échange de données entre le deuxième programme de gestion et le programme d'appel 30 pour transférer la clé d'accès au deuxième programme de gestion et interdire l'utilisation ultérieure de la clé d'accès par le programme d'appel pour accéder au domaine sécurisé, - faire télécharger et installer l'application 35 dans le domaine sécurisé par le deuxième programme de 3037686 7 gestion. Ainsi, le programme d'appel assure également la centralisation des flux de données entre les serveurs de confiance. L'ajout de cet intermédiaire fluidifie les 5 échanges de données car il est globalement plus dispo- nible que les serveurs de confiance de sorte qu'il est plus facile d'échanger des données entre chacun des serveurs de confiance d'une part et le programme d'appel d'autre part. En outre, seules deux sessions d'échanges 10 de données sont ouvertes entre le programme d'appel et les serveurs de confiance : une première session d'échange de données avec le premier programme de gestion, puis une deuxième session d'échange de données avec le deuxième programme de gestion. 15 D'autres caractéristiques et avantages de l'invention ressortiront à la lecture de la description qui suit d'un mode de mise en oeuvre particulier non limitatif de l'invention. BREVE DESCRIPTION DES FIGURES 20 Il sera fait référence à la figure unique annexée illustrant la mise en oeuvre du procédé de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION L'invention est décrite à titre d'exemple à une application de paiement mobile, c'est-à-dire que le télé- 25 phone mobile est utilisé comme une carte de paiement. En référence à la figure, le téléphone mobile utilisé pour la mise en oeuvre de l'invention, désigné en 1, est un téléphone GSM de type smartphone comprenant : - un circuit de traitement non sécurisé, symbo1i- 3u se en 2, comportant un processeur (le processeur princi- pal du téléphone) et des mémoires pour exécuter un programme d'exploitation (couramment appelé O.S.) et des applications diverses (téléphonie, connexion au réseau INTERNET, messagerie, gestion de fichiers, appareil pho- 35 tographique, géolocalisation, calendrier, radio, bloc- 3037686 8 notes, calculatrice, jeux...), - un élément sécurisé (SE) comportant des moyens de traitement (un processeur) et une mémoire qui ne sont utilisables qu'en disposant d'une clé. L'élément sécurisé 5 est susceptible de recevoir des messages courts (couram- ment appelés SMS) sans que ceux-ci ne passent par le circuit de traitement non sécurisé 2. L'élément sécurisé est ici un circuit soudé à la carte électronique du téléphone mobile 1. 10 La mémoire du circuit de traitement non sécurisé (l'expression « non sécurisé » est ici utilisée par opposition à l'élément sécurisé) contient un programme d'appel qui est exécuté par le processeur principal du téléphone et est agencé pour demander au processeur de 15 l'élément sécurisé d'exécuter des applications de paie- ment mobile qui sont, elles, contenues dans la mémoire de l'élément sécurisé. Le programme d'appel fournit à l'utilisateur la possibilité de choisir une des applications de paiement 20 mobile contenu dans l'élément sécurisé et de lancer cette application. Le programme d'appel détient à cette fin une clé qui lui permet d'appeler chacune des applications de paiement mobile qu'aura choisie l'utilisateur. L'appel des applications de paiement mobile est connu en lui-même 25 et ne sera pas détaillé ici. Conformément à l'invention, le programme d'appel est également agencé pour jouer un rôle centralisateur dans les échanges de données nécessaires à l'installation d'une application de paiement mobile dans l'élément sécu- 30 risé comme cela sera décrit dans la suite. Les applications de paiement mobile sont des ap- plications d'authentification connues en elles-mêmes et ne seront pas plus détaillées ici. Le téléphone mobile 1 comprend de manière clas- 35 sique des moyens de sa liaison à un réseau de communica- 3037686 9 tion sans fil, ici le réseau GSM symbolisé en 100. A ce réseau sont également reliés, un premier serveur de confiance 10 et un deuxième serveur de confiance 20. 5 Le premier serveur de confiance 10 est relié via le réseau INTERNET 200 à des serveurs 30 de fournisseurs ou de propriétaires des éléments sécurisés (un seul de ces serveurs est ici représenté). Le premier serveur de confiance 10 héberge et exécute un premier programme ges- 10 tionnaire d'éléments sécurisés. Ce programme est couram- ment appelé SEI-TSM (de l'anglais « Secure Element Issuer - Trusted Service Manager). Le deuxième serveur de confiance 20 est relié via le réseau INTERNET 200 à des serveurs 40 de fournisseurs 15 de service (comme des banques et des organismes de crédit - un seul de ces serveurs est ici représenté). Le deuxième serveur de confiance 20 héberge et exécute un deuxième programme gestionnaire d'applications de paiement mobile. Ce programme est couramment appelé SP-TSM (de 20 l'anglais « Service Provider - Trusted Service Manager). Le programme d'appel est relié au serveur 40 par une liaison GSM ou internet (au moins 3G) de sorte que le programme d'appel puisse recevoir un ordre de lancement émis par le serveur 40 (cette liaison 24 est symbolisée 25 en trait pointillé sur la figure). Le procédé de l'invention vise au déploiement d'une application d'authentification dans l'élément sécurisé SE du téléphone mobile 1. Ce procédé met en oeuvre lo transfert, via le ré- 30 seau de communication GSM 100, de données entre le pre- mier serveur de confiance 10, le deuxième serveur de confiance 20, et le téléphone 1 pour créer dans l'élément sécurisé SE un domaine sécurisé SD et y installer l'application d'authentification. 35 Le procédé selon l'invention comprend les étapes 3037686 10 de - établir un premier échange de données entre l'un des serveurs 40 et le programme d'appel pour trans- férer au programme d'appel une autorisation 5 d'installation de l'application, - établir un deuxième échange de données entre le premier programme gestionnaire SEI-TSM et le programme d'appel pour créer le domaine sécurisé SD dans l'élément sécurisé SE et transférer au programme d'appel une clé 10 d'accès au domaine sécurisé SD, - établir un troisième échange de données entre le deuxième programme gestionnaire SP-TSM et le programme d'appel pour transférer la clé d'accès au deuxième programme gestionnaire SP-TSM et 15 - interdire l'utilisation ultérieure de la clé d'accès par le programme d'appel pour accéder au domaine sécurisé SD, - faire télécharger et installer l'application dans le domaine sécurisé SD par le deuxième programme de 20 gestion SP-TSM. Lors du premier échange de données : - le programme d'appel émet, à la demande de l'utilisateur, une requête demandant l'installation de la nouvelle application de paiement mobile. La requête est 25 envoyée par le programme d'appel via la liaison 24 directement au serveur 40 du fournisseur de service concerné sous forme d'un message SMS (ceci va aussi permettre au programme d'appel de recevoir depuis le serveur 40 rtdentification du SEI-TSM à qui il va devoir ulté- 30 rieurement s'adresser lors du deuxième échange de données décrit plus loin) ; - le fournisseur de service vérifie que l'utilisateur remplit les conditions pour se voir attribuer l'application de paiement mobile (moyens financiers 35 suffisants par exemple) et envoie sa réponse au deuxième 3037686 11 programme gestionnaire SP-TSM. Si la réponse est favorable, elle est accompagnée de données de personnalisation de l'application de paiement mobile ; - le deuxième programme gestionnaire SP-TSM 5 transmet la réponse via le réseau GSM 100 au programme d'appel. Lors du deuxième échange de données : - le programme d'appel envoie une requête demandant la création du domaine sécurisé SD dans l'élément 10 sécurisé SE, la requête est envoyée par le programme d'appel au premier serveur 10 via le réseau GSM 100 et comprend un identifiant du téléphone mobile et un identifiant de l'application de paiement mobile à installer ; - le premier programme gestionnaire SEI-TSM véri- 15 fie la compatibilité technique de l'application de paie- ment mobile avec l'élément sécurisé SE du téléphone mobile 1. Le premier serveur 10 héberge une base de données mettant en relation des identifiants d'applications avec des caractéristiques techniques de celles-ci et une base 20 de données mettant en relation des identifiants de télé- phones mobiles avec des caractéristiques techniques de ceux-ci. En cas de besoin, le premier programme gestionnaire SEI-TSM transmet la requête au serveur 20 du fournisseur ou propriétaire de l'élément sécurisé concerné 25 via le réseau INTERNET 200 ; - si l'application est compatible avec l'élément sécurisé SE, le premier programme gestionnaire SEI-TSM envoie via le réseau GSM 100 un message court SMS directement à l'élément sécurisé SE pour y créer le domaine _30 sécurisé SD ; - une fois le domaine sécurisé SD créé, le premier programme gestionnaire SEI-TSM transmet au programme d'appel la clé d'accès au domaine sécurisé SD. La réponse est transmise via le réseau GSM 100. 35 Lors du troisième échange de données, le pro- 3037686 12 gramme d'appel transfère la clé d'accès au deuxième programme de gestion SP-TSM. Le deuxième programme gestionnaire SP-TSM prépare un programme d'installation de l'application et de sa 5 configuration avec les données de personnalisation. Parmi les données de personnalisation de l'application de paiement mobile, se trouvent par exemple un nom d'utilisateur, une date limite de validité, un plafond de paiement... 10 Le deuxième programme gestionnaire SP-TSM inter- dit l'utilisation de la clé d'accès par un autre que lui pour accéder au domaine sécurisé SD. L'interdiction d'utilisation résulte ici d'une modification de la clé par le deuxième programme de gestion SP-TSM dès réception 15 de la clé. Ainsi, à aucun moment le propriétaire de l'élément sécurisé n'a accès aux données sécurisées envoyées par le fournisseur d'accès et stockées dans l'élément sécurisé. Grâce à la clé d'accès, le deuxième programme 20 gestionnaire SP-TSM télécharge le programme d'installation dans le domaine sécurisé SD de l'élément sécurisé SE qui exécute le programme d'installation de sorte que l'application est installée dans le domaine sécurisé SD. 25 Rien entendu, l'invention n'est pas limitée aux modes de réalisation décrits mais englobe toute variante entrant dans le champ de l'invention telle que définie par les revendications. En parttculier, bien que l'invention ait été dé- 30 crise dans le cadre d'une application de paiement mobile, l'invention peut concerner également une application d'authentification en vue de déverrouiller une serrure, par exemple pour accéder à un lieu ou utiliser un véhicule. 35 L'élément sécurisé peut être un élément embarqué, 3037686 13 une carte mémoire sécurisée de type SMC, ou une carte mémoire de type UICC. L'élément sécurisé peut également être de type logiciel correspondant à l'environnement de l'association GLOBALPLATFORM nommé « Trusted Execution 5 Environment ». Avant d'être transférée au programme d'appel, la clé d'accès au domaine sécurisé peut être chiffrée par le premier programme de gestion avec une clé intermédiaire de chiffrement connue du deuxième programme de gestion. 10 Le deuxième programme de gestion n'est donc plus obligé de modifier la clé d'accès après le premier accès au domaine sécurisé. L'environnement de l'association GLOBALPLATFORM incorpore un tel processus de chiffrement. Dans ce cadre de changement de clé, l'invention 15 est également applicable à tout environnement similaire à celui mise en place par l'association GLOBALPLATFORM. L'invention est applicable avec un terminal de communication comme une tablette communicante ou un microordinateur ou tout autre objet connecté comportant un 20 élément sécurisé matériel ou logiciel. D'autres réseaux que ceux mentionnés peuvent être utilisés pour la mise en oeuvre de l'invention. On pourrait, de plus, mettre en place une possibilité de partager un secret entre le programme d'appel 25 et le serveur 40 pour que l'utilisateur soit bien reconnu (on évite de la sorte les tentatives de fraude consistant à subtiliser un premier code PAN d'une première carte SIM pour charger une deuxième carte avec un deuxième code PAN dérivé du premier code sur un téléphone portable). Ainsi, 30 est possible de mettre, dans ce premier échange de données, un secret entre le serveur et le mobile (modèle biométrique issu d'une photo du visage, des empreintes ou de l'iris, ou plus simplement un code d'accès partagé entre le service provider et l'utilisateur final). 35 Il faut noter que la demande d'éligibilité tech- 3037686 14 nique peut se faire par une connexion directe du téléphone mobile 1 vers le serveur 30 sans passer par le premier serveur de confiance 10. Par exemple, le téléphone mobile 1 demande directement à l'opérateur s'il est éli- 5 gible pour un type de création de domaine sécurisé qui lui aura été décrit dans l'acceptation de l'éligibilité bancaire. Cela permet de simplifier les flux car le SEITSM n'apporte aucune plus-value, les données utilisées demande d'éligibilité technique étant stockées par 10 l'opérateur lui-même. Le procédé peut comprendre l'étape, à la fin d'au moins un des échanges de données, de faire envoyer par le programme d'appel un message à un superviseur pour rendre compte du bon déroulement de l'échange de données en 15 question. Par exemple, après réception de la clé d'accès, un tel message peut être envoyé par le programme d'appel au serveur du propriétaire de l'élément sécurisé. L'autorisation d'installation peut être demandée directement par le programme d'appel ou via l'élément sé- 20 curisé. La facturation du service de mise à disposition d'un emplacement dans l'élément sécurisé peut se faire au moment de l'envoi de la clef d'accès. En effet à ce moment-là le premier serveur de confiance a terminé ses 25 travaux. On notera que le deuxième échange de données peut être utilisé pour créer au moins deux domaines sécurisés dans l'élément sécurisé. Le programme d'appel a pu demander consécutivement, à peu d'intervalle, l'installation 30 de deux applications de deux fournisseurs d'applications différents. On profite alors du canal communication privée établi entre le programme d'appel et le premier serveur de confiance pour demander la création des deux domaines sécurisés et l'envoi d'une ou deux clés d'accès au 35 programme d'appel qui renverra la ou les clés d'accès au REVENDICATIONS1. Procédé de déploiement d'une application dans un élément sécurisé d'un terminal de communication com- portant une unité de traitement non sécurisé exécutant un programme d'appel des applications de l'élément sécurisé ; le procédé comprenant l'étape de transférer via au moins un réseau de communication des données entre un premier serveur de confiance associé à un fournisseur de l'élément sécurisé pour exécuter un premier programme de gestion de l'élément de sécurité, un deuxième serveur de confiance associé à au moins un fournisseur d'applications pour exécuter un programme de gestion d'applications de l'élément sécurisé, et le terminal de communication, pour créer dans l'élément sécurisé un do- maine sécurisé et y installer l'application ; caractérisé en ce que le procédé comprend les étapes de : - établir un premier échange de données entre le fournisseur d'applications et le programme d'appel pour obtenir une autorisation d'installation d'application ; - établir un deuxième échange de données entre le premier programme de gestion et le programme d'appel pour créer le domaine sécurisé dans l'élément sécurisé et transférer au programme d'appel une clé d'accès au do- maine sécurisé, - établir un troisième échange de données entre le deuxième programme de gestion et le programme d'appel pour transférer la clé d'accès au deuxième programme de gestion et faire télécharger et installer l'application dans le domaine sécurisé par le deuxième programme de gestion, - interdire l'utilisation de la clé d'accès par un autre que le deuxième programme de gestion pour accéder au domaine sécurisé. 2. Procédé selon la revendication 1, dans lequel 3037686 17 l'interdiction d'utilisation résulte d'une modification de la clé par le deuxième programme de gestion après qu'il ait accédé une première fois au domaine sécurisé. 3. Procédé selon l'une quelconques des revendica- 5 tions précédentes, dans lequel l'interdiction d'utilisation de la clé est effectuée juste après que le deuxième programme gestionnaire soit entré en possession de celle-ci avant le téléchargement de l'application dans le domaine sécurisé. 10 4. Procédé selon l'une quelconques des revendica- tions précédentes, comprenant l'étape, à la fin d'au moins un des échanges de données, de faire envoyer par le programme d'appel un message à un superviseur pour rendre compte du bon déroulement de l'échange de données en 15 question. 5. Procédé selon l'une quelconques des revendications précédentes, dans lequel le deuxième échange de données est utilisé pour créer au moins deux domaines sécurisés dans l'élément sécurisé.