WO2018002491A1 - Sécurisation de documents électroniques - Google Patents

Sécurisation de documents électroniques Download PDF

Info

Publication number
WO2018002491A1
WO2018002491A1 PCT/FR2017/051682 FR2017051682W WO2018002491A1 WO 2018002491 A1 WO2018002491 A1 WO 2018002491A1 FR 2017051682 W FR2017051682 W FR 2017051682W WO 2018002491 A1 WO2018002491 A1 WO 2018002491A1
Authority
WO
WIPO (PCT)
Prior art keywords
electronic document
terminal
public key
signature
processing terminal
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/FR2017/051682
Other languages
English (en)
Inventor
Patrick Remery
Jacques Traore
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 SA filed Critical Orange SA
Publication of WO2018002491A1 publication Critical patent/WO2018002491A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards

Definitions

  • the invention relates to the field of securing electronic documents.
  • the invention applies in particular to the field of dematerialized electronic medical prescriptions, also called e. requirements.
  • the invention applies to any portable terminal equipped with a microcontroller and a secure memory.
  • the invention is particularly applicable to portable terminals equipped with physical and software resources including a near field communication module capable of communicating with external reading terminals and hosting dematerialized electronic medical prescriptions.
  • a medical prescription is a paper-based document, including a certain amount of information related to the patient as well as to the treatment that is offered to him (prescriptions for drugs and medical devices, prescriptions for acts of care or rehabilitation). , biology prescriptions, radiology prescriptions, etc.).
  • decentralized systems have been proposed.
  • the US2003 / 0121972 patent proposes a system of dematerialized e.prescriptions on an electronic support of the patient.
  • the practitioner the hospital
  • the electronic card is read later by the health professional when the patient wishes to see the prescription issued.
  • a centralized server receives the information concerning I '' e. prescription and its delivery by the pharmacist.
  • the subject of the invention is a method of hosting an electronic document on a secure portable object to access a service, said electronic document having been generated by a generation terminal and to be processed by a processing terminal, the method comprising the following steps in the object:
  • a step of generating a message comprising at least:
  • a step of transmitting said message to the processing terminal a step of transmitting said message to the processing terminal. a step of modifying a piece of data relating to said electronic document in order to prevent another transmission of said document.
  • electronic document any dematerialized document containing electronic data of a user, for example an e. prescription.
  • portable object is meant an object that can be worn by a user, for example a bracelet, or an electronic card, or a laptop, etc.
  • secure portable object is meant such an object equipped with a security element capable of generating electronic signatures, for example a smart card, or a SIM card, or a dedicated memory area of a processor of the object. .
  • data relating to said electronic document is meant any type of data whose modification prevents the portable object, after its modification, to transmit the document again.
  • the invention offers the advantage of an end-to-end secure method for handling an electronic document on an electronic medium, for example an e.prescription.
  • Such a document is generated on a generation terminal, typically that of a practitioner, then transmitted to the object by a secure protocol based on a cryptographic method, and subsequently transmitted from the object to a processing terminal according to another protocol also secure.
  • the exchange is therefore secure from start to finish.
  • the modification of a data item related to the document after a first transmission thereof prevents its retransmission. It is thus possible to read the transmitted information in the object (provided that it has not been erased) but not to replay the protocol between the patient (the portable object) and the practitioner with respect to the same document.
  • a method as described above is further characterized in that the step of modifying a datum is a step of modifying a variable Boolean variable retransmission, whose state is representative of the issuance of said document
  • Boolean variable we mean a variable that takes two distinct states.
  • the variable changes state after transmission of the message.
  • a systematic evaluation of this variable before any transmission makes it possible to detect a possible change of state and to prohibit the reissue of the document. This prohibition is important because it prevents the document from being issued and used several times, which could be particularly troublesome in the case of a sensitive document such as an e.prescription.
  • this change of state if correctly interpreted, may allow the object system to free the memory relative to the document and thus make room for storing other documents.
  • a method as described above is further characterized in that the step of modifying a data item is a step of erasing the electronic document in the memory of the portable object.
  • a method as described above is further characterized in that the authentication step of the terminal generation is followed by a step of modifying a Boolean variable, called reception variable, the state of which is representative of the reception of said document.
  • Such a mode of implementation makes it possible to know that the document ⁇ V e.prescription) has indeed been received on the portable object and can therefore be processed. This allows the user to verify that the e.prescription is available and can benefit from it, ie to submit it to a processing terminal. according to the invention.
  • this mode one can moreover avoid receiving twice the same prescription.
  • a method as described above is further characterized in that it further comprises a step of cancellation of the document.
  • Such a mode of implementation allows the user to cancel e. prescription if it no longer needs it, for example because the prescriber wishes to modify his prescription.
  • it avoids overloading the memory of the portable object, and accidentally issue an unnecessary prescription.
  • the portable object can thus detect that ⁇ 'e. prescription has been canceled, and can advantageously proceed to its deletion or crushing, thus freeing memory on the portable object; it will no longer be possible to calculate a valid signature on the document, nor to issue it.
  • a method as described above is further characterized in that the object comprises a counter of the number of electronic document presentations, in that the signature signed by the private key of the object is a function of this counter, and in that it comprises a step of modifying said counter after each signature step
  • the invention also relates to a portable object for hosting an electronic document for accessing a service, said electronic document having been generated by a generation terminal and to be processed by a processing terminal.
  • portable object comprising: a module for receiving an electronic document and a signature of said electronic document;
  • a module for generating a message comprising at least:
  • a module for transmitting said message to the processing terminal a module able to modify a piece of data relating to said electronic document in order to prevent another transmission of said document.
  • the invention also relates to a secure portable object as described above, characterized in that the obtaining module is a near-field communication module.
  • the near-field communication makes it possible to receive the document in a very simple manner, by approaching the portable object of a reader in the near field, for example of the NFC type, installed for example on the practitioner's terminal.
  • Near-field communication in addition to its simplicity, provides intrinsic safety the exchange since the range of such a mode of communication is reduced to a few centimeters.
  • the invention also relates to a secure portable object as described above, characterized in that the transmission module is a near field communication module.
  • the invention also relates to a secure portable object as described above, characterized in that the authentication module is a subscriber electronic card.
  • the invention also relates to a processing method for transmitting an electronic document from a processing terminal to a processing server, said electronic document coming from a generation terminal and being stored on a portable object, the processing method comprising the following steps on the processing terminal: a step of receiving an electronic document and a signature of said electronic document;
  • a step of generating a message comprising at least:
  • the invention also relates to a method of managing an electronic document hosted on a secure portable object to access a service, said electronic document having been generated by a generation terminal and to be processed by a terminal. processing and stored on a management server, the method comprising the following steps on the management server:
  • the public key of the generation terminal is the public key of the generation terminal.
  • a step of storing the message on the management server if the two authentication steps are successful, a step of storing the message on the management server.
  • the invention also relates to any one of the methods described above, characterized in that the electronic data are dematerialized medical prescription data. According to another embodiment, the invention also relates to any of the methods described above where each of the public keys is certified by the same certification entity.
  • the invention also relates to a computer program adapted to be implemented on a portable object as defined above, the program comprising code instructions which, when the program is executed by a processor, performs the steps of the hosting method.
  • This computer program has features and benefits similar to those previously described in connection with the hosting method.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other form desirable shape.
  • the invention relates to a recording medium readable by a data processor on which is recorded a program comprising program code instructions for performing the steps of the method defined above.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a magnetic recording medium, for example a floppy disk or a disk. hard.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can be downloaded in particular on an Internet type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
  • Figure 1 shows a system for implementing the management of an e. prescription according to the invention.
  • FIG. 2 represents a hardware architecture of a device for storing an e. prescription according to one embodiment of the invention.
  • FIG. 3 represents a flowchart illustrating the various steps of a method in a system according to two embodiments of the invention.
  • Figure 1 shows a system for implementing the management of an e. prescription according to the invention on a portable object (1).
  • the architecture proposed here involves four actors:
  • the object (1) is according to this example a bracelet very simple and inexpensive to wear on the wrist, carrying the services of the user, including in this example the management software e.prescriptions dematerialized and e.prescriptions they -Same.
  • the portable object (1) could take another form. Its only mandatory communication interface is an interface for establishing a local communication, for example of the NFC (Near Field Communication) contactless type, or wired serial USB (Universal Serial Bus), to be able to communicate with the terminals (TD, TP) of the practitioner and health professional. Any other communication interface for establishing point-to-point communication between the portable object and the terminal could be considered.
  • NFC Near Field Communication
  • USB Universal Serial Bus
  • the bracelet can be used as a contactless card in front of these terminals equipped with NFC readers (2,4). It typically comprises an antenna, an NFC controller and a security element (SE) of smart card type, for example a SIM card, for the storage of e.prescriptions and secret data of the user. It may comprise a communication module with the mobile network or any other communication network, for example the Internet. Loading a application for the management of data and associated secret data in the bracelet is done for example via this mode of communication.
  • the object may also optionally include a display and a keyboard. The patient can then read the data from e. prescription on the display of the electronic support, or from an NFC reader connected to its terminal and having a display. He can enter a secret code via the keyboard. A secret code or other biological imprint may indeed be required to read e. prescription.
  • the health professional (pharmacist, physiotherapist, etc.), rated P; when he wishes the treatment of ⁇ 'e. prescription, the patient presents his electronic support to the health professional, this one retrieves the data of ⁇ 'e. prescription from a suitable reader, according to a secure protocol compliant with the standards guaranteeing completeness and confidentiality.
  • the professional (P) is equipped with a terminal (TP) consisting of a computer (5) connected to a non-contact reader (4).
  • the health professional transmit e. prescription to the health organization by any means, according to a secure protocol.
  • the system according to this embodiment comprises a certification authority (6) mandated by the health organization.
  • the four actors likely to emit or receive e. prescription have a public key system containing a private key Si and a public key Pi.
  • Each of the public keys is certified by the certification authority (6) and issued to the various actors.
  • FIG. 2 represents a hardware architecture of a dematerialized e.prescription storage device (1) according to an embodiment of the invention, for example an electronic bracelet to be worn on the wrist of the user. It comprises, according to this example:
  • a processing unit or "CPU” (for "Central Processing Unit"), intended to load instructions in memory, to execute them, to perform operations; a set of memories M, including a volatile memory, or “RAM” (for "Random Access Memory”) used to execute code instructions, store variables, etc. and a non-volatile memory, of the "ROM” type (of "Read Only Memory”), or “EEPROM” (for "Electronically Erasable Programmable Read Only Memory”) intended to contain persistent data, used for example to store the APM application in charge of the management of the interface (in the case where a display is used) and the reading of the data.
  • CPU Central Processing Unit
  • RAM for "Random Access Memory”
  • EEPROM for "Electronically Erasable Programmable Read Only Memory”
  • persistent data used for example to store the APM application in charge of the management of the interface (in the case where a display is used) and the reading of the data.
  • a contactless communication module (CLF), able to communicate the object with a close equipment, in this context the readers 3 and 4 of the practitioner and health professional, via a contactless contact type NFC.
  • this link can use another proximity communication technology with or without wires (Bluetooth, Zigbee, DECT, USB, etc.).
  • a communication module MC adapted to communicate with a security element (SE), via a communication interface (II).
  • a security element (SE) in this example it is a SIM card (for Subscriber Identification Module) but we can consider without loss of generality a memory card hosting a secure element (SD card, Embedded Secure Controller, etc.) or yet with less security, a specific memory area of the object as it is possible in the context of the HCE (for Host Card Emulation).
  • the purpose of the security element SE is to implement, in the context of the present invention, the security mechanisms (signature, encryption) which will be detailed later in support of FIG.
  • the security element SE also comprises a transmission-reception module MC able to communicate with the main processor (CPU) of the object (1) via the communication interface II.
  • the security element SE is a SIM card and conventionally comprises ROM type memories M 'containing in particular the operating system of the security element and programs implementing the security mechanisms. security, EEPROM memories containing the authentication keys, as well as specific applications also called applets running in a RAM type memory.
  • FIG. 2 shows the security applet (APS) used in the context of the present invention for processing the electronic prescriptions according to the security protocols that will be described later.
  • FIG. 3 represents a flowchart illustrating the different steps of a dematerialized prescription management method according to two embodiments of the invention.
  • the security keys are distributed by the server (6) to the various parties.
  • Each pair of keys consists of a private key SK, and a public key PK ,.
  • a certificate is calculated for each entity.
  • the certificate is used to authenticate a public key by certifying its membership (for example the certificate C D atteste that the public key PK D belongs to the practitioner D).
  • This certificate may for example be calculated according to the X509 standard, an asymmetric cryptographic standard for Public Key Infrastructure (PKI) defined by the International Telecommunications Union (ITU).
  • PKI Public Key Infrastructure
  • the practitioner of the terminal (D) has a private key denoted SK D, a public key PK D and D PK certificate calculated by the certification authority;
  • the patient's object (M) has a private key denoted SK M , a public key PK M and the certificate PK M calculated by the certification authority;
  • the health professional's (P) terminal has a private key marked SK P , a public key PK P and the PK P certificate calculated by the certification authority;
  • the server belongs to the health insurance organization and holds the keys of this organization and those to verify the signatures it receives each prescription transmission (health professionals).
  • Each entity also has an identifier (Id,) and a counter (CPTj) of its own, denoted respectively: ID D , CPT D for the practitioner; ID M , CPT m for the patient; ID, CPT P for the health professional; ID S , CPT S for the health insurance organization.
  • ID D CPT D for the practitioner
  • ID M CPT m for the patient
  • ID CPT P for the health professional
  • ID S CPT S for the health insurance organization.
  • the bracelet was correctly initialized during previous steps, in particular via: - an installation step of the application (APM, APS).
  • the application can be installed during the manufacturing step of the bracelet and personalized during its marketing, from an online device of the health organization; alternatively, the application can be downloaded or updated after the sale of the bracelet (for example on the health agency's server or on another application server) and the personal data of the user entered by the device online health agency;
  • steps E1 to E43 relating to the exchange of an e.prescription since the prescription by the doctor until storage on the server health insurance. These stages are grouped into three phases.
  • the patient M is at the doctor / practitioner P. He presents his bracelet to the NFC reader associated with the terminal of the practitioner P. A number of steps follows in order to ensure a secure communication between the bracelet and the practitioner's terminal.
  • the practitioner's identifiers ID D and CPT D are transmitted to the electronic bracelet that receives them during a step E10 and responds in a next step Eli by transmitting its own identifiers ID M and CPT M as well. as his public key PK M and a signed message using his private key SK M including the patient's identifiers and the identifiers previously received from the practitioner. This message is noted:
  • ID M , CPT M , PK M , S M ⁇ M ID, CPT M: IDp, CPTQ ⁇ SK M
  • the practitioner's terminal tests the validity of the received message, using the PK M public key he has just received; in particular, it checks the validity of the signature S M of the message. If the result of verification is correct, it means that the signature has been issued by the patient (that is, he is correctly identified). Otherwise, the process stops. In this case it can be requested the online help of the application's after-sales service, or it may be decided to establish a paper-based order, etc.
  • the certificate C M of the patient is transmitted in the message and used by the receiver (the practitioner D) to verify that the PK M public key is that of the patient . The same goes for the messages described later, exchanged between the patient and the health professional.
  • the practitioner enters his prescription 0, and the terminal calculates a signature of the order So, in the form:
  • the prescription and the public key are signed using the private key SK D of the practitioner's terminal (TD) to generate the signature So of the order, proving that the order is authentic.
  • step E5 a message is transmitted in the near field from the practitioner's reader to the bracelet.
  • the counter of e. requirements CPT D is incremented in a next step E6.
  • This counter (irreversible) aims to make it impossible to use S signatures already issued (the replay). Indeed, each signature calculated on the basis of a different counter value is unique.
  • each signature calculated on the basis of a different counter value is unique.
  • the respective counters of the health professional and the patient which are incremented during steps E14, E20 and E35. According to a variant well known to those skilled in the art, these counters can be replaced by hazards.
  • the bracelet receives the message during a step E12 and tests the validity during a step E13, using the public key PK D he just received; the security element verifies the validity of the signature S D of the message. If the verification result is correct, it means that the signature has been issued by the practitioner, so that the practitioner is correctly identified. Otherwise, the process stops.
  • the counter of the bracelet CPT M is incremented during a next step E14. The incrementation of this counter makes it possible to guard against a fraudulent duplication of Ye.prescription. It will be noted that this step E14 relates to the Practitioner-Patient protocol.
  • step E20 This same counter will be incremented in step E20 at the end of the exchange between the bracelet and the health professional, but according to a variant of implementation could be used two separate counters in the bracelet: one to secure the protocols Practitioner-Patient and the other to secure protocols Patient-Professional Health.
  • the SIM card can use one or more variables representative of the state of the document to avoid in particular its reissue.
  • one or more flags in English flag (s), which can take binary values (0 or 1) corresponding to two distinct values of the electrical voltage of the EEPROM of the security element (the state change between two values being managed by the software) associated with Ye.prescription: this flag is for example initialized to 1 and reset when it is activated. These flags are used to indicate the different states of Ye.prescription (canceled, discount, non-delivery, etc.). Depending on the context and the type of document, one could consider other states.
  • the state of the prescription is managed in the secure application (APS) that runs in the SIM card; for example, a chronological serial number is chosen by the secure application for the e. prescription, which can be in one of the following three states, for example managed by three flags fl to f3: • "received not delivered”; flag fl is updated during step E14b; this flag is called "receiving variable";
  • APS secure application
  • the new prescriptions may take the place of those which have been delivered or canceled, preferably the oldest ones.
  • the patient M is at the health professional (the Pharmacist) P. He presents his bracelet to the NFC reader associated with the professional's processing terminal. A number of steps follow in order to ensure secure communication between the bracelet and the treatment terminal of the health professional.
  • the patient's ID M and CPT M identifiers are transmitted to the professional who receives them during a step E30 and responds in a next step E31 by transmitting his own identifiers ID P and CPT P as well as his public key PK and a signed message using his private key SK P containing the identifiers of the professional and the identifiers previously received from the patient.
  • the bracelet receives this message during a step E16 and then tests the validity during a step E17, using the public key PK P he just received; it checks the validity of the signature S P of the message. If the verification result is correct, it means that the signature has been issued by the professional, and therefore it is correctly identified.
  • step E19 a message is transmitted in the near field from the bracelet to the professional.
  • This message including e. prescription, its signature, public keys and a signed message using its private key SK M , is noted:
  • the prescription counter CPT M is incremented during a following step E20.
  • the purpose of step E20 is to update the CPT M counter of the portable object, which is used to generate the electronic signature S M. Note that the update of this counter does not prevent the reissue of the message if the algorithm is implemented a second time for the same e. prescription, but that in this case the signature S M will be different from that obtained during the first implementation. As a result, this mechanism prevents replay of e.prescription.
  • step E21 is to update the flag f3 (corresponding to the state "e.prescription grasp"), prohibiting the reissue of V e.prescription which has just been transferred, as explained above.
  • the e. prescriptions remain in memory of the portable object. However, if one of the flags f2 or f3 is activated (ie the binary value 0), this means that the e.prescription can be overwritten by the arrival of a new e.prescription, or cleared by the operating system (CPU) of the object.
  • theprescription is erased from the EEPROM memory of the security element during step ⁇ 2. V! e.prescription being erased, it is no longer possible to calculate a new signature in step E18.
  • the step E21 of modifying the retransmission flag (f3) is no longer necessary because the retransmission will be made impossible by this erasure.
  • the modification of flags fl and f2 also becomes optional because only the object remains e. prescriptions received and not issued. Note that the erasure can be total or partial, it suffices for example to delete the first data of the e. prescription to make it impossible to calculate the signature and thereby a new issue.
  • the health professional's processing terminal receives the data during a step E32.
  • this terminal tests the validity of the received message, using the PK M public key it has received; he checks the validity of the signature of the message. If the verification result is correct, it means that the signature has been issued by the patient's object.
  • the treatment terminal of the health professional tests the validity of the signature So, using the public key PK D of the practitioner D, he received it checks the validity S 0 of the signature of the message. If the verification result is correct, it means that the e. prescription is authentic.
  • the counter of the health professional CPT P is incremented in a next step E35.
  • The. prescription is treated in a subsequent step E36 (drug delivery, physiotherapy, etc.)
  • the health professional P who just treated ⁇ 'e. prescription, transmits it to the server (7) of the health organization, via any means of communication, for example on an Internet network.
  • a number of steps follow in order to ensure secure communication between the health professional's processing terminal and the healthcare organization's server.
  • step E37 the message is transmitted to the health organization.
  • steps E41 and E42 correspond to the verification of the message received and the So signature of Ye.prescription. If the message is correctly deciphered, it means that the data sent by the health professional are authentic and in particular:
  • the health organization's database can be updated during a step E43.
  • This system could also apply to any insurance system (home, ...) requiring the intervention of the three actors mentioned above: the user, the expert and the professional.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

L'invention s'applique à un objet portable (1) pour l'hébergement d'un document électronique (O) pour accéder à un service. Le document électronique est généré par un terminal de génération (TD) et doit être traité par un terminal de traitement (TP). L'objet portable comporte les modules suivants : - réception d'un document électronique (O) et d'une signature (So); - obtention (CLF) de la clé publique (PKD) du terminal de génération (TD), et d'une signature (SD) dudit terminal de génération (TD); - obtention (CLF) de la clé publique (PKP) du terminal de traitement (TP) et d'une signature (SP) dudit terminal de traitement (TP); - authentification du terminal de génération; - authentification du terminal de traitement; - génération d'un message - émission dudit message vers le terminal de traitement - un module apte à modifier une donnée relative audit document électronique afin de prévenir une autre émission.

Description

Sécurisation de documents électroniques.
Domaine technique
L'invention se rapporte au domaine de la sécurisation de documents électroniques. L'invention s'applique en particulier au domaine des prescriptions médicales électroniques dématérialisées, aussi appelées e. prescriptions.
L'invention s'applique à tout terminal portable équipé d'un microcontrôleur et d'une mémoire sécurisée. L'invention s'applique tout particulièrement à des terminaux portables équipés de ressources physiques et logicielles incluant un module de communication en champ proche apte à communiquer avec des terminaux externes de lecture et à héberger des prescriptions médicales électroniques dématérialisées.
Etat de la technique
Actuellement, une ordonnance médicale est un document géré sur un support papier, incluant un certain nombre d'informations liées au patient ainsi qu'au traitement qui lui est proposé (prescriptions de médicaments et dispositifs médicaux, prescriptions d'actes de soins ou de rééducation, prescriptions de biologie, prescriptions de radiologie, etc.).
Récemment, il a été proposé un certain nombre de solutions visant à dématérialiser l'ordonnance médicale sous forme de document électronique, appelée dans la suite e.prescription.
Dans ce contexte, des projets à' e. prescriptions centralisées sur une base de données sont en cours d'étude. Un tel système est décrit par exemple dans la note d'orientation établie par les Conseils Nationaux des Ordres des Professions de santé, réunis en France au sein d'un Comité de Liaison Inter Ordres (CLIO Santé), disponible à l'adresse https://www.conseil- national.medecin.fr/sites/default/files/Prescription_electronique.pdf. Dans un tel système, Y e.prescription établie par le praticien est transmise et rangée dans une base de données accessible de tout endroit du territoire acceptant les e.prescriptions. Depuis cette base, \'e. prescription est accessible aux professionnels de santé (pharmaciens, kinésithérapeutes, etc.) impliqués dans la démarche. Le professionnel de santé peut consulter la base de données à l'aide de sa carte professionnelle de santé et de la carte de santé du patient.
Une telle gestion centralisée des e.prescriptions comporte cependant un certain nombre d'inconvénients, puisque la base de données pour gérer l'ensemble des e.prescriptions est complexe, volumineuse, nécessitant des investissements importants de la part des organismes de santé. De surcroît la base de données centralisée peut-être inaccessible au moment où le patient se présente au professionnel de santé.
Plus récemment ont donc été proposés des systèmes décentralisés. Par exemple, le brevet US2003/0121972 propose un système de e.prescriptions dématérialisées sur un support électronique du patient. Dans ce système, le praticien (l'hôpital) inscrit l'ordonnance dématérialisée dans le support électronique, de préférence une carte sécurisée. La carte électronique est lue ultérieurement par le professionnel de santé lorsque le patient souhaite voir délivrer son ordonnance. Un serveur centralisé reçoit les informations concernant I' 'e. prescription et sa délivrance par le pharmacien.
Cependant, ce système n'offre aucune protection contre la duplication éventuelle ou une attaque par « rejeu » de Γ e.prescription. On rappelle qu'une attaque par rejeu (en anglais, « replay attack ») est une forme d'attaque sur un réseau de télécommunications, dans laquelle une transmission de données est frauduleusement répétée par une tierce partie interceptant les paquets de données sur la ligne. Un tel système n'est donc pas fiable. Dans le contexte de l'ordonnance électronique elle peut notamment aboutir à une réplication de Γ e.prescription (qui pourra être utilisée plusieurs fois). En effet, si une personne tierce a subtilisé soit le support électronique, soit l'application logicielle et l'ordonnance, il peut se présenter dans une ou plusieurs pharmacies pour bénéficier de la e.prescription. L'invention offre une solution ne présentant pas les inconvénients de l'état de la technique.
L'invention
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
A cet effet, selon un aspect fonctionnel, l'invention a pour objet un procédé d'hébergement d'un document électronique sur un objet portable sécurisé pour accéder à un service, ledit document électronique ayant été généré par un terminal de génération et devant être traité par un terminal de traitement, le procédé comportant les étapes suivantes dans l'objet :
- une étape de réception d'un document électronique et d'une signature dudit document électronique ;
- une étape d'obtention de la clé publique du terminal de génération complémentaire d'une clef privée du terminal de génération, et d'une signature dudit terminal de génération ;
- une étape d'obtention de la clé publique du terminal de traitement complémentaire d'une clef privée du terminal de traitement et d'une signature dudit terminal de traitement ;
- une étape d'authentification du terminal de génération à l'aide de ladite clef publique du terminal de génération ;
- une étape d'authentification du terminal de traitement à l'aide de ladite clef publique du terminal de traitement ;
- si les deux étapes d'authentification sont réussies :
• une étape de génération d'un message comportant au moins :
- le document électronique et sa signature ;
- La clé publique du terminal de génération ;
- La clé publique de l'objet complémentaire d'une clef privée de l'objet ;
- une signature signée par la clé privée de l'objet ;
- une étape d'émission dudit message vers le terminal de traitement. - une étape de modification d'une donnée relative audit document électronique afin de prévenir une autre émission dudit document.
Par « document électronique », on entend tout document dématérialisé contenant des données électroniques d'un utilisateur, par exemple une e. prescription.
Par « objet portable », on entend un objet qui peut être porté par un utilisateur, par exemple un bracelet, ou une carte électronique, ou un ordinateur portable, etc. Par objet portable « sécurisé » on entend un tel objet équipé d'un élément de sécurité apte à générer des signatures électroniques, par exemple une carte à puce, ou une carte SIM, ou une zone mémoire dédiée d'un processeur de l'objet.
Par « donnée relative audit document électronique », on entend tout type de donnée dont une modification empêche l'objet portable, ultérieurement à sa modification, de transmettre une nouvelle fois le document. Ainsi, l'invention offre l'avantage d'un procédé sécurisé de bout en bout pour la manipulation d'un document électronique sur un support électronique, par exemple une e.prescription. Un tel document est généré sur un terminal de génération, typiquement celui d'un praticien, puis transmis à l'objet par un protocole sécurisé basé sur une méthode cryptographique, puis transmis ultérieurement de l'objet vers un terminal de traitement selon un autre protocole également sécurisé. L'échange est donc sécurisé de bout en bout. De surcroît, avantageusement, la modification d'une donnée liée au document après une première émission de celui-ci empêche sa réémission. Il reste ainsi possible de lire dans l'objet les informations transmises (à condition qu'elles n'aient pas été effacées) mais pas de rejouer le protocole entre le patient (l'objet portable) et le praticien relativement au même document.
Selon un mode de mise en œuvre particulier de l'invention, un procédé tel que décrit ci-dessus est en outre caractérisé en ce que l'étape de modification d'une donnée est une étape de modification d'une variable booléenne, dite variable de réémission, dont l'état est représentatif de l'émission dudit document Par variable booléenne, on entend une variable qui prend deux états distincts. Avantageusement selon ce mode de réalisation, la variable change d'état après la transmission du message. Une évaluation systématique de cette variable avant toute transmission permet de détecter un éventuel changement d'état et d'interdire la réémission du document. Cette interdiction est importante car elle évite que le document soit émis et utilisé plusieurs fois, ce qui pourrait être particulièrement gênant dans le cas d'un document sensible comme une e.prescription. De plus, ce changement d'état, s'il est correctement interprété, peut permettre au système de l'objet de libérer la mémoire relative au document et de faire ainsi de la place pour mémoriser d'autres documents.
Selon un deuxième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement avec le précédent, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'étape de modification d'une donnée est une étape d'effacement du document électronique dans la mémoire de l'objet portable.
Ce mode de mise en œuvre de l'invention permet d'interdire simplement la réémission du document. Une fois le document effacé, tout calcul d'une nouvelle signature mènera à un résultat incorrect et empêchera automatiquement la réémission du document. Selon encore un troisième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'étape d'authentification du terminal de génération est suivie d'une étape de modification d'une variable booléenne, dite variable de réception, dont l'état est représentatif de la réception dudit document.
Un tel mode de mise en œuvre permet de savoir que le document {V e.prescription) a effectivement été reçue sur l'objet portable et peut donc être traité. Ceci permet à l'utilisateur de vérifier que Y e.prescription est disponible et qu'il peut en bénéficier, c'est-à-dire la soumettre à un terminal de traitement selon l'invention. Avantageusement selon ce mode, on peut de plus éviter de recevoir deux fois la même prescription.
Selon encore un quatrième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce qu'il comporte en outre une étape d'annulation du document .
Un tel mode de mise en œuvre permet à l'utilisateur d'annuler l'e. prescription s'il n'en a plus besoin, par exemple parce que le prescripteur souhaite modifier sa prescription. Avantageusement, on évite de surcharger la mémoire de l'objet portable, et d'émettre accidentellement une prescription inutile. L'objet portable peut ainsi détecter que \'e. prescription a été annulée, et peut avantageusement procéder à sa suppression ou à son écrasement, libérant ainsi de la mémoire sur l'objet portable ; il ne sera plus possible de calculer une signature valide sur le document, ni donc de l'émettre. Selon encore un cinquième mode de mise en œuvre particulier de l'invention, qui pourra être mis en œuvre alternativement ou cumulativement avec les précédents, un procédé tel que décrit plus haut est en outre caractérisé en ce que l'objet comporte un compteur du nombre de présentations de documents électroniques, en ce que la signature signée par la clé privée de l'objet est fonction de ce compteur, et en ce qu'il comporte une étape de modification dudit compteur après chaque étape de signature
Avantageusement selon ce mode de réalisation, l'incrémentation du compteur permet de générer une signature différente. Le « rejeu » du document sera donc détectable et pourra être aisément évité. Selon un aspect matériel, l'invention concerne également un objet portable pour l'hébergement d'un document électronique pour accéder à un service, ledit document électronique ayant été généré par un terminal de génération et devant être traité par un terminal de traitement, l'objet portable comportant : - un module de réception d'un document électronique et d'une signature dudit document électronique ;
- un module d'obtention de la clé publique du terminal de génération complémentaire d'une clef privée du terminal de génération, et d'une signature dudit terminal de génération ;
- un module d'obtention de la clé publique du terminal de traitement complémentaire d'une clef privée (SK ) du terminal de traitement et d'une signature dudit terminal de traitement ;
- un module d'authentification du terminal de génération à l'aide de ladite clef publique du terminal de génération ;
- un module d'authentification du terminal de traitement à l'aide de ladite clef publique du terminal de traitement ;
- un module de génération d'un message comportant au moins :
- le document électronique et sa signature ;
- La clé publique du terminal de génération ;
- La clé publique de l'objet complémentaire d'une clef privée de l'objet ;
- une signature signée par la clé privée de l'objet ;
- un module d'émission dudit message vers le terminal de traitement - un module apte à modifier une donnée relative audit document électronique afin de prévenir une autre émission dudit document.
Selon un autre aspect matériel, l'invention concerne également un objet portable sécurisé tel que décrit ci-dessus, caractérisé en ce que le module d'obtention est un module de communication en champ proche.
Avantageusement selon ce mode de réalisation, la communication en champ proche permet de recevoir le document de manière très simple, en approchant l'objet portable d'un lecteur en champ proche, par exemple de type NFC, installé par exemple sur le terminal du praticien. La communication en champ proche, outre sa simplicité, permet d'assurer une sécurité intrinsèque à l'échange puisque la portée d'un tel mode de communication est réduite à quelques centimètres.
Selon un autre aspect matériel, l'invention concerne également un objet portable sécurisé tel que décrit ci-dessus, caractérisé en ce que le module de transmission est un module de communication en champ proche
Selon un autre aspect matériel, l'invention concerne également un objet portable sécurisé tel que décrit ci-dessus, caractérisé en ce que le module d'authentification est une carte électronique d'abonné.
Selon un autre aspect logiciel, l'invention concerne également un procédé de traitement pour transmettre un document électronique d'un terminal de traitement vers un serveur de traitement, ledit document électronique provenant d'un terminal de génération et étant stocké sur un objet portable, le procédé de traitement comportant les étapes suivantes sur le terminal de traitement : - une étape de réception d'un document électronique et d'une signature dudit document électronique ;
- une étape d'obtention de la clé publique complémentaire d'une clef privée de l'objet portable, et d'une signature dudit objet portable ;
- une étape d'obtention de la clé publique du terminal de génération ;
- une étape d'authentification de l'objet portable à l'aide de ladite clef publique de l'objet ;
- une étape d'authentification du terminal de génération à l'aide de ladite clef publique du terminal de génération;
- si les deux étapes d'authentification sont réussies :
· une étape de génération d'un message comportant au moins :
- le document électronique et sa signature ;
- La clé publique du terminal de génération ;
- La clé publique du terminal de traitement ;
- une signature signée par la clé privée du terminal de traitement ; • une étape de transmission dudit message vers un serveur de traitement des documents électroniques.
Selon un autre aspect logiciel, l'invention concerne également un procédé de gestion d'un document électronique hébergé sur un objet portable sécurisé pour accéder à un service, ledit document électronique ayant été généré par un terminal de génération et devant être traité par un terminal de traitement et stocké sur un serveur de gestion, le procédé comportant les étapes suivantes sur le serveur de gestion :
- réception d'un message en provenance du serveur de traitement, ledit message comprenant :
- le document électronique et sa signature ;
La clé publique du terminal de génération ;
La clé publique du terminal de traitement ;
- une signature signée par la clé privée du terminal de traitement ;
- authentification du terminal de traitement à l'aide de ladite clef publique du terminal de traitement ;
- authentification du terminal de génération à l'aide de ladite clef publique du terminal de génération ;
- si les deux étapes d'authentification sont réussies, une étape de stockage du message sur le serveur de gestion.
Selon un autre mode de réalisation, l'invention concerne également l'un quelconque des procédés décrits ci-dessus, caractérisé en ce que les données électroniques sont des données de prescription médicale dématérialisée. Selon un autre mode de réalisation, l'invention concerne également l'un quelconque des procédés décrits ci-dessus où chacune des clés publiques est certifiée par une même entité de certification.
Selon un autre aspect matériel, l'invention concerne également un programme d'ordinateur apte à être mis en œuvre sur un objet portable tel que défini ci-dessus, le programme comprenant des instructions de code qui, lorsque le programme est exécuté par un processeur, réalise les étapes du procédé d'hébergement.
Ce programme d'ordinateur présente des caractéristiques et avantages analogues à ceux décrits précédemment en relation avec le procédé d'hébergement. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
Selon encore un autre aspect matériel, l'invention a trait à un support d'enregistrement lisible par un processeur de données sur lequel est enregistré un programme comprenant des instructions de code de programme pour l'exécution des étapes du procédé défini ci-dessus.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
L'invention sera mieux comprise à la lecture de la description qui suit, donnée à titre d'exemple et faite en référence aux dessins annexés.
Les figures: La figure 1 représente un système permettant de mettre en œuvre la gestion d'une e. prescription selon l'invention.
La figure 2 représente une architecture matérielle d'un dispositif de stockage d'une e. prescription selon un mode de réalisation de l'invention. La figure 3 représente un organigramme illustrant les différentes étapes d'un procédé dans un système selon deux modes de réalisation de l'invention.
Description détaillée d'un exemple de réalisation illustrant l'invention
La figure 1 représente un système permettant de mettre en œuvre la gestion d'une e. prescription selon l'invention sur un objet portable (1). L'architecture proposée ici fait intervenir quatre acteurs :
- le patient (ou Malade noté M) propriétaire de l'objet portable (1) destiné au stockage des e.prescriptions ; l'objet (1) est selon cet exemple un bracelet très simple et peu coûteux à porter au poignet, portant les services de l'utilisateur, incluant dans cet exemple le logiciel de gestion des e.prescriptions dématérialisées ainsi que les e.prescriptions elles-mêmes. L'objet portable (1) pourrait prendre une toute autre forme. Sa seule interface de communication obligatoire est une interface pour établir une communication locale, par exemple de type sans contact NFC (Near Field Communication), ou filaire série USB (Universal Sériai Bus), pour pouvoir dialoguer avec les terminaux (TD, TP) du praticien et du professionnel de santé. Toute autre interface de communication permettant d'établir une communication point à point entre l'objet portable et le terminal pourrait être envisagée. Dans la suite, on considère qu'il s'agit d'une interface sans contact de type NFC. Dans ce contexte, le bracelet peut être utilisé comme une carte sans contact face à ces terminaux équipés de lecteurs NFC (2,4). Il comprend typiquement une antenne, un contrôleur NFC et un élément de sécurité (SE) de type carte à puce, par exemple une carte SIM, pour le stockage des e.prescriptions et des données secrètes de l'utilisateur. Il peut comporter un module de communication avec le réseau mobile ou un quelconque autre réseau de communication, par exemple Internet. Le chargement d'une application pour la gestion des données et des données secrètes associées dans le bracelet se fait par exemple via ce mode de communication. L'objet peut aussi comporter, optionnellement, un afficheur et un clavier. Le patient peut alors lire les données de \'e. prescription sur l'afficheur du support électronique, ou à partir d'un lecteur NFC connecté à son terminal et possédant un afficheur. Il peut entrer un code secret via le clavier. Un code secret ou toute autre empreinte biologique peut en effet être requis pour lire \'e. prescription.
- Le praticien qui délivre les e. prescriptions (ou Docteur, noté D dans la suite), dont le terminal (TD) est constitué ici d'un ordinateur (3) relié à un lecteur sans contact (2) ; on rappelle qu'une ordonnance est un document électronique, ou e. prescription, incluant un certain nombre d'informations liées au patient ainsi qu'au traitement qui lui est proposé (prescriptions de médicaments et dispositifs médicaux, prescriptions d'actes de soins ou de rééducation, prescriptions de biologie, de radiologie, etc.) Le praticien peut, après avoir saisi \'e. prescription, transmettre à l'aide du lecteur de proximité (2) connecté à son terminal de saisie les données au support électronique sécurisé (1) du patient selon un protocole sécurisé conforme aux normes d'échanges sécurisés garantissant l'intégralité et la confidentialité des données, comme il sera décrit plus en détails par la suite. Par lecteur de proximité, on entend un lecteur local, qui se trouve directement relié au terminal de traitement du praticien ; un tel lecteur peut être notamment de type sans contact, ou avec contact via une liaison USB, etc.
- Le professionnel de santé (pharmacien, kinésithérapeute, etc.), noté P ; lorsqu'il souhaite le traitement de \'e. prescription, le patient présente son support électronique au professionnel de santé, celui-ci récupère les données de \' e. prescription à partir d'un lecteur adapté, selon un protocole sécurisé conforme aux normes garantissant l'intégralité et la confidentialité. Selon cet exemple, le professionnel (P) est équipé d'un terminal (TP) constitué d'un ordinateur (5) relié à un lecteur sans contact (4).
- L'organisme de santé représenté par le serveur 7 ; le serveur 7 est par exemple un serveur connecté à un réseau Internet (8). Le professionnel de santé transmet \'e. prescription à l'organisme de santé par tout moyen, selon un protocole sécurisé.
De plus, le système selon ce mode de réalisation comporte une autorité de certification (6) mandatée par l'organisme de santé. Les quatre acteurs susceptibles d'émettre ou recevoir une e. prescription disposent d'un système à clés publiques contenant une clé privée Si et une clé publique Pi. Chacune des clés publiques est certifiée par l'autorité de certification (6) et délivrée aux différents acteurs.
La figure 2 représente une architecture matérielle d'un dispositif de stockage à' e.prescriptions dématérialisées (1) selon un mode de réalisation de l'invention, par exemple un bracelet électronique à porter au poignet de l'utilisateur. Il comporte, selon cet exemple :
-une unité de traitement, ou « CPU » (pour « Central Processing Unit »), destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ; un ensemble de mémoires M, dont une mémoire volatile, ou "RAM" (pour "Random Access Memory") utilisée pour exécuter des instructions de code, stocker des variables, etc. et une mémoire non volatile, de type « ROM » (de l'anglais « Read Only Memory »), ou « EEPROM » (pour « Electronically Erasable Programmable Read Only Memory ») destinée à contenir des données persistantes, utilisées par exemple pour stocker l'application APM en charge notamment de la gestion de l'interface (dans la cas où un afficheur est utilisé) et de la lecture des données.
- un module de communication sans contact (CLF), apte à faire communiquer l'objet avec un équipement proche, dans ce contexte les lecteurs 3 et 4 du praticien et du professionnel de santé, via une liaison sans contact de type NFC. Alternativement, cette liaison peut utiliser une autre technologie de communication de proximité avec ou sans fils (Bluetooth, Zigbee, DECT, USB, etc.)
- un module de communication MC apte à communiquer avec un élément de sécurité (SE), via une interface de communication (II). - un élément de sécurité (SE) ; dans cet exemple il s'agit d'une carte SIM (pour Subscriber Identification Module) mais on peut envisager sans perte de généralité une carte à mémoire hébergeant un élément sécurisé (SD card, Embedded Secure Controller, etc.) ou encore, avec cependant une sécurité moindre, une zone mémoire spécifique de l'objet comme il est envisageable dans le contexte de la norme HCE (pour Host Card Emulation). L'élément de sécurité SE a pour fonction de mettre en œuvre, dans le cadre de la présente invention, les mécanismes de sécurité (signature, chiffrage) qui seront détaillés plus tard à l'appui de la figure 3 ; à cet effet, la carte SIM possède notamment la clé privée (SKM) qui va lui permettre de chiffrer les données émises en association avec \' e. prescription, ainsi que, temporairement, les clés publiques (PKp, PKD) des autres entités. L'élément de sécurité SE comporte aussi un module d'émission- réception MC apte à dialoguer avec le processeur principal (CPU) de l'objet (1) via l'interface de communication II. Dans ce mode de réalisation de l'invention, l'élément de sécurité SE est une carte SIM et comporte classiquement des mémoires M' de type ROM contenant notamment le système d'exploitation de l'élément de sécurité et des programmes implémentant les mécanismes de sécurité, des mémoires de type EEPROM contenant les clés d'authentification, ainsi que des applications spécifiques aussi appelées applets s'exécutant dans une mémoire de type RAM. Sur la figure 2 est représentée l'applet (APS) de sécurité utilisée dans le cadre de la présente invention pour traiter les prescriptions électroniques suivant les protocoles de sécurité qui seront décrits par la suite.
La figure 3 représente un organigramme illustrant les différentes étapes d'un procédé de gestion de prescriptions dématérialisées selon deux modes de réalisation de l'invention.
Lors d'une étape E0 initiale, les clés de sécurité sont distribuées par le serveur (6) aux différents intervenants. Chaque couple de clés consiste en une clé privée SK, et une clé publique PK,. De manière préférentielle, mais non obligatoire, un certificat est calculé pour chaque entité. Classiquement, le certificat sert à authentifier une clé publique en attestant son appartenance (par exemple le certificat CD atteste que la clé publique PKD appartient bien au praticien D). Ce certificat peut par exemple être calculé selon la norme X509, une norme de cryptographie asymétrique pour les infrastructures à clés publiques (PKI) définie par l'Union internationale des télécommunications (UIT).
Ainsi, à la suite de cette étape :
• Le terminal du praticien (D) dispose d'une clé privée notée SKD, d'une clé publique PKD et du certificat de PKD calculé par l'autorité de certification ;
• L'objet du patient (M) dispose d'une clé privée notée SKM, d'une clé publique PKM et du certificat de PKM calculé par l'autorité de certification ;
• Le terminal du professionnel de santé (P) dispose d'une clé privée notée SKP, d'une clé publique PKP et du certificat de PKP calculé par l'autorité de certification ;
Le serveur appartient à l'organisme d'assurance de santé et détient les clés de cet organisme et celles permettant de vérifier les signatures qu'il reçoit à chaque transmission d'ordonnance (professionnels de santé).
Chaque entité dispose par ailleurs d'un identifiant (Id,) et d'un compteur (CPTj) qui lui sont propres, notées respectivement : IDD, CPTD pour le praticien ; IDM, CPTm pour le patient ; ID , CPTP pour le professionnel de santé ; IDS, CPTS pour l'organisme d'assurance de santé. Ces compteurs ont pour but de rendre impossible l'utilisation de signatures S déjà émises par l'un des intervenants (donc les rejeux).
On suppose par ailleurs que le bracelet a été correctement initialisé lors d'étapes préalables, notamment via : - une étape d'installation de l'application (APM, APS). L'application peut être installée pendant l'étape de fabrication du bracelet puis personnalisée lors de sa commercialisation, à partir d'un dispositif en ligne de l'organisme de santé ; alternativement, l'application peut être téléchargée ou mise à jour après la vente du bracelet (par exemple sur le serveur de l'organisme de santé ou sur un autre serveur d'applications) et les données personnelles de l'utilisateur entrées par le dispositif en ligne de l'organisme de santé ;
- une étape de test d'éligibilité pour vérifier la compatibilité de la carte SIM avec l'application e.prescription.
- une étape de personnalisation des données de l'utilisateur dans la carte SIM.
On va maintenant décrire les étapes El à E43 relatives aux échanges d'une e.prescription depuis la prescription par le médecin jusqu'au stockage sur le serveur de l'assurance maladie. Ces étapes se regroupent en trois phases.
Au cours d'une première phase, le patient M se trouve chez le médecin/Praticien P. Il présente son bracelet au lecteur NFC associé au terminal du praticien P. Un certain nombre d'étapes s'ensuit dans le but d'assurer une communication sécurisée entre le bracelet et le terminal du praticien. Lors d'une étape El, les identifiants IDD et CPTD du praticien sont transmis au bracelet électronique qui les reçoit lors d'une étape E10 et répond lors d'une étape suivante Eli en transmettant ses propres identifiants IDM et CPTM ainsi que sa clé publique PKM et un message signé en utilisant sa clé privée SKM comportant les identifiants du patient et les identifiants préalablement reçus du praticien. Ce message est noté :
IDM, CPTM, PKM, SM = {IDM, CPTM : IDp, CPTQ ^SKM
Puis lors d'une étape E3, le terminal du praticien teste la validité du message reçu, à l'aide de la clé publique PKM qu'il vient de recevoir ; en particulier, il vérifie la validité de la signature SM du message. Si le résultat de vérification est correct, cela signifie que la signature a bien été émise par le patient (c'est-à-dire qu'il est correctement identifié). Dans le cas contraire, le procédé s'arrête. Il peut dans ce cas être demandé l'aide en ligne du service après-vente de l'application, ou il peut être décidé d'établir une prescription papier, etc. De manière préférentielle, non illustrée mais bien connue de l'homme du métier, le certificat CM du patient est transmis dans le message et utilisé par le récepteur (le praticien D) pour vérifier que la clé publique PKM est bien celle du patient. Il en va de même pour les messages décrits par la suite, échangés entre le patient et le professionnel de santé. Puis lors d'une étape E4, le praticien saisit son ordonnance 0, et le terminal calcule une signature de l'ordonnance So, sous la forme :
So= {0, PKD}SKD
C'est à dire que l'ordonnance et la clé publique sont signées en utilisant la clé privée SKD du terminal du praticien (TD) pour générer la signature So de l'ordonnance, prouvant que l'ordonnance est authentique.
Puis, lors de l'étape E5, un message est transmis en champ proche depuis le lecteur du praticien jusqu'au bracelet. Ce message, comprenant V e. prescription, sa signature, la clé publique du praticien et une signature SD obtenue à l'aide de la clé privée SKD du praticien, est noté : 0, So, PKD, SD = {IDM, CPTm , IDD, CPTD }SKD
Le compteur de e. prescriptions CPTD est incrémenté lors d'une étape E6 suivante. Ce compteur (irréversible) a pour but de rendre impossible l'utilisation de signatures S déjà émises (les rejeux). En effet, chaque signature calculée sur la base d'une valeur de compteur différente est unique. Il en va de même pour les compteurs respectifs du professionnel de santé et du patient, qui sont incrémentés lors des étapes E14, E20 et E35. Selon une variante bien connue de l'homme du métier, ces compteurs peuvent être remplacés par des aléas.
Le bracelet reçoit le message lors d'une étape E12 et en teste la validité lors d'une étape E13, à l'aide de la clé publique PKD qu'il vient de recevoir ; l'élément de sécurité vérifie la validité de la signature SD du message. Si le résultat de vérification est correct, cela signifie que la signature a bien été émise par le praticien, donc que le praticien est correctement identifié. Dans le cas contraire, le procédé s'arrête. Le compteur du bracelet CPTM est incrémenté lors d'une étape E14 suivante. L'incrémentation de ce compteur permet de se prémunir d'une duplication frauduleuse de Ye.prescription. On notera que cette étape E14 concerne le protocole Praticien-Patient. Ce même compteur sera incrémenté à l'étape E20 à la fin de l'échange entre le bracelet et le professionnel de santé, mais selon une variante d'implémentation on pourrait utiliser deux compteurs distincts dans le bracelet : l'un pour sécuriser les protocoles Praticien-Patient et l'autre pour sécuriser les protocoles Patient-Professionnel de santé.
Selon un premier mode de réalisation de l'invention, la carte SIM peut utiliser une ou plusieurs variables représentatives de l'état du document pour éviter notamment sa réémission. Selon un exemple, on utilise un ou plusieurs drapeaux, en anglais flag(s), qui peuvent prendre des valeurs binaires (0 ou 1) correspondant à deux valeurs distinctes de la tension électrique de la mémoire EEPROM de l'élément de sécurité (le changement d'état entre deux valeurs étant géré par le logiciel) associé à Ye.prescription : ce flag est par exemple initialisé à 1 et remis à 0 lorsqu'il est activé. Ces flags servent à indiquer les différents états de Ye.prescription (annulée, remise, non remise, etc.). Selon le contexte et le type de document, on pourrait envisager d'autres états.
Selon ce mode de réalisation, afin de gérer plusieurs e. prescriptions dans le bracelet, reçues d'un ou plusieurs praticiens, l'état de la prescription est géré dans l'application sécurisée (APS) qui s'exécute dans la carte SIM ; par exemple, un numéro d'ordre chronologique est choisi par l'application sécurisée pour la e. prescription, qui peut se trouver dans un des trois états suivants, par exemple gérés par trois flags fl à f3 : • « reçue non remise » ; le flag fl est mis à jour au cours de l'étape E14b ; ce flag est appelé « variable de réception » ;
• « annulée » ; le flag f2 est mis à jour au cours de l'étape E14c si la demande d'annulation est effectuée ; · « remise » ; le flag f3, appelé aussi « variable de réémission », est mis à jour au cours de l'étape E21. Lorsque la prescription est remise, il n'est plus possible de rejouer un échange de prescription avec un professionnel de santé, par contre il est possible de restituer les données dans l'état de la remise, dans la mesure où elles n'ont pas été effacées. On notera que, pour que la prescription soit annulée par le patient dans la carte SIM, elle doit être annulée avant sa remise au professionnel de santé donc il ne doit pas être possible de restituer les données signées dans l'état annulé (dans ce cas les données n'ont pas été signées par l'élément de sécurité).
On notera également que, si pour une raison quelconque, les données de la remise sont perdues ou corrompues pendant le transfert (c'est un cas peu probable mais très gênant) il doit être possible de récupérer les données du transfert dans la carte SIM.
Ce mode de réalisation basé sur la gestion du document via les flags fl à f3 apporte des améliorations dans la sécurité et la gestion d'un document électronique par rapport à l'état de l'art, qui n'empêche pas la réémission éventuelle ou le rejeu de \'e. prescription :
- il permet l'annulation par le patient d'une prescription ;
- il permet la gestion dans la carte SIM de plusieurs e. prescriptions, par exemple lorsque la mémoire EEPROM de la SIM allouée à l'application est pleine, les nouvelles ^..prescriptions pourront prendre la place de celles qui ont été remises ou annulées, de préférence les plus anciennes.
Au cours d'une seconde phase, le patient M se trouve chez le professionnel de santé (le Pharmacien) P. Il présente son bracelet au lecteur NFC associé au terminal de traitement du professionnel. Un certain nombre d'étapes s'ensuit dans le but d'assurer une communication sécurisée entre le bracelet et le terminal de traitement du professionnel de santé.
Lors d'une étape E15, les identifiants IDM et CPTM du patient sont transmis au professionnel qui les reçoit lors d'une étape E30 et répond lors d'une étape suivante E31 en transmettant ses propres identifiants IDP et CPTP ainsi que sa clé publique PK et un message signé en utilisant sa clé privée SKP comportant les identifiants du professionnel et les identifiants préalablement reçus du patient. Ce message est noté : IDP, CPTp, PKp, SP = {IDp, CPTP , IDM, CPTM }SKP
Le bracelet reçoit ce message lors d'une étape E16 puis en teste la validité lors d'une étape E17, à l'aide de la clé publique PKP qu'il vient de recevoir ; il vérifie la validité de la signature SP du message. Si le résultat de vérification est correct, cela signifie que la signature a bien été émise par le professionnel, et donc qu'il est correctement identifié.
Puis lors d'une étape E18, le bracelet calcule une signature SM = {IDM, CPTM, IDp, CPTp, So}SKM à l'aide de sa clé SKM.
Lors de l'étape E19, un message est transmis en champ proche depuis le bracelet jusqu'au professionnel. Ce message, comprenant \'e. prescription, sa signature, les clés publiques et un message signé en utilisant sa clé privée SKM, est noté :
O, So, PKM, PKD , SM = {IDM, CPTM, IDP, CPTP, SO}SKM
Le compteur de prescriptions CPTM est incrémenté lors d'une étape E20 suivante. L'étape E20 a pour but la mise à jour du compteur CPTM de l'objet portable, qui est utilisé pour générer la signature électronique SM. On notera que la mise à jour de ce compteur n'empêche pas la réémission du message si l'algorithme est mis en œuvre une seconde fois pour la même e. prescription, mais que dans ce cas la signature SM sera différente de celle obtenue lors de la première mise en œuvre. De ce fait, ce mécanisme prévient le rejeu de \' e.prescription.
L'étape E21 a pour but la mise à jour du flag f3 (correspondant à l'état « e.prescription remise »), interdisant la réémission de V e.prescription qui vient d'être transférée, comme il a été expliqué précédemment.
On notera que ces variables peuvent aussi être remises à jour avant le transfert des données.
Dans le mode de réalisation décrit ci-dessus, les e. prescriptions restent en mémoire de l'objet portable. Cependant, si l'un des flags f2 ou f3 est activé (c'est à dire à la valeur binaire 0), cela signifie que V e.prescription peut être écrasée par l'arrivée d'une nouvelle e.prescription, ou effacée par le système d'exploitation (CPU) de l'objet.
Selon un autre mode de réalisation de l'invention, le.prescription est effacée de la mémoire EEPROM de l'élément de sécurité lors de l'étape Ε2 . V! e.prescription étant effacée, il n'est plus possible de calculer une nouvelle signature à l'étape E18. Selon ce mode de réalisation, l'étape E21 de modification du flag de réémission (f3) n'est plus nécessaire car la réémission sera rendue impossible par cet effacement. La modification des flags fl et f2 devient également optionnelle car seules restent en mémoire de l'objet les e. prescriptions reçues et non émises. On notera que l'effacement peut être total ou partiel, il suffit par exemple de supprimer les premières données de l'e. prescription pour rendre impossible le calcul de la signature et de ce fait une nouvelle émission. Le terminal de traitement du professionnel de santé reçoit les données lors d'une étape E32.
Puis lors d'une étape E33, ce terminal teste la validité du message reçu, à l'aide de la clé publique PKM qu'il a reçue ; il vérifie la validité de la signature du message. Si le résultat de vérification est correct, cela signifie que la signature a bien été émise par l'objet du patient.
Puis lors d'une étape E34, le terminal de traitement du professionnel de santé teste la validité de la signature So, à l'aide de la clé publique PKD du praticien D, qu'il a reçue il vérifie la validité S0 de la signature du message. Si le résultat de vérification est correct, cela signifie que l'e. prescription est authentique.
Le compteur du professionnel de santé CPTP est incrémenté lors d'une étape E35 suivante. L'e. prescription est traitée lors d'une étape E36 suivante (délivrance de médicament, acte de kiné, etc.)
Au cours d'une troisième phase, le professionnel de santé P, qui vient de traiter \'e. prescription, la transmet au serveur (7) de l'organisme de santé, via un moyen de communication quelconque, par exemple sur un réseau Internet. Un certain nombre d'étapes s'ensuit dans le but d'assurer une communication sécurisée entre le terminal de traitement du professionnel de santé et le serveur de l'organisme de santé.
Le message est préparé lors d'une étape E36. Ce message est noté :
0, So, PKp, PKD, Sp = {PKp, PKS, DD, So...} SKP Lors de l'étape E37, le message est transmis à l'organisme de santé.
Il est traité par l'organisme de santé au cours des étapes E40 à E43 : les étapes E41 et E42 correspondent à la vérification du message reçu et de la signature So de Ye.prescription. Si le message est correctement déchiffré, cela signifie que les données envoyées par le professionnel de santé sont authentiques et en particulier :
- que Ye.prescription est authentique ;
- qu'elle a été traitée par un professionnel de santé correctement authentifié ; La base de données de l'organisme de santé peut être remise à jour lors d'une étape E43.
Il va de soi que le mode de réalisation qui a été décrit ci-dessus a été donné à titre purement indicatif et nullement limitatif, et que de nombreuses modifications peuvent être facilement apportées par l'homme de l'art sans pour autant sortir du cadre de l'invention.
Notamment, elle peut être généralisée à tout échange de documents similaire à celui de la prescription médicale.
Par exemple, on peut envisager sans perte de généralités d'appliquer l'invention à un système d'assurance automobile dans lequel l'utilisateur est un assuré, le praticien est un expert en assurance automobile fournissant un diagnostic des dégâts, le garage jouant le rôle du professionnel.
Ce système pourrait aussi s'appliquer à tout système d'assurance (habitation, ...) nécessitant l'intervention des trois acteurs précédemment cités : l'utilisateur, l'expert et le professionnel.

Claims

Revendications
1. Procédé d'hébergement d'un document électronique (0) sur un objet portable sécurisé (1) pour accéder à un service, ledit document électronique ayant été généré par un terminal de génération (TD) et devant être traité par un terminal de traitement (TP), le procédé comportant les étapes suivantes dans l'objet :
- une étape (E12) de réception d'un document électronique (0) et d'une signature (So) dudit document électronique (0) ;
- une étape d'obtention (E12) de la clé publique (PKD) du terminal de génération (TD) complémentaire d'une clef privée (SKD) du terminal de génération (TD), et d'une signature (SD) dudit terminal de génération (TD);
- une étape d'obtention (E16) de la clé publique (PK ) du terminal de traitement (TP) complémentaire d'une clef privée (SKP) du terminal de traitement (TP) et d'une signature (SP) dudit terminal de traitement (TP);
- une étape (E13) d'authentification du terminal de génération à l'aide de ladite clef publique (PKD) du terminal de génération ;
- une étape (E17) d'authentification du terminal de traitement à l'aide de ladite clef publique (PKP) du terminal de traitement ;
- si les deux étapes d'authentification sont réussies :
• une étape (E18) de génération d'un message comportant au moins :
- le document électronique (0) et sa signature (So) ;
- La clé publique (PKD) du terminal de génération (TD) ; - La clé publique (PKM) de l'objet complémentaire d'une clef privée (SKM) de l'objet ;
- une signature (SM) signée par la clé privée (SKM) de l'objet ;
- une étape (E19) d'émission dudit message vers le terminal de traitement. - une étape (E21, Ε2 ) de modification d'une donnée relative audit document électronique afin de prévenir une autre émission dudit document.
2. Procédé d'hébergement d'un document électronique selon la revendication 1, caractérisé en ce que l'étape de modification d'une donnée (E21) est une étape de modification d'une variable booléenne, dite variable de réémission (f3), dont l'état est représentatif de l'émission dudit document.
3. Procédé d'hébergement d'un document électronique selon la revendication 1, caractérisé en ce que en ce que l'étape de modification d'une donnée (Ε2 ) est une étape d'effacement du document électronique dans la mémoire de l'objet portable.
4. Procédé d'hébergement d'un document électronique (0) selon la revendication 1, caractérisé en ce que l'étape (E13) d'authentification du terminal de génération est suivie d'une étape de modification (E14b) d'une variable booléenne, dite variable de réception (fl), dont l'état est représentatif de la réception dudit document.
5. Procédé d'hébergement d'un document électronique selon la revendication 1, caractérisé en ce qu'il comporte en outre une étape d'annulation (E14c) du document.
6. Procédé d'hébergement d'un document électronique selon la revendication 1, caractérisé en ce que l'objet comporte en outre un compteur (CPTM) du nombre de présentations de documents électroniques, en ce que la signature (SM) signée par la clé privée (SKM) de l'objet est fonction de ce compteur et en ce qu'il comporte une étape de modification dudit compteur après chaque étape de signature.
7. Procédé selon l'une des revendications précédentes, caractérisé en ce que le document électronique est une prescription médicale dématérialisée.
8. Procédé selon l'une des revendications précédentes, chacune des clés publiques (PKD, PKP, PKM) étant certifiée par une même entité de certification (6).
9. Objet portable (1) pour l'hébergement d'un document électronique (0) pour accéder à un service, ledit document électronique ayant été généré par un terminal de génération (TD) et devant être traité par un terminal de traitement (TP), l'objet portable comportant :
- un module (CLF) de réception d'un document électronique (0) et d'une signature (So) dudit document électronique (0) ;
- un module d'obtention (CLF) de la clé publique (PKD) du terminal de génération (TD) complémentaire d'une clef privée (SKD) du terminal de génération (TD), et d'une signature (SD) dudit terminal de génération (TD);
- un module d'obtention (CLF) de la clé publique (PK ) du terminal de traitement (TP) complémentaire d'une clef privée (SKP) du terminal de traitement (TP) et d'une signature (SP) dudit terminal de traitement (TP);
- un module (SE, APS) d'authentification du terminal de génération à l'aide de ladite clef publique (PKD) du terminal de génération ;
- un module (SE, APS) d'authentification du terminal de traitement à l'aide de ladite clef publique (PKP) du terminal de traitement ;
- un module (APS) de génération d'un message comportant au moins :
- le document électronique (0) et sa signature (So) ;
- La clé publique (PKD) du terminal de génération (TD) ;
- La clé publique (PKM) de l'objet complémentaire d'une clef privée (SKM) de l'objet ;
- une signature (SM) signée par la clé privée (SKM) de l'objet ;
- un module (CLF) d'émission dudit message vers le terminal de traitement
- un module (SE, CPU) apte à modifier une donnée relative audit document électronique afin de prévenir une autre émission dudit document
10. Objet portable sécurisé (1) selon la revendication 9, caractérisé en ce que le module d'obtention est un module de communication en champ proche (CLF).
11. Objet portable sécurisé (1) selon la revendication 9, caractérisé en ce que le module de transmission est un module de communication en champ proche (CLF).
12. Objet portable sécurisé (1) selon la revendication 9, caractérisé en ce que le module d'authentification est une carte électronique d'abonné (SIM).
13. Procédé de traitement pour transmettre un document électronique (0) d'un terminal de traitement (TP) vers un serveur de traitement (7), ledit document électronique provenant d'un terminal de génération et étant stocké sur un objet portable, le procédé de traitement comportant les étapes suivantes sur le terminal de traitement :
- une étape (E32) de réception d'un document électronique (0) et d'une signature (So) dudit document électronique (0) ;
- une étape d'obtention (E32) de la clé publique (PKM) complémentaire d'une clef privée (SKM) de l'objet portable (1), et d'une signature (SM) dudit objet portable (1) ;
- une étape d'obtention (E32) de la clé publique (PKD) du terminal de génération ;
- une étape (E33) d'authentification de l'objet portable à l'aide de ladite clef publique (PKM) de l'objet ;
- une étape (E34) d'authentification du terminal de génération à l'aide de ladite clef publique (PKD) du terminal de génération ;
- si les deux étapes d'authentification sont réussies :
· une étape (E36) de génération d'un message comportant au moins :
- le document électronique (0) et sa signature (So) ;
- La clé publique (PKD) du terminal de génération (TD) ;
- La clé publique (PKP) du terminal de traitement (TD) ; - une signature (SP) signée par la clé privée (SK ) du terminal de traitement.
• une étape (E37) de transmission dudit message vers un serveur de traitement des documents électroniques.
14. Procédé de gestion d'un document électronique hébergé sur un objet portable sécurisé (1) pour accéder à un service, ledit document électronique ayant été généré par un terminal de génération (TD) et devant être traité par un terminal de traitement (TP) et stocké sur un serveur de gestion (7), le procédé comportant les étapes suivantes sur le serveur de gestion (7) :
- réception (E40) d'un message en provenance du serveur de traitement, ledit message comprenant :
- le document électronique (0) et sa signature (So) ;
La clé publique (PKD) du terminal de génération (TD) ; La clé publique (PK ) du terminal de traitement (TP) ;
- une signature (S ) signée par la clé privée (SKP) du terminal de traitement ;
- authentification (E41) du terminal de traitement à l'aide de ladite clef publique (PKP) du terminal de traitement (TP) ;
- authentification (E42) du terminal de génération à l'aide de ladite clef publique (PKD) du terminal de génération ;
- si les deux étapes d'authentification sont réussies, une étape (E43) de stockage du message sur le serveur de gestion (7).
15. Programme d'ordinateur comportant des instructions de code pour la mise en œuvre du procédé d'hébergement conforme à la revendication 1, lorsque celle-ci est exécutée par un processeur.
PCT/FR2017/051682 2016-06-27 2017-06-23 Sécurisation de documents électroniques Ceased WO2018002491A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1655945A FR3053142A1 (fr) 2016-06-27 2016-06-27 Securisation de documents electroniques
FR1655945 2016-06-27

Publications (1)

Publication Number Publication Date
WO2018002491A1 true WO2018002491A1 (fr) 2018-01-04

Family

ID=58992908

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2017/051682 Ceased WO2018002491A1 (fr) 2016-06-27 2017-06-23 Sécurisation de documents électroniques

Country Status (2)

Country Link
FR (1) FR3053142A1 (fr)
WO (1) WO2018002491A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030121972A1 (en) 2001-02-16 2003-07-03 Lee Seung Kuk System for providing medical service using electronic cards and a method thereof

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030121972A1 (en) 2001-02-16 2003-07-03 Lee Seung Kuk System for providing medical service using electronic cards and a method thereof

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"HBA_Spezifikation _Teil2_V2 1 0 Einführung der Gesundheitskarte Heilberufs-Ausweis und Security Module Card", 28 May 2006 (2006-05-28), pages 1 - 144, XP055152508, Retrieved from the Internet <URL:http://www.dkgev.de/pdf/1436.pdf> [retrieved on 20141112] *
GEMATIK: "Heilberufs-Ausweis und Security Module Card Einführung der Gesundheitskarte Heilberufs-Ausweis und Security Module Card", 28 May 2006 (2006-05-28), XP055384190, Retrieved from the Internet <URL:http://www.dkgev.de/pdf/1435.pdf> [retrieved on 20170622] *
GEMATIK: "Speicherstrukturen der eGK für Gesundheitsanwendungen", 18 March 2008 (2008-03-18), XP055383826, Retrieved from the Internet <URL:https://www.gematik.de/cms/media/dokumente/release_0_5_3/release_0_5_3_egk/gematik_eGK_Speicherstrukturen_V1_6_0.pdf> [retrieved on 20170621] *

Also Published As

Publication number Publication date
FR3053142A1 (fr) 2017-12-29

Similar Documents

Publication Publication Date Title
JP2011517354A (ja) ファイルの配信および購入を行うためのシステムおよび方法
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&#39;ordinateur correspondants
WO2013079848A1 (fr) Protocole d&#39;authentification mutuelle d&#39; entitees ayant prealablement initie une transaction en ligne
EP3758322A1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
WO2002097751A1 (fr) Procédé et dispositif de certification d&#39;une transaction
EP3542335B1 (fr) Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant
EP2053553A1 (fr) Procédé et dispositif pour l&#39;échange de valeurs entre entités électroniques portables personnelles
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
WO2018002491A1 (fr) Sécurisation de documents électroniques
EP2808819B1 (fr) Procédé de mise à jour de certificats dans un dispositif portable
EP2795830B1 (fr) Procede d&#39;echange de donnee chiffree entre un terminal et une machine
FR3073998B1 (fr) Procede numerique de controle d&#39;acces a un objet, une ressource ou service par un utilisateur
WO2014135519A1 (fr) Système et procédé de gestion d&#39;au moins une application en ligne, objet portable utilisateur communiquant par un protocole radioélectrique et dispositif distant du système
WO2017077210A1 (fr) Procédé de verification d&#39;identité lors d&#39;une virtualisation
WO2017005644A1 (fr) Procédé et système de contrôle d&#39;accès à un service via un média mobile sans intermediaire de confiance
FR3133463A1 (fr) Dispositif portable et autonome de sécurisation de transfert de données et procédé correspondant.
FR3003058A1 (fr) Systeme et procede de gestion d’au moins une application en ligne, objet portable utilisateur usb et dispositif distant du systeme
CA2285642A1 (fr) Procede de certification d&#39;un cumul dans un lecteur
EP4348459A1 (fr) Procédé de traitement d&#39;une transaction, dispositif et programme correspondant
WO2025125562A1 (fr) Procédé d&#39;authentification d&#39;un individu pour la mise en œuvre d&#39;une transaction sur un terminal marchand
FR3101991A1 (fr) Système et méthode d&#39;authentification et d&#39;assurance d’objets
FR2990818A1 (fr) Procede de transfert et de stockage securise de documents et appareils associes au procede.
FR2971109A1 (fr) Systeme biometrique de verification de l&#39;identite avec un signal de reussite, cooperant avec un objet portatif
WO2006056667A1 (fr) Certificat de cle publique pour le transport d&#39;information confidentielle

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: 17745792

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: 17745792

Country of ref document: EP

Kind code of ref document: A1