FR3053142A1 - Securisation de documents electroniques - Google Patents

Securisation de documents electroniques Download PDF

Info

Publication number
FR3053142A1
FR3053142A1 FR1655945A FR1655945A FR3053142A1 FR 3053142 A1 FR3053142 A1 FR 3053142A1 FR 1655945 A FR1655945 A FR 1655945A FR 1655945 A FR1655945 A FR 1655945A FR 3053142 A1 FR3053142 A1 FR 3053142A1
Authority
FR
France
Prior art keywords
terminal
electronic document
signature
public key
generation
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.)
Pending
Application number
FR1655945A
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
Priority to FR1655945A priority Critical patent/FR3053142A1/fr
Priority to PCT/FR2017/051682 priority patent/WO2018002491A1/fr
Publication of FR3053142A1 publication Critical patent/FR3053142A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR 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; CALCULATING OR 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

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 d'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, \'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 Γ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 Y 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 (l'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 1'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 (SKP) 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 Serial 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 l'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 Y e.prescription, le patient présente son support électronique au professionnel de santé, celui-ci récupère les données de Y 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 d'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 l'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 EO 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 SKj 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 (CPT,) qui lui sont propres, notées respectivement : IDd, CPTd pour le praticien ; IDm, CPTm pour le patient ; IDP, 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 N FC 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é :
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 O, et le terminal calcule une signature de l'ordonnance So, sous la forme :
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 l'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é :
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 l'e. 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 Y e.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 Ye.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 e.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 PKP et un message signé en utilisant sa clé privée SKf» comportant les identifiants du professionnel et les identifiants préalablement reçus du patient. Ce message est noté :
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 PKf» 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,
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é :
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 I'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 1'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, l'e.prescription est effacée de la mémoire EEPROM de l'élément de sécurité lors de l'étape E21'. L'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é :
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 Γe.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 Γe.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 (15)

  1. Revendications
    1. Procédé d'hébergement d'un document électronique (O) 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 (O) et d'une signature (So) dudit document électronique (O) ; - une étape d'obtention (E12) de la dé publique (PKd) du terminal de génération (TD) complémentaire d'une clef privée (SKo) 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 (PKp) 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, E210 de modification d'une donnée relative audit document électronique afin de prévenir une autre émission dudit document.
  2. 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. 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 (E21') est une étape d'effacement du document électronique dans la mémoire de l'objet portable.
  4. 4. Procédé d'hébergement d'un document électronique (O) 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. 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. 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. 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. 8. Procédé selon l'une des revendications précédentes, chacune des clés publiques (PKq, PKp, PKM) étant certifiée par une même entité de certification (6).
  9. 9. Objet portable (1) pour l'hébergement d'un document électronique (O) 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 (O) et d'une signature (So) dudit document électronique (O) ; - un module d'obtention (CLF) de la clé publique (PKo) du terminal de génération (TD) complémentaire d'une clef privée (SKo) du terminal de génération (TD), et d'une signature (SD) dudit terminal de génération CTD); - un module d'obtention (CLF) de la clé publique (PKp) 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 (PKq) 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 (O) et sa signature (So) ; - La clé publique (PKo) 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. 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. 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. 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. 13. Procédé de traitement pour transmettre un document électronique (O) 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 (O) et d'une signature (So) dudit document électronique (O) ; - 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 (PKq) du terminal de génération ; - une étape (E33) d'authentification de l'objet portable à l'aide de ladite def publique (PKm) de l'objet ; - une étape (E34) d'authentification du terminal de génération à l'aide de ladite clef publique (PKo) 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 (O) et sa signature (So) ; - La clé publique (PKo) du terminal de génération (TD) ; - La dé publique (PKp) du terminal de traitement (TD) ; - une signature (SP) signée par la clé privée (SKP) du terminal de traitement. • une étape (E37) de transmission dudit message vers un serveur de traitement des documents électroniques.
  14. 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 (O) et sa signature (So) ; La clé publique (PKD) du terminal de génération (TD) ; La clé publique (PKp) du terminal de traitement (TP) ; une signature (SP) 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 (PKo) 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. 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.
FR1655945A 2016-06-27 2016-06-27 Securisation de documents electroniques Pending FR3053142A1 (fr)

Priority Applications (2)

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

Applications Claiming Priority (1)

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

Publications (1)

Publication Number Publication Date
FR3053142A1 true FR3053142A1 (fr) 2017-12-29

Family

ID=58992908

Family Applications (1)

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

Country Status (2)

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

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010044394A (ko) 2001-02-16 2001-06-05 이승국 전자카드를 이용한 전자처방전달 방법 및 그 장치

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
WO2018002491A1 (fr) 2018-01-04

Similar Documents

Publication Publication Date Title
EP0763803B1 (fr) Système de comptabilisation anonyme d&#39;informations à des fins statistiques, notamment pour des opérations de vote électronique ou de relevés périodiques de consommation
JP2011513839A (ja) 無線による金銭取引を行うためのシステムおよび方法
EP2048814A1 (fr) Procédé d&#39;authentification biométrique, programme d&#39;ordinateur, serveur d&#39;authentification, terminal et objet portatif correspondants.
EP1908215A1 (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
WO2007012583A1 (fr) Procede de controle de transactions securisees mettant en oeuvre un dispositif physique unique, dispositif physique, systeme, et programme d&#39;ordinateur correspondants
CA2421850C (fr) Procede et dispositif de certification d&#39;une transaction
EP3163487A1 (fr) Procédé de sécurisation de traitement de données transactionnelles, terminal et programme d&#39;ordinateur correspondant
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
FR3035248A1 (fr) Systeme-sur-puce a fonctionnement securise et ses utilisations
EP3542335B1 (fr) Procédé de traitement de données transactionnelles, terminal de communication, lecteur de cartes et programme correspondant
WO2018002491A1 (fr) Sécurisation de documents électroniques
EP2053553A1 (fr) Procédé et dispositif pour l&#39;échange de valeurs entre entités électroniques portables personnelles
FR3002056A1 (fr) Authentification de signature manuscrite numerisee.
EP2795830B1 (fr) Procede d&#39;echange de donnee chiffree entre un terminal et une machine
WO2015107175A1 (fr) Méthode de transmission de données chiffrées, méthode de réception, dispositifs et programmes d&#39;ordinateur correspondants
EP3371760A1 (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
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
WO2022254002A1 (fr) Procédé de traitement d&#39;une transaction, dispositif et programme correspondant.
WO2023170186A1 (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
FR3007929A1 (fr) Procede d&#39;authentification d&#39;un utilisateur d&#39;un terminal mobile
CA2285642A1 (fr) Procede de certification d&#39;un cumul dans un lecteur
FR3101991A1 (fr) Système et méthode d&#39;authentification et d&#39;assurance d’objets
FR2971109A1 (fr) Systeme biometrique de verification de l&#39;identite avec un signal de reussite, cooperant avec un objet portatif

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20171229