FR3003980A1 - Procede de delivrance de billets electroniques - Google Patents

Abstract

L'invention concerne procédé de délivrance d'un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité (11-3) d'un dispositif utilisateur (11), ledit procédé comprenant les étapes suivantes, mises en œuvre par une entité émettrice (10) de billets : - génération (E101) d'un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur du dispositif, lesdites informations et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, - envoi (E102) dudit billet électronique au module de sécurité du dispositif utilisateur.

Description

Procédé de délivrance de billets électroniques La présente invention concerne un procédé de délivrance de billets électroniques à un dispositif utilisateur, ainsi qu'un procédé de contrôle de billets délivrés au moyen d'une technologie sans contact. L'invention trouve une application particulièrement intéressante dans la sécurisation de systèmes de billetterie destinés à délivrer des billets, tels que des billets de spectacle, d'événement sportif, de transport, etc., à des utilisateurs équipés de terminaux mobiles ; les billets sont stockés dans un module de sécurité du terminal mobile des utilisateurs et utilisés au moyen de leur terminal mobile. Il a déjà été démontré la faisabilité de services de dématérialisation de billets sur terminaux mobiles au moyen de la technologie sans contact. On peut citer par exemple l'expérimentation M-Stadium, à Caen, qui a montré l'intégration de la technologie sans contact tout au long du parcours d'un public dans un stade : de l'acquisition et de la dématérialisation de billets sur des terminaux mobiles, au contrôle des billets et à la lecture d'étiquettes interactives autour, et dans le stade. Ainsi, les utilisateurs d'un tel système chargent préalablement un ticket au moyen d'une application mobile de leur terminal mobile équipé de la technologie sans contact, par exemple la technologie « NFC » (de l'anglais « Near Field Communication »). Les données ainsi chargées, relatives au ticket sont mémorisées dans la carte d'abonné de l'utilisateur puis contrôlées à l'entrée du stade au moyen d'un terminal de contrôle. Cependant, ce système ne dispose pas de fonctionnalités de sécurité permettant de vérifier l'authenticité et l'intégrité d'un billet, de vérifier que le billet n'a pas été dupliqué frauduleusement, ou transféré d'un premier terminal mobile à un deuxième terminal mobile. Un tel transfert peut être interdit dans le cas de billets nominatifs.

Un des buts de l'invention est de remédier à des insuffisances/inconvénients de l'état de la technique et/ou d'y apporter des améliorations. A cette fin, l'invention propose un procédé de délivrance d'un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité d'un dispositif utilisateur, ledit procédé comprenant les étapes suivantes, mises en oeuvre par une entité émettrice de billets : - génération d'un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur du dispositif, lesdites informations et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, - envoi dudit billet électronique au module de sécurité du dispositif utilisateur.

Le procédé de délivrance selon l'invention permet de délivrer des billets électroniques de manière sécurisée. En effet, les billets électroniques ainsi délivrés sont stockés de manière sécurisée dans un module de sécurité du dispositif utilisateur et peuvent être ultérieurement vérifiés en termes de sécurité. Le billet est signé par l'entité émettrice lors de la délivrance, permettant un contrôle ultérieur de l'intégrité du billet. Par ailleurs, le billet comprend une information propre à l'utilisateur, en l'espèce la clé publique de l'utilisateur. Cette information lie l'utilisateur, plus précisément le module de sécurité du dispositif utilisateur, au billet. Un contrôle lors de l'utilisation du billet permet de s'assurer que le billet n'a pas été intercepté par un autre utilisateur ou transmis du dispositif utilisateur auquel il a été délivré à un autre dispositif utilisateur. Ce contrôle garantit que le billet n'a pas été cloné. Dans un exemple de réalisation, le billet comprend en outre une information de comptage NMax, représentative d'un nombre maximal d'utilisation du billet. Avec le procédé de l'invention, plusieurs billets électroniques peuvent être délivrés à un dispositif utilisateur et comptabilisés de manière à faciliter un contrôle ultérieur des billets.

L'invention concerne aussi un procédé de contrôle d'un billet électronique, ledit billet ayant été préalablement délivré par une entité émettrice et mémorisé dans un module de sécurité d'un dispositif utilisateur, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur du dispositif, ladite information et la clé publique ayant étant signées au moyen d'une clé secrète de l'entité émettrice, le procédé comprenant les étapes suivantes, mises en oeuvre par une entité de contrôle : - envoi d'un aléa au dispositif utilisateur, - réception, en provenance du dispositif utilisateur, du billet électronique et de l'aléa signé au moyen d'une clé secrète associée à la clé publique de l'utilisateur, - contrôle de la signature de l'aléa au moyen de la clé publique de l'utilisateur comprise dans le billet. Le procédé de contrôle de billets électroniques selon l'invention peut être effectué hors ligne, c'est-à-dire au moyen de dispositifs de contrôle qui n'ont pas besoin d'être reliés en réseau. Les dispositifs de contrôle peuvent donc être réduits à de petits dispositifs de type lecteur sans contact. Cela facilite l' architecture physique de contrôle à mettre en place. En effet, un billet électronique comprend, lorsqu'il est délivré, la clé publique de l'utilisateur du dispositif sur lequel il est délivré. Dans les échanges mis en oeuvre lors du contrôle, un aléa transmis par l'entité de contrôle au dispositif utilisateur est signé par le module de sécurité du dispositif utilisateur au moyen de la clé secrète de l'utilisateur, et envoyé au dispositif de contrôle. Celui-ci utilise alors la clé publique de l'utilisateur qui est adjointe au billet électronique pour vérifier la signature de l'aléa et pour s'assurer ainsi que le billet n'a pas été cloné et/ou transmis à un autre dispositif utilisateur. Dans un exemple de réalisation, le procédé de contrôle selon l'invention comprend en outre une étape de contrôle de la validité du billet au moyen de la clé publique de l'entité émettrice. Selon cet exemple, il est procédé à un contrôle de l'intégrité du billet électronique délivré au moyen de la clé publique de l'entité émettrice. Ce contrôle permet ainsi de vérifier que le billet n'a pas été falsifié depuis qu'il a été délivré. Dans un exemple de réalisation du procédé de contrôle, le billet comprend au moins une information relative à un événement et le procédé comprend en outre une étape de contrôle de l'événement, au cours de laquelle il est contrôlé qu'au moins une des informations relatives à l'événement comprises dans le billet est identique à au moins une des informations d'un événement courant. Ce contrôle permet de vérifier que l'événement auquel assiste l'utilisateur correspond bien à l'événement pour lequel un billet électronique lui a été délivré sur son dispositif mobile. Selon un exemple de réalisation du procédé de contrôle, le billet comprend une information de comptage NMax représentative d'un nombre d'utilisation maximal du billet et le procédé comprend en outre les étapes suivantes : - envoi au module de sécurité d'un message d'interrogation et de décrément d'un compteur, le compteur ayant été initialisé à la valeur de l'information de comptage lors de la délivrance du billet, - réception de la valeur du compteur, le compteur étant décrémenté de un par le module de sécurité lorsque sa valeur est supérieure ou égale à un, - vérification que la valeur du compteur est supérieure ou égale à un.

