FR 2933559 A1 20100108 FR 0854428 A 20080701 Procédé d'installation d'une application de gestion et procédé de gestion de données d'applications d'un module de sécurité associé à un terminal mobile La présente invention se rapporte au domaine des télécommunications, et plus particulièrement à celui de l'intégration et de la gestion de services sur un élément sécurisé d'un terminal mobile. Les cartes à microprocesseur, notamment les cartes au format ISO 7816 contiennent un microprocesseur permettant l'enregistrement et l'exécution des programmes, appelés applications, aptes à être utilisés avec un lecteur de cartes. Ces programmes sont par exemple, des applications de paiement, de fidélité, de transport... Ces cartes sont soit à contact et introduites dans un lecteur de carte, soit elles sont dites "sans contact" et le dialogue entre le lecteur et la carte est alors un dialogue sans contact utilisant une technologie sans contact, par exemple une technologie NFC (pour "Near Field Contactless"). De plus en plus, ces applications sont téléchargées dans les modules de sécurité des terminaux mobiles. Le dialogue entre le lecteur et l'application est alors effectué via le terminal mobile. Ce module de sécurité peut être un module mémoire du terminal ou un support amovible (par exemple une carte à puce d'abonné) inséré dans le terminal. Cette configuration évite à l'utilisateur de détenir un grand nombre de cartes. De plus, ceci permet une gestion aisée à distance de ces applications, le ou les serveurs gestionnaires des applications pouvant accéder, au module de sécurité, via le terminal mobile et via un réseau de télécommunication. Les dialogues entre ces applications existantes et les équipements extérieurs (appelés "bornes" ou lecteurs) sont conformes aux spécifications ISO 7816. Par ailleurs, il existe des cartes sans contact qui ne contiennent pas de microprocesseur. Parmi celles-ci, les cartes sans contact les plus répandues actuellement dans le monde du transport sont des cartes basées sur une technologie Mifare Classic (marque déposée). Le dialogue entre une telle carte basée sur une technologie Mifare Classic et un équipement extérieur, par exemple une borne située 2933559 -2 à l'entrée d'un moyen de transport, est non compatible avec les standards ISO. Aussi, l'intégration de ces cartes dans un terminal mobile nécessite des adaptations. Certains constructeurs ont essayé d'intégrer une ou plusieurs cartes de type Mifare dans un téléphone portable. Le terminal modifié est apte à dialoguer avec un 5 lecteur de type Mifare et permet la lecture et l'écriture de données dans une zone mémoire du terminal suivant les spécifications Mifare. De plus, une application spécifique de type JavaCard, installée sur un module de sécurité du terminal, permet l'accès aux données enregistrées. L'utilisation de cette application nécessite de connaître des mots de passe associés aux données Mifare. 10 Ce système présente plusieurs inconvénients : D'une part, il nécessite de gérer plusieurs mots de passe en plus des clés intrinsèques à Mifare. En effet, dans ce système, un mot de passe est attribué à chaque secteur d'une carte Mifare, celle-ci comportant au minimum 16 secteurs. Ce système introduit une vulnérabilité supplémentaire car la seule 15 connaissance d'un mot de passe permet d'atteindre la zone ou secteur correspondant. D'autre part, la gestion de ces applications Java installées sur des téléphones portables n'est pas compatible avec la gestion des applications de type ISO. La gestion de l'installation, de la personnalisation, de l'activation, du blocage, de la suppression des programmes Java associées aux cartes Mifare nécessite le 20 développement de plates-formes spécifiques, les plates-formes existantes pour la gestion des applications au format ISO n'étant pas compatibles. Il existe donc un besoin d'intégrer ces cartes Mifare dans un environnement dans lequel elles puissent être gérées de façon sécuritaire sans nécessiter la connaissance de mots de passe spécifiques à ces cartes. 25 A cet effet la présente invention propose un procédé d'installation d'une application de gestion de données d'applications d'un premier type contenues dans un module de sécurité associé à un terminal mobile, ledit module de sécurité comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des 30 clés de gestion et accessible par un équipement extérieur de second type selon un - 3 protocole de second type caractérisé en ce que les données d'applications de premier type sont stockées dans une zone mémoire de premier type accessible par un équipement extérieur de premier type selon un protocole de premier type, et en ce que le procédé comporte : - une étape de réception, par le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée associée à au moins une partie de la zone mémoire de premier type, - une étape de création de la zone sécurisée par le module de gestion, - une étape d'installation dans la zone mémoire sécurisée d'une application de gestion 10 apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type. Ainsi, selon l'invention, l'accès à des données de premier type, par exemple des données de type Mifare, stockées sur un module de sécurité est effectué à partir d'un module de gestion sécurisé qui existe déjà et qui est apte à gérer des applications 15 de second type, par exemple au format ISO. Comme cette gestion est sécurisée par le biais des clés de gestion, il n'est pas nécessaire d'utiliser d'autres systèmes de sécurité, comme des mots de passe, pour accéder à la zone Mifare. Selon un mode de réalisation particulier, la commande de création est une commande prédéterminée lisible et interprétable par le module de gestion. Cette 20 commande comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant de la au moins une partie de la zone mémoire de premier type. Ainsi, la commande utilisée est la même quel que soit le protocole utilisé. Les paramètres de la commande permettent de déterminer si les données d'applications 25 qui seront gérées au moyen de la zone mémoire sécurisée sont de premier type ou de second type. Les paramètres déterminent ainsi le rôle de la zone mémoire sécurisée à créer. Ainsi, le procédé d'installation peut être effectué par un système de gestion de l'état de l'art. Il ne nécessite pas la mise en place d'un nouveau système de gestion. - 4 Selon une caractéristique particulière, l'étape d'installation comprend une mise à jour d'au moins un indicateur d'activation associé à la au moins une partie de la zone mémoire de premier type. Cet indicateur apporte une sécurité supplémentaire, en permettant de contrôler, 5 lors de la réception d'une demande d'accès à une partie de la zone mémoire, si cette partie de zone mémoire est accessible. Selon un mode de réalisation particulier, la zone mémoire de premier type est une zone de type Mifare comprenant un ou plusieurs secteurs et dans lequel la commande de création comprend au moins un identifiant de secteur. 10 Le procédé de l'invention permet de gérer les cartes de type Mifare insérées dans un module de sécurité d'un terminal mobile sans nécessiter la modification du système Mifare (bornes, protocole...) La présente invention propose également un procédé de gestion de données d'applications d'un premier type contenues dans un module de sécurité associé à un 15 terminal mobile, ledit module de sécurité comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type caractérisé en ce que des données d'applications de premier type sont stockées dans une zone 20 mémoire de premier type accessible par un équipement extérieur de premier type selon un protocole de premier type, en ce qu'une application de gestion est installée dans une zone mémoire sécurisée associée à au moins une partie de la zone mémoire de premier type, l'application de gestion étant apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type et en ce 25 que le procédé comporte : - une étape de réception, en provenance du terminal mobile, d'une commande d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type, - une étape de transmission d'une requête d'accès à des données d'applications de la 30 au moins une partie de la zone mémoire de premier type, - 5 - une étape de réception d'une réponse relative aux données d'applications, - une étape d'envoi au terminal mobile d'un message contenant ladite réponse. Ainsi, la gestion des données d'applications de premier type peut être effectuée au moyen d'un serveur de gestion apte à gérer des applications de second type et ne nécessite pas le développement de plates-formes spécifiques. Selon un mode de réalisation particulier, la commande d'accès reçue est chiffrée, et le procédé comporte en outre une étape de déchiffrement de ladite commande d'accès. Le chiffrement permet d'assurer la sécurité de l'accès. Selon une caractéristique de l'invention, la commande d'accès est consécutive à un accès à une partie de la zone mémoire de premier type, par un équipement extérieur de premier type, selon le protocole de premier type et le message envoyé est un message de commande d'affichage relatif audit accès sur un écran du terminal. Cette caractéristique permet d'informer l'utilisateur en temps réel des transactions effectuées. L'invention se rapporte également à un module de sécurité associé à un terminal mobile comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type caractérisé en ce qu'il comprend - une zone mémoire de premier type contenant des données d'applications de premier type et accessible par un équipement extérieur de premier type selon un protocole de premier type, û des moyens de réception, via le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée associée à au moins une partie de la zone mémoire de premier type, - des moyens de création de la zone mémoire sécurisée, 2933559 -6 - des moyens d'installation dans la zone mémoire sécurisée d'une application de gestion apte à accéder à des données de la au moins une partie de la zone mémoire de premier type. Le module de sécurité comporte en outre des moyens de réception, en 5 provenance du terminal mobile, d'une commande d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type, des moyens de transmission d'une requête d'accès auxdites données d'applications de la au moins une partie de la zone mémoire de premier type, des moyens de réception d'une réponse relative aux données d'applications et des moyens d'émission vers le 10 terminal mobile d'un message contenant ladite réponse. L'invention se rapporte aussi à un terminal de communication comportant un module de communication sans contact apte à communiquer avec un équipement extérieur de premier type selon un protocole de premier type, un module de communication apte à communiquer avec un réseau de télécommunication, et un 15 module de sécurité tel que décrit précédemment Selon un mode de réalisation, le module de communication sans contact est en outre apte à communiquer avec un équipement extérieur de second type selon un protocole de second type, par exemple un protocole ISO. L'invention concerne aussi un serveur de gestion apte à accéder, via un réseau 20 de télécommunication et via des clés de gestion, à des données d'applications d'un second type contenues dans des zones mémoires sécurisées gérées par un module de gestion d'un module de sécurité associé à un terminal mobile caractérisé en ce qu'il comporte des moyens d'émission d'une commande de création d'une zone mémoire sécurisée associée à au moins une partie d'une zone mémoire de premier type du 25 module de sécurité dans laquelle sont stockées des données d'applications d'un premier type, accessibles par un équipement extérieur de premier type selon un protocole de premier type. Le serveur de gestion est un serveur existant adapté pour être apte à transmettre des commandes de création modifiées. - 7 Ainsi, un serveur de gestion existant peut être adapté pour être apte à accéder et gérer des données d'application de premier type. L'invention se rapporte encore à un message de création pour l'installation d'une application de gestion de données d'applications d'un premier type contenues dans un module de sécurité associé à un terminal mobile, ledit module de sécurité comprenant un module de gestion de zones mémoires sécurisées aptes à recevoir des applications d'un second type accessibles par un réseau de télécommunication via des clés de gestion, et accessibles par u équipement extérieur de second type selon un protocole de second type, caractérisé en ce que les données d'applications de premier type sont stockées dans une zone mémoire de premier type accessible par un équipement extérieur de premier type selon un protocole de premier type, et en ce que le message comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant de la au moins une partie de la zone mémoire de premier type. L'invention se rapporte enfin à un produit programme d'ordinateur comprenant des instructions pour mettre en oeuvre les étapes du procédé d'installation telles que décrites précédemment et/ou du procédé de gestion telles que décrites précédemment lorsqu'il est chargé et exécuté par un processeur. D'autres particularités et avantages de la présente invention apparaitront dans la description suivante de modes de réalisation donnés à titre d'exemple non limitatif, en référence aux dessins annexés, dans lesquels : - la figure 1 est un schéma illustrant un système selon un mode de réalisation de l'invention, - la figure 2 est un organigramme illustrant les différentes étapes d'un procédé d'installation selon l'invention, - la figure 3 est un organigramme illustrant les différentes étapes d'un procédé de gestion suite à l'exécution d'un procédé d'installation selon l'invention, - la figure 4 est un schéma-bloc illustrant un module de sécurité selon un mode de réalisation de l'invention, - 8 - la figure 5 est un organigramme illustrant un mode de réalisation particulier du procédé d'installation, - la figure 6 est un schéma bloc illustrant une table de correspondance utilisée dans un procédé de gestion selon un mode de réalisation de l'invention, - la figure 7 est un organigramme illustrant un premier mode de réalisation particulier d'un procédé de gestion selon l'invention, - la figure 8 est un organigramme illustrant un deuxième mode de réalisation d'un procédé de gestion selon l'invention, - la figure 9 est un schéma bloc représentant un serveur de gestion apte à réaliser les étapes d'un procédé d'installation selon un mode de réalisation de l'invention, - la figure 10 est un schéma bloc représentant un serveur de gestion apte à réaliser les étapes d'un procédé de gestion selon un mode de réalisation de l'invention. Un mode de réalisation d'un procédé d'installation d'une application de gestion de données d'applications d'un premier type et d'un procédé de gestion de données de même type selon l'invention va maintenant être décrit en référence aux figures 1 à 3 En référence à la figure 1, un utilisateur dispose d'un terminal mobile 100 qui est, par exemple un téléphone mobile ou un PDA (pour "Personal Digital Assistant"). Ce terminal mobile possède un module de communication 130, par exemple un module GSM, permettant une communication, via un réseau de communication R, avec des serveurs distants, par exemple avec des serveurs de gestion (SP, SPO). Cette communication est par exemple une communication "OTA" (pour "Over The Air"), c'est-à-dire une communication sans fil classique. A titre d'alternative, le terminal mobile est relié au réseau R par une ligne téléphonique filaire. Le terminal mobile 100 comporte également un module de sécurité 120. Le module de sécurité 120 est par exemple un support amovible de type SIM ou UICC (pour "Universal Integrated Circuit Card"), une zone mémoire sécurisée du 2933559 -9 terminal mobile ou une carte à mémoire hébergeant un élément sécurisé (SD card, Embeded Secure controler ...)). Le terminal mobile 100 comporte également un module 140 de communication sans contact permettant l'échange de messages selon un protocole de dialogue de 5 premier type entre une borne BM de premier type, par exemple une borne de type Mifare Classic (marque déposée), et le module de sécurité 120 du terminal mobile. La borne BM est un équipement extérieur de premier type. A titre d'alternative, ce module 140 permet également le dialogue entre une borne B de second type et le module de sécurité 120 du terminal mobile selon le 10 protocole ISO qui est un protocole de dialogue de second type. La borne B est un équipement extérieur de second type. Le module de sécurité 120 peut comporter une ou plusieurs zones mémoire sécurisées (SD2) contenant des applications correspondant à des applications (AP2) d'un second type. Ces applications sont accessibles par la borne B en utilisant le 15 protocole ISO, qui correspond à un protocole de dialogue de second type. Elles sont également accessibles via le réseau R, par un serveur de gestion (SP) possédant des clés associées à la zone mémoire sécurisée qui les héberge. Le module de sécurité 120 comprend un module de gestion ISD de zones mémoires sécurisées. Ce module de gestion est apte à gérer l'installation des zones 20 mémoires sécurisées du module de sécurité 120. Le module de sécurité 120 comporte également un module ZM de stockage comprenant une zone mémoire MMF, qui est une zone mémoire de premier type, dans laquelle sont stockées des données d'applications d'un premier type. Un tel module de stockage ZM est apte à dialoguer avec la borne BM, selon un protocole de 25 dialogue de premier type. La borne BM de premier type émet périodiquement des messages à l'attention des terminaux mobiles. Lorsque le terminal mobile 100 entre dans le champ émis par la borne de premier type BM, le module sans contact 140 reçoit ce message et le transmet au module de sécurité 120 qui le transmet au module de stockage ZM pour traitement. 2933559 -10- Un mode de réalisation du procédé d'installation va maintenant être décrit en référence à la figure 2. Lors d'une première étape El, le module de sécurité 120 reçoit via le réseau R 5 et le module de communication 130 du terminal mobile 100, une commande de création CREAT d'une zone mémoire sécurisée SD1 associée à une zone Z de la zone mémoire MMF. La zone Z est une partie de la zone MMF. A titre d'alternative, la zone Z correspond à la zone MMF. Suite à la réception de cette commande, le module de gestion ISD du module 10 de sécurité procède à la création d'une zone mémoire sécurisée SD1 associée à la zone Z, lors d'une étape E2. Une zone mémoire sécurisée, telle que SD1, est une zone mémoire protégée en lecture et en écriture par des clés partagées avec un serveur distant tel que par exemple le serveur SP. 15 L'étape E2 est suivie d'une étape E3 lors de laquelle le module de sécurité 120 installe une application de gestion PGC dans la zone mémoire sécurisée SD1. Cette application PGC est apte à accéder aux données contenues dans la zone Z. Ainsi, la création de la zone mémoire sécurisée SD 1 permettant la gestion des données de la zone Z qui est une zone mémoire de premier type, est effectuée par un 20 module existant du module de sécurité apte à créer des zones mémoire sécurisées permettant la gestion de données d'applications de second type. En référence à la figure 3, un mode de réalisation du procédé de gestion selon l'invention va maintenant être présenté. 25 Ce procédé de gestion est mis en oeuvre suite à l'installation d'une application de gestion selon par exemple un procédé d'installation tel que décrit précédemment. Lors d'une étape E10, le module de sécurité 120 reçoit une commande d'accès CA à la zone Z. Cette commande d'accès est, par exemple, une commande d'écriture d'une ou plusieurs données de la zone Z. 30 A titre d'alternative, la commande d'accès est une commande de lecture. 2933559 -11- Dans un mode de réalisation, cette commande est transmise au module de sécurité par le serveur distant SP, via le module 130 du terminal mobile. Cette commande contient alors un identifiant de la zone Z. Ce mode de réalisation est décrit dans la suite de la description en référence à la figure 7. 5 Dans un autre mode de réalisation, la commande est déclenchée par la réception d'un évènement, par exemple la réception d'un évènement de fin de transaction transmis par le module sans contact 140 du terminal mobile au module de sécurité. Ce mode de réalisation est décrit dans la suite de la description en référence à la figure 8. 10 Suite à la réception de cette commande, le module de sécurité 120 construit une requête d'accès REQ à partir de la commande CA reçue et transmet cette requête REQ au module de stockage ZM, lors d'une étape E20. Cette requête d'accès est par exemple un ordre d'écriture ou de lecture de données dans la zone Z. Le module de sécurité 120 reçoit en retour une réponse REP, lors d'une étape 15 E30. La réponse à un ordre d'écriture est par exemple un message d'acquittement. La réponse à un ordre de lecture contient par exemple tout ou partie des données de la zone Z. L'étape E30 est suivie d'une étape E40 lors de laquelle le module de sécurité 120 transmet au terminal mobile 100, un message MSG contenant la réponse 20 transmise par le module de stockage ZM lors de l'étape 30. Un mode de réalisation particulier du procédé d'installation et du procédé de gestion dans lequel le module MMF est un module comportant des données de type Mifare Classic (marque déposée) va maintenant être décrit en référence aux figures 4 25 à 8. Dans ce mode de réalisation, le module de sécurité 120 est une carte à mémoire amovible compatible avec les spécifications de GlobalPlatform (GlobalPlatform Card Specification - version 2.2 de mars 2006). En référence à la figure 4, selon un mode de réalisation particulier, le module 30 de sécurité 120 comprend notamment un microprocesseur 122, un module 2933559 - 12- d'émission-réception 124, une ou plusieurs mémoires 125 de type RAM et une ou plusieurs mémoires 126 de type ROM ou EEPROM dans laquelle sont enregistrés des programmes pouvant être exécutés par le microprocesseur 122. La mémoire 126 contient notamment un programme P qui est le programme 5 principal de la carte. Ce programme P est également appelé "OS" (pour "operating System"). Le module de sécurité 120 comprend également un module de gestion ISD de zones mémoires sécurisées. Dans ce mode de réalisation, le module de gestion ISD est un domaine de 10 sécurité conforme aux spécifications Global Platform. Un domaine de sécurité est une zone mémoire sécurisée, protégée en lecture et en écriture par des clés partagées avec un serveur de gestion. De façon classique, une clé partagée est soit une même clé connue de deux entités, soit une paire de clés associées. Un exemple de clés associées est un couple 15 de clés dont l'une est secrète et n'est connue que d'une seule entité et l'autre publique utilisée par l'autre entité. Le module de gestion ISD possède des clés partagées avec un serveur de gestion SPO du module de sécurité, par exemple le serveur d'un opérateur téléphonique. 20 Le module de sécurité 120 peut comporter une ou plusieurs zones mémoire sécurisées (non représentées) contenant des applications correspondant à des applications d'un second type et fonctionnant en utilisant le protocole ISO, qui correspond à un protocole de dialogue de second type. Le module de sécurité 120 comporte également un module de stockage ZM 25 contenant une zone de données MMF, un module MAF d'accès à cette zone de données MMF et deux modules d'interface Il et I2. La zone de données MMF comporte une ou plusieurs zones appelées "cartes Mifare Classic". La taille d'une carte est soit de 1 koctet (il s'agit alors d'une carte 1k), soit de 4 koctets (carte 4k). 2933559 - 13 - Une carte Mifare Classic comporte, de façon classique, une structure en secteurs et blocs. Une carte Mifare 1k comporte 16 secteurs de 4 blocs chacun. Une carte 4k comporte 32 secteurs de 4 blocs et 8 secteurs de 16 blocs. Le bloc 0 est un bloc contenant les informations du fabriquant. Les blocs 1 et 2 contiennent des 5 données d'applications. Le bloc 4 contient des clés et n'est pas accessible. A chaque secteur est associé un couple de clés KeyA, KeyB. Dans ce mode particulier de réalisation, la zone de données MMF contient 4 cartes Mifare distinctes : 1 carte Mifare 4k (Cl) et 3 cartes Mifare 1k (C2, C3, C4). A titre d'alternative, la zone MMF peut comporter un nombre de cartes Mifare 10 différent et une répartition entre les cartes 1k et les cartes 4k différente. Chaque bloc comporte 16 octets. Les données stockées dans un bloc sont protégées en lecture et en écriture par les clés du secteur dont elles font partie. Les données de la zone MMF sont donc identifiées par un numéro de carte, un numéro de secteur et un numéro de bloc. L'adressage dans la zone MMF est inconnu 15 des autres modules du module de sécurité et notamment du programme principal P du module de sécurité. La borne de premier type BM ne possède pas de moyens de sélection ou d'activation d'une carte. L'activation d'une carte est effectuée par le module de sécurité suite à une requête de l'utilisateur. Le numéro de la carte activée est 20 enregistré dans une mémoire CMF du module de sécurité. Le module MAF dispose également de cette information, soit par accès à cette mémoire CMF, soit par enregistrement de cette information dans une zone interne à ce module. Dans ce mode de réalisation, une carte est activée par défaut, par exemple, la carte permettant l'accès à un moyen de transport. L'utilisateur peut ensuite, à l'aide 25 d'un menu du terminal mobile sélectionner une autre carte, par exemple pour effectuer une opération de paiement. En alternative, cette opération peut être transparente pour l'opérateur. Par exemple, l'utilisateur sélectionne une application de paiement et cette opération de sélection va déclencher l'envoi de la requête de sélection d'une autre carte Mifare au 30 module de sécurité. 2933559 - 14- La borne de premier type BM émet périodiquement des messages à l'attention des terminaux mobiles. Lorsque le terminal mobile 100 entre dans le champ émis par la borne de premier type BM, le module sans contact 140 reçoit ce message et le transmet au programme principal P du module de sécurité, via le module 5 d'émission/réception 124. Le programme principal P détermine alors qu'il s'agit d'un message de type Mifare. Le message reçu est un message de lecture ou d'écriture dans un secteur d'une carte de type Mifare. Il contient une adresse (numéro de secteur et numéro de bloc) 10 ainsi que des données codées avec les clés du secteur. L'algorithme utilisé pour le codage est un algorithme secret, propriétaire et confidentiel de Mifare. Le programme P enregistre l'adresse du secteur (numéro de secteur et numéro de bloc) contenu dans le message dans une mémoire DER de la mémoire 126, puis transmet le message reçu au module d'accès MAF via l'interface Il. 15 Suite à la réception du message, le module d'accès MAF accède à la zone MMF pour déchiffrer ce message en utilisant les clés associées au secteur et réaliser l'opération de lecture ou d'écriture demandée. Il retransmet ensuite une réponse à la borne de premier type BM, via l'interface Il. Dans un mode de réalisation où le module d'accès MAF ne dispose pas 20 d'information concernant le numéro de la carte activée, il transmet l'information au secteur adressé de toutes les cartes et seule la carte pouvant déchiffrer le message lui répond. La zone de données MMF n'est pas directement accessible par le programme principal P du module de sécurité 120. 25 Comme il va être décrit par la suite, l'interface I2 permet un accès, interne au module de sécurité, aux données de la zone MMF. En référence à la figure 5, un mode de réalisation du procédé d'installation dans lequel le module MMF est un module comportant des données de type Mifare 30 (marque déposée) va maintenant être décrit. 2933559 - 15 - Ce procédé comporte des étapes El, E2 et E3 correspondant aux étapes El, E2 et E3 décrites précédemment. Lors d'une première étape E0, le serveur SPO, qui est par exemple le serveur de l'opérateur gérant le module de sécurité, transmet une commande de création 5 CREAT d'un domaine de sécurité SD1 associé aux secteurs 5 et 10 de la carte C2 de la zone MMF. Le domaine de sécurité SD1 constitue une zone mémoire sécurisée. Le serveur SPO est également apte à transmettre au module de sécurité des commandes de création de domaines de sécurité aptes à gérer des données d'applications de second type. 10 Ainsi, un seul serveur est utilisé pour la création de domaines de sécurité apte à gérer des données d'applications de premier type et pour la création de domaines de sécurité apte à gérer des données d'applications de second type. Cette commande de création CREAT est reçue par le module de sécurité 120 lors de l'étape El. 15 De façon classique, cette commande est transmise chiffrée avec des clés partagées entre le serveur SPO et le module de gestion ISD du module de sécurité 120, puis déchiffrée par le module de sécurité. L'utilisation de telles clés permet une gestion sécurisée. Cette commande ou message de création comporte au moins un paramètre 20 relatif au type des données d'applications et au moins un identifiant d'une partie de la zone mémoire de premier type. Cette commande de création est une commande "Install for Install" définie dans les spécifications Global Platform V2.2 dans laquelle le paramètre "Privilèges" indique que le domaine de sécurité SD 1 est appairé à une zone mémoire de type 25 Mifare, c'est-à-dire que le domaine de sécurité SD1 est apte à permettre la gestion d'un ou plusieurs secteurs de la zone MMF. Les données relatives à l'identification de la zone mémoire, c'est-à-dire le ou les numéros de cartes et de secteurs, sont transmises dans le champ "Install Parameters Field" de la commande "Install for Install". 2933559 -16- Les spécifications Global Platform définissent un champ "Privileges", pour la commande "Install for install", constitué de 3 octets, dont 7 bits sont réservés pour une utilisation future. Dans le mode de réalisation décrit ici, un bit parmi ces 7 bits est utilisé pour indiquer le type du domaine de sécurité. Ce bit est positionné à 1 pour 5 indiquer que le domaine de sécurité à créer est de type "Mifare". Il est positionné à 0 sinon. La commande CREAT de création est reçue, par le programme principal P, via le module d'émission/réception 124. Le programme P déchiffre cette commande de création en utilisant les clés du domaine de sécurité ISD, partagée avec l'opérateur et 10 procède, lors de l'étape E2, à la création du domaine de sécurité SD 1. L'étape E2 de création va maintenant être décrite plus en détail. Lors d'une première sous étape E102, le programme principal P vérifie, dans une table de correspondance T que les identifiants de secteurs contenus dans la commande de création reçue ne correspondent pas à des secteurs gérés par un autre 15 domaine de sécurité du module de sécurité. Comme illustré sur la figure 6, la table de correspondance T enregistrée dans une mémoire 126 du module de sécurité comporte, pour chaque secteur S de chaque carte C de la zone mémoire MMF, un champ CID contenant un identifiant AID d'un domaine de sécurité. Ce champ CID est vide lorsqu'aucun domaine de sécurité n'y est 20 associé. A titre d'alternative, le champ CID comporte une valeur prédéterminée, par exemple "0", lorsqu'aucun domaine de sécurité n'est associé. La vérification effectuée lors de la sous étape E102 consiste à vérifier que le champ CID correspondant aux secteurs contenus dans la commande CREAT de 25 création est vide. Si ce n'est pas le cas, le secteur est géré par un autre domaine de sécurité et le programme principal P renvoie au serveur SPO un message indiquant son refus de créer ce domaine de sécurité. A titre d'alternative, le module de sécurité ne répond pas à la commande de création. Le processus s'arrête. 2933559 - 17 - Cette vérification évite l'appairage d'un secteur avec plusieurs domaines de sécurité et permet de renforcer la sécurité. Si le champ CID lu est vide, le programme principal P réserve une zone mémoire dans la mémoire 126 (sous étape E104). Il enregistre ensuite dans la table 5 de correspondance T, un identifiant AID1 de ce domaine de sécurité SD1 en association avec le numéro de carte et de secteur associé (sous étape E106). Si la commande reçue contient plusieurs numéros de secteur, les étapes E102 à E106 sont exécutées pour chaque secteur. Ainsi, dans le mode de réalisation décrit, comme illustré sur la figure 6, 10 l'identifiant AID1 est stocké d'une part en association avec la carte C2 et le secteur 5 et, d'autre part en association avec la carte C2 et le secteur 10. Le programme principal P transmet ensuite au serveur SPO, lors d'une sous étape E108, un message d'acquittement ACQ. Suite à la réception de ce message d'acquittement, lors d'une sous étape E110, 15 le serveur SPO transmet au module de sécurité 220 les clés K associées à la zone SD1, en utilisant par exemple un ordre "PutKey" ou "Install[for Personnalisation]/StoreData" définis dans les spécifications GlobalPlatform. Ces clés sont également connues d'un serveur SP, apte à gérer le domaine de sécurité SD1. Le module de sécurité enregistre ces clés dans le domaine de sécurité SD1, lors 20 d'une sous étape E112. Le module de sécurité positionne ensuite le domaine de sécurité en position "activé" (sous étape E114). Ce passage à l'état "activé" correspond au passage à l'état "Personalized" décrit dans les spécifications Global PlatForm partie "Card Specifications" 25 Le passage à l'état "activé" du domaine de sécurité SD1 permet au serveur SP, qui partage ces clés avec le domaine de sécurité SD1, d'accéder au domaine de sécurité SD 1. Le module de sécurité, et plus particulièrement le module de gestion ISD, est ainsi apte à gérer des domaines de sécurité aptes à recevoir des applications de 30 premier type et aptes à recevoir des applications de second type. 2933559 - 18 - Lors de l'étape E3 suivante, le serveur SP commande l'installation d'une application de gestion PGC dans le domaine de sécurité SD1. Plus précisément, lors d'une première sous étape E302, le serveur SP commande le téléchargement d'une application de gestion PGC dans le domaine de 5 sécurité SD1. Cette application PGC est apte à accéder aux données contenues dans la partie de la zone MMF désignée dans la commande de création du domaine de sécurité SD1, c'est-à-dire aux secteurs 5 et 10 de la carte C2. Le téléchargement de l'application PGC s'effectue de façon classique et ne sera pas décrite ici. Cette opération est notamment décrite dans la norme Global Platform 10 V2.2. A titre d'alternative, le programme PCG a été téléchargé dans le module de sécurité lors d'une étape précédente et l'étape de téléchargement consiste à transférer ce programme dans la zone SD1. La sous étape E302 de téléchargement est suivie d'une sous étape E304 15 d'activation du programme PCG. Cette étape consiste à mettre à jour un registre permettant au programme principal du module de sécurité de savoir que le programme est activé. Dans le mode de réalisation décrit ici, le registre utilisé est le registre GPRegistry défini dans les spécifications Global Platform. La sous étape E304 est suivie d'une sous étape E305 d'activation des secteurs 20 associés au domaine de sécurité SD1. Pour cela, un champ est ajouté au registre GPRegistry. Ce champ contient autant de bits que de secteurs contenus dans la zone MMF. La sous étape E305 de validation consiste à positionner, par exemple à la valeur 1, le bit correspondant à chaque secteur associé au domaine de sécurité SD1. Un tel bit constitue un indicateur d'activation. 25 A titre d'alternative, la sous étape E305 n'est pas réalisée. Ainsi, le serveur de gestion SP est apte à installer une application d'un premier type dans un domaine de sécurité de premier type. Le serveur de gestion SP est par ailleurs apte à installer des applications de second type dans des domaines de sécurité de second type. Les serveurs de gestion existants peuvent être utilisés. Il n'est donc 2933559 -19- pas nécessaire de développer des serveurs spécifiques pour la gestion de données d'applications de premier type. Les étapes El, E2 et E3 sont réalisées par le microprocesseur 122 du module de sécurité 120. 5 En référence à la figure 7, un mode de réalisation d'un procédé de gestion dans lequel un serveur de gestion SP accède à des données du module mémoire MMF qui est un module comportant des données de type Mifare (marque déposée), va maintenant être décrit. 10 L'exécution des étapes suivantes est subordonné à l'exécution préalable des étapes EO à E3 du procédé d'installation décrit en référence à la figures 5. Lors d'une étape E400, le serveur SP établit un canal sécurisé avec le domaine de sécurité SD1 du module de sécurité 120. L'établissement d'un tel canal est décrit dans les spécifications Global Platform. 15 Suite à l'établissement d'un tel canal, le serveur SP et le programme PGC sont aptes à s'échanger des messages applicatifs spécifiques. Lors d'une étape E402, le serveur SP transmet au module de sécurité 120 un message applicatif spécifique qui est une commande d'accès CA à une partie de la zone MMF. Cette commande d'accès est, par exemple, un ordre d'écriture du secteur 20 S de la carte X. A titre d'alternative, la commande d'accès est un ordre de lecture. La commande d'accès CA est transmise chiffrée avec les clés du domaine de sécurité SD 1. L'utilisation d'un système de clés permet une gestion sécurisée et évite 25 l'utilisation d'autres systèmes de sécurité comme des mots de passe pour accéder aux données de la zone mémoire MMF. Cette commande d'accès est reçue par le module de sécurité 120 lors d'une étape E410. Plus précisément, elle est reçue par le module d'émission/réception qui la transmet au programme PGC du domaine SD1. 2933559 - 20 - Le programme PGC vérifie, lors d'une étape E412, dans la table de correspondance T qu'il est autorisé à accéder au secteur S de la carte C. Pour cela, il vérifie que l'AID stocké dans la table de correspondance T en correspondance avec le secteur S de la carte C est l'identifiant du domaine de sécurité SD1. 5 Si ce n'est pas le cas, le module de sécurité ne répond pas ou transmet un message d'erreur. Cette étape de vérification permet d'augmenter la sécurité du système en s'assurant que le serveur SP ne tente pas d'accéder à des secteurs pour lequel il n'est pas autorisé. 10 Si l'accès est autorisé, le programme PGC construit un ordre d'écriture du secteur demandé et le transmet à l'interface 12 du module de stockage ZM, lors d'une étape E414. Lors d'une étape E415, l'ordre d'écriture est intercepté par le programme principal P du module de sécurité qui vérifie, dans la table de correspondance T que 15 le programme PGC est autorisé à accéder au secteur S de la carte C. Pour cela, il vérifie que l'AID stocké dans la table de correspondance T en correspondance avec le secteur S de la carte X est l'identifiant du domaine de sécurité SD1. Si ce n'est pas le cas, le module de sécurité ne répond pas ou transmet un message d'erreur. 20 Cette étape de vérification permet d'augmenter la sécurité du système en s'assurant que le programme PGC ne tente pas d'accéder à des secteurs pour lequel il n'est pas autorisé. L'interface 12 reçoit l'ordre transmis lors de la sous étape E414 et transmet la demande au module d'accès MAF qui accède au secteur S de la carte C, inscrit la 25 nouvelle valeur dans ce secteur et renvoie un accusé de réception au programme PGC via l'interface I2 (étape E416). Cet accusé de réception est, par exemple, un ou plusieurs octets dont la valeur indique si l'écriture a eu lieu correctement ou non. Lors d'une étape E418 suivante, le programme PGC transmet un message contenant l'accusé de réception au serveur de gestion SP, via le module de 30 communication 130 du terminal mobile. 2933559 - 21 - Ainsi, la gestion des données d'au moins une partie de la zone mémoire MMF peut être effectuée par un serveur de gestion apte à gérer également des données d'applications de second type; la gestion de ces données d'applications de premier type ne nécessite donc pas le développement de plates-formes spécifiques. 5 En référence à la figure 8, un deuxième mode de réalisation d'un procédé de gestion dans lequel des données d'applications de premier type sont communiquées à l'utilisateur suite à une transaction effectuée avec une borne BM de premier type, va maintenant être décrit. Dans ce mode de réalisation, le module MMF est un module 10 comportant des données de type Mifare (marque déposée). L'exécution des étapes suivantes est subordonnée à l'exécution préalable des étapes EO à E3 du procédé d'installation décrit en référence à la figure 5. Lors d'une étape préalable E500, suite à l'entrée du terminal mobile dans le champ émis par la borne de premier type BM, une transaction a lieu entre la borne 15 BM et le module de stockage ZM du module de sécurité 220. Par exemple, la borne BM est installée dans un bus de ville et le bloc 2 du secteur 5 de la carte 2 du module ZM comprend une valeur qui correspond à un nombre de tickets de transport achetés par le propriétaire du terminal mobile. La transaction entre la borne BM et le module de sécurité permet la décrémentation de 1 de la valeur stockée dans le bloc 2 secteur 20 5 de la carte 2. Si la sous étape E305 d'activation a été réalisée lors de la phase d'installation du domaine de sécurité SD1 associé au secteur 5 de la carte 2, le programme principal P du module de sécurité vérifie, lors de la réception d'un message de la borne de premier type BM, si ce secteur est en mode activé (étape E501) et refuse 25 tout dialogue avec la borne BM si ce secteur n'est pas activé dans le registre GPRegistry. Ainsi, les secteurs Mifare ne sont visibles et/ou adressables par un lecteur sans contact externe qu'à partir du moment où un domaine de sécurité a été créé pour la gestion de ces secteurs et que ce domaine de sécurité est en mode "activé". 2933559 - 22 - Tout secteur Mifare qui n'est pas rattaché à un domaine de sécurité activé n'est pas visible et est donc inutilisable. Si la transaction a lieu, en fin de transaction, le module sans contact 140 du terminal mobile 100 envoie au programme principal P du module de sécurité 120 une 5 indication de fin de transaction, lors d'une étape E502. Le programme principal lit dans la mémoire CMF du module de sécurité la valeur correspondant à la carte activée et dans la mémoire DER du module de sécurité la valeur correspondant au secteur qui vient d'être accédé (étape E504). Lors de l'étape suivante E506, il recherche dans la table de correspondance T, 10 l'identifiant AID du domaine de sécurité associé. Le programme principal P réveille ensuite le programme PGC du domaine de sécurité SD1, par exemple en lui envoyant un évènement de fin de transaction (étape E510). Suite à la réception de cet évènement, le programme PGC du domaine de 15 sécurité SD 1 lit dans la mémoire CMF le numéro de carte, et dans la mémoire DER le numéro de secteur et de bloc pour lequel une transaction vient d'avoir lieu (étape E508) Puis lors d'une étape E512, il envoie un ordre de lecture d'un ou plusieurs blocs de ce secteur au module MAF via l'interface 12. Cet ordre de lecture est une requête 20 d'accès au module de stockage ZM. L'interface I2 reçoit cet ordre et transmet la demande au module d'accès MAF qui accède au secteur 5 de la carte 2 et renvoie, lors d'une étape E514, via l'interface 12 au programme PGC un message contenant le contenu du secteur lu. Lors de l'étape E516 suivante, le programme PGC construit un message MR 25 contenant ce contenu. Ce message est, par exemple, constitué d'un texte prédéterminé et du contenu du bloc lu; par exemple, le message est "Bus ù ville de ... - Il vous reste ... tickets". Le message construit est ensuite transmis, lors d'une étape E518, au terminal mobile qui l'affiche sur son écran. 2933559 -23- Ainsi, le programme PGC permet de communiquer à l'utilisateur des informations suite à une transaction réalisée entre une borne de type Mifare et un terminal mobile contenant une zone de données de type Mifare. 5 Dans les modes de réalisation décrits, la table T ainsi que les valeurs DER et CMF sont enregistrées dans une mémoire 126 du module de sécurité. A titre d'alternative, tout ou partie de ces valeurs sont enregistrées dans la zone de stockage ZM. Elles sont alors accessibles via l'interface I2 via une commande applicative spécifique. 10 Ainsi, les données de type Mifare Classic sont installées dans un environnement dans lequel elles sont gérées de façon sécuritaire sans nécessiter la connaissance de mots de passe. 15 Selon un mode de réalisation choisi et représenté à la figure 9, un serveur de gestion mettant en oeuvre un procédé d'installation selon l'invention est par exemple un micro-ordinateur 500 qui comporte de façon connue, notamment une unité de traitement 502 équipée d'un microprocesseur, une mémoire morte de type ROM ou EEPROM 503, une mémoire vive de type RAM 504 et une interface de 20 communication 505 avec un réseau de communication R. Le micro-ordinateur 500 peut comporter de manière classique et non exhaustive les éléments suivants: un clavier, un écran, un microphone, un haut-parleur, un lecteur de disque, un moyen de stockage... Ce serveur 500 comprend un module ME1 d'émission de données vers le 25 réseau R et un module MT1 de traitement. Le module MT1 de traitement est apte à préparer un message contenant une commande de création d'au moins une zone mémoire sécurisée associée à au moins une partie d'une première zone mémoire, contenant des données d'applications d'un premier type, ladite première zone étant accessible par un équipement extérieur de 30 premier type selon un protocole de premier type. 2933559 - 24 - Le module ME1 de transmission est apte à transmettre le message préparé. Le module MT1 est également apte à préparer une commande de téléchargement d'une application de gestion de données d'applications de premier type. 5 Le module ME1 est apte à transmettre la commande préparée. La mémoire morte 503 comporte des registres mémorisant un programme d'ordinateur PG1 comportant des instructions de programme adaptées à transmettre, via le réseau de télécommunication R, une commande de création d'une zone 10 mémoire sécurisée (SD1) associée à au moins une partie d'une zone mémoire de premier type. Lors de la mise sous tension, le programme PG1 stocké dans la mémoire morte 503 est transféré dans la mémoire vive qui contiendra alors un code exécutable ainsi que des registres pour mémoriser les variables nécessaires à la mise en oeuvre 15 d'une étape de transmission, via le réseau de télécommunication R, d'une commande de création d'une zone mémoire sécurisée (SD1) associée à au moins une partie d'une zone mémoire de premier type. De manière plus générale un moyen de stockage, lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, 20 mémorise un programme mettant en oeuvre une étape de transmission, via le réseau de télécommunication R, d'une commande de création d'une zone mémoire sécurisée (SD1) associée à au moins une partie d'une zone mémoire de premier type, selon l'invention. 25 Selon un mode de réalisation choisi et représenté à la figure 10, un serveur de gestion mettant en oeuvre un procédé de gestion selon l'invention est par exemple un ordinateur de type PC 600 qui comporte de façon connue, notamment une unité de traitement 602 équipée d'un microprocesseur, une mémoire morte de type ROM 603, une mémoire vive de type RAM 604. Le terminal 600 peut comporter de manière 30 classique et non exhaustive les éléments suivants: un clavier, un écran, un 2933559 -25- microphone, un haut-parleur, une interface de communication, un lecteur de disque, un moyen de stockage... Ce serveur comprend un module ME2 d'émission de données vers un réseau de communication R, un module MR2 de réception de données en provenance du 5 réseau de communication R et un module MT2 de traitement. Le module MT2 de traitement est apte à préparer un message contenant une commande d'accès à des données d'applications d'au moins une partie d'une première zone mémoire, contenant des données d'applications d'un premier type, ladite première zone étant accessible par un équipement extérieur de premier type, selon un 10 protocole de premier type. Le module ME2 de transmission est apte à transmettre le message préparé. Le module MR2 de réception est apte à recevoir un message contenant une réponse à ladite commande d'accès. La mémoire morte 603 comporte des registres mémorisant un programme 15 d'ordinateur PG2 comportant des instructions de programme adaptées à transmettre un message contenant une commande d'accès à au moins une partie de la zone mémoire de premier type et à recevoir une réponse à ladite commande d'accès. Lors de la mise sous tension, le programme PG2 stocké dans la mémoire morte 603 est transféré dans la mémoire vive qui contiendra alors le code exécutable 20 de l'invention ainsi que des registres pour mémoriser les variables nécessaires à la réalisation d'une étape de transmission d'un message contenant une commande d'accès à au moins une partie d'une zone de premier type et d'une étape de réception d'une réponse à ladite commande d'accès De manière plus générale un moyen de stockage, lisible par un ordinateur 25 ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, mémorise un programme mettant en oeuvre les étapes de transmission d'un message contenant une commande d'accès à au moins une partie d'une zone de premier type et de réception d'une réponse à ladite commande d'accès. 30 REVENDICATIONS1. Procédé d'installation d'une application de gestion de données d'applications d'un premier type contenues dans un module de sécurité (120) associé à un terminal mobile (200), ledit module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication (R) via des clés de gestion et accessibles par un équipement extérieur (B) de second type selon un protocole de second type, caractérisé en ce que les données d'applications de premier type sont stockées dans une zone mémoire (MMF) de premier type accessible par un équipement extérieur (BM) de premier type selon un protocole de premier type, et en ce que le procédé comporte : - une étape de réception (El), par le réseau de télécommunication, d'une commande de création d'une zone mémoire sécurisée (SD1) associée à au moins une partie de la zone mémoire de premier type, - une étape de création (E2) de la zone mémoire sécurisée (SD1) par le module de gestion (ISD), - une étape d'installation (E3) dans la zone mémoire sécurisée, d'une application de gestion (PGC) apte à accéder à des données d'applications de la au moins une partie de la zone mémoire de premier type. 2. Procédé d'installation selon la revendication 1 dans lequel la commande de création est une commande prédéterminée interprétable par le module de gestion, qui comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant de la au moins une partie de la zone mémoire de premier type. 2933559 - 27 - 3. Procédé d'installation selon la revendication 1 dans lequel l'étape d'installation comprend une mise à jour d'au moins un indicateur d'activation associé à la au moins une partie de la zone mémoire de premier type. 5 4. Procédé d'installation selon la revendication 1 dans lequel la zone mémoire de premier type est une zone de type Mifare comprenant une pluralité de secteurs et dans lequel la commande de création comporte au moins un identifiant de secteur. 5. Procédé de gestion de données d'applications d'un premier type contenues 10 dans un module de sécurité (120) associé à un terminal mobile (100), ledit module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication (R) via des clés de gestion et accessibles par un équipement extérieur (B) de second type selon un protocole de second type, 15 caractérisé en ce que les données d'applications de premier type sont stockées dans une zone mémoire (MMF) de premier type accessible, par un équipement extérieur (BM) de premier type, selon un protocole de premier type, en ce qu'une application de gestion (PGC) est installée dans une zone mémoire sécurisée (SD1) associée à au moins une partie de la zone mémoire de premier type, l'application de gestion (PGC) 20 étant apte à accéder à des données de la au moins une partie de la zone mémoire de premier type et en ce que le procédé comporte : - une étape de réception (ElO), en provenance du terminal mobile, d'une commande d'accès (CA) à des données d'applications de la au moins une partie de la zone mémoire de premier type, 25 - une étape de transmission (E20) d'une requête d'accès auxdites données d'application de la au moins une partie de la zone mémoire de premier type, - une étape de réception (E30) d'une réponse relative aux données d'application, - une étape d'envoi (E40) au terminal mobile d'un message contenant ladite réponse. 2933559 - 28 - 6. procédé de gestion selon la revendication 5 caractérisé en ce que la commande d'accès reçue est chiffrée, et en que le procédé comporte en outre une étape de déchiffrement de ladite commande. 5 7. procédé de gestion selon la revendication 5 dans lequel la commande d'accès est consécutive à un accès à une partie de la zone mémoire de premier type, par l'équipement extérieur de premier type, selon le protocole de premier type, et dans lequel le message envoyé est un message de commande d'affichage relatif audit accès sur un écran du terminal. 10 8. Module de sécurité (120) associé à un terminal mobile (100) comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications (AP2) d'un second type accessibles par un réseau de télécommunication (R) via des clés de gestion et accessibles par un équipement extérieur (B) de second 15 type selon un protocole de second type caractérisé en ce qu'il comprend - une zone mémoire (MMF) de premier type contenant des données d'applications de premier type et accessible par un équipement extérieur (BM) de premier type via un protocole de premier type, - des moyens de réception par le réseau de télécommunication, d'une commande de 20 création d'une zone mémoire sécurisée (SD1) associée à au moins une partie de la zone mémoire de premier type, - des moyens de création de la zone mémoire sécurisée, - des moyens d'installation dans la zone mémoire sécurisée d'une application de gestion (PGC) apte à accéder à des données d'application de la au moins une partie 25 de la zone de premier type. 9. Module de sécurité selon la revendication 8 caractérisé en ce qu'il comporte en outre : 2933559 - 29 - - des moyens de réception, en provenance du terminal mobile, d'une commande d'accès à des données d'applications de la au moins une partie de la zone mémoire de premier type, - des moyens de transmission d'une requête d'accès auxdites données d'applications 5 de la au moins une partie de la zone mémoire de premier type, - des moyens de réception d'une réponse relative aux données d'applications, - des moyens d'émission vers le terminal mobile d'un message contenant ladite réponse. 10 10. Terminal de communication (100) comportant un module de communication sans contact (140) apte à communiquer avec un équipement extérieur (BM) de premier type selon un protocole de premier type, un module de communication (130) apte à communiquer avec un réseau de télécommunication (R), et un module de sécurité (120) selon la revendication 8 ou 9. 15 11. Terminal selon la revendication 10 caractérisé en ce que le module de communication sans contact (140) est en outre apte à communiquer avec un équipement extérieur (B) de second type selon un protocole de second type. 20 12. Serveur de gestion (SPO) apte à accéder, via un réseau de télécommunication (R) et via des clés de gestion, à des applications (AP2) d'un second type contenues dans des zones mémoires sécurisées (SD2) gérées par un module de gestion (ISD) d'un module de sécurité (120) associé à un terminal mobile (100), caractérisé en ce qu'il comporte des moyens d'émission d'une commande de 25 création d'une zone mémoire sécurisée (SD1) associée à au moins une partie d'une zone mémoire (MMF) de premier type du module de sécurité dans laquelle sont stockées des données d'applications d'un premier type, accessibles par un équipement extérieur (BM) de premier type selon un protocole de premier type. 2933559 - 30 - 13. Message de création pour l'installation d'une application (PGC) de gestion de données d'applications d'un premier type contenues dans un module de sécurité associé à un terminal mobile, ledit module de sécurité comprenant un module de gestion (ISD) de zones mémoires sécurisées (SD2) aptes à recevoir des applications 5 (AP2) d'un second type accessibles par un réseau de télécommunication via des clés de gestion et accessibles par un équipement extérieur de second type selon un protocole de second type, caractérisé en ce que les données d'applications de premier type sont stockées dans une zone mémoire (MMF) de premier type accessible par un équipement extérieur de 10 premier type selon un protocole de premier type, et en ce que le message comporte au moins un paramètre relatif au type des données d'applications et au moins un identifiant de la au moins une partie de la zone mémoire de premier type. 14. Produit programme d'ordinateur comprenant des instructions pour mettre 15 en oeuvre les étapes du procédé d'installation selon l'une des revendications 1 à 4 et/ou du procédé de gestion selon l'une des revendications 5 à 7 lorsqu'il est chargé et exécuté par un processeur.