WO2014154961A1 - Procédé de délivrance de billets électroniques - Google Patents

Procédé de délivrance de billets électroniques Download PDF

Info

Publication number
WO2014154961A1
WO2014154961A1 PCT/FR2014/050305 FR2014050305W WO2014154961A1 WO 2014154961 A1 WO2014154961 A1 WO 2014154961A1 FR 2014050305 W FR2014050305 W FR 2014050305W WO 2014154961 A1 WO2014154961 A1 WO 2014154961A1
Authority
WO
WIPO (PCT)
Prior art keywords
ticket
user
entity
public key
control
Prior art date
Application number
PCT/FR2014/050305
Other languages
English (en)
Inventor
Dominique Le Hello
Jacques Traore
Jacques Burger
Stéphane GUILLOTEAU
Original Assignee
Orange
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange filed Critical Orange
Publication of WO2014154961A1 publication Critical patent/WO2014154961A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events

Definitions

  • the present invention relates to a method of issuing electronic tickets to a user device, as well as to a method of controlling tickets issued by means of a contactless technology.
  • the invention finds a particularly interesting application in securing ticketing systems for issuing tickets, such as tickets, sports events, transportation, etc., to users equipped with mobile terminals; the tickets are stored in a security module of the mobile terminal of the users and used by means of their mobile terminal.
  • this system does not have security features to verify the authenticity and integrity of a ticket, to verify that the ticket has not been fraudulently duplicated, or illegally transferred from a first mobile terminal to a second mobile terminal. Such transfer may be prohibited in the case of registered notes.
  • One of the aims of the invention is to remedy the shortcomings / disadvantages of the state of the art and / or to make improvements thereto.
  • the invention proposes a method for issuing an electronic ticket, said ticket being intended to be stored in a security module of a user device, said method comprising the following steps, implemented by an issuing entity of tickets:
  • an electronic ticket comprising at least one identification information and a public key of the user of the device, said information and the public key being signed by means of a secret key of the issuing entity,
  • the delivery method according to the invention makes it possible to deliver electronic tickets in a secure manner. Indeed, the electronic tickets thus delivered are stored securely in a security module of the user device and can be later verified in terms of security.
  • the ticket is signed by the issuing entity upon delivery, allowing a subsequent check of the integrity of the ticket.
  • the ticket includes information specific to the user, in this case the public key of the user. This information links the user, specifically the security module of the user device, to the ticket.
  • a check during the use of the ticket makes it possible to ensure that the ticket has not been intercepted by another user or transmitted from the user device to which it has been delivered to another user device. This check ensures that the ticket has not been cloned.
  • the ticket further comprises a counting information NMax, representative of a maximum number of use of the ticket.
  • the invention also relates to a method for controlling an electronic ticket, stored in a security module of a user device, said ticket comprising at least one identifying information of said ticket and a public key of the user of the device, said electronic ticket having previously been received from an issuing entity, said identification information and said public key having been signed by means of a secret key of the issuing entity, the method comprising the following steps, implemented by a controlling entity, separate from the issuing entity:
  • the method of electronic ticket control according to the invention can be performed offline, that is to say by means of control devices that do not need to be connected in a network.
  • the control devices can therefore be reduced to small devices of the contactless reader type.
  • This facilitates the physical control architecture to set up.
  • an electronic ticket includes, when issued, the public key of the user of the device on which it is issued.
  • a hazard transmitted by the control entity to the user device is signed by the security module of the user device by means of the secret key of the user, and sent to the control device.
  • This uses the public key of the user who is assistant to the ticket to verify the signature of the hazard and to ensure that the ticket has not been cloned and / or transmitted to another user device.
  • the transmitting entity is a second user device that has received a first electronic ticket from a transmitting entity, said first ticket comprising at least the ticket identification information and a public key of the transmission entity. of the second device, said identification information and said public key of the user of the second device having been signed by means of a secret key of said transmitting entity, said second device having generated said ticket from the first ticket and transmitted said ticket to the user device, said ticket comprising said first ticket, the method further comprising:
  • the electronic ticket has been transferred to the device by a second device.
  • the transfer was for the second device to (re) generate the ticket from the first ticket previously received by the second device of a transmission entity.
  • the controlling entity it is thus possible for the controlling entity to check offline that a ticket that has been transferred one or more times has been legitimately delivered initially, and that the transfer from one device to another is legitimate.
  • this control can be implemented regardless of the number of transfers of the ticket originally issued, these successive transfers forming for an electronic ticket a chain of transfers, the validity of the ticket is verified at each link of this chain, it is at each transfer point and ensures that the ticket has not been tampered with during a transfer.
  • control method according to the invention further comprises a step of checking the validity of the ticket by means of the public key of the issuing entity.
  • the integrity of the electronic ticket issued by means of the public key of the issuing entity is checked. This check ensures that the ticket has not been tampered with since it was issued.
  • the bill includes at least one information relating to an event and the method further comprises a step of controlling the event, during which it is checked that at least one of the information related to the event included in the ticket is identical to at least one of the information of a current event.
  • the bill includes a count information NMax representative of a maximum number of use of the ticket and the method further comprises the following steps:
  • the counter being decremented by the security module when its value is greater than or equal to one
  • the user is issued with several electronic tickets, counted by means of a counting value denoted NMax.
  • NMax a counting value
  • This value is written in the electronic ticket when it is issued, at the same time as a counter Cpt is initialized to this value in the security module.
  • the counter associated with the count value is decremented by one indicating that a ticket has been used. This allows to know at any time the balance of electronic tickets. It is indeed not possible to modify the count value initially provided to know the balance of tickets after a check. Indeed, this value is part of the information of the electronic ticket when it is issued. It is therefore signed in the same way as the information relating to the ticket and can not be changed at the risk of failing the validity check of the ticket.
  • the invention also relates to a method for acquiring and verifying an electronic ticket, said ticket being intended to be stored in a security module of a user device, said method comprising the following steps, implemented by the device user:
  • the invention also relates to an issuing entity, intended to deliver at least one electronic ticket, said ticket being intended to be stored in a security module of a user device, said entity comprising: generation means, arranged to generate an electronic ticket, said ticket comprising at least one identification information and a public key of the user, said information and the public key being signed by means of a secret key of the issuing entity,
  • the invention also relates to a control entity, intended to control an electronic ticket, said ticket being previously delivered by an issuing entity and stored in a security module of a user device, said ticket comprising at least one identification information and a public key of the user, said information and the public key having been signed by means of a secret key of the bill-issuing entity, the control entity comprising:
  • reception means arranged to receive from the user device, the signed ticket and the randomly signed by means of a secret key associated with the public key of the user,
  • Control means arranged to control the signature of the hazard by means of the public key of the user included in the ticket.
  • the invention also relates to a user device for acquiring and verifying an electronic ticket, said ticket being intended to be stored in a security module of the user device, a secret user key being installed in the security module, said device comprising:
  • first receiving means arranged to receive an electronic ticket from an issuing entity, said ticket comprising at least one identification information and a public key of the user associated with the secret user key, said ticket being signed by means of a secret key of the issuing entity,
  • second reception means arranged to receive a random error from a control entity
  • means of sending arranged to send the control entity the signed electronic ticket, and the random signed by means of the secret user key.
  • the invention also relates to a system comprising:
  • At least one user device according to the invention.
  • the invention also relates to a program on a data carrier and loadable in the memory of a user device, the program comprising portions of code for performing the steps of the method of acquiring and verifying an electronic ticket according to the invention, when the program is executed on said user device.
  • the invention also relates to a program on a data carrier and loadable in the memory of a control device, the program comprising portions of code for executing the steps of the method for controlling an electronic ticket according to the invention when the program is executed on said device.
  • the invention also relates to a program on a data carrier and loadable in the memory of a bill-issuing device, the program comprising portions of code for executing the steps of the method of issuing an electronic ticket according to the invention, when the program is executed on said device.
  • FIGS. 1a and 1b show the steps of a method for issuing an electronic ticket relating to an event, according to an exemplary embodiment of the invention
  • FIG. 2 presents the steps of a method for controlling an electronic ticket, according to an exemplary embodiment of the invention
  • FIG. 3 is a functional block diagram of an electronic bill issuing entity, according to an exemplary embodiment of the invention.
  • FIG. 4 is a functional block diagram of a user device, according to an exemplary embodiment of the invention.
  • FIGS. 1a and 1b are block diagrams of an electronic ticket control entity, according to an exemplary embodiment of the invention. The steps of a method for issuing an electronic ticket, according to a first exemplary embodiment, will now be described in relation to FIGS. 1a and 1b.
  • An electronic ticket is issued by a transmitting entity 10 to a user (not shown in FIG. 1) equipped with a user device 11.
  • the user device 11 is equipped with a contactless module 11-2 and a module security 11-3.
  • the user device 11 is for example a mobile terminal.
  • the contactless module 11-2 is for example an "NFC" (Near Field Communication) module.
  • the security module 11-3 is for example a subscriber identity card, or "SIM" card (for "Subscriber Identity Module”), arranged to allow the mobile terminal to access a mobile communications network.
  • SIM Subscriber Identity Module
  • the invention is not limited to a SIM card type security module.
  • the security module 11-3 can also be a "(e) -UICC” card (for "(embedded) -Uni Integrated Circuit Card”), or a secure memory area of the mobile device such as a "TEE” (Trusted Execution Environment) component embedded in the processor, or a removable SD Card type ("SD” for SanDisk ®).
  • the user device 11 is arranged to access a data network, for example the Internet network.
  • Figure la presents the steps of a phase prior to the issuance of an electronic ticket by the issuing entity 10, during which a cryptographic material is generated and distributed by a Third Party of Trust 12.
  • security is guaranteed by means of asymmetric cryptography and relies on a public key infrastructure (the term usually used is the term "PKI", for "Public Key Infrastructure”).
  • PKI public Key Infrastructure
  • Such an infrastructure is known and is not detailed here.
  • the Trusted Third Party 12 is arranged to generate, in an initial generation step E10, private / public key pairs, and certificates for issuing entities and users.
  • the certificates are adapted to certify the public keys generated.
  • the Trusted Third Party 12 then distributes to the issuing entity 10, during a step El 1 of distribution to issuing entities, a pair of public / private keys, pk E / sk E , and a certificate C E of the public key pk E , generated for the issuing entity 10.
  • This pair of keys pk E / sk E and this certificate C E are received by the sending entity 10 during a receiving step E12. It also distributes to the user, during a distribution step E13 to users, a pair of public / private keys, pk s / sk s , and a certificate C s of the public key pk s generated for the user. user.
  • the secret key sk s of the pair of keys pk s / sk s is intended to be installed in a memory (not shown) of the security module 11-3 of the mobile device 11; the public key and / or the certificate C s are intended to be installed in a memory of the mobile device 11 of the user.
  • the cryptographic data in this case the private / public keys and the certificate are specific to the user device 11 and the security module 11-3 of the device.
  • the secret key sk s is never extracted from the security module 11-3 and is only accessible from this module.
  • the pair of keys pk s / sk s and the certificate C s are received by the mobile device 11 during a receiving step E14.
  • Mechanisms for generating and distributing keys and certificates are mechanisms inherent to public key infrastructures. Such mechanisms have been widely described in the literature. They are supposed to be known and are not detailed here.
  • Figure lb shows the steps of a method of issuing an electronic ticket, according to an exemplary embodiment.
  • an initial purchase decision step E100 the user who wishes to buy an electronic ticket for a particular event goes, provided with his user device 11, from the issuing entity 10 which sells such notes.
  • the particular event is an event such as a show, a sporting event, an exhibition, etc., for which electronic tickets are on sale to the issuing entity 10.
  • the electronic ticket is intended to prove that the user who holds it has acquired the right to attend the event. It is intended to be installed on the user device 11 and to be used by means of the user device 11.
  • the sending entity 10 In a generation step E101, the sending entity 10 generates an electronic ticket for the user.
  • the electronic ticket includes several types of information: identification information, user information and optional additional information.
  • the ticket includes at least:
  • a unique ticket identifier in the form of, for example, a numerical value, incremented with each ticket issued.
  • the e-ticket also includes:
  • this information corresponds to the public key pk s issued to the user and associated with the associated private key sk s , stored in the security module 11-3 of the user device 11.
  • the unique ticket identifier and the information specific to the user, in this case the public key pk s are always present in a dematerialized ticket. They are called mandatory information.
  • the electronic ticket may include additional information, such as:
  • a reference of the event for example in the form of an event number, or a title
  • validity date which corresponds to the date on which the ticket can be used, or the date until which the ticket can be used.
  • the validity date is the date on which the ticket can be used, it may include a time associated with a particular session of the event.
  • counting information representative of the maximum number of use of the ticket: such information may be useful when the user purchases electronic tickets for himself and other persons with whom he wishes to attend the event, or when he wishes to attend the event several times.
  • this counting information is present and equal to one, the ticket can only be used once. Note that this information is optional: if it is not present, the ticket has been validly issued and in this case it is equivalent to a ticket that includes counting information equal to one,
  • personal information is intended to facilitate control.
  • personal information may be a picture of the user. The user's photo can be used for facial recognition during a ticket check,
  • This additional information is qualified as optional information.
  • the issuing entity 10 builds an electronic ticket IBillet which includes the mandatory information and optionally the optional information.
  • the electronic ticket is then signed by the issuing entity 10 by means of its private key sk E.
  • the signature is implemented by a known signature algorithm, for example "RSA” (named after the inventors Rivest, Shamir and Adleman "), or” DSA “(of the” Digital Signature Algorithm ").
  • IBillet ((infos_obl, infos_opt), sig ((infos_obl, infos_opt), sk E )), where sig denotes a known signature algorithm.
  • the user-specific information such as the public key pk s and possibly the second personal information can be obtained from the mobile device 11 by means of a near-field communication with the user device 11.
  • the public key of the user pk s can be obtained by means of access to a remote server (not shown in Figure 1) which stores the public keys and certificates issued to users.
  • the issuing entity 10 has generated the electronic ticket IBillet and is ready to issue it to the user.
  • the issuing entity 10 delivers the IBillet ticket to the user. More specifically, the transmitting entity transmits the IBillet ticket to the mobile device 11 of the user by means of a near-field communication.
  • the issuing entity, or issuing entity is the entity that issued the note.
  • the electronic ticket IBillet is stored in a memory of the security module 11-3 of the mobile terminal. It is noted here that the dematerialized ticket is received by the security module 11-3 via the contactless module 11-2. In particular, the electronic ticket IBillet does not pass through a memory of the mobile terminal 11. Thus, the ticket is inaccessible to the user device 11 and is therefore not likely to be altered or analyzed by a fraudulent program that would be installed on the 11. In addition, the electronic ticket is stored in the security module 11-3, which is deemed safe. Security is thus assured from end to end when the ticket is issued.
  • the electronic ticket is delivered to the user by means of a near-field communication.
  • the invention is not limited to this means.
  • the user device l i has access to a data network and the electronic ticket is delivered online, securely and installed in the security module 11-3 of the user device 11.
  • the electronic ticket IBillet is received and stored by the security module 11-3 during a step El 03 of reception.
  • the electronic ticket IBillet can be used a specified number of times.
  • the ticket includes, as additional information, the counting information indicating a maximum number NMax of use of the IBillet ticket.
  • a counter Cpt stored by the security module 11-3 is initialized to the value associated with the counting information.
  • the counter Cpt is initialized to the value NMax.
  • the counter Cpt is intended to be decremented with each use of a ticket and thus to make it possible to verify that the paperless ticket IBillet is not used more than times specified by the counting information. At a given moment, the counter Cpt is representative of the number of electronic tickets not yet used.
  • a control entity 13, arranged to check the validity of the electronic tickets, is equipped with a contactless module (not shown in FIG. 2). It includes in a memory (not shown) the public keys and / or certificates of all the issuing entities, or issue, likely to have delivered dematerialized tickets for the event.
  • a step E20 of presentation to the control the user presents his user device 11 to the control entity 13. More precisely, the The user approaches his user device 12 of the control entity 13 at a distance less than a determined distance. In the context of the NFC, this determined distance is of the order of ten centimeters.
  • the control entity 13 sends a random c to the user device 11 by means of a near field communication.
  • the hazard c is generated for example by means of a pseudo-random generator.
  • the hazard c is received by the user device 11, more precisely by the security module 11-3, via the contactless module 11-2, during a reception step E22.
  • the security module 11-3 signs the hazard c by means of the private key s of the user and sends the control entity 13 the electronic ticket.
  • IBillet as well as the hazard c received during step E21 and signed by means of the private key sk s of the user.
  • the data D which comprises the electronic ticket IBillet and the hazard c signed is received by the control entity 13 during a reception step E24.
  • control entity 13 performs a plurality of checks:
  • the control entity 13 verifies the signature of the random number c by means of the public key pk s user, extracted from IBillet electronic ticket. This check verifies that the ticket has not been cloned and transferred to another user device than the one to which it was issued. Indeed, the verification of the signature of the hazard c being implemented by means of the user's public key pk s registered in the dematerialized ticket during the delivery thereof, only the user device 11 which stores in her security module the secret key sk s associate is able to sign validly hazard c. If the control of the user is negative, that is to say if the verification of the signature of the hazard c is negative ("nok" branch in FIG. 2), the process stops;
  • step E25-2 if the control implemented during step E25-1 is positive (branch "ok” in FIG. 2), that is to say if the signature of the hazard is correct, then in a sub step E25-2 of the validity check, the checking entity 13 verifies the validity of the IBillet dematerialized ticket by verifying the signature of the electronic ticket IBillet, sig ((infos_obl, infos_opt), sk E ), by means of the key public pk E of the issuing entity 10 that it has memorized.
  • This control makes it possible to guarantee the authenticity and the integrity of the ticket: it was issued by the issuing entity 10 and was not modified after delivery. If this control is negative ("nok" branch in FIG. 2), the process stops;
  • step E25-2 if the control carried out during step E25-2 is positive (branch "ok” in FIG. 2), that is to say if the signature of the ticket is correct, then in an optional sub-step E25 3-control of the event (dashed in FIG. 2), performed only if optional information relating to the event is present, the checking entity 13 verifies that the event is the one for which the dematerialized ticket IBillet has been issued. At this Finally, it verifies that the optional event information in the IBillet e-ticket is identical to the event information for which the check is being performed.
  • the controls described above can be performed in series, as shown in Figure 2. The success of a first control then conditions the implementation of the following control. Controls can be implemented in a different order. In another embodiment, the controls can also be implemented in parallel. In this case, a decision module (not shown in FIG. 2), a function of the results of the checks, is arranged to decide whether the control of the electronic ticket is positive or negative.
  • step E26 verification of the count ( in dashed lines in FIG. 2), it is verified that the counter Cpt associated in the security module 11-3 with the number of electronic tickets not yet used is greater than or equal to one.
  • it is sent by the sending entity 10, during an interrogation and decrement substep E26-1, an interrogation message from the counter Cpt to the user device 11, more specifically to the module security 11-3.
  • This message is received by the security module 11-3 during a substep E26-2 reception.
  • the value of the counter Cpt is sent in response to the control entity 13 during a substep E26-3 response.
  • the value of the counter is received by the control entity 13 during a substep E26-4 reception.
  • the control entity 13 checks whether the value of the previously received counter is greater than one. If this is the case (branch "ok” in FIG. 2), the verification of the count is positive; this means that the electronic ticket that is checked is valid. In the opposite case ("nok" branch in FIG. 2), the verification is negative and the process stops.
  • a test sub-step E26-6 implemented at the level of the security module 11-3, it is checked whether the value of the counter Cpt is greater than one. If this is the case (branch ">1" in FIG.
  • step E26-7 of decrement the value of the counter Cpt is decremented by 1.
  • the counter Cpt indicates the balance of banknotes e. It is understood that the step E26 verification of the count can give rise to various variants.
  • the security module 11-3 can just tell the controlled entity 13, during the response step E26-3, that the value of the counter is positive, without sending the value of the counter.
  • these controls implemented by the control entity 13 can be performed offline, that is to say without it being connected to a centralized server. Indeed, it has in its memory information useful to controls, in this case the public keys of all issuing entities that may have issued dematerialized tickets. Moreover, the public key pk s of the user, necessary for the verification of the signature of hazard c is included in the dematerialized ticket IBillet and is therefore extracted from the ticket at the time of the control.
  • the electronic ticket that has been delivered to the user of the mobile device 11 in accordance with the steps of the delivery method described with reference to FIG. 1b is legitimately transferred by the user of the device 11 to a second user, equipped with a second mobile device.
  • a legitimate transfer is a transfer that is allowed under certain conditions.
  • the controlling entity 13 which controls a ticket which has been transferred one or more times, to verify that it has been legitimately delivered initially and that the transfer from one device to another is legitimate in accordance with the steps described below.
  • the transfer is done for example in the near field, or by means of a network, for example the Internet, or the mobile network.
  • the transferred electronic ticket is stored in the security module of the second mobile device.
  • the transfer of the electronic ticket between the first and the second user comprises in a first step, the creation on the first mobile device 11 of a new ticket, or ticket to be transferred. , for the attention of the second user. It is assumed that the second user has been distributed cryptographic material in accordance with the steps of the pre-issue phase described in connection with FIG. Thus, the second user has been issued a pair of public / private keys pk ⁇ / sk ⁇ and a certificate of the public key C ⁇ .
  • the private key sk u2 delivered to the second user has been installed in a memory of the security module of the second mobile device; the public key pk u2 and / or the certificate C u2 of the public key have been installed in a memory of the second mobile device.
  • It includes information that has been signed by the entity issuing 13 by means of its private key sk E , and among the required information infos_obl figure the public key pk s of the user as information relating to the user.
  • the new IBillet 'ticket comprises the electronic ticket IBillet as delivered to the user of the device 11 by the issuing entity 13, the public key of the second user pk u2 and a signature of the data thus obtained by means of the secret key sk s of the user of the mobile device 11.
  • IBillet ' ((IBillet, pk ⁇ ), sig (IBillet, pk ⁇ ), sk s ), or,
  • IBillet ' (((infos_obl, infos_opt), sig ((infos_obl, infos_opt), sk E ), pk u2 ), sig (((infos_obl, infos_opt), sig ((infos_obl, infos_opt), sk E )), pk u2 ), sk s )).
  • this new IBillet 'ticket is transferred to the second mobile device and stored in the security module of the second device.
  • the second user equipped with the second mobile device presents the new ticket to the control entity 13 for control.
  • a near-field communication is established between the second device and the control entity 13.
  • the control comprises, in accordance with the control steps described in connection with FIG. by the second mobile device of a hazard signed by means of the secret key sk u2 of the second user and the new electronic ticket IBillet '.
  • the control device 13 checks, in accordance with the substep E25-1 control of the user, the signature of the hazard by means of the public key pk ⁇ of the user who appears in the new electronic ticket IBillet ' .
  • the control device checks the validity of the new electronic ticket by verifying the electronic signature of the new electronic ticket IBillet 'made by the user of the mobile device 11 by means of his secret key sk s .
  • This verification requires the public key pk s of the user of the mobile device 11.
  • This public key pk s by construction in the electronic ticket IBillet as issued by the issuing entity 13: it was inserted by the issuing entity 13 during the generation step E101. It is therefore included in the new IBillet electronic ticket '.
  • the control entity 13 then proceeds to check the validity of the new IBillet 'ticket by means of the public key pks of the user of the mobile device 11 contained in the new ticket IBillet'.
  • this second check ensures that the new IBillet ticket 'from transfer of the electronic ticket Ticket of the mobile device 11 to the second device, was not modified during this transfer.
  • control entity 13 can implement the controls independently of any connection to a server.
  • the ticket has been transferred from the user of the mobile device 11 to a second user.
  • the ticket can be transferred from the second user to a third user in the same way: the second user generates a third electronic ticket which includes the second electronic ticket, the third user's public key and a signature of the data obtained by means of the secret key of the second user.
  • the controls subsequently implemented by the control entity 13 during the control step E25 make it possible to check that the third ticket has not been cloned, by verifying the signature of the hazard by means of the key third user, then check the validity of the third ticket by verifying that each transfer from one device to another, the electronic ticket has not been changed.
  • control entity 13 verifies by means of the public key of the second user pk, which appears in the second ticket, the signature of the third ticket. Then, it verifies by means of the public key of the issuing entity pk E the signature of the second ticket. It is recalled that the control entity 13 has memorized all the public keys of the issuing entities, or issuing entities, which issue the electronic tickets.
  • the sending entity 10 is a computer equipment, for example a server which comprises:
  • microprocessor 10-1 or "CPU” (of the "Central Processing Unit"), able to load instructions into memory, to execute them, to perform operations;
  • the storage memory 10-3 is arranged to store a first application that includes code instructions for implementing those steps of the method of generating the cryptographic and distribution material that are implemented by the transmitting entity 10.
  • the memory 10-3 storage is also arranged to store a second application that includes code instructions to implement those steps of the electronic ticket issuing process that are implemented by the issuing entity 10.
  • the memory of storage 10-3 is also arranged to store the certificate C E and the public key / private key pair, pk E / sk E of the issuing entity 10.
  • the secret key sk E of the issuing entity 10 is stored in an area secure 10-3 memory;
  • a 10-4 (optional) access interface to a network, for example the Internet network, adapted to obtain the Trusted Third Party 12 the public key / private key pair pk E / sk E and the certificate of the public key C E , and to check the certification chain that is in the certificate.
  • the key pair and the certificate can be obtained from the Trusted Party 12 according to other known methods, for example by installation from a removable storage module in which this information is stored.
  • the network access interface 10-4 can also be used during online delivery to the user devices of the generated electronic tickets.
  • the issuing entity 10 further comprises:
  • a contactless module 10-5 arranged to communicate in non-contact mode with other devices.
  • the contactless module 10-5 is present in the exemplary embodiment where the notes are delivered to the user devices by means of a near field communication.
  • a first entity can operate as a contactless card and the other as a contactless reader.
  • P2P for "Peer-To-Peer”
  • the two contactless entities operate as a contactless card and exchange data locally; they play an equivalent role.
  • the contactless module 10-5 therefore operates as a contactless card and exchanges data locally with other devices without contact.
  • the other non-contact devices are the user device 11;
  • a generation module 10-6 designed to generate at least one electronic ticket relating to an event.
  • the ticket includes mandatory information infos_obl, and if necessary, optional information infos_opt.
  • the ticket is signed using the secret key sk E of the issuing entity 10; -
  • a module which coupled to the contactless module 10-5 forms a sending module 10-7, arranged to send in contactless mode the electronic ticket to the security module 11-3 of the mobile device 11 of the user.
  • the generation 10-6 and the sending 10-7 modules are in the form of software modules comprising instructions for implementing the steps E101 for generating the electronic ticket and E102 for issuing the method for issuing an electronic ticket described in relationship with Figure lb.
  • the software modules can be stored in, or transmitted by, a data carrier. This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium, or a network.
  • a user device 11, according to an exemplary embodiment of the invention will now be described in connection with FIG. 4.
  • the user device 11 is a portable device of small size. In an exemplary embodiment, it is a mobile user terminal.
  • the user device 11 comprises:
  • a microprocessor 11-1 able to implement the conventional functions of a user device and to load instructions in memory, to execute them, to perform operations.
  • the conventional functions of the device are access functions to the telecommunications network;
  • non-contact module 11-2 arranged to communicate in non-contact mode with other devices.
  • the contactless module 11-2 operates as a contactless card and exchanges data locally with other devices without contact.
  • the other non-contact devices are the control entity 13 and the transmitting entity 10;
  • the security element 11-3 which comprises a processor, a RAM memory, one or more memories of ROM type, or EEPROM (not shown in FIG. 4), in which programs that can be executed by the microphone are recorded; -processor.
  • the security element 11-3 is a SIM card which comprises a memory in which secure zones are defined.
  • a secure area is arranged to store an application.
  • a secure zone is arranged for storing a contactless application that includes code instructions implementing those of the steps of the delivery and control methods according to the invention that are implemented by the security module.
  • a first memory zone is arranged to store a first application that includes code instructions implementing those steps of the electronic ticket issuing process which are implemented by the security module 11-3
  • a second secure area is arranged to store a second application that includes code instructions implementing those steps of the electronic ticket control method that are implemented by the security module 11-3.
  • the ROM or EEPROM memories are also arranged to store the electronic tickets issued by the issuing entity 10, according to the method of the invention.
  • the security element 11-3 conforms to the GlobalPlatform specifications that define one or more security domains in the security element.
  • a security domain is a memory area dedicated to an application or / and a service provider;
  • a set of memories including a volatile memory 11-4, or RAM, used to execute code instructions, store variables, etc., and an 11-5 storage memory of the ROM or EEPROM type.
  • the storage memory 11-5 stores an operating system, an "HMI” module (for "Human Machine Interface"), an eyelet HMI of the application for issuing an electronic ticket and for controlling the ticket according to the invention.
  • This IHMi module B iii and performs the interface between the user and the contactless application for issuing an electronic ticket and ticket check installed in the security element 11-3;
  • the mobile device 11 also comprises:
  • a parameterization module 11-6 arranged to receive and store a secret user key sk s in the security module 11-3 of the user device and to store the associated public key pk s and the certificate C s of the key public;
  • first receiving means 11-7 Means that coupled to the contactless module 11-2 form first receiving means 11-7, arranged to receive the electronic ticket, said ticket comprising at least the information relating to the event and the public key pk s of the user, said information and the public key being signed by means of a secret key of the issuing entity 10;
  • the means 11-6 of parameterization, the first means 11-7 of reception, the second means 11-8 of reception and the means 11-9 of signature and sending are preferably software modules comprising software instructions to execute those of the steps of the method of issuing an electronic ticket and the method of controlling an electronic ticket according to the invention which are implemented by the mobile device 11.
  • the invention therefore also relates to: a program comprising instructions for implementing the method for issuing an electronic ticket and the method for controlling an electronic ticket as described above when this program is executed by a processor of the mobile device;
  • the software modules can be stored in, or transmitted by, a data carrier.
  • a data carrier This may be a hardware storage medium, for example a CD-ROM, a magnetic diskette or a hard disk, or a transmission medium such as a signal or a telecommunications network.
  • a control entity 13 according to an exemplary embodiment of the invention, will now be described in relation to FIG.
  • the control entity 13 is a portable computer equipment, small in size and autonomous in terms of power consumption.
  • the control entity 13 comprises:
  • a microprocessor 13-1 able to load instructions in memory, to execute them, to perform operations
  • a set of memories including a volatile memory 13-2, used to execute code instructions, store variables, etc., and a storage memory 13-3 of the ROM or EEPROM type.
  • the storage memory 13-3 is arranged to store an application that includes code instructions for implementing those steps of the method of controlling an electronic ticket that are implemented by the control entity 13.
  • the controlling entity 13 also includes:
  • non-contact module 13-4 arranged to communicate in non-contact mode with other devices adapted to dialogue also in contactless mode.
  • the other non-contact devices are mobile devices of users as described in relation to FIG. 4;
  • a module which coupled to the contactless module forms a random sending module 13-5, arranged to generate and send a hazard c to the mobile device 11;
  • a module that couples to the contactless module 13-6 forms a module 13-6 for receiving an electronic ticket, arranged to receive an electronic ticket
  • the invention also relates to a system for generating, issuing and controlling dematerialized bills which comprises an issuer entity according to the invention, at least one control entity according to the invention, and at least one user device according to the invention.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Economics (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Development Economics (AREA)
  • Quality & Reliability (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

Procédé de délivrance de billets électroniques 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é illégitimement 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 œuvre 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, mémorisé dans un module de sécurité d'un dispositif utilisateur, ledit billet comprenant au moins une information d'identification dudit billet et une clé publique de l'utilisateur du dispositif, ledit billet électronique ayant été préalablement reçu d'une entité émettrice, ladite information d'identification et ladite clé publique ayant été signées au moyen d'une clé secrète de l'entité émettrice, le procédé comprenant les étapes suivantes, mises en œuvre par une entité de contrôle, distincte de l'entité émettrice :
- 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 œuvre 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, l'entité émettrice est un deuxième dispositif utilisateur qui a reçu un premier billet électronique d'une entité d'émission, ledit premier billet comprenant au moins l'information d'identification du billet et une clé publique de l'utilisateur du deuxième dispositif, ladite information d'identification et ladite clé publique de l'utilisateur du deuxième dispositif ayant été signées au moyen d'une clé secrète de ladite entité d'émission, ledit deuxième dispositif ayant généré ledit billet à partir du premier billet et transmis ledit billet au dispositif utilisateur, ledit billet comprenant ledit premier billet, le procédé comprenant en outre :
- une étape de contrôle du premier billet compris dans le billet, au moyen de la clé publique de l'utilisateur du deuxième dispositif comprise dans le premier billet.
Dans cet exemple de réalisation, le billet électronique a été transféré au dispositif par un deuxième dispositif. Le transfert a consisté pour le deuxième dispositif à (ré)générer le billet à partir du premier billet reçu préalablement par le deuxième dispositif d'une entité d'émission. Dans cet exemple il est ainsi possible pour l'entité de contrôle de vérifier hors ligne qu'un billet qui a été transféré une ou plusieurs fois a été légitimement délivré initialement, et que le transfert d'un dispositif à un autre est légitime.
Par ailleurs, ce contrôle peut être mis en œuvre quelque soit le nombre de transferts du billet émis initialement, ces transferts successifs formant pour un billet électronique une chaîne de transferts, la validité du billet est vérifiée à chaque maillon de cette chaîne, c'est-à-dire à chaque point de transfert et permet de s'assurer que le billet n'a pas été altéré lors d'un transfert.
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 œuvre 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)-Uni versai 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 ®). 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 E10 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 El 1 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. Le billet électronique est destiné à prouver que l'utilisateur qui le détient a acquis le droit d'assister à l'événement. Il est destiné à être installé sur le dispositif utilisateur 11 et à être utilisé au moyen du dispositif utilisateur 11.
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 œuvre 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 El 02 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. Dans ce cas, l'entité émettrice, ou entité d'émission, est l'entité qui a émis le billet. 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 l i 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 El 03 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 œuvre ; 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, ou d'émission, 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é 11- 3 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 œuvre 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 œuvre 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 œuvre du contrôle suivant. Les contrôles peuvent être mis en œuvre selon un ordre différent. Dans un autre exemple de réalisation, les contrôles peuvent également être mis en œuvre 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 œuvre 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 œuvre 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 aléa c est comprise dans le billet dématérialisé IBillet et est donc extraite du billet au moment du contrôle.
Dans un exemple de réalisation (non représenté sur la figure 2), le billet électronique qui a été délivré à l'utilisateur du dispositif mobile 11 conformément aux étapes du procédé de délivrance décrites en relation avec la figure lb, est transféré légitimement par l'utilisateur du dispositif 11 à un deuxième utilisateur, équipé d'un deuxième dispositif mobile. Un transfert légitime est un transfert qui est autorisé sous certaines conditions. Notamment, il est possible pour l'entité de contrôle 13 qui contrôle un billet qui a été transféré une ou plusieurs fois, de vérifier qu'il a été légitimement délivré initialement et que le transfert d'un dispositif à un autre est légitime conformément aux étapes décrites ci-dessous. Le transfert se fait par exemple en champ proche, ou au moyen d'un réseau, par exemple le réseau Internet, ou le réseau mobile. Au terme du transfert, le billet électronique transféré est mémorisé dans le module de sécurité du deuxième dispositif mobile.
Le transfert du billet électronique entre le premier et le deuxième utilisateur, plus précisément entre le dispositif mobile 11 et le deuxième dispositif mobile, comprend dans une première étape, la création sur le premier dispositif mobile 11 d'un nouveau billet, ou billet à transférer, à l'attention du deuxième utilisateur. On suppose que le deuxième utilisateur s'est vu distribué un matériel cryptographique conformément aux étapes de la phase préalable à la délivrance d'un billet, décrites en relation avec la figure la. Ainsi, il a été délivré au deuxième utilisateur un couple de clés publique/privée pk^/sk^ et un certificat de la clé publique C^. La clé privée sku2 délivrée au deuxième utilisateur a été installée dans une mémoire du module de sécurité du deuxième dispositif mobile ; la clé publique pku2 et/ou le certificat Cu2 de la clé publique ont été installés dans une mémoire du deuxième dispositif mobile.
Pour mémoire, le billet électronique délivré initialement par l'entité émettrice 13 à l'utilisateur du dispositif mobile 11 est de la forme IBillet = ((infos_obl, infos_opt), sig((infos_obl, infos_opt), skE). Il comprend des informations qui ont été signées par l'entité émettrice 13 au moyen de sa clé privée skE, et parmi les informations obligatoires infos_obl figure la clé publique pks de l'utilisateur en tant qu'information relative à l'utilisateur.
Afin de transférer ce billet électronique IBillet au deuxième utilisateur, l'utilisateur du dispositif 11 génère le nouveau billet IBillet' , ou billet à transférer. Le nouveau billet IBillet' comprend le billet électronique IBillet tel que délivré à l'utilisateur du dispositif 11 par l'entité émettrice 13, la clé publique du deuxième utilisateur pku2 et une signature des données ainsi obtenues au moyen de la clé secrète sks de l'utilisateur du dispositif mobile 11. En d'autres termes, le nouveau billet électronique IBillet' est de la forme :
IBillet' = ((IBillet, pk^), sig(IBillet, pk^), sks), ou,
IBillet' = (((infos_obl, infos_opt), sig((infos_obl, infos_opt), skE), pku2), sig(((infos_obl, infos_opt), sig((infos_obl, infos_opt), skE)), pku2), sks)).
Une fois généré, ce nouveau billet IBillet' est transféré au deuxième dispositif mobile et mémorisé dans le module de sécurité du deuxième dispositif.
Le jour de l'événement, le deuxième utilisateur équipé du deuxième dispositif mobile présente le nouveau billet à l'entité de contrôle 13 pour contrôle. Par exemple une communication en champ proche est établie entre le deuxième dispositif et l'entité de contrôle 13.
Lorsqu'un billet électronique associé à un événement a été transféré d'un utilisateur à un autre, ici du dispositif mobile 11 au deuxième dispositif mobile, le contrôle comprend, conformément aux étapes de contrôle décrites en relation avec la figure 2, l'envoi par le deuxième dispositif mobile d'un aléa signé au moyen de la clé secrète sku2 du deuxième utilisateur et du nouveau billet électronique IBillet' .
Le dispositif de contrôle 13 vérifie, conformément à la sous-étape E25-1 de contrôle de l'utilisateur, la signature de l'aléa au moyen de la clé publique pk^ de l'utilisateur qui figure dans le nouveau billet électronique IBillet' .
Si la vérification est positive, dans une deuxième étape de contrôle, le dispositif de contrôle vérifie la validité du nouveau billet électronique en vérifiant la signature électronique du nouveau billet électronique IBillet' réalisée par l'utilisateur du dispositif mobile 11 au moyen de sa clé secrète sks. Cette vérification nécessite la clé publique pks de l'utilisateur du dispositif mobile 11. Cette clé publique pks figure par construction dans le billet électronique IBillet tel que délivré par l'entité émettrice 13 : elle a été insérée par l'entité émettrice 13 au cours de l'étape E101 de génération. Elle figure donc dans le nouveau billet électronique IBillet'. L'entité de contrôle 13 procède alors au contrôle de validité du nouveau billet IBillet' au moyen de la clé publique pks de l'utilisateur du dispositif mobile 11 contenue dans le nouveau billet IBillet'. Ainsi, ce deuxième contrôle permet de s'assurer que le nouveau billet IBillet' issu du transfert du billet électronique Billet du dispositif mobile 11 au deuxième dispositif, n'a pas été modifié lors de ce transfert.
Ainsi, même lorsqu'un billet a été transféré d'un dispositif mobile à un autre, l'entité de contrôle 13 peut mettre en œuvre les contrôles indépendamment de toute connexion à un serveur.
Dans l'exemple décrit ici, le billet a été transféré de l'utilisateur du dispositif mobile 11 à un deuxième utilisateur. Bien sûr, le billet peut être transféré du deuxième utilisateur à un troisième utilisateur de la même manière : le deuxième utilisateur génère un troisième billet électronique qui comprend le deuxième billet électronique, la clé publique du troisième utilisateur et une signature des données obtenues au moyen de la clé secrète du deuxième utilisateur. Les contrôles mis en œuvre ensuite par l'entité de contrôle 13 au cours de l'étape E25 de contrôle, permettent de contrôler que le troisième billet n'a pas été cloné, en vérifiant la signature de l'aléa au moyen de la clé publique du troisième utilisateur, puis de vérifier la validité du troisième billet en vérifiant qu'à chaque transfert d'un dispositif à un autre, le billet électronique n'a pas été modifié. Ainsi, l'entité de contrôle 13 vérifie au moyen de la clé publique du deuxième utilisateur pk^ qui figure dans le deuxième billet, la signature du troisième billet. Puis, elle vérifie au moyen de la clé publique de l'entité émettrice pkE la signature du deuxième billet. On rappelle que l'entité de contrôle 13 a mémorisé l'ensemble des clés publiques des entités émettrices, ou entités d'émission, qui délivrent les billets électroniques.
Ainsi, quelque soit le nombre de transferts mis en œuvre, ces transferts successifs formant pour un billet électronique une chaîne de transferts, la validité du billet est vérifiée à chaque maillon de cette chaîne, c'est-à-dire à chaque point de transfert, et permet de s'assurer que le billet n'a pas été altéré lors d'un transfert.
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 œuvre celles des étapes du procédé de génération du matériel cryptographique et distribution qui sont mises en œuvre 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 œuvre celles des étapes du procédé de délivrance d'un billet électronique qui sont mises en œuvre 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 œuvre 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 œuvre 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 œuvre celles des étapes des procédés de délivrance et de contrôle selon l'invention qui sont mises en œuvre 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 œuvre celles des étapes du procédé de délivrance d'un billet électronique qui sont mises en œuvre 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 œuvre celles des étapes du procédé de contrôle d'un billet électronique qui sont mises en œuvre 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 »), IHMœillet de l'application de délivrance d'un billet électronique et de contrôle du billet selon l'invention. Ce module IHMiBiiiet 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 œuvre par le dispositif mobile 11.
L'invention concerne donc aussi : - un programme comportant des instructions pour la mise en œuvre 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 i l ;
- 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 œuvre celles des étapes du procédé de contrôle d'un billet électronique qui sont mises en œuvre 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.

Claims

REVENDICATIONS
1. Procédé de contrôle d'un billet électronique, mémorisé dans un module de sécurité (11-3) d'un dispositif utilisateur (11), ledit billet comprenant au moins une information d'identification dudit billet et une clé publique de l'utilisateur du dispositif, ledit billet électronique ayant été préalablement reçu d'une entité émettrice, ladite information d'identification et ladite clé publique ayant été signées au moyen d'une clé secrète de l'entité émettrice, le procédé comprenant les étapes suivantes, mises en œuvre par une entité de contrôle (13), distincte de l'entité émettrice :
- 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.
2. Procédé de contrôle, selon la revendication 1, dans lequel l'entité émettrice est un deuxième dispositif utilisateur qui a reçu un premier billet électronique d'une entité d'émission, ledit premier billet comprenant au moins l'information d'identification du billet et une clé publique de l'utilisateur du deuxième dispositif, ladite information d'identification et ladite clé publique de l'utilisateur du deuxième dispositif ayant été signées au moyen d'une clé secrète de ladite entité d'émission, ledit deuxième dispositif ayant généré ledit billet à partir du premier billet et transmis ledit billet au dispositif utilisateur, ledit billet comprenant ledit premier billet, le procédé comprenant en outre :
- une étape de contrôle du premier billet compris dans le billet, au moyen de la clé publique de l'utilisateur du deuxième dispositif comprise dans le premier billet.
3. Procédé de contrôle selon l'une des revendications précédentes, 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.
4. Procédé de contrôle selon l'une des revendications précédentes, dans lequel le 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.
5. Procédé de contrôle selon l'une des revendications précédentes, dans lequel le billet comprenant une information de comptage (NMax) représentative d'un nombre d'utilisation maximal du billet, il 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 (E26-
7) 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.
6. 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 œuvre par le dispositif utilisateur :
- réception (E103) d'un billet électronique en provenance d'une entité émettrice (10), 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,
- mémorisation dudit billet dans le module de sécurité,
- réception (E22) d'un aléa (c) en provenance d'une entité de contrôle (13),
- 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.
7. 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 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, 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.
8. Dispositif utilisateur (11), agencé pour 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 :
- 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 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.
9. Système de contrôle de billets électroniques comprenant :
- une entité de contrôle selon la revendication 7, et
- au moins un dispositif utilisateur selon la revendication 8.
10. 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 la revendication 6, lorsque le programme est exécuté sur ledit dispositif utilisateur.
11. 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'une des revendications 1 à 5, lorsque le programme est exécuté sur ledit dispositif.
PCT/FR2014/050305 2013-03-29 2014-02-14 Procédé de délivrance de billets électroniques WO2014154961A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1352884A FR3003980A1 (fr) 2013-03-29 2013-03-29 Procede de delivrance de billets electroniques
FR1352884 2013-03-29

Publications (1)

Publication Number Publication Date
WO2014154961A1 true WO2014154961A1 (fr) 2014-10-02

Family

ID=49111309

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2014/050305 WO2014154961A1 (fr) 2013-03-29 2014-02-14 Procédé de délivrance de billets électroniques

Country Status (2)

Country Link
FR (1) FR3003980A1 (fr)
WO (1) WO2014154961A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003938A1 (fr) * 2003-07-04 2005-01-13 Nokia Corporation Administration de zones de stockage a cles cryptographiques
WO2008113951A2 (fr) * 2007-02-28 2008-09-25 France Telecom Procede d'authentification unique d'un utilisateur aupres de fournisseurs de service

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2005003938A1 (fr) * 2003-07-04 2005-01-13 Nokia Corporation Administration de zones de stockage a cles cryptographiques
WO2008113951A2 (fr) * 2007-02-28 2008-09-25 France Telecom Procede d'authentification unique d'un utilisateur aupres de fournisseurs de service

Also Published As

Publication number Publication date
FR3003980A1 (fr) 2014-10-03

Similar Documents

Publication Publication Date Title
EP3085133B1 (fr) Système et procédé pour fournir un service a l'utilisateur d'un terminal mobile
EP1412926B1 (fr) Procede de gestion d'achat de contenus numeriques diffuses et moyens de telechargement de tels contenus
WO2007012584A1 (fr) Procédé de contrôle de transactions sécurisées mettant en oeuvre un dispositif physique unique à bi-clés multiples, dispositif physique, système et programme d'ordinateur correspondants
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d'ordinateur correspondants
EP3665609A1 (fr) Procédé et serveur de certification d'un document électronique
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
WO2020064890A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
WO2019092327A1 (fr) Procédé d'obtention d'une identité numérique de niveau de sécurité élevé
FR3037754A1 (fr) Gestion securisee de jetons electroniques dans un telephone mobile
EP2927857A1 (fr) Méthode de vérification d'authenticité d'un terminal, dispositif et programme correspondant
EP3479518A1 (fr) Procede d'authentification de donnees de paiement, dispositifs et programmes correspondants
EP3095223B1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d'ordinateur correspondants
EP2824625B1 (fr) Méthode de réalisation de transaction, terminal et programme d'ordinateur correspondant
WO2014154961A1 (fr) Procédé de délivrance de billets électroniques
WO2020128240A1 (fr) Traitement d'un service de tickets electroniques
WO2017005644A1 (fr) Procédé et système de contrôle d'accès à un service via un média mobile sans intermediaire de confiance
FR3070516A1 (fr) Procede d'authentification d'un utilisateur aupres d'un serveur d'authentification
EP3395042B1 (fr) Serveur d'authentification pour le contrôle d'accès a un service
FR3011111A1 (fr) Securisation d'une transmission de donnees d'identification
FR3081246A1 (fr) Procede de realisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
EP3371760A1 (fr) Procédé de verification d'identité lors d'une virtualisation
EP3029878A1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement
FR2865060A1 (fr) Procede pour modifier de maniere sure le contenu de la memoire non volatile d'une carte a microcircuit a l'aide d'un terminal portable et d'un serveur distant.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14710010

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14710010

Country of ref document: EP

Kind code of ref document: A1