Brevet FR3037754A1 — publié le 20161223

Gestion sécurisée de jetons électroniques dans un téléphone mobile. Domaine technique L'invention se rapporte au domaine général de la dématérialisation des titres de propriété autrement connus sous le nom de « jetons électroniques », ou « tickets électroniques » et plus particulièrement au domaine d'application dans lequel un jeton électronique est destiné à être mémorisé dans un terminal mobile apte à restituer ledit jeton pour permettre à son utilisateur d'accéder à un bien ou plus généralement à un service. Elle trouve une application privilégiée, mais non limitative, dans les applications pour lesquelles le terminal mobile restitue le jeton électronique en utilisant une technique de communication par champ proche. Etat de la technique Les techniques de communication "en champ proche" se développent largement ; la plus utilisée de ces technologies pour la téléphonie mobile est celle connue sous l'acronyme de NFC (en anglais « Near Field Communication »). On rappelle que les communications « NFC », basées principalement sur la norme ISO (International Standard Organisation) 14443, utilisent des technologies sans fil pour permettre un échange d'informations entre deux périphériques éloignés d'une courte distance, typiquement inférieure à dix centimètres. Par « champ proche », on entend dans la suite principalement une technologie de type NFC, mais celle-ci peut être remplacée par une autre technologie de proximité de type RFID (technologie radio à courte distance d'après l'anglais Radio Frequency IDentecation), Zigbee (technologie radio sans fil de basse puissance basée sur la norme IEEE 802.15.4), Bluetooth, infra-rouge, etc. Il a déjà été démontré la faisabilité de services de dématérialisation de jetons, ou tickets électroniques, sur terminaux mobiles, au moyen de la technologie sans contact. Par la suite, on utilisera indifféremment les termes « jeton » ou « ticket » pour « jeton électronique » ou « ticket électronique ». On connait notamment des services de transport dans lesquels les usagers des transports publics utilisent une application dédiée de leur terminal mobile pour acheter des jetons électroniques et pour valider leur jeton à l'entrée du bus ou du tramway en approchant leur terminal mobile d'un dispositif de contrôle d'accès apte à communiquer avec le terminal mobile, ou plus exactement avec un élément de sécurité du terminal mobile, par des moyens de communication en champ proche, 3037754 2 pour obtenir le jeton électronique afin d'en vérifier la validité. Par la suite on appelle un tel usager un « utilisateur », on entend donc par là l'utilisateur du terminal mobile, qui est aussi le client du fournisseur de jetons. Par « élément de sécurité », on entend ici un élément de stockage et de 5 manipulation des données permettant de garantir à un utilisateur du terminal mobile une sécurité élevée puisque les données enregistrées dans l'élément de sécurité ne sont pas accessibles à un utilisateur non autorisé. Dans notre contexte, la mise en oeuvre d'un élément de sécurité permet au service concerné de s'assurer de la validité du jeton présenté à l'accès au service. Cet élément de sécurité peut par 10 exemple être constitué par une carte SIM (de l'anglais Subscriber Identity Module), utilisée en téléphonie mobile pour stocker les informations spécifiques à l'abonné d'un réseau mobile et des applications de l'utilisateur, de son opérateur ou dans certains cas de tierces parties. Cet élément de sécurité peut encore être un support amovible de type carte SD sécurisée ou un élément de sécurité intégré au terminal 15 ("Embedded Secure Element') ou encore un mode sécurisé du terminal, grâce à l'utilisation d'une technologie de sécurité intégrée dans le processeur et ses composants périphériques (par exemple la technologie « TrustZone », marque déposée de la société ARM). Dans le cas d'un terminal supportant des applications de type Android (on rappelle qu'une application Android est une application mobile 20 spécifiquement développée pour les terminaux mobiles utilisant le système d'exploitation Android développé par la société Google), des applications à champ proche peuvent également s'exécuter dans le terminal Android lui-même (à partir de la version 4.4. "KitKat"), grâce à la technologie "HCE" ("Host Card Emulation"). Par la suite, on utilisera indifféremment les termes « élément de sécurité » et « carte 25 SIM ». Par « dispositif de contrôle d'accès », on entend un dispositif physique comportant un module de lecture en champ proche, apte à prendre connaissance du contenu du jeton électronique et en vérifier la validité, en association avec un serveur de vérification (de la date de validité du jeton, etc.) et d'authentification (de 30 l'élément de sécurité associé à l'utilisateur du terminal mobile). Par la suite, on utilisera indifféremment les termes « dispositif de contrôle d'accès » et «lecteur ». Par « validation du jeton », on entendra l'ensemble des deux opérations, à savoir la vérification du jeton et l'authentification de l'élément de sécurité. On peut également citer, selon un autre exemple, l'expérimentation « M- 35 Stadium », à Caen, France, qui a montré l'intégration de la technologie sans contact tout au long du parcours d'un public dans un stade : acquisition et dématérialisation de jetons électroniques sur des terminaux mobiles, contrôle des jetons électroniques 3037754 et lecture d'étiquettes interactives dans le stade, etc. Les utilisateurs d'un tel système chargent préalablement un jeton au moyen d'une application mobile de leur terminal mobile équipé de la technologie sans contact. Les données ainsi chargées, relatives au jeton, sont mémorisées et gérées dans un élément de sécurité associé au terminal 5 mobile, en l'occurrence la carte SIM de l'utilisateur, puis contrôlées à l'entrée du stade au moyen d'un terminal de contrôle. Dans tous ces exemples, il est nécessaire que le serveur distant qui délivre les tickets possède la clé secrète de l'application sécurisée correspondante contenue 10 dans l'élément de sécurité associé au mobile. Par exemple, le « théâtre » auquel accède l'utilisateur (ainsi que le service qui a fourni les tickets de théâtre aux utilisateurs), doit connaître la clé secrète du service stockée dans l'élément de sécurité. Ceci présente une contrainte, puisque cela impose à tout nouveau service de disposer en propre d'une clé secrète dans l'élément de sécurité. 15 L'invention propose un système de contrôle d'accès à un service par l'utilisateur d'un terminal mobile équipé d'une fonction de communication en champ proche et d'un élément de sécurité, par validation d'un jeton électronique, qui ne présente pas de tels inconvénients. 20 L'invention Selon un premier aspect fonctionnel, l'invention a pour objet un procédé de gestion sécurisée d'un ticket électronique stocké dans un terminal mobile auquel est 25 associé un élément de sécurité, le ticket comportant une partie non secrète comportant l'identification d'un service et une partie secrète chiffrée par une première clé connue de l'élément de sécurité, comprenant au moins une seconde clé, le ticket étant prévu pour accéder au service via un dispositif de contrôle d'accès, le procédé étant caractérisé en ce qu'il comporte les étapes suivantes dans le terminal 30 mobile : transmission à l'élément de sécurité de la seconde clé chiffrée et d'au moins une donnée de vérification ; réception d'au moins une donnée de vérification chiffrée par l'élément de sécurité ; 35 transmission d'au moins une donnée de vérification chiffrée au dispositif de contrôle d'accès. 3037754 4 Avantageusement selon l'invention, il n'est pas nécessaire qu'une entité tierce possède la clé secrète de l'application sécurisée correspondante contenue dans l'élément de sécurité associé au mobile. En effet, l'élément de sécurité lui-même, par exemple une carte SIM, est capable de déchiffrer les données de vérification 5 correspondant à des données chiffrées par la première clé secrète et de rechiffrer les éléments qu'elle vient de déchiffrer à l'aide de la clé contenue dans la partie secrète du jeton. De cette manière, le serveur qui délivre les tickets, et qui connaît la clé du ticket, à défaut de connaître celle de l'élément de sécurité, est capable de savoir que 10 le ticket a été correctement déchiffré par le bon élément de sécurité. On évite donc avantageusement la nécessité de charger une application sécuritaire spécifique à chaque service et une clé propre au service dans l'élément de sécurité (application qui devrait gérer spécifiquement les tickets selon le service à rendre, i.e. une application pour le transport, une application pour le paiement, une 15 troisième pour les spectacles, etc.), tout en conservant les avantages de l'élément sécurisé, c'est à dire l'authentification forte par l'élément de sécurité qui déchiffre puis chiffre (ou rechiffre) les données sans stocker le ticket et sans avoir besoin d'en analyser les données. Il est de plus avantageux, conformément à cet aspect, de stocker les tickets 20 dans le terminal mobile et de les faire traiter quand nécessaire par l'élément de sécurité car les tickets peuvent être volumineux (en nombre d'octets) et occuper un espace mémoire important dans l'élément de sécurité. 25 Selon un premier mode de mise en oeuvre particulier de cet aspect, la partie secrète du ticket comporte au moins une donnée secrète distincte de la seconde clé et une donnée de vérification transmise à l'élément de sécurité comporte au moins cette donnée secrète. Avantageusement selon ce mode de réalisation, dit mode « sans aléa », une 30 donnée secrète contenue dans le ticket, quelconque, est utilisée comme donnée de vérification pour être déchiffrée (par la première clé) puis rechiffrée (par la seconde clé) par l'élément de sécurité, garantissant ainsi que l'on a à faire au bon élément de sécurité, ce qui permet de valider le ticket. 35 Selon un second mode de mise en oeuvre particulier de cet aspect, qui pourra être mis en oeuvre alternativement ou cumulativement avec le précédent, un procédé tel que décrit ci-dessus est caractérisé en ce qu'il inclut en outre une étape de 3037754 5 réception d'un aléa en provenance du dispositif de contrôle d'accès et en ce qu'une donnée de vérification transmise à l'élément de sécurité comporte au moins l'aléa. Avantageusement selon ce mode de réalisation, dit mode « avec aléa », le 5 nombre aléatoire, ou aléa, reçu du serveur (via le dispositif de contrôle d'accès) est chiffré par la carte SIM à l'aide de la seconde clé qu'elle vient de déchiffrer dans la partie secrète, en tant que donnée de vérification. Le serveur de vérification est donc capable, sur réception des données de vérification, de déchiffrer l'aléa qu'il a émis précédemment, et de constater qu'il a été chiffré par la bonne clé associée au bon 10 ticket. Dans ce cas, la transaction peut être validée. Le serveur de vérification possède de plus l'assurance que le procédé de déchiffrement / chiffrement n'a pas été fait en avance et capté par un mobile tiers. Comme décrit ci-dessus, ce mode de réalisation peut naturellement être associé au précédent, les données de vérification pouvant alors contenir une donnée 15 secrète et un aléa, mais cette association n'est pas nécessaire, la présence de l'un ou l'autre de ces éléments suffisant à la validation de l'opération. Selon un second aspect fonctionnel, l'invention a pour objet un procédé de vérification d'un ticket électronique stocké dans un terminal mobile auquel est 20 associé un élément de sécurité, le ticket comportant une partie non secrète comportant l'identification d'un service et une partie secrète chiffrée par une première clé connue de l'élément de sécurité, ladite partie secrète comprenant au moins une seconde clé, le ticket étant prévu pour accéder à un service via un dispositif de contrôle d'accès, le procédé étant caractérisé en ce qu'il comporte les 25 étapes suivantes dans l'élément de sécurité : réception en provenance du mobile de données comportant au moins : o la seconde clé de la partie secrète et o au moins une donnée de vérification ; déchiffrement de la partie secrète à l'aide de la première clé ; 30 chiffrement d'une donnée de vérification reçue à l'aide de la seconde clé déchiffrée ; - transmission d'une donnée de vérification chiffrée au mobile. Avantageusement selon cet aspect, il n'est pas nécessaire de stocker les tickets dans l'élément de sécurité qui se contente de déchiffrer à l'aide de la première 35 clé puis chiffrer à l'aide de la seconde clé les données de vérification qui lui sont transmises par le mobile. En effet, la carte SIM elle-même est capable de déchiffrer 3037754 6 la partie chiffrée par la première clé secrète et de chiffrer les éléments qu'elle vient de déchiffrer ou l'aléa à l'aide de la seconde clé contenue dans la partie secrète du jeton. L'élément de sécurité dans ce contexte peut être avantageusement dépourvu de tout moyen de communication avec l'extérieur, en particulier ne pas disposer par 5 lui-même de capacité de communication en champ proche. Selon un troisième aspect fonctionnel, l'invention a pour objet un procédé de génération d'un ticket électronique pour un terminal mobile auquel est associé un 10 élément de sécurité, le procédé comportant les étapes suivantes : génération d'une partie non secrète comportant l'identification d'un service ; génération d'une partie secrète comportant une seconde clé ; caractérisé en ce que la partie secrète est chiffrée par une première clé 15 connue de l'élément de sécurité. Avantageusement selon cet aspect, une seule clé de l'élément de sécurité peut être utilisée pour tous les services liés au générateur de tickets ; il peut donc y avoir plusieurs générateurs. L'émetteur de jetons (générateur de tickets) au contraire 20 ne connaît pas cette clé de l'élément de sécurité. Selon un mode de mise en oeuvre particulier de cet aspect, un procédé tel que décrit ci-dessus est caractérisé en outre en ce que la seconde clé est générée par les étapes suivantes : 25 obtention d'une clé-mère ; génération de la seconde clé à partir de la clé-mère et de la partie non secrète du jeton. Avantageusement selon ce mode de réalisation, des champs de la partie non secrète du jeton, par exemple la date du spectacle et une chaîne de caractères, 30 servent au serveur de vérification à obtenir la clé jeton par un procédé de dit de « diversification » basé sur la connaissance d'une clé mère contenue dans le serveur de vérification. Un tel procédé est bien connu de l'homme du métier dans le domaine de la fabrication des cartes à puces où la clé de fabrication de chaque carte est générée à partir d'une clé maîtresse (mère) et du numéro de série de la carte. 3037754 7 Le serveur de vérification est rendu plus simple dans la mesure où il n'a pas besoin d'une base de données de jetons et peut être inclus dans le dispositif de contrôle, en local, sans accès au réseau. 5 Selon un aspect matériel, l'invention concerne également un terminal mobile auquel est associé un élément de sécurité, apte à gérer un ticket, le ticket comportant une partie non secrète comportant l'identification d'un service et une partie secrète chiffrée par une première clé connue de l'élément de sécurité, ladite 10 partie secrète comprenant au moins une seconde clé, le ticket étant prévu pour accéder au service via un dispositif de contrôle d'accès, le terminal étant caractérisé en ce qu'il comporte les modules suivants : un module de transmission à l'élément de sécurité de la seconde clé chiffrée et d'au moins une donnée de vérification ; 15 un module de réception d'au moins une donnée de l'élément de sécurité ; un module de transmission d'au moins une donnée chiffrée au dispositif de contrôle d'accès. Le terme module peut correspondre aussi bien à un composant logiciel qu'à 20 un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions telles que décrites pour les modules concernés. De la même manière, un composant 25 matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en oeuvre une fonction ou un ensemble de fonctions pour le module concerné (circuit intégré, carte à puce, carte à mémoire, etc.). Selon un autre aspect matériel, l'invention concerne également un élément 30 de sécurité associé à un terminal mobile apte à mettre à disposition d'un dispositif de contrôle d'accès, via le terminal mobile, un ticket électronique stocké dans le terminal mobile, le ticket comportant une partie non secrète comportant l'identification d'un service et une partie secrète chiffrée par une première clé connue de l'élément de sécurité, ladite partie secrète comprenant au moins une seconde clé, caractérisé en 35 ce qu'il comporte les modules suivants : 3037754 8 un module de réception de données en provenance du mobile, comportant au moins : o la seconde clé de la partie secrète et o au moins une donnée de vérification ; 5 un module de déchiffrement des données reçues à l'aide de la première clé connue de l'élément de sécurité ; un module de chiffrement d'une donnée reçue à l'aide de la seconde clé déchiffrée ; un module de transmission d'une donnée de vérification chiffrée au 10 mobile. Selon un autre aspect matériel, l'invention concerne également une entité de génération de tickets apte à générer des tickets pour un terminal mobile auquel est associé un élément de sécurité, caractérisée en ce qu'elle comporte les 15 modules suivants : - un module de génération d'une partie non secrète comportant l'identification d'un service ; - un module de génération d'une partie secrète comportant une seconde clé ; 20 - un module de chiffrage de la partie secrète par une première clé connue de l'élément de sécurité. Selon un autre aspect matériel, l'invention concerne également un système pour fournir un service de tickets dématérialisés sécurisé à l'utilisateur d'un terminal 25 mobile, ce système comportant : - une entité de génération d'un ticket électronique selon la description précédente ; - un terminal mobile selon la description précédente; - un élément de sécurité associé au terminal mobile selon la description 30 précédente. Selon encore un autre aspect matériel, l'invention concerne également un programme d'ordinateur apte à être mis en oeuvre dans un dispositif mobile pour la mise en oeuvre du procédé de gestion sécurisée de tickets électroniques tel que 35 défini ci-dessus, le programme comprenant des instructions de code qui, lorsque le 3037754 9 programme est exécuté par un processeur, réalise les étapes du procédé de gestion sécurisée. Selon encore un autre aspect matériel, l'invention concerne également un programme d'ordinateur apte à être mis en oeuvre dans un dispositif pour la mise en oeuvre du procédé de vérification de tickets, lorsque celle-ci est exécutée par un processeur. Selon encore un autre aspect matériel, l'invention concerne également un 10 programme d'ordinateur apte à être mis en oeuvre dans un dispositif pour la mise en oeuvre du procédé de génération de tickets, lorsque celle-ci est exécutée par un processeur. Ces dispositifs et ces programmes d'ordinateur présentent des 15 caractéristiques et avantages analogues à ceux décrits précédemment en relation avec les procédés de gestion, vérification et génération d'un ticket électronique. Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un 20 programme comprenant des instructions de code de programme pour l'exécution des étapes de l'un des procédés définis ci-dessus. L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés. 25 Les figures: La figure 1 représente le contexte général d'un mode de réalisation de l'invention. La figure 2 représente une architecture d'un équipement mobile équipé d'un 30 module d'identité d'abonné et d'un module NFC, apte à mettre en oeuvre un mode de réalisation de l'invention. La figure 3 représente la structure possible d'un jeton électronique selon un mode de réalisation de l'invention. La figure 4 représente un organigramme illustrant les différentes étapes du 35 procédé selon un mode de réalisation de l'invention. 3037754 10 Description détaillée d'un exemple de réalisation illustrant l'invention La figure 1 correspond au contexte général d'un mode de réalisation de l'invention ; il s'agit de contrôler, par un dispositif de contrôle d'accès, ou lecteur (B), des jetons dématérialisés stockés sur le mobile (T) d'un utilisateur (1), avec une 5 authentification par l'élément de sécurité (C_SE) qui est dans cet exemple une carte SIM. Dans ce mode de réalisation de l'invention, le terminal mobile (T) dispose également d'un module NFC (3) permettant l'usage de communications sans contact entre le mobile et le lecteur (B). La capacité NFC du mobile est donc rendue, non pas par l'élément de sécurité (qui n'a pas de capacité de communication en champ 10 proche), mais par le mobile lui-même, équipé de capacités NFC (par exemple la technologie HCE sur le système Android). Le mobile peut contenir diverses applications dont une au moins pour la gestion des tickets, que l'on nommera APM (pour Application Mobile). La carte SIM contient au moins une application générique (APS) valable pour tous les services de gestion de tickets. On rappelle que les usages 15 visés par l'invention sont ceux pour lesquels l'utilisateur dispose d'un jeton ou ticket (4) grâce auquel il peut prouver être en possession d'un droit d'accès à un service avec une validité limitée à une date précise ou durant une durée définie (par exemple, un abonnement de transport pour le mois d'octobre 2014) ou pouvant être vérifié lors de l'accès au service (par exemple, un accès à un concert, une 20 compétition sportive, etc.). On considère, dans ce mode de réalisation, que l'application visée est une application de billetterie délivrant des jetons de concert. On suppose ici que l'utilisateur a acheté un jeton électronique de concert auprès d'un fournisseur de services, représenté ici par son serveur de génération et de vérification de jetons (7), situé dans l'exemple dans un réseau Internet (9) ; le jeton, 25 généré par le serveur de génération (7) est transmis au serveur (5), aussi appelé serveur de confiance, qui peut être par exemple un serveur de l'opérateur du réseau. Le jeton (4) est constitué : - d'une Partie Non Secrète (4a, PNS) comportant notamment l'identité du service, les informations publiques du jeton (nom du spectacle, date et 30 heure, etc.) et optionnellement le numéro du jeton dans ce service ; - d'une partie secrète (4b, 4c), comportant : o les données secrètes (4b, DS) du jeton, optionnelles selon ce mode de réalisation dit « avec aléa » (comme on le verra par la suite, elles ne peuvent être optionnelles dans d'autres modes de 35 réalisation) ; par exemple une donnée secrète peut renvoyer à des éléments techniques propres au serveur de jetons, 3037754 11 o une clé de sécurité propre au jeton (4c, K_TO) qui n'est pas optionnelle. On va maintenant, à l'appui de la figure 1, illustrer les différentes étapes de mise en oeuvre du service, depuis la génération du ticket jusqu'à sa validation au 5 niveau du dispositif de validation (lecteur). L'utilisateur commande selon cet exemple son jeton (4) sur le serveur du fournisseur de services (7), avec son terminal mobile (T), à travers une connexion de données du réseau mobile se prolongeant dans cet exemple vers Internet, et reçoit son jeton sur le mobile (T) sous forme de SMS (sigle anglais pour Short Message 10 Service) ou MMS (Multimedia Message Service). Alternativement, le jeton pourrait être transmis dans une réponse à une commande HTTP (de l'anglais Hyper Text Transport Protocol) faisant suite à la phase de commande du ticket suivant le même protocole. Selon encore une autre possibilité, l'utilisateur commande son jeton à l'aide d'un autre terminal (PC, tablette, etc.) et le reçoit sur son mobile sous forme 15 de SMS ou de MMS. Le réseau d'accès à Internet (Internet dans lequel se situe le serveur du fournisseur de services (7)) est ici un réseau mobile, mais d'autres types de réseaux d'accès seraient possibles, par exemple un réseau ADSL (commande du ticket sur un PC et livraison sur le mobile), un point d'accès Wifi (commande et réception du ticket 20 sur un terminal mobile ou une tablette), etc. Dans ce présent mode de réalisation, c'est le serveur de confiance (5) qui transmet au téléphone mobile de l'utilisateur (T) le jeton (4) dont il a chiffré au préalable la partie secrète (4b, 4c). Le chiffrage est effectué au moyen d'une clé de sécurité de l'élément de sécurité (SIM), notée K_SE (pour Key of Secure Element), 25 connue du serveur de confiance. Dans un autre mode de réalisation, le serveur de confiance (5) pourrait effectuer les opérations de chiffrement ci-dessus et rendre le résultat au serveur de génération (7) qui se chargerait lui-même de transmettre le ticket (sous forme de SMS, MMS, ou réponse HTTP suite à la phase d'achat du ticket sur mobile). 30 Un fois délivré sur le mobile, le jeton (4), dont la partie secrète (4b, 4c) est chiffrée (ce qui est illustré sur la figure 1 par le rectangle noir en haut du ticket), est stocké dans la mémoire du terminal (T) ; celui-ci peut vérifier qu'il a reçu un nouveau jeton grâce à une application mobile du terminal qui est apte à lire la partie non secrète du jeton (puisqu'elle n'a pas été chiffrée) et à l'afficher. Typiquement, 35 lorsque le terminal mobile reçoit le jeton, par exemple sous forme de SMS commençant par un identifiant donné, l'application mobile le détecte. Sur requête ou automatiquement, les jetons stockés sur le mobile apparaissent dans l'interface 3037754 12 graphique que l'application mobile de gestion des jetons propose à l'utilisateur, et sont utilisables si les conditions de validité sont remplies (date, etc.). Alternativement, les jetons peuvent être gérés par plusieurs applications sur le mobile (une pour le transport, une autre pour les spectacles, etc.). 5 Selon un exemple, chaque jeton affiché est sélectionnable par l'utilisateur, par exemple par une pression du doigt sur l'écran tactile du téléphone mobile, et une boite de dialogue peut lui demander une confirmation de la sélection du jeton. On notera que les jetons électroniques dématérialisés ne sont pas stockés dans l'élément de sécurité mais sur le terminal mobile. Comme on le verra par la 10 suite, lors de l'accès de l'utilisateur au service, l'élément de sécurité sert uniquement à assurer la confidentialité de la partie secrète du jeton et l'authentification de l'utilisateur (en déchiffrant le sous-ensemble chiffré du jeton, puis en chiffrant certaines données, dites données de validation avec la clé du jeton et en authentifiant dans le même temps l'utilisateur). 15 L'élément de sécurité (C_SE), ici une carte SIM, contient une application sécuritaire, aussi appelée applet, qui est installée sur les cartes SIM des utilisateurs de terminaux mobiles désirant avoir accès aux différents services de jetons 20 dématérialisés. Il s'agit d'une application unique pour tous les services et tous les jetons. On l'appelle par la suite "Applet", ou "APplication Sécuritaire", ou encore "APS". Elle peut accéder à la clé secrète (K_SE) localisée dans la mémoire de la carte SIM, ce qui permet à la carte SIM, lors de l'accès de l'utilisateur au service, d'assurer la confidentialité de la partie secrète du jeton et d'assurer l'authentification de 25 l'utilisateur, par le procédé qui va être décrit plus loin. Ultérieurement, lorsque l'utilisateur approche du dispositif de contrôle d'accès son mobile contenant le ticket (T), une communication NFC s'établit entre le lecteur et le module NFC (3) du terminal mobile de l'utilisateur. 30 Dans ce premier mode de réalisation « avec aléa », le lecteur (B) dialogue par ailleurs avec le serveur (7) de vérification des jetons (qui est selon cet exemple le même que celui qui a généré le ticket, mais pourrait être indépendant) et lui demande un aléa. Cet aléa est typiquement un nombre aléatoire choisi par le serveur (7) de vérification des jetons, ce qui permet qu'un tiers mal intentionné qui serait à 35 l'écoute ne puisse aucunement deviner un aléa futur sur la base de l'observation des aléas passés. La borne transmet au mobile cet aléa et l'identité du service. 3037754 13 Dans une première variante, l'application mobile de gestion (APM) récupère le jeton dans une liste de jetons grâce à sa partie non secrète (4a), sélectionne le jeton (4) et le transmet à l'applet de la carte SIM avec l'aléa. Dans une seconde variante, seule la partie chiffrée (Partie Secrète PS) du 5 jeton est transmise à la carte SIM avec l'aléa. La carte SIM déchiffre les données secrètes (4b, DS) si elles existent et la clé du jeton (4c, K_TO) avec la clé secrète (K_SE) et chiffre les données secrètes (si elles existent) et l'aléa à l'aide de la clé jeton (K_TO) qu'elle vient de déchiffrer ; elle transmet ensuite le résultat de l'opération au mobile (T). Le mobile adjoint ensuite la partie publique du jeton au 10 résultat reçu depuis la carte SIM avant de transmettre le tout au serveur de vérification via le lecteur. On comprendra que selon ce mode de réalisation de l'invention, les données secrètes (DS, 4b) du ticket sont optionnelles car l'aléa constitue à lui seul une donnée de vérification qui peut être valablement chiffrée par la carte SIM. En 15 l'absence d'aléa, en revanche, selon un autre mode de réalisation, il faut au moins une donnée secrète sur laquelle appliquer le chiffrage par la clé jeton (K_TO). Cette clé-jeton ne peut en effet de manière satisfaisante se chiffrer elle-même. La suite des étapes étant quasi identique pour la première (transfert du ticket 20 complet à l'élément de sécurité avec l'aléa) et la seconde variante (transfert de l'aléa et de la partie secrète comprenant optionnellement des données secrètes et obligatoirement la clé du jeton) de ce mode de réalisation avec aléa, seule la première variante est décrite ci-après. Le second mode de réalisation ne sera pas décrit explicitement, mais il suffit 25 sans perte de généralité de remplacer le chiffrement de l'aléa par le chiffrement des données secrètes (DS) par la clé du jeton (K_TO) pour bénéficier des avantages de l'invention. Naturellement, les deux modes de réalisation peuvent être combinés (chiffrement de l'aléa et d'une donnée secrète du ticket par la clé K_TO). 30 Dans ce mode de réalisation, l'aléa chiffré par la carte SIM et la partie non secrète (4a, PNS) du jeton, sont transmis au serveur de vérification via le téléphone mobile et le lecteur en champ proche (3). La partie non secrète (4a) du jeton sert au serveur de vérification à déterminer l'entrée correspondante au jeton en question dans sa base de données. Le serveur de vérification retrouve alors la clé jeton. Il 35 peut subséquemment déchiffrer les données de vérification du jeton (l'aléa). Si l'aléa issu du déchiffrement par le serveur de vérification est égal à l'aléa émis au préalable 3037754 14 pour ce jeton, alors il en déduit que c'était bien un jeton associé à la SIM de l'acheteur du jeton et décrète que le jeton est valide pour cette session. Le lecteur (B) attend la réponse des phases de vérification du jeton (4) effectuées par le serveur de vérification. Le lecteur peut comporter une interface 5 graphique, non représentée, qui lui permet d'afficher des informations à destination du porteur du terminal mobile. Par exemple, une partie « état » indique l'état de la vérification : l'affichage indique en vert que l'accès est autorisé, en gris ce que doit faire l'utilisateur et en rouge toute erreur survenue. Si la réponse des phases de vérification du jeton effectuées par le serveur de 10 vérification est positive, alors la borne répond positivement à la requête de l'utilisateur, par exemple en ouvrant un portillon pour le laisser passer. La borne détecte à quel moment le terminal mobile n'est plus posé sur le lecteur, et peut alors lancer alors une nouvelle vérification quand un nouveau terminal s'approche. 15 En référence à la figure 2, un système comprend un terminal T apte à communiquer avec un réseau (9) comportant un fournisseur de jetons (7) et à communiquer avec un lecteur (B) pour effectuer la validation d'un jeton électronique, 20 et un élément de sécurité (C_SE) apte à être inséré dans le terminal (T) et à réaliser un déchiffrement et un chiffrement pour l'authentification. Le terminal T est, par exemple, un téléphone mobile ou un PDA (pour "Personal Digital Assistant') ou encore une tablette de l'utilisateur. Le terminal T comprend classiquement une unité de traitement, ou « CPU » (pour « Central 25 Processing Unit »), destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ; un ensemble de mémoires M, dont une mémoire volatile, ou 'ffli" (pour "Random Access Memory') utilisée pour exécuter des instructions de code, stocker des variables, etc. et une mémoire non volatile, de type « ROM » (de l'anglais « Read Only Memory»), ou « EEPROM » (pour « Electronically Erasable 30 Programmable Read Only Memory») destinée à contenir des données persistantes, utilisées par exemple pour stocker les tickets électroniques et l'application APM de gestion des tickets. Le terminal T comporte par ailleurs : - un premier module de communication MC1 apte à communiquer avec l'élément de sécurité C_SE, via une interface de communication (Il). 35 - un deuxième module de communication MR, permettant une communication, via un réseau de communication mobile, avec des serveurs distants, 3037754 15 par exemple avec le serveur de confiance (5) pour la réception de jetons via SMS, réseau de communication mobile prolongé via Internet (9) vers le fournisseur/vérificateur de tickets (7) si l'utilisateur achète son jeton depuis son mobile (en mode de navigation HTTP). C'est par exemple par ce media (réseau de 5 communication mobile prolongé via Internet (9)) que le terminal mobile (T) reçoit l'application APM (Application dans le Mobile) de gestion des tickets (selon notre exemple, de concert) chargée dans une mémoire M du mobile. - un troisième module de communication sans contact (3), apte à faire communiquer le mobile avec un équipement proche via une liaison sans contact de 10 type NFC, par exemple le lecteur B située à proximité du terminal T. Alternativement cette liaison peut utiliser une autre technologie de communication de proximité (Bluetooth, Zig bee, DECT, etc.) L'élément de sécurité C_SE est dans cet exemple une "carte SIM" mais 15 pourrait sans perte de généralité être une carte à mémoire hébergeant un élément sécurisé (SD card, Embeded Secure controler, etc.) ou encore une zone mémoire spécifique du terminal comme dans le contexte de la norme HCE définie ci-avant. L'élément de sécurité C_SE, couramment utilisé pour l'authentification au réseau mobile (cas de la carte SIM) a pour fonction (outre la fonction classique consistant à 20 assurer l'authentification de l'abonné pour la connexion au réseau mobile) de mettre en oeuvre, dans le cadre de la présente invention, les phases présentées précédemment. A cet effet, la carte SIM possède la clé secrète (K_SE) qui lui est propre. L'élément de sécurité C_SE comporte un premier module d'émission- 25 réception MC1' apte à dialoguer avec le terminal T via l'interface de communication Il. Dans ce mode de réalisation de l'invention, l'élément de sécurité C_SE est une carte SIM et comporte classiquement des mémoires M' de type ROM contenant notamment le système d'exploitation de l'élément de sécurité et des programmes implémentant les mécanismes de sécurité, entre autres l'algorithme d'authentification 30 réseau, des mémoires de type EEPROM contenant de manière permanente des répertoires et données définis par la norme mobile (e,g. GSM, UMTS, etc.), les clés d'authentification (dont la clé K_SE), ainsi que des applications spécifiques aussi appelées applets s'exécutant dans une mémoire de type RAM. Sur la figure 2 est représentée l'applet (APS) de sécurité commune utilisée dans le cadre de cette 35 présente invention pour traiter les jetons électroniques suivant le procédé décrit. 3037754 16 Pour communiquer avec la carte SIM, l'application sur le mobile utilise selon ce mode de réalisation l'API SmartCard selon la recommandation ETSI 102.221. Elle permet d'ouvrir un canal de communication avec l'application APS de la carte SIM pour l'envoi des données (le jeton et optionnellement l'aléa) et la réception de 5 données (le jeton et optionnellement l'aléa signés par la clé jeton) sous forme de paquets. La figure 3 représente la structure possible d'un jeton électronique selon un 10 mode de réalisation de l'invention. Comme mentionné ci-dessus à l'appui de la figure 1, il comporte - une Partie Non Secrète (4a, PNS) comportant par exemple : o l'identité du service (M1), e .g. « tickets de concert de l'opéra de Rennes » 15 o les informations publiques du jeton (M2) : nom du spectacle, date et heure, etc. o optionnellement, le numéro du jeton dans ce service. o etc. - des données secrètes (4b, DS), optionnelles, correspondant aux données 20 privées du jeton ; par exemple des éléments techniques propres au serveur de jetons (prix auquel le jeton a été acheté, etc.). On rappelle que si ces données sont optionnelles dans le premier mode de réalisation, dit « mode avec aléa » décrit à l'appui de la figure 1, elles ne le sont pas dans un mode de réalisation sans aléa, puisque dans ce cas il 25 est nécessaire au bon fonctionnement de l'invention qu'au moins une donnée secrète soit déchiffrée puis chiffrée par la carte SIM. - une clé de sécurité propre au jeton, la clé jeton (4c, K_TO) constituant avec les données secrètes (optionnelles- selon le mode de réalisation) la Partie Secrète (PS) du jeton. 30 La figure 4 représente une cinématique des échanges entre les différentes entités de l'invention. On suppose ici que les prérequis concernant l'obtention du jeton, déjà décrits 35 à l'appui de la figure 1, ont été remplis lors d'une étape E0 : le jeton de concert (4) a été chargé sur le mobile (T) de l'utilisateur, qui souhaite passer la borne de la salle de concert. Un enchaînement d'étapes, transparentes pour l'utilisateur, sont alors 3037754 17 effectuées entre le mobile (T) et son module NFC (3), la carte SIM (C_SE), la borne (B) et le serveur de vérification (7) représentés en haut de la figure 4. Sur requête ou automatiquement, les jetons stockés sur le mobile 5 apparaissent dans l'interface graphique que l'application mobile de gestion des jetons propose à l'utilisateur, et sont utilisables si les conditions de validité sont remplies (date, etc.). Le jeton souhaité (4) est sélectionnable par l'utilisateur, par exemple par une pression du doigt sur l'écran tactile du téléphone mobile, et une boite de dialogue peut lui demander une confirmation de la sélection du jeton. 10 Lors d'une étape El, l'utilisateur (1) du service mobile confirme la sélection puis approche son mobile du lecteur. Lors d'une étape correspondante E31, le lecteur (B) ouvre une session avec le serveur (7) de génération et/ou de vérification de jetons et demande un aléa au serveur. Cette étape peut être facultative, l'absence d'aléa rendant cependant le 15 service moins fiable. On notera par ailleurs que si cette étape est facultative, les données secrètes (DS, 4b) du jeton ne sont plus optionnelles. Le lecteur (B) demande alors au mobile, au cours d'une étape E32, la lecture de jeton, en fournissant l'identité du service (SID); il fournit en même temps l'aléa 20 reçu du serveur. Lors de l'étape E2, le service sur mobile (application APM) trouve le bon jeton grâce à la partie non secrète du jeton qui contient entre autres l'identité du service (SID). Il transmet à l'élément de sécurité des données dites de vérification, qui comportent, dans ce mode de réalisation avec aléa, la partie secrète du jeton 25 (données secrètes 4b de manière optionnelle et clé-jeton K TO de manière obligatoire) et l'aléa. Selon une variante, l'ensemble du jeton (partie non secrète et partie secrète) peut être transmise, ceci simplifiant l'application mobile (qui n'a plus à sélectionner les champs avant envoi à l'élément de sécurité) au détriment de l'élément de sécurité 30 lui-même (il est nécessaire de bénéficier de plus d'espace mémoire dans l'élément de sécurité et d'une application plus complexe puisque apte à analyser la structure du message pour en extraire les différentes données). Selon un autre mode de réalisation « sans aléa », l'aléa n'est pas- utilisé mais la partie secrète comporte nécessairement des données secrètes (4b). 35 On rappelle que l'élément de sécurité (C_SE), par exemple une carte SIM, contient une application sécuritaire, aussi appelée applet (APS) qui est installée sur l'élément de sécurité des utilisateurs de terminaux mobiles désirant avoir accès aux 3037754 18 différents services de jetons dématérialisés. Elle peut accéder à la clé privée. K_SE de l'utilisateur dans la mémoire de l'élément de sécurité, ce qui permet à celui-ci de déchiffrer le sous-ensemble chiffré du jeton, d'en extraire la seconde clé, ou clé du jeton (4c, K TO), de chiffrer ensuite les Données Secrètes DS ou l'aléa avec la clé 5 du jeton (4c, K TO), en authentifiant en même temps la carte SIM auprès du serveur de jetons (grâce au chiffrement de l'aléa ou des Données Secrètes DS de la Partie Secrète). L'applet de l'élément de sécurité effectue donc les opérations suivantes dans ce mode de réalisation : 10 - E10 : la carte reçoit du mobile l'aléa et la partie secrète PS (4b, 4c) ; - E11 : elle déchiffre à l'aide de sa clé (K_SE) la partie chiffrée du jeton correspondant à la partie secrète (4b,4c) et contenant au minimum la clé du jeton (K_TO, 4c) ; - E12 : elle chiffre les Données Secrètes DS (selon le second mode de 15 réalisation) du jeton ou l'aléa (selon le premier mode de réalisation) à l'aide de la clé jeton (4c, K_TO) qu'elle vient de déchiffrer. Les données résultant de l'opération de chiffrage (résultat chiffré des données secrètes DS du jeton et de l'aléa) sont retransmises au mobile lors d'une 20 étape E13, puis transmises avec la partie publique du jeton par le mobile au serveur de vérification, via le lecteur NFC (étapes E4 et E33). Ces différentes transmissions sont notées de manière abrégée : PNS, [Aléa + DS} K ro pour signifier la transmission de la partie non secrète (PNS), puis des 25 données secrètes (DS) ainsi que de de l'aléa chiffrés par la clé K_TO du jeton. Lors de l'étape E41 suivante, la partie publique (4a, PNS) du jeton, qui n'est pas chiffrée, sert à déterminer l'entrée correspondante au jeton en question dans la base de données du serveur de vérification. Il a en effet conservé dans sa base de données, lors de la génération du jeton, une entrée associant la partie non secrète 30 du jeton au jeton. Il extrait de ce jeton la clé jeton (4c, K_TO) qu'il avait choisie lui- même lors de la génération du jeton puis utilise cette clé pour déchiffrer l'ensemble qu'il vient de recevoir (l'aléa chiffré selon le premier mode de réalisation, les Données Secrètes DS selon le second mode de réalisation ou l'ensemble {Aléa et DS} chiffré selon le mode combiné représenté dans la Figure 4). 35 Selon le mode de réalisation « avec aléa », l'aléa issu du déchiffrement par le serveur de vérification est comparé lors de l'étape E42 à celui qui se trouve dans la 3037754 19 base de données ; si les deux valeurs d'aléas sont identiques, il en déduit que c'était un jeton associé à la SIM de l'acheteur du jeton et décrète que le jeton est valide pour cette session et le signifie à la borne. Sinon l'étape échoue. En effet, puisqu'il fait confiance au serveur de confiance (par exemple 5 l'opérateur mobile, ou bien la chaîne culturelle qui a vendu le jeton), le serveur de vérification sait que le bon jeton (contenant au moins la clé jeton (4c, K_TO) chiffrée par la bonne clé K_SE) a été envoyé au bon élément de sécurité et que seul cet élément possédant la clé K_SE pouvait déchiffrer le jeton. On s'assure donc à la fois de la validité du jeton (grâce à l'aléa et à la clé 10 jeton) et à la validité de l'élément de sécurité (grâce à la clé de l'élément de sécurité) et donc à l'authenticité du porteur du mobile associé. Selon un autre mode de réalisation « sans aléa », ce sont les données secrètes du jeton, obligatoires dans ce cas, qui permettent de valider la transaction. On remarquera que l'utilisation du système sans aléa pour assurer l'authentification 15 de la carte SIM (et donc de son porteur) offre un niveau de sécurité moindre à l'authentification puisque le serveur de vérification n'a pas alors l'assurance que le procédé de déchiffrement / chiffrement n'a pas été fait en avance et capté par un mobile tiers. Ce mode sans aléa est cependant acceptable pour l'accès à des spectacles par exemple, qui demandent un niveau de sécurité moins élevé ; il ne l'est 20 pas pour les abonnements de transport. Lors d'une étape E34, le lecteur (B), en attente de la réponse des phases de vérification du jeton (4) effectuées par le serveur de vérification reçoit de celui-ci les informations d'authentification (de la carte SIM) et de validation du jeton. Le lecteur peut comporter une interface graphique, non représentée, qui lui permet d'afficher 25 des informations à destination du porteur du terminal mobile. Par exemple, une partie « état » indique l'état de la vérification : l'affichage de la borne indique en vert que l'accès est autorisé, en gris ce que doit faire l'utilisateur et en rouge toute erreur survenue. Si la réponse des phases d'authentification et de vérification du jeton est 30 positive, alors la borne répond positivement à la requête de l'utilisateur, par exemple en ouvrant un portillon pour le laisser passer. Par la suite, elle détecte quand le terminal mobile n'est plus posé sur le lecteur NFC, et peut alors lancer une nouvelle vérification quand un nouveau terminal s'approche. 35 Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications 3037754 20 peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention. Notamment, selon une variante des modes de réalisation présentés ci-dessus 5 (mode « avec aléa » et « sans aléa »), des champs de la partie non secrète du jeton (4a) servent au serveur de vérification à obtenir la clé jeton par un procédé de diversification basé sur l'utilisation d'une clé mère, contenue dans le serveur de vérification. Le serveur de vérification n'a dans ce cas pas besoin de base de données des jetons et peut être inclus dans le lecteur (B); il peut fonctionner en local, sans 10 accès réseau. Dans un tel cas, le serveur de vérification dans le lecteur, lorsqu'il reçoit la partie non secrète (PNS) du jeton ainsi que les données secrètes et/ou l'aléa chiffrés par l'élément de sécurité : utilise la clé mère qu'il a à sa disposition et les champs ad hoc de la partie non secrète du jeton pour régénérer la clé de session (la clé fille correspondant à la 15 clé jeton K_TO dans la description précédente), il peut alors déchiffrer les données de vérification chiffrées qui lui ont été transmises. Si les données de vérification issues de ce déchiffrement sont égales à celles émises au préalable, il en déduit que c'est un jeton associé à l'élément de sécurité de l'acheteur du jeton et décrète que le jeton est valide. 20 L'invention peut aussi s'appliquer aux services de paiement ou de transfert d'argent pour lesquelles un jeton peut représenter une somme d'argent. REVENDICATIONS1. Procédé de gestion sécurisée d'un ticket électronique (4) stocké dans un terminal mobile (T) auquel est associé un élément de sécurité (C_SE,SIM), le ticket (4) comportant une partie non secrète (4a) comportant l'identification d'un service (SID) et une partie secrète (4b, 4c) chiffrée par une première clé (K_SE) connue de l'élément de sécurité (C_SE), ladite partie secrète (4b, 4c) comprenant au moins une seconde clé (4c, K_TO), le ticket étant prévu pour accéder au service via un dispositif de contrôle d'accès (B), le procédé étant caractérisé en ce qu'il comporte les étapes suivantes dans le terminal mobile (T) : transmission (E3) à l'élément de sécurité (C_SE) de la seconde clé (K_TO) chiffrée et d'au moins une donnée de vérification (4b, aléa) ; réception (E4) d'au moins une donnée de vérification (4b, aléa) chiffrée par l'élément de sécurité (C_SE) ; transmission (E4) d'au moins une donnée de vérification (4b, aléa) chiffrée au dispositif de contrôle d'accès (B). 2. Procédé de gestion sécurisée d'un ticket électronique (4) stocké dans un terminal mobile (T) selon la revendication 1, caractérisé en ce que la partie secrète (PS) du ticket (4) comporte au moins une donnée secrète (DS, 4b) distincte de la seconde clé (K_TO) et en ce qu'une donnée de vérification transmise à l'élément de sécurité (C_ES, SIM) comporte au moins cette donnée secrète (DS). 3. Procédé de gestion sécurisée d'un ticket électronique (4) stocké dans un terminal mobile (T) selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape de réception (E2) d'un aléa en provenance du dispositif de contrôle d'accès (B) et en ce qu'une donnée de vérification transmise à l'élément de sécurité (C_ES, SIM) comporte au moins l'aléa. 4. Procédé de vérification d'un ticket électronique (4) stocké dans un terminal mobile (T) auquel est associé un élément de sécurité (C_SE,SIM), le ticket (4) comportant une partie non secrète (4a) comportant l'identification d'un service (SID) et une partie secrète (4b, 4c) chiffrée par une première clé (K_SE) 3037754 22 connue de l'élément de sécurité (C_SE), ladite partie secrète (4b, 4c) comprenant au moins une seconde clé (4c, K TO), le ticket étant prévu pour accéder au service via un dispositif de contrôle d'accès (B), le procédé étant caractérisé en ce qu'il comporte les étapes suivantes dans l'élément de sécurité : 5 réception (E10) en provenance du mobile (T) de données comportant au moins : o la seconde clé (4c, K_TO) de la partie secrète (PS) et o au moins une donnée de vérification (4b, DS) ; déchiffrement (E11) de la partie secrète (4b, 4c) à l'aide de la première 10 clé (K_SE); chiffrement (E12) d'une donnée de vérification reçue (4b, aléa) à l'aide de la seconde clé (K_TO) déchiffrée ; transmission (E13) d'une donnée de vérification (4b, aléa) chiffrée au mobile (T). 15 5. Procédé de génération d'un ticket électronique (4) pour un terminal mobile (T) auquel est associé un élément de sécurité (C_SE, SIM), le procédé comportant les étapes suivantes : génération d'une partie non secrète (PNS, 4a) comportant l'identification 20 d'un service (SID) ; génération d'une partie secrète (4b, 4c) comportant une seconde clé (4c, K_TO) ; caractérisé en ce que la partie secrète (PS) est chiffrée par une première clé (K_SE) connue de l'élément de sécurité (C_SE). 25 6. Procédé de génération d'un ticket électronique (4) selon la revendication 5, caractérisé en ce que la seconde clé (K TO) est générée par les étapes suivantes obtention d'une clé-mère ; 30 génération de la seconde clé (K_TO) à partir de la clé-mère et de la partie non secrète du jeton (4a). 7. Terminal mobile (T) auquel est associé un élément de sécurité (C_SE, SIM) , apte à gérer un ticket (4), le ticket (4) comportant une partie non secrète (4a) 3037754 23 comportant l'identification d'un service (SID) et une partie secrète (4b, 4c) chiffrée par une première clé (K_SE) connue de l'élément de sécurité (C_SE), ladite partie secrète (4b, 4c) comprenant au moins une seconde clé (4c, K_TO), le ticket étant prévu pour accéder au service (S) via un dispositif de contrôle 5 d'accès (B), le terminal étant caractérisé en ce qu'il comporte les modules suivants : un module de transmission à l'élément de sécurité (C_SE) de la seconde clé (K_TO) chiffrée et d'au moins une donnée de vérification (4b, aléa) ; un module de réception d'au moins une donnée (K_TO, 4b, aléa) de 10 l'élément de sécurité (C_SE) ; un module de transmission (E4) d'au moins une donnée (K_TO, 4b, aléa) au dispositif de contrôle d'accès (B). 8. Elément de sécurité (C_SE, SIM) associé à un terminal mobile (T) apte à mettre à disposition d'un dispositif de contrôle d'accès (B), via le terminal mobile (T), un 15 ticket électronique (4) stocké dans le terminal mobile (T), le ticket (4) comportant une partie non secrète (4a) comportant l'identification d'un service (SID) et une partie secrète (4b, 4c) chiffrée par une première clé (K_SE) connue de l'élément de sécurité (C_SE), ladite partie secrète (4b, 4c) comprenant au moins une seconde clé (4c, K_TO), caractérisé en ce qu'il comporte les 20 modules suivants : un module de réception (E10) de données en provenance du mobile (T) comportant au moins : o la seconde clé (4c, K_TO) de la partie secrète (PS) et o au moins une donnée de vérification (4b, DS, aléa) ; 25 un module de déchiffrement (E11, CPU', M', APS) des données reçues à l'aide de la première clé (K_SE) connue de l'élément de sécurité (C_SE) ; un module de chiffrement (E12, CPU', M', APS) d'une donnée reçue (4b, aléa) à l'aide de la seconde clé (K_TO) déchiffrée ; un module de transmission (E13) d'une donnée de vérification (4b, aléa) 30 chiffrée au mobile (T). 9. Entité (6) de génération de tickets (7) apte à générer des tickets électroniques pour un terminal mobile (T) auquel est associé un élément de sécurité (C_SE, SIM), caractérisée en ce qu'elle comporte les modules suivants : 3037754 24 un module de génération d'une partie non secrète (PNS, 4a) comportant l'identification d'un service (SID, M1) ; un module de génération d'une partie secrète (4b, 4c) comportant une seconde clé (4c, K_TO) ; 5 un module de chiffrage de la partie secrète par une première clé (K_SE) connue de l'élément de sécurité (C_SE). 10. Système (SYS) pour fournir un service de tickets dématérialisés sécurisé à l'utilisateur d'un terminal mobile (T), ce système comportant : - une entité (7) de génération d'un ticket électronique (4) selon la 10 revendication 9 ; - un terminal mobile selon la revendication 7 ; - un élément de sécurité associé au terminal mobile selon la revendication 8. 15 11. Programme d'ordinateur comportant des instructions de code pour la mise en oeuvre du procédé de gestion sécurisée de tickets électroniques conforme à la revendication 1, lorsque celle-ci est exécutée par un processeur. 12. Programme d'ordinateur comportant des instructions de code pour la mise en oeuvre du procédé de vérification d'un ticket conforme à la revendication 4, 20 lorsque celle-ci est exécutée par un processeur. 13. Programme d'ordinateur comportant des instructions de code pour la mise en oeuvre du procédé de génération de tickets conforme à la revendication 5, lorsque celle-ci est exécutée par un processeur. 25