Dans cet exemple de réalisation, il est délivré à l'utilisateur plusieurs billets électroniques, comptabilisés au moyen d'une valeur de comptage notée NMax. Cette valeur est inscrite dans le billet électronique lors de sa délivrance, en même temps qu'un compteur Cpt est initialisé à cette valeur dans le module de sécurité. Ainsi, lors du contrôle d'un billet, le compteur associé à la valeur de comptage est décrémenté de un indiquant qu'un billet a été utilisé. Cela permet de connaître à tout moment le solde de billets électroniques. Il n'est en effet pas possible de modifier la valeur de comptage fournie initialement pour connaître le solde de billets après un contrôle. En effet, cette valeur fait partie des informations du billet électronique lorsqu'il est délivré. Elle est donc signée au même titre que les informations relatives au billet et ne peut être modifiée au risque de faire échouer le contrôle de validité du billet.

L'invention concerne également un procédé d'acquisition et de vérification d'un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité d'un dispositif utilisateur, ledit procédé comprenant les étapes suivantes, mises en oeuvre par le dispositif utilisateur : - réception d'un billet électronique en provenance d'une entité émettrice, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur, ladite clé publique étant associée à une clé secrète d'utilisateur mémorisée dans le module de sécurité, ladite information et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, - réception d'un aléa en provenance d'une entité de contrôle, - envoi à l'entité de contrôle du billet électronique et de l'aléa signé au moyen de la clé secrète associée à la clé publique de l'utilisateur. L'invention porte aussi sur un entité émettrice, destinée à délivrer au moins un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité d'un dispositif utilisateur, ladite entité comprenant : - des moyens de génération, agencés pour générer un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur, ladite information et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, - des moyens d'envoi, agencés pour envoyer ledit billet électronique au module de sécurité du dispositif utilisateur. L'invention concerne également une entité de contrôle, destinée à contrôler un billet électronique, ledit billet ayant étant préalablement délivré par une entité émettrice et mémorisé dans un module de sécurité d'un dispositif utilisateur, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur, ladite information et la clé publique ayant étant signées au moyen d'une clé secrète de l'entité émettrice de billets, l'entité de contrôle comprenant : - des moyens d'envoi, agencés pour envoyer un aléa au dispositif utilisateur, - des moyens de réception, agencés pour recevoir en provenance du dispositif utilisateur, le billet signé et l'aléa signé au moyen d'une clé secrète associée à la clé publique de l'utilisateur, - des moyens de contrôle, agencés pour contrôler la signature de l'aléa au moyen de la clé publique de l'utilisateur comprise dans le billet. L'invention concerne aussi un dispositif utilisateur, destiné à acquérir et vérifier un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité du dispositif utilisateur, une clé secrète d'utilisateur étant installée dans le module de sécurité, ledit dispositif comprenant : - des premiers moyens de réception, agencés pour recevoir d'une entité émettrice un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur associée à la clé secrète d'utilisateur, ledit billet étant signé au moyen d'une clé secrète de l'entité émettrice, - des deuxièmes moyens de réception, agencés pour recevoir un aléa en provenance d'une entité de contrôle, - des moyens d'envoi, agencés pour envoyer à l'entité de contrôle le billet électronique signé, et l'aléa signé au moyen de la clé secrète d'utilisateur. L' invention porte aussi sur un système comprenant : - au moins une entité émettrice selon l'invention, - au moins une entité de contrôle selon l'invention, et - au moins un dispositif utilisateur selon l'invention.

L' invention concerne aussi un programme sur un support de données et chargeable dans la mémoire d'un dispositif utilisateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé d'acquisition et de vérification d'un billet électronique selon l'invention, lorsque le programme est exécuté sur ledit dispositif utilisateur. L' invention concerne également un programme sur un support de données et chargeable dans la mémoire d'un dispositif de contrôle, le programme comprenant des portions de code pour l'exécution des étapes du procédé de contrôle d'un billet électronique selon l'invention, lorsque le programme est exécuté sur ledit dispositif. L' invention porte aussi sur un programme sur un support de données et chargeable dans la mémoire d'un dispositif émetteur de billets, le programme comprenant des portions de code pour l'exécution des étapes du procédé de délivrance d'un billet électronique selon l'invention, lorsque le programme est exécuté sur ledit dispositif. D'autres caractéristiques et avantages de la présente invention seront mieux compris de la description et des dessins annexés parmi lesquels : - les figures la et lb présentent les étapes d'un procédé de délivrance d'un billet électronique relatif à un événement, selon un exemple de réalisation de l'invention ; - la figure 2 présente les étapes d'un procédé de contrôle d'un billet électronique, selon un exemple de réalisation de l'invention ; - la figure 3 est un schéma blocs fonctionnels d'une entité émettrice de billets électroniques, selon un exemple de réalisation de l'invention ; - la figure 4 est un schéma blocs fonctionnels d'un dispositif utilisateur, selon un exemple de réalisation de l'invention ; - la figure 5 est un schéma blocs fonctionnels d'une entité de contrôlé de billets électroniques, selon un exemple de réalisation de l'invention.

Les étapes d'un procédé de délivrance d'un billet électronique, selon un premier exemple de réalisation, vont maintenant être décrites en relation avec les figures la et lb. Un billet électronique est délivré par une entité émettrice 10 à un utilisateur (non représenté sur la figure 1) équipé d'un dispositif utilisateur 11. Le dispositif utilisateur 11 est équipé d'un module sans contact 11-2 et d'un module de sécurité 11-3. Le dispositif utilisateur 11 est par exemple un terminal mobile. Le module sans contact 11-2 est par exemple un module « NFC » (de l'anglais « Near Field Communication »). Dans le cas où le dispositif utilisateur 11 est un terminal mobile, le module de sécurité 11-3 est par exemple une carte d'identité d'abonné, ou carte « SIM » (pour « Subscriber Identity Module »), agencée pour permettre au terminal mobile d'accéder à un réseau mobile de communications. L'invention n'est pas limitée à un module de sécurité de type carte SIM. Ainsi, le module de sécurité 11-3 peut également être une carte « (e)-UICC » (pour « (embedded)-Universal Integrated Circuit Card »), ou une zone mémoire sécurisée du dispositif mobile tel un composant « TEE» (de l'anglais « Trusted Execution Environment ») embarqué dans le processeur, ou un composant amovible de type SD Card (« SD» pour SanDisk (D). Dans un exemple de réalisation, le dispositif utilisateur 11 est agencé pour accéder à un réseau de données, par exemple le réseau Internet. La figure la présente les étapes d'une phase préalable à la délivrance d'un billet électronique par l'entité émettrice 10, au cours de laquelle un matériel cryptographique est généré et distribué par un Tiers de Confiance 12. Dans l'exemple décrit ici, la sécurité est garantie au moyen de cryptographie asymétrique et repose sur une infrastructure à clés publiques (le terme habituellement utilisé est le terme anglais « PKI », pour « Public Key Infrastructure »). Une telle infrastructure est connue et n'est pas détaillée ici. Dans ce contexte, le Tiers de Confiance 12 est agencé pour générer dans une étape initiale El0 de génération, des couples de clés privée/publique, et des certificats à l'attention d'entités émettrices et d'utilisateurs. Les certificats sont adaptés pour certifier les clés publiques générées. Le Tiers de Confiance 12 distribue ensuite à l'entité émettrice 10, au cours d'une étape E 11 de distribution à des entités émettrices, un couple de clés publique/privée, pkE/skE, et un certificat CE de la clé publique pkE, générés pour l'entité émettrice 10. Ce couple de clés pkE/skE et ce certificat CE sont reçus par l'entité émettrice 10 au cours d'une étape E12 de réception. Il distribue également à l'utilisateur, au cours d'une étape E13 de distribution à des utilisateurs, un couple de clés publique/privée, pks/sks, et un certificat Cs de la clé publique pks générés pour l'utilisateur. Plus précisément, la clé secrète sks du couple de clés pks/sks est destinée à être installée dans une mémoire (non représentée) du module de sécurité 11-3 du dispositif mobile 11; la clé publique et/ou le certificat Cs sont destinés à être installés dans une mémoire du dispositif mobile 11 de l'utilisateur. Ainsi, les données cryptographiques, en l'espèce les clés privée/publique et le certificat sont propres au dispositif utilisateur 11 et au module de sécurité 11-3 du dispositif. Une fois installée, la clé secrète sks n'est jamais extraite du module de sécurité 11-3 et n'est accessible que depuis ce module. Le couple de clés pks/sks et le certificat Cs sont reçus par le dispositif mobile 11 au cours d'une étape E14 de réception.

Les mécanismes de génération et de distribution des clés et certificats sont des mécanismes inhérents aux infrastructures à clé publiques. De tels mécanismes ont été largement décrits dans la littérature. Ils sont supposés connus et ne sont pas détaillés ici. La figure lb présente les étapes d'un procédé de délivrance d'un billet électronique, selon un exemple de réalisation.

Dans une étape initiale E100 de décision d'achat, l'utilisateur qui souhaite acheter un billet électronique pour un événement particulier se rend, muni de son dispositif utilisateur 11, auprès de l'entité émettrice 10 qui vend de tels billets. L'événement particulier est une manifestation telle qu'un spectacle, un événement sportif, une exposition, etc., pour lequel des billets électroniques sont en vente auprès de l'entité émettrice 10.

Dans une étape E101 de génération, l'entité émettrice 10 génère un billet électronique à l'attention de l'utilisateur. Le billet électronique comprend plusieurs types d'informations : une information d'identification, une information relative à l'utilisateur et des informations supplémentaires optionnelles. Ainsi, le billet comprend au moins : - un identifiant unique de billet, sous forme par exemple d'une valeur numérique, incrémentée à chaque billet délivré. Le billet électronique comprend également : - une information propre à l'utilisateur qui permet de lier le billet à la personne qui l'acquiert. Plus précisément l'information permet de lier le billet au module de sécurité du dispositif utilisateur dans lequel le billet est enregistré. Cette information est destinée à être utilisée pour vérifier que le billet n'a pas été transféré d'un dispositif utilisateur à un autre. Dans un exemple de réalisation, cette information correspond à la clé publique pks délivrée à l'utilisateur et associée à la clé privée associée sks, mémorisée dans le module de sécurité 11-3 du dispositif utilisateur 11.

L'identifiant unique de billet et l'information propre à l'utilisateur, en l'espèce la clé publique pks sont toujours présentes dans un billet dématérialisé. Elles sont qualifiées d'informations obligatoires. De manière optionnelle, le billet électronique peut comprendre des informations supplémentaires, telles que : - une référence de l'événement, sous forme par exemple d'un numéro d'événement, ou d'un intitulé, - une date de validité qui correspond à la date à laquelle le billet peut être utilisé, ou la date jusqu'à laquelle le billet peut être utilisé. Lorsque la date de validité correspond à la date à laquelle le billet peut être utilisé, elle peut comprendre une heure associée à une séance particulière de l'événement. - une information de comptage, représentative du nombre d'utilisation maximal du billet : une telle information peut être utile lorsque l'utilisateur achète des billets électroniques pour lui et d'autres personnes avec lesquelles il souhaite assister à l'événement, ou lorsqu'il souhaite lui-même assister à l'événement plusieurs fois. Lorsque cette information de comptage est présente et égale à un, le billet n'est utilisable qu'une fois. On note que cette information est optionnelle : si elle n'est pas présente, le billet a été valablement délivré et dans ce cas il est équivalent à un billet qui comprendrait une information de comptage égale à un, - une deuxième information personnelle, propre à l'utilisateur. Cette information personnelle est destinée à faciliter le contrôle. Par exemple, l'information personnelle peut être une photo de l'utilisateur. La photo de l'utilisateur peut être utilisée pour une reconnaissance faciale lors d'un contrôle de billet nominatif, - d'autres informations spécifiques relatives à l'événement et/ou au lieu dans lequel il se passe, telles que la place, le prix, la catégorie, la date de l'événement, etc.

Ces informations supplémentaires sont qualifiées d'informations optionnelles. L'entité émettrice 10 construit un billet électronique IBillet qui comprend les informations obligatoires et le cas échéant les informations optionnelles. Le billet électronique est ensuite signé par l'entité émettrice 10 au moyen de sa clé privée skE. La signature est mise en oeuvre par un algorithme de signature connu, par exemple « RSA » (du nom des inventeurs Rivest, Shamir et Adleman »), ou « DSA » (de l' anglais « Digital Signature Algorithm ») Ce billet est noté IBillet = ((infos_obl, infos_opt), sig((infos_obl, infos_opt), skE)), où sig désigne un algorithme de signature connu. Les informations propres à l'utilisateur telles que la clé publique pks et le cas échéant la deuxième information personnelle peuvent être obtenues du dispositif mobile 11 au moyen d'une communication en champ proche avec le dispositif utilisateur 11. Dans une variante de réalisation, la clé publique de l'utilisateur pks peut être obtenue au moyen d'un accès à un serveur distant (non représenté sur la figure 1) qui mémorise les clés publiques et certificats délivrés aux utilisateurs. Au terme de l'étape E101 de génération, l'entité émettrice 10 a généré le billet électronique IBillet et est prête à le délivrer à l'utilisateur. Dans une étape suivante E102 de délivrance de billet, l'entité émettrice 10 délivre le billet IBillet à l'utilisateur. Plus précisément, l'entité émettrice transmet le billet IBillet au dispositif mobile 11 de l'utilisateur au moyen d'une communication en champ proche. Le billet électronique IBillet est mémorisé dans une mémoire du module de sécurité 11-3 du terminal mobile. On note ici que le billet dématérialisé est reçu par le module de sécurité 11-3 par l'intermédiaire du module sans contact 11-2. En particulier, le billet électronique IBillet ne transite pas par une mémoire du terminal mobile 11. Ainsi, le billet est inaccessible au dispositif utilisateur 11 et n'est donc pas susceptible d'être altéré ou analysé par un programme frauduleux qui serait installé sur le dispositif utilisateur 11. Par ailleurs, le billet électronique est mémorisé dans le module de sécurité 11-3, qui est réputé sûr. La sécurité est donc assurée de bout en bout lors de la délivrance du billet. Dans l'exemple de réalisation décrit ici, le billet électronique est délivré à l'utilisateur au moyen d'une communication en champ proche. L'invention n'est pas limitée à ce moyen. Ainsi dans un autre exemple de réalisation, le dispositif utilisateur 11 a accès à un réseau de données et le billet électronique est délivré en ligne, de manière sécurisée et installé dans le module de sécurité 11-3 du dispositif utilisateur 11. Le billet électronique IBillet est reçu et mémorisé par le module de sécurité 11-3 au cours d'une étape E103 de réception. Dans un exemple particulier de réalisation, le billet électronique IBillet peut être utilisé un nombre déterminé de fois. Dans ce cas, le billet comprend comme information supplémentaire, l'information de comptage indiquant un nombre maximal NMax d'utilisation du billet IBillet. Dans ce cas, lors de la réception du billet électronique IBillet durant l'étape E103 de réception, un compteur Cpt, mémorisé par le module de sécurité 11-3 est initialisé à la valeur associée à l'information de comptage. En d'autres termes le compteur Cpt est initialisé à la valeur NMax. Le compteur Cpt est destiné à être décrémenté à chaque utilisation d'un billet et donc à permettre de vérifier que le billet dématérialisé IBillet n'est pas utilisé plus de fois que précisé par l'information de comptage. A un instant donné, le compteur Cpt est représentatif du nombre de billets électroniques non encore utilisés.

Les étapes d'un procédé de contrôle d'un billet électronique, selon un exemple de réalisation de l'invention, vont maintenant être décrites en relation avec la figure 2. On suppose que les étapes du procédé de délivrance d'un billet électronique selon l'invention, décrites en relation avec les figures la et lb ont déjà été mises en oeuvre ; le billet électronique IBillet est stocké dans le module de sécurité 11-3 du dispositif utilisateur 11. Il est prêt à être utilisé. Une entité de contrôle 13, agencée pour contrôler la validité des billets électroniques est équipée d'une module sans contact (non représenté sur la figure 2). Elle comprend dans une mémoire (non représentée) les clés publiques et/ou certificats de toutes les entités émettrices susceptibles d'avoir délivré des billets dématérialisés pour l'événement. Le jour où l'événement pour lequel l'utilisateur a acheté le billet électronique IBillet se produit, dans une étape E20 de présentation au contrôle, l'utilisateur présente son dispositif utilisateur 11 à l'entité de contrôle 13. Plus précisément, l'utilisateur approche son dispositif utilisateur 12 de l'entité de contrôle 13 à une distance inférieure à une distance déterminée Dans le cadre du NFC, cette distance déterminée est de l'ordre d'une dizaine de centimètres. Dans une étape E21 d'envoi d'un aléa, l'entité de contrôle 13 envoie un aléa c au dispositif utilisateur 11 au moyen d'une communication en champ proche. L'aléa c est généré par exemple au moyen d'un générateur pseudo-aléatoire. L'aléa c est reçu par le dispositif utilisateur 11, plus précisément par le module de sécurité 11-3, via le module sans contact 11-2, au cours d'une étape E22 de réception. Dans une étape suivante E23 de signature et d'envoi du billet, le module de sécurité 113 signe l'aléa c au moyen de la clé privée sks de l'utilisateur et envoie à l'entité de contrôle 13 le billet électronique IBillet, ainsi que l'aléa c reçu au cours de l'étape E21 et signé au moyen de la clé privée sks de l'utilisateur. Ainsi, l'entité de contrôle 13 reçoit une donnée D = (((infos_obl, infos_opt), sig((infos_obl, infos_opt), skE)), sig(c, sks)), où sig désigne un algorithme de signature connu. La donnée D qui comprend le billet électronique IBillet et l'aléa c signé est reçue par l'entité de contrôle 13 au cours d'une étape E24 de réception. Dans une étape suivante E25 de contrôle, l'entité de contrôle 13 procède à une pluralité de contrôles : - dans une sous étape E25-1 de contrôle de l'utilisateur, l'entité de contrôle 13 vérifie la signature de l'aléa c au moyen de la clé publique pks de l'utilisateur, extraite du billet électronique IBillet. Ce contrôle permet de vérifier que le billet n'a pas été cloné et transféré sur un autre dispositif utilisateur que celui auquel il a été délivré. En effet, la vérification de la signature de l'aléa c étant mise en oeuvre au moyen de la clé publique pks d'utilisateur inscrite dans le billet dématérialisé lors de la délivrance de celui-ci, seul le dispositif utilisateur 11 qui mémorise dans son module de sécurité la clé secrète sks associée est apte à signer de façon valide l'aléa c. Si le contrôle de l'utilisateur est négatif, c'est-à-dire si la vérification de la signature de l'aléa c est négative (branche « nok » sur la figure 2), le procédé s' arrête ; - si le contrôle mis en oeuvre au cours de l'étape E25-1 est positif (branche « ok » sur la figure 2), c'est-à-dire si la signature de l'aléa est correcte, alors dans une sous-étape E25-2 de contrôle de la validité, l'entité de contrôle 13 vérifie la validité du billet dématérialisé IBillet en vérifiant la signature du billet électronique IBillet, sig((infos_obl, infos_opt), skE), au moyen de la clé publique pkE de l'entité émettrice 10 qu'elle a mémorisée. Ce contrôle permet de garantir l'authenticité et l'intégrité du billet : il a été émis par l'entité émettrice 10 et n'a pas été modifié après délivrance. Si ce contrôle est négatif (branche « nok » sur la figure 2), le procédé s' arrête ; - si le contrôle effectué au cours de l'étape E25-2 est positif (branche « ok » sur la figure 2), c'est-à-dire si la signature du billet est correcte, alors dans une sous-étape optionnelle E25-3 de contrôle de l'événement (en pointillés sur le figure 2), exécutée uniquement si des informations optionnelles relatives à l'événement sont présentes, l'entité de contrôle 13 vérifie que l'événement est bien celui pour lequel le billet dématérialisé IBillet a été délivré. A cette fin, il vérifie que les informations optionnelles relatives à l'événement qui figurent dans le billet électronique IBillet sont identiques aux informations relatives à l'événement pour lequel le contrôle est effectué. En l'espèce, il vérifie que la référence de l'événement et la date de validité qui figurent dans le billet électronique sont bien cohérentes avec ceux de l'événement : il vérifie que la référence de l'événement est identique et que la date de validité est soit égale à la date de validité de l'événement soit inférieure, selon la nature de l'événement. Si le contrôle de l'événement est négatif, c'est-à-dire si l'événement qui figure sur le billet électronique ne correspond pas à l'événement auquel assiste l'utilisateur (branche « nok » sur la figure 2), le procédé s' arrête. Dans le cas contraire (branche « ok » sur la figure 2), le contrôle a été réalisé avec succès, et le billet électronique IBillet de l'utilisateur est valide. Les contrôles décrits précédemment peuvent être effectués en série, comme cela est présenté sur la figure 2. Le succès d'un premier contrôle conditionne alors la mise en oeuvre du contrôle suivant. Les contrôles peuvent être mis en oeuvre selon un ordre différent. Dans un autre exemple de réalisation, les contrôles peuvent également être mis en oeuvre en parallèle.

Dans ce cas, un module de décision (non représenté sur la figure 2), fonction des résultats des contrôles est agencé pour décider si le contrôle du billet électronique est positif ou négatif. Dans l'exemple particulier de réalisation où le billet peut être utilisé un nombre maximal de fois et comprend comme information supplémentaire l'information de comptage indiquant le nombre maximal NMax d'utilisation du billet électronique, alors dans une étape E26 de vérification du décompte (en pointillés sur la figure 2), il est vérifié que le compteur Cpt associé dans le module de sécurité 11-3 au nombre de billets électroniques non encore utilisés est supérieur ou égal à un. A cette fin, il est envoyé par l'entité émettrice 10, au cours d'une sous-étape E26-1 d'interrogation et de décrément, un message d'interrogation du compteur Cpt au dispositif utilisateur 11, plus précisément au module de sécurité 11-3. Ce message est reçu par le module de sécurité 11-3 au cours d'une sous-étape E26-2 de réception. La valeur du compteur Cpt est envoyée en réponse à l'entité de contrôle 13 au cours d'une sous-étape E26-3 de réponse. La valeur du compteur est reçue par l'entité de contrôle 13 au cours d'une sous-étape E26-4 de réception. Dans une sous-étape E26-5 de test, l'entité de contrôlé 13 vérifie si la valeur du compteur reçue précédemment est supérieure à un. Si c'est le cas (branche « ok » sur la figure 2), la vérification du décompte est positive ; cela signifie que le billet électronique qui est contrôlé est valide. Dans le cas contraire (branche « nok » sur la figure 2), la vérification est négative et le procédé s'arrête. Dans une sous-étape E26-6 de test, mise en oeuvre au niveau du module de sécurité 11-3, il est vérifié si la valeur du compteur Cpt est supérieure à un. Si c'est le cas (branche « > 1 » sur la figure 2), alors dans une sous-étape E26-7 de décrément, la valeur du compteur Cpt est décrémentée de 1. Le compteur Cpt indique alors le solde de billets électroniques. On comprend que l'étape E26 de vérification du décompte peut donner lieu à diverses variantes. Par exemple, le module de sécurité 11-3 peut juste indiquer à l'entité de contrôlé 13, au cours de l'étape E26-3 de réponse, que la valeur du compteur est positive, sans envoyer la valeur du compteur.

De manière avantageuse, ces contrôles, mis en oeuvre par l'entité de contrôle 13 peuvent être effectués hors-ligne, c'est-à-dire sans que celle-ci ne soit connectée à un serveur centralisé. En effet, elle dispose en mémoire des informations utiles aux contrôles, en l'espèce les clés publiques de toutes les entités émettrices susceptibles d'avoir délivré des billets dématérialisés. Par ailleurs, la clé publique pks de l'utilisateur, nécessaire à la vérification de la signature de l'aléa c est comprise dans le billet dématérialisé IBillet et est donc extraite du billet au moment du contrôle. Une entité émettrice 10, selon un exemple de réalisation de l'invention, va maintenant être décrite en relation avec la figure 3.

L'entité émettrice 10 est un équipement informatique, par exemple un serveur qui comprend : - un microprocesseur 10-1, ou « CPU » (de l'anglais « Central Processing Unit »), apte à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ; - un ensemble de mémoires, dont une mémoire volatile 10-2, ou « RAM » (pour « Random Access Memory »), utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 10-3 de type « ROM » ou « EEPROM » (de l'anglais « Read-Only Memory » et « Electronically-Erasable Programmable Read-Only Memory »). La mémoire de stockage 10-3 est agencée pour mémoriser une première application qui comprend des instructions de code pour mettre en oeuvre celles des étapes du procédé de génération du matériel cryptographique et distribution qui sont mises en oeuvre par l'entité émettrice 10. La mémoire de stockage 10-3 est également agencée pour mémoriser une deuxième application qui comprend des instructions de code pour mettre en oeuvre celles des étapes du procédé de délivrance d'un billet électronique qui sont mises en oeuvre par l'entité émettrice 10. La mémoire de stockage 10-3 est agencée également pour mémoriser le certificat CE et le couple clé publique/clé privée, pkE/skE de l'entité émettrice 10. La clé secrète skE de l'entité émettrice 10 est stockée dans une zone sécurisée de la mémoire 10-3; - une interface 10-4 (optionnelle) d'accès à un réseau, par exemple le réseau Internet, adaptée pour obtenir du Tiers de Confiance 12 le couple clé publique/clé privée pkE/skE et le certificat de la clé publique CE, et pour vérifier la chaîne de certification qui figure dans le certificat. Le couple de clés et le certificat peuvent être obtenus du Tiers de Confiance 12 selon d'autres méthodes connues, par exemple par installation à partir d'un module de stockage amovible dans lequel ces informations sont stockées. L'interface d'accès au réseau 10-4 peut également être utilisée lors d'une délivrance en ligne aux dispositifs utilisateurs des billets électroniques générés.

L'entité émettrice 10 comprend en outre : - un module sans contact 10-5, agencé pour dialoguer en mode sans contact avec d'autres dispositifs. Le module sans contact 10-5 est présent dans l'exemple de réalisation où les billets sont délivrés aux dispositifs utilisateurs au moyen d'une communication en champ proche. Selon un fonctionnement connu de communication entre deux entités sans contact, une première entité peut opérer en tant que carte sans contact et l' autre en tant que lecteur sans contact. Dans un autre mode de fonctionnement, dit « P2P » (pour « Peer-To-Peer »), correspondant au mode décrit ici, les deux entités sans contact opèrent en tant que carte sans contact et échangent des données localement ; elles jouent donc un rôle équivalent. Le module sans contact 10-5 opère donc en tant que carte sans contact et échange des données localement avec les autres dispositifs équipés sans contact. Dans l'exemple de réalisation décrit ici, les autres dispositifs sans contact sont le dispositif utilisateur 11; - un module de génération 10-6, agencé pour générer au moins un billet électronique relatif à un événement. Le billet comprend des informations obligatoires infos_obl, et le cas échéant, des informations optionnelles infos_opt. Le billet est signé au moyen de la clé secrète skE de l'entité émettrice 10; - un module qui couplé au module sans contact 10-5 forme un module d'envoi 10-7, agencé pour envoyer en mode sans contact le billet électronique au module de sécurité 11-3 du dispositif mobile 11 de l'utilisateur. Les modules de génération 10-6 et d'envoi 10-7 sont sous forme de modules logiciels comprenant des instructions pour mettre en oeuvre les étapes E101 de génération du billet électronique et E102 de délivrance du procédé de délivrance d'un billet électronique décrit en relation avec la figure lb. Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission, ou un réseau. Un dispositif utilisateur 11, selon un exemple de réalisation de l'invention va maintenant être décrit en relation avec la figure 4. Le dispositif utilisateur 11 est un dispositif portatif de petite taille. Dans un exemple de réalisation, c'est un terminal mobile d'utilisateur. Le dispositif utilisateur 11 comprend : - un microprocesseur 11-1, apte à mettre en oeuvre les fonctions classiques d'un dispositif utilisateur et à charger des instructions en mémoire, à les exécuter, à effectuer des opérations. Dans le cas où le dispositif utilisateur est un terminal mobile, les fonctions classiques du dispositif sont des fonctions d'accès au réseau de télécommunications ; - un module sans contact 11-2, agencé pour dialoguer en mode sans contact avec d'autres dispositifs. Le module sans contact 11-2 opère en tant que carte sans contact et échange des données localement avec les autres dispositifs équipés sans contact. Dans l'exemple de réalisation décrit ici, les autres dispositifs sans contact sont l'entité de contrôlé 13 et l'entité émettrice 10 ; - l'élément de sécurité 11-3, qui comprend un processeur, une mémoire RAM, une ou plusieurs mémoires de type ROM, ou EEPROM (non représentés sur la figure 4), dans lesquelles sont enregistrés des programmes pouvant être exécutés par le micro-processeur. Dans l'exemple de réalisation décrit ici, l'élément de sécurité 11-3 est une carte SIM qui comprend une mémoire dans laquelle sont définies des zones sécurisées. Une zone sécurisée est agencée pour mémoriser une application. Par exemple, une zone sécurisée est agencée pour mémoriser une application sans contact qui comprend des instructions de code mettant en oeuvre celles des étapes des procédés de délivrance et de contrôle selon l'invention qui sont mises en oeuvre par le module de sécurité. Dans un autre exemple de réalisation, une première zone mémoire est agencée pour mémoriser une première application qui comprend des instructions de code mettant en oeuvre celles des étapes du procédé de délivrance d'un billet électronique qui sont mises en oeuvre par le module de sécurité 11-3, et une deuxième zone sécurisée est agencée pour mémoriser une deuxième application qui comprend des instructions de code mettant en oeuvre celles des étapes du procédé de contrôle d'un billet électronique qui sont mises en oeuvre par le module de sécurité 11-3. Les mémoires ROM ou EEPROM sont également agencées pour mémoriser les billets électroniques délivrés par l'entité émettrice 10, selon le procédé de l'invention. Dans un autre exemple de réalisation, l'élément de sécurité 11-3 est conforme aux spécifications GlobalPlatform qui définissent un ou plusieurs domaines de sécurité dans l'élément de sécurité. Un domaine de sécurité est une zone mémoire dédiée à une application ou/et à un fournisseur de services ; - un ensemble de mémoires, dont une mémoire volatile 11-4, ou RAM, utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 11-5 de type ROM ou EEPROM. La mémoire de stockage 11-5 mémorise un système d'exploitation, un module « IHM » (pour « Interface Homme-Machine »), IHMiiiet de l' application de délivrance d'un billet électronique et de contrôle du billet selon l'invention. Ce module IHMmillet réalise l'interface entre l'utilisateur et l'application sans contact de délivrance d'un billet électronique et de contrôle du billet installée dans l'élément de sécurité 11-3 ; Le dispositif mobile 11 comprend également : - un module de paramétrage 11-6, agencé pour recevoir et mémoriser une clé secrète d'utilisateur sks dans le module de sécurité 11-3 du dispositif utilisateur et pour mémoriser la clé publique pks associée et le certificat Cs de la clé publique ; - des moyens qui couplés au module sans contact 11-2 forment des premiers moyens de réception 11-7, agencés pour recevoir le billet électronique, ledit billet comprenant au moins les informations relatives à l'événement et la clé publique pks de l'utilisateur, lesdites informations et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice 10 ; - des moyens qui couplés au module sans contact 11-2 forment des deuxièmes moyens de réception 11-8, agencés pour recevoir de l'entité de contrôle 13 l'aléa c ; - des moyens qui couplés au module sans contact 11-2 forment des moyens de signature et d'envoi 11-9, agencés pour signer l'aléa c et pour envoyer le billet et l'aléa c signé à l'entité de contrôle 13.

Les moyens 11-6 de paramétrage, les premiers moyens 11-7 de réception, les deuxièmes moyens 11-8 de réception et les moyens 11-9 de signature et d'envoi sont de préférence des modules logiciels comprenant des instructions logicielles pour faire exécuter celles des étapes du procédé de délivrance d'un billet électronique et du procédé de contrôle d'un billet électronique selon l'invention qui sont mises en oeuvre par le dispositif mobile 11.

L'invention concerne donc aussi : - un programme comportant des instructions pour la mise en oeuvre du procédé de délivrance d'un billet électronique et du procédé de contrôle d'un billet électronique tel que décrits précédemment lorsque ce programme est exécuté par un processeur du dispositif mobile 11; - un support d'enregistrement lisible sur lequel est enregistré le programme décrit ci- dessus. Les modules logiciels peuvent être stockés dans, ou transmis par un support de données. Celui-ci peut être un support matériel de stockage, par exemple un CD-ROM, une disquette magnétique ou un disque dur, ou bien un support de transmission tel qu'un signal ou un réseau de télécommunication. Une entité de contrôle 13, selon un exemple de réalisation de l'invention, va maintenant être décrite en relation avec la figure 5. L'entité de contrôle 13 est un équipement informatique portatif, de petite taille et autonome en termes de consommation électrique. L'entité de contrôle 13 comprend : - un microprocesseur 13-1, apte à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ; - un ensemble de mémoires, dont une mémoire volatile 13-2, utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 13-3 de type ROM ou EEPROM. La mémoire de stockage 13-3 est agencée pour mémoriser une application qui comprend des instructions de code pour mettre en oeuvre celles des étapes du procédé de contrôle d'un billet électronique qui sont mises en oeuvre par l'entité de contrôle 13. L'entité de contrôle 13 comprend également : - un module sans contact 13-4, agencé pour dialoguer en mode sans contact avec d'autres dispositifs adaptés pour dialoguer également en mode sans contact. Selon l'exemple de réalisation décrit ici, les autres dispositifs sans contact sont des dispositifs mobiles d'utilisateurs tels que décrits en relation avec la figure 4 ; - un module qui couplé au module sans contact forme un module 13-5 d'envoi d'aléas, agencé pour générer et envoyer un aléa c au dispositif mobile 11 ; - un module qui couplé au module sans contact 13-6 forme un module 13-6 de réception de billet électronique, agencé pour recevoir un billet électronique - un module de contrôle 13-7, agencé pour contrôler la validité d'un billet électronique reçu d'un dispositif mobile 11 par rapport à un événement donné.

L'invention concerne également un système de génération, de délivrance et de contrôle de billets dématérialisés qui comprend une entité émettrice selon l'invention, au moins une entité de contrôle selon l'invention, et au moins un dispositif utilisateur selon l'invention.5

Claims (14)

1. REVENDICATIONS1. Procédé de délivrance d'un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité (11-3) d'un dispositif utilisateur (11), ledit procédé comprenant les étapes suivantes, mises en oeuvre par une entité émettrice (10) de billets : - génération (E101) d'un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur du dispositif, lesdites informations et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, - envoi (E102) dudit billet électronique au module de sécurité du dispositif utilisateur. 10
2. 2. Procédé selon la revendication 1, dans lequel le billet comprend en outre une information de comptage (NMax), représentative d'un nombre maximal d'utilisation du billet.
3. 3. Procédé de contrôle d'un billet électronique, ledit billet ayant été préalablement 15 délivré par une entité émettrice (10) et mémorisé dans un module de sécurité (11-3) d'un dispositif utilisateur (11), ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur du dispositif, ladite information et la clé publique ayant étant signées au moyen d'une clé secrète de l'entité émettrice, le procédé comprenant les étapes suivantes, mises en oeuvre par une entité de contrôle (13) : 20 - envoi (E21) d'un aléa (c) au dispositif utilisateur, - réception (E24), en provenance du dispositif utilisateur, du billet électronique et de l'aléa signé au moyen d'une clé secrète associée à la clé publique de l'utilisateur, - contrôle (E25-1) de la signature de l'aléa au moyen de la clé publique de l'utilisateur comprise dans le billet. 25
4. 4. Procédé de contrôle selon la revendication 3, comprenant en outre une étape de contrôle de la validité (E25-2) du billet au moyen de la clé publique de l'entité émettrice.
5. 5. Procédé de contrôle selon la revendication 3, ou la revendication 4, dans lequel le 30 billet comprenant au moins une information relative à un événement, le procédé comprend en outre une étape de contrôle de l'événement (E25-3), au cours de laquelle il est contrôlé qu'au moins une des informations relatives à l'événement comprises dans le billet est identique à au moins une des informations d'un événement courant.
6. 6. Procédé de contrôle selon l'une des revendications 3 à 5, dans lequel, le billet comprenant une information de comptage (NMax) représentative d'un nombre d'utilisation maximal du billet, le procédé comprend en outre les étapes suivantes : - envoi (E26-1) au module de sécurité d'un message d'interrogation et de décrément d'un compteur, le compteur ayant été initialisé à la valeur de l'information de comptage lors de la délivrance du billet, - réception (E26-4) de la valeur du compteur, le compteur étant décrémenté de un (E267) par le module de sécurité lorsque sa valeur est supérieure ou égale à un, - vérification (E26-5) que la valeur du compteur est supérieure ou égale à un. 10
7. 7. Procédé d'acquisition et de vérification d'un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité (11-3) d'un dispositif utilisateur (11), ledit procédé comprenant les étapes suivantes, mises en oeuvre par le dispositif utilisateur : - réception (El 03) d'un billet électronique en provenance d'une entité émettrice (10), 15 ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur, ladite clé publique étant associée à une clé secrète d'utilisateur mémorisée dans le module de sécurité, ladite information et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, - réception (E22) d'un aléa (c) en provenance d'une entité de contrôle (13), 20 - envoi (E23) à l'entité de contrôle du billet électronique et de l'aléa signé au moyen de la clé secrète associée à la clé publique de l'utilisateur.
8. 8. Entité émettrice (10), destinée à délivrer au moins un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité (11-3) d'un dispositif utilisateur (11), 25 ladite entité comprenant : - des moyens de génération (10-6), agencés pour générer un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur, ladite information et la clé publique étant signées au moyen d'une clé secrète de l'entité émettrice, 30 - des moyens d'envoi (10-7), agencés pour envoyer ledit billet électronique au module de sécurité du dispositif utilisateur.
9. 9. Entité de contrôle (13), destinée à contrôler un billet électronique, ledit billet ayant étant préalablement délivré par une entité émettrice (10) et mémorisé dans un module de 35 sécurité (11-3) d'un dispositif utilisateur (11), ledit billet comprenant au moins une informationd'identification et une clé publique de l'utilisateur, ladite information et la clé publique ayant étant signées au moyen d'une clé secrète de l'entité émettrice de billets, l'entité de contrôle comprenant : - des moyens d'envoi (13-5), agencés pour envoyer un aléa au dispositif utilisateur, - des moyens de réception (13-6), agencés pour recevoir en provenance du dispositif utilisateur, le billet signé et l'aléa signé au moyen d'une clé secrète associée à la clé publique de l'utilisateur, - des moyens de contrôle (13-7), agencés pour contrôler la signature de l'aléa au moyen de la clé publique de l'utilisateur comprise dans le billet. 10
10. 10. Dispositif utilisateur (11), destiné à acquérir et vérifier un billet électronique, ledit billet étant destiné à être mémorisé dans un module de sécurité (11-3) du dispositif utilisateur, une clé secrète d'utilisateur étant installée dans le module de sécurité, ledit dispositif comprenant : 15 - des premiers (11-7) moyens de réception, agencés pour recevoir d'une entité émettrice (10) un billet électronique, ledit billet comprenant au moins une information d'identification et une clé publique de l'utilisateur associée à la clé secrète d'utilisateur, ledit billet étant signé au moyen d'une clé secrète de l'entité émettrice, - des deuxièmes (11-8) moyens de réception, agencés pour recevoir un aléa (c) en 20 provenance d'une entité de contrôle (13), - des moyens d'envoi (11-9), agencés pour envoyer à l'entité de contrôle le billet électronique signé, et l'aléa signé au moyen de la clé secrète d'utilisateur.
11. 11. Système comprenant : 25 - au moins une entité émettrice selon la revendication 8, - au moins une entité de contrôle selon la revendication 9, et - au moins un dispositif utilisateur selon la revendication 10.
12. 12. Programme sur un support de données et chargeable dans la mémoire d'un dispositif 30 utilisateur, le programme comprenant des portions de code pour l'exécution des étapes du procédé d' acquisition et de vérification d'un billet électronique selon la revendication 7, lorsque le programme est exécuté sur ledit dispositif utilisateur.
13. 13. Programme sur un support de données et chargeable dans la mémoire d'un dispositif 35 de contrôle, le programme comprenant des portions de code pour l'exécution des étapes duprocédé de contrôle d'un billet électronique selon l'une des revendications 3 à 6, lorsque le programme est exécuté sur ledit dispositif.
14. 14. Programme sur un support de données et chargeable dans la mémoire d'un dispositif émetteur de billets, le programme comprenant des portions de code pour l'exécution des étapes du procédé de délivrance d'un billet électronique selon l'une des revendications 1 à 2, lorsque le programme est exécuté sur ledit dispositif